ICFs are PUs in a CPC configured to run only CFCC code. The PUs are not shipped with a fixed function assignment, but are assigned during power-on reset (POR) or later non-disruptively by on demand offerings such as: CBU, CUoD, CIU, ON/OFF CoD.

Those offerings allow the customer to convert, in seconds, a non-characterizable PU in any PU personality type such as: CPU, ICF, IFL, zAAP, zIIP and SAP.

An ICF can reduce the cost of exploiting coupling facility technology because:

• ICFs are less expensive than CPs.
• An ICF has a special software license charge. Special PR/SM microcode prevents the defined ICF PUs from executing non-CFCC code such as z/OS.

Notes:

CBU – Capacity BackUp

CFCC – Coupling Facility Control Code

CIU – Customer Initiated Upgrade

CoD – Capacity on Demand

CP – Central Processor

CPC – Central Processor Complex

CPU – Central Processor Unit

CUoD – Capacity Upgrade on Demand

ICF – Internal Coupling Facility

IFL – Integrated Facility for Linux

POR – Power-On Reset

PR/SM – Processor Resource/System Manager

PU – Processor Units

SAP – System Assistance Processor

zAAP – z Application Assist Processor

zIIP – z Integrated Information Processor

A coupling facility is a special logical partition that runs the coupling facility control code (CFCC) and provides high-speed caching, list processing, and locking functions in a sysplex.

HCD enables you to specify whether a logical partition can be a coupling facility, operating system, or either on certain processors. You connect the coupling facility logical partition to a processor through the coupling facility channels.

With z/OS services, a component called XES allows authorized applications, such as subsystems and z/OS components, to use the coupling facility to cache data, exchange status, and access sysplex lock structures in order to implement high performance data sharing and rapid recovery from failures.

The coupling facility is defined using HCD and PR/SM panels. Once you have defined an LP to be a coupling facility, only the coupling facility control code can run in that LP. When you activate the coupling facility LP, the system automatically loads the CFCC from the support element (an internal laptop) of the CPC.

Implementing a coupling facility in your sysplex requires both hardware and software:

• CPC that supports the CFCC.
• CPCs on which one or more z/OS images run and which are capable of connecting to the coupling facility with CF links.
• Appropriate level of z/OS that allows an exploiter to access a desired function when managing the coupling facility resources.
• CFCC must implement the functions the exploiter needs.

Notes:

CF – Coupling Facility

CFCC – Coupling Facility Control Code

CPC – Central Processor Complex

HCD – Hardware Configuration Definition

LP – Logical Partition

PR/SM – Processor Resource/System Manager

XES – Cross-system Extended Services

External Time Reference hardware facility (ETR) is the generic name for IBM Sysplex Timer.

The ETR architecture provides the means of synchronizing TOD clocks in different CPCs with a centralized time reference, which in turn can be set accurately on the basis of UTC time standard (External Time Source). The architecture defines a time-signal protocol and a distribution network (called the ETR network) that permits accurate setting, maintenance, and consistency of TOD clocks.

Notes:

CPC – Central Processor Complex

TOD – Time of Day

UTC – Coordinated Universal Time

The cross-system coupling facility (XCF) component of z/OS manages communications between applications in a sysplex. XCF services allow authorized programs in a sysplex to communicate with programs on the same MVS system or other MVS systems. If a system fails, XCF services also provide the capability for batch jobs and started tasks to be restarted on another eligible system in the sysplex.

z/OS XCF allows up to 32 z/OS systems to communicate in a sysplex.

A catalog describes data set attributes and indicates the volumes on which a data set is located.

When a data set is cataloged, it can be referred to by name without the user needing to specify where the data set is stored. Data sets can be cataloged, uncataloged, or recataloged. All system-managed DASD data sets are cataloged automatically in a catalog.

Cataloging of data sets on magnetic tape is not required, but doing so can simplify users’ jobs.

In z/OS, the Master Catalog and User Catalogs store the locations of data sets. Both disk and tape data sets can be cataloged. To find a data set that you have requested, z/OS must know three pieces of information:

-    Data set name

-    Volume name

-    Unit (the volume device type, such as a 3390 disk or 3590 tape)

You can specify all three values on ISPF panels or in JCL. However, the unit device type and the volume are often not relevant to an end user or application program. A system catalog is used to store and retrieve UNIT and VOLUME location of a data set. In its most basic form, a catalog can provide the unit device type and volume name for any data set that is cataloged. A system catalog provides a simple look-up function. With this facility the user need only provide a data set name.

Master Catalog and User Catalog

A z/OS system always has at least one Master Catalog. If it has a single catalog, this catalog would be the Master Catalog and the location entries for all data sets would be stored in it. A single catalog, however, would be neither efficient nor flexible, so a typical z/OS system uses a master catalog and numerous User Catalogs connected to it.

A User Catalog stores the name and location of a data set (dsn/volume/unit). The master catalog usually stores only a data set High-Level Qualifier (HLQ) with the name of the user catalog, which contains the location of all data sets prefixed by this HLQ. The HLQ is called an alias.

As a general rule, all user data sets in a z/OS installation are cataloged. Uncataloged data sets are rarely needed and their use is often related to recovery problems or installation of new software. Data sets created through ISPF are automatically cataloged.

Batch processing is a method of running a program or a series of programs in which one or more records (a batch) are processed with little or no action from the user or operator.

A program that reads a large file and generates a report, for example, is considered to be a batch job.

To enable the processing of a batch job, z/OS professionals use Job Control Language (JCL) to tell z/OS which programs are to be executed and which files will be needed by the executing programs.

JCL allows the user to describe certain attributes of a batch job to z/OS, such as:

-    Who the user is (the submitter of the batch job)

-    What program to run

-    Where input and output are located

-    When a job is to run

After the user submits the job to the system, there is normally no further human interaction with the job until it is complete.

z/OS initialization, or an Initial Program Load (IPL), is the act of loading a copy of the operating system from disk into the processor’s real storage and executing it.

This process essentially consists of:

-    System and storage initialization, including the creation of system component address spaces

-    Master scheduler initialization and subsystem initialization

z/OS systems are designed to run continuously with many months between reloads, allowing important production workloads to be continuously available. Changes are the usual reason for a reload, and the level of changes on a system dictates the reload schedule.

Bear in mind that:

-    A test system may be IPLed daily or even more often.

-    A high-availability system (from a bank for example), may only be reloaded once a year, or even less frequently, to refresh the software levels.

-    Outside influences may often be the cause of IPLs, such as the need to test and maintain the power systems in the machine room.

-    Sometimes faulty software uses up system resources that can only be replenished by an IPL. This sort of incident is normally the subject of investigation and correction so that it does not happen again.

Shutting down the system usually requires a single command, which results in the removal of most tasks except for the automation task itself. The automation task is closed manually, followed by any commands needed to remove the system from a Sysplex or serialization ring.