CP The processor purchased and activated supporting the z/OS, z/VSE, VSE/ESA™, z/VM, TPF, and Linux operating systems. Can also run Coupling Facility Control Code (CFCC). A CP can also be configured to run as an SAP.

Capacity marked CP A processor purchased for future use as a CP is marked as available capacity. It is offline and unavailable for use.

Note: The size of the HSA on the z9 EC may be significantly larger than on a z990 or z890 system. It may range from less than 2 GB to up to 4.5 GB for a fully configured system.  Especially for systems with relatively small memory sizes, caution is requested. IBM recommends using the HSA Estimator for z9 EC, available on Resource Link, to be able to plan for a sufficient amount of memory.

Unassigned IFL A processor purchased for future use as an IFL. It is offline and unavailable for use.

ICF A processor purchased and activated for use by the Coupling Facility Control Code (CFCC).

zAAP A processor purchased and activated to run Java code under control of z/OS JVM2.

zIIP A processor purchased and activated for z/OS V1R8 and later to run eligible workloads (DB2).

Additional SAP The optional System Assist Processor (SAP) is a processor that is purchased and activated for use as an SAP.  A Capacity Marker identifies that a certain number of CPs have been purchased. This number of purchased CPs is higher than the number of CPs actively used. The Capacity Marker marks the availability of purchased but unused capacity intended to be used as CPs in the future; they usually have this status for software charging reasons. Unused CPs do not count in establishing the MSU value to be used for MLC software charging, or when charged on a per processor basis.

Unassigned IFLs are purchased IFLs with the intention to be used as IFLs, and usually have this status for software and maintenance charging reasons. Unassigned IFLs do not count in establishing the charge for either z/VM or Linux.

This method prevents RPQ handling in case a temporary downgrade is required. When the capacity need arises, the marked CPs and unassigned IFLs can be assigned nondisruptively.

Concurrent CP, IFL, ICF, zAAP, or zIIP upgrades are done within a z9 EC model. Concurrent upgrades require PU spares. PU spares are PUs that are not the two standard spares but those PUs that are not characterized as a CPs, IFLs, ICFs, zAAPs, zIIPs, or SAPs.

If the upgrade request cannot be accomplished within the given configuration, an upgrade is required. An upgrade will cause the addition of one or more books to accommodate the desired capacity. Additional books can be installed concurrently.

Upgrades from one z9 EC configuration to another are concurrent and mean that one or more books are added. However, there is an exception. Upgrades from any z9 EC model up to a Model S38 to a z9 EC Model S54 is disruptive since this upgrade requires a full book replacement. Table 2-9 shows the possible upgrades within the z9 EC configuration range.

Upgrades from any z900 to any z9 EC server are supported (with the exception of the z900 model 100, which can only can be upgraded to another z900 model). Upgrades from any z990 to any z9 EC server are supported.  There are no upgrade paths to the z9 EC from either z800 models or z890 models. Upgrades from a z9 BC Model xxx to a z9 EC Model S08 are available. Table 2-10 shows the upgrade paths to a z9 EC.

A minimum of one PU characterized as a CP, IFL, or ICF is required per system. The maximum number of CPs is 54, the maximum number of IFLs is 54, and the maximum number of ICFs is 16. The maximum number of zAAPs amounts to 27 but requires an equal number of characterized CPs. Even so the maximum number of zIIPs amounts to 27 and requires an equal number of characterized CPs. The sum of all zAAPs, and zIIPs cannot be larger than two times the number of characterized CPs.  Not all PUs on a given model are required to be characterized. Only purchased PUs are identified by a feature code.

Assigned CPs, assigned IFLs, unassigned IFLs, ICFs, zAAPs, and zIIPs may be converted to other assigned or unassigned feature codes. Valid conversions are:

Most listed conversions are nondisruptive. In exceptional cases the conversion may be disruptive, for example, when a z9 EC Model S08 with eight CPs is converted to an all IFL system. In addition, a logical partition may be disrupted when PUs must be freed before they can be converted. Conversion information is summarized in Table 2-11.

In order to recognize how many PUs are characterized as a CP, the STSI instruction returns a value that can be seen as a model capacity identifier that determines the number and speed of characterized CPs. Characterization of a PU as an IFL, an ICF, a zAAP or a zIIP is not reflected in the output of the STSI instruction, since they have no effect on software charging.

Four distinct model capacity identifier ranges are recognized.

The z9 EC offers 24 additional capacity settings at the low end of the processor. Only 8 CPs can have granular capacity. When sub-capacity settings are used, other PUs can only be characterized as specialty engines.

Three ranges of granular sub-capacity settings are defined. They have model capacity identifiers numbered from 401 to 408, 501 to 508, and 601 to 608.

Table 2-12 shows that regardless of the number of books, a configuration with one characterized CP is possible; for example, a z9 EC Model S54 may have only one PU characterized as a CP.

All model capacity identifiers have a related MSU value that is used to determine the software license charge for MLC software. Table 2-13 and Table 2-14 on page 72 show MSU values for each model capacity identifier.

CBU deliver temporary backup capacity on top of what an installation might have installed in numbers of assigned CPs, IFLs, ICFs, zAAPs, zIIPs, and additional SAPs.

When CBU for CP is added within the same capacity setting range as the currently assigned PUs, the total number of active PUs (the sum of all assigned CPs, IFLs, ICFs, zAAPs, zIIPs, and additional SAPs) plus the number of CBU cannot exceed the total number of PUs available in the system.

When CBU for CP capacity is acquired by switching from one capacity setting to another, no more CBU can be requested than the total number of PUs available for that capacity setting.

There is a distinction between five CBU types:

1. CBU for CP

   • CBU for CP7, feature code 7820.

   • CBU for CP6, feature code 7819.

   • CBU for CP5, feature code 7818.

   • CBU for CP4, feature code 7817.

2. CBU for IFL, feature code 7821.

3. CBU for ICF, feature code 7822.

4. CBU for zAAP, feature code 7824.

5. CBU for zIIP, feature code 7825.

Specialty engines (ICFs, IFLs, zAAPs, and zIIPs) always run at full capacity. When CBU for CP is needed, features 7820, 7819, 7818, or 7817 can be ordered to provide backup capacity.  CBU for CP is ordered by specifying both, a number of CPs and a model capacity identifier. Table 2-15 shows the MSU values for subcapacity models.

The following should be taken into account when considering CBU for CP capacity:

When the CBU feature matches the model capacity identifier range of the permanent CP feature, the CBU activation results in the total number of CPs active equaling the number of permanent CPs plus the number of CPs added for CBU. For example, when a z9 EC with model capacity identifier 504 is ordered two CPs for CBU, the CBU configuration, when activated becomes a z9 EC at capacity identifier 506; see Example 2-1.  When the CBU configuration is activated, the server capacity will grow from 197 to 279 MSUs, as shown in Table 2-15.

When the CBU results in a cross over from one capacity identifier range to another, the CBU features no longer specifies an addition to the number of CPs but rather, the total number of CPs that will make up the configuration when the CBU is activated. The total number of CPs when the CBU is activated is equal to the number of CPs ordered for CBU.

For example, when a z9 EC with model capacity identifier 504 specifies a CBU with six CP6, the CBU server being activated will have model capacity identifier 606. When the CBU configuration is activated, the server capacity will grow from 197 to 339 MSUs.

A cross-over from one CP range to another does not necessarily imply that the number of CPs will increase for the CBU configuration. For example, a model capacity identifier 504 can have a CBU to model capacity identifier 704. In this case, there is no increase in the number of CPs. When the CBU configuration is activated, the server capacity will grow from 197 to 298 MSUs.

• Temporary capacity must be greater than permanent capacity.

• Temporary capacity cannot be more than double the permanent capacity.

• On/Off CoD cannot decrease the number of engines on the server.

• It is not possible to add more engines than are currently owned.