The quantity of temporary CP capacity ordered is limited by the quantity of purchased CP capacity (permanently active plus unassigned)

The quantity of temporary IFLs ordered is limited by quantity of purchased IFLs (permanently active plus unassigned)

Temporary use of unassigned CP capacity or unas- signed IFLs will not incur a hardware charge

The quantity of permanent zIIPs plus temporary zIIPs can not exceed the quantity of purchased (permanent plus unassigned) CPs plus temporary CPs and the quantity of temporary zIIPs can not exceed the quantity of permanent zIIPs

The quantity of permanent zAAPs plus temporary zAAPs can not exceed the quantity of purchased (permanent plus unassigned) CPs plus temporary CPs and the quantity of temporary zAAPs can not exceed the quan- tity of permanent zAAPs

The quantity of temporary ICFs ordered is limited by the quantity of permanent ICFs as long as the sum of perma- nent and temporary ICFs is less than or equal to 16

The quantity of temporary SAPs ordered is limited by the quantity of permanent SAPs as long as the sum of per- manent and temporary SAPs is less than or equal to 32

Although the System z10 BC will allow up to eight tempo- rary records of any type to be installed, only one tempo- rary On/Off CoD record may be active at any given time. An On/Off CoD record may be active while other tempo- rary records are active.

Management of temporary capacity through On/Off CoD is further enhanced through the introduction of resource tokens. For CP capacity, a resource token represents an amount of processing capacity that will result in one MSU of SW cost for one day – an MSU-day. For specialty engines, a resource token represents activation of one engine of that type for one day – an IFL-day, a zIIP-day or a zAAP-day. The different resource tokens are contained in separate pools within the On/Off CoD record. The

customer, via the Resource Link ordering process, deter- mines how many tokens go into each pool. Once On/Off CoD resources are activated, tokens will be decremented from their pools every 24 hours. The amount decremented is based on the highest activation level for that engine type during the previous 24 hours.

Resource tokens are intended to help customers bound the hardware costs associated with using On/Off CoD. The use of resource tokens is optional and they are available on either a prepaid or post-paid basis. When prepaid, the customer is billed for the total amount of resource tokens contained within the On/Off CoD record. When post-paid, the total billing against the On/Off Cod record is limited by the total amount of resource tokens contained within the record. Resource Link will provide the customer an ordering wizard to help determine how many tokens they need to purchase for different activation scenarios. Resource tokens within an On/Off CoD record may also be replenished.

Resource Link offers an ordering wizard to help determine how many tokens you need to purchase for different acti- vation scenarios. Resource tokens within an On/Off CoD record may also be replenished. For more information on the use and ordering of resource tokens, refer to the Capacity on Demand Users Guide, SC28-6871.

Capacity Provisioning

Hardware working with software is critical. The activation of On/Off CoD on z10 EC can be simplifi ed or automated by using z/OS Capacity Provisioning (available with z/OS V1.10 and z/OS V1.9). This capability enables the monitor- ing of multiple systems based on Capacity Provisioning and Workload Manager (WLM) defi nitions. When the defi ned conditions are met, z/OS can suggest capacity changes for manual activation from a z/OS console or the system can add or remove temporary capacity automatically and with- out operator intervention. z10 BC Can Do IT better.

43

Page 43
Image 43
IBM Z10 BC manual Capacity Provisioning