System z Hardware – Capacity on Demand

1. System z Hardware – Capacity on Demand • Bob Neidig • System z Executive Technology Consultant • zAtlas Team Member • RACE Core Team Member • AG zChampions Technical Lead • neidig@us.ibm.com 1-914-766-2853 IBM System z z10 EC z10 BC

2. Evolution Scalability and virtualization to reduce cost and complexity Improved efficiency to further reduce energy consumption Improved security and resiliency to reduce risk New heights in storage scalability and data protection Revolution 4.4 GHz chip to deliver improved performance for CPU intensive workloads ‘Just in time’ deployment of capacity resources Vision to expand System z capabilities with Cell Broadband Engine™ technology Introducing the IBM System z10™ Enterprise Class (z10™ EC) … A marriage of evolution and revolution

3. z10 CoD Offerings • On-line Permanent Upgrade • Permanent upgrade performed by customer (previously referred to Customer Initiated Upgrade - CIU) • Capacity Backup (CBU) • For disaster recovery • Concurrently add CPs, IFLs, ICFs, zAAPs, zIIPs, SAPs • Pre-paid • Capacity for Planned Event (CPE) • To replace capacity for short term lost within the enterprise due to a planned event such as a facility upgrade or system relocation • Predefined capacity for a fixed period of time (3 days) • Pre-paid • On/Off Capacity on Demand (On/Off CoD) • Production Capacity • Supported through software offering – Capacity Provisioning Manager (CPM) • Payment: • Post-paid or Pre-paid by purchase of capacity tokens • Post-paid with unlimited capacity usage • On/Off CoD records and capacity tokens configured on Resource Link • Customer Initiated Upgrade (CIU) • Process/tool for ordering temporary and permanent upgrades via Resource Link • Permanent upgrade support: • Un-assignment of currently active capacity • Reactivation of unassigned capacity • Purchase of all PU types physically available but not already characterized • Purchase of installed but not owned memory

4. On demand simplifiedNew architectural approach for capacity Orders downloaded from System Support electronically or by IBM Service SE Hard Drive Customer defined policy or manual operations Capacity Provisioning Manager * HMC APIquery, activate, deactivate • Enforce terms and conditions • Enforce physical model limitations Authorization Layer • Up to 4 temporary capacity offerings • Each record represents an individual offering • Customer assigns in any combination R1 R2 R3 R4 Dormant Capacity CIU - CBU – On/Off CoD – CPE • Base model • Change permanent capacity via MES order Permanent Capacity * Capacity Provisioning available with z/OS v1.9

5. Capacity Provisioning - ESP Customer Feedback

6. z10 – Basics of CoD Capacity on Demand Permanent Upgrade Temporary Upgrade Billable Capacity (On/Off CoD) Replacement Capacity CBU CPE Pre-paid Post-paid On/Off CoD with tokens 180 days expiration Capacity - MSU % - # Engines Tokens - MSU days - Engine days Using pre-paid unassigned capacity up to the limit of the HWM No expiration Capacity - MSU % - # Engines On/Off CoD with tokens No expiration Capacity - MSU % - # Engines Tokens - MSU days - Engine days On/Off CoD 180 days expiration Capacity - MSU % - # Engines

7. z10 CoD – Removal of limitations • A permanent upgrade cannot occur while CBU or On/Off CoD is active • Only one solution can be active at a time • Either CBU or On/Off Capacity on Demand • A disaster (CBU) could occur while On/Off CoD is active • Limited to the permanent capacity • After a permanent capacity upgrade, the old temporary contract may become useless • Cannot add temporary capacity while a Concurrent Book Add is in progress (z10 EC) • Need for a CBU-like offering where a disaster is not involved • When On/Off CoD or CBU records were activated/deactivated, all processors defined in those records must be activated/deactivated • The HMC requires connectivity to the IBM Support System to obtain temporary records or verify passwords at the time of activation • HMC connectivity or response time is a potential inhibitor • The process to activate/deactivate On/Off CoD can take too long • Software Billing needs to be able to determine which capacity is permanent versus temporary

8. Resources can be activated in any amount up to defined limit Customer can customize activation real-time, based on circumstances Eliminates unique record to be managed for all possible permutations Dynamic changes in activation level without reloading records As records expire or are consumed, the resources will be deactivated System will not reduce to sub capacity when records expire Will not deactivate if removing dedicated engines or last of that engine type Various record limits can be dynamically updated / replenished Changes possible even if record is currently active Ability to perform permanent upgrades while temporary capacity is active Allows quick conversion of temporary capacity to permanent Pre-paid resource consumption and capacity liability capping done at the server API enhancements to support use by Capacity Provisioning Manager Capacity Provisioning Manager provides policy based automation z10 CoD – New architecture

9. z10 CoD – Key Enhancements • All offering records are resident on machine • No connection or passwords required at time of activation • Records are changed only when customer places order for new / updated offering • Multiple records can be simultaneously active • Each has independent controls and policy • Each can be activated / deactivated in any sequence • Individual record can be used to temporarily reach multiple configurations • Customer determines level of resources activation real time based on circumstances (i.e. multiple use for a single On/Off CoD record, even during a permanent upgrade) • All movement between configurations is concurrent • More flexibility to configure offering limits • Ability to perform upgrades while temporary resources are active • Modification of record entitlement performed dynamically and concurrently • “Capacity Provisioning Manager” provides policy based advice and automation

10. Capacity on Demand Comparisons – z9 vs z10

11. z10 CoD Provisioning Architecture Orders downloaded from Retain/media to SE hard drive Customer defined policy or user commands CPM (z/OS 1.9 or higher) Manual operations API HMC application Query Activation * Only one On/Off CoD record can be active Enforce Terms and Conditions and physical model limitations Authorization Layer Up to 8 records installed and active on the System and up to 200 records staged on the SE R1* R2* R3* R4* R5* R6* R7* R8* Dormant Capacity CBU – CPE – On/Off CoD Base Model Change permanent capacity via CIU or MES order Purchased Capacity

12. Replenishments z10 COD Elements of the Offerings Time Elements Tokens Resources Order process limits Machine limits Contract terms and conditions

13. Offering Parameters – 3 ways of handling • Resources • Limit the amount of a particular resource that can be activated • Absolute number which represents maximum resource entitlement • Activation to resource limits may not be achieved depending on current configuration • e.g. #CPs, #IFLs, #Capacity levels • Time Elements • Limit the length of time that the record can be active; full or partial (applies to all record types) • All time limits are measured in days or calendar date • Absolute number which represents maximum time entitlement • e.g. Number of days in test, Number of days in real activation, calendar date • Tokens • Means of controlling ‘spending’ limits for On/Off CoD • Consumable – record updated each 24 hours to reflect consumption level • Values are treated as incremental delta to the current token level • e.g. number of tests, number of real activations • MSU days (for CPUs) / processor days (for specialty engines) • NOTE: Negative updates to these limits are not allowed

14. z10 Resources, Time elements and Tokens Summary

15. z10 Capacity Back Up – CBU Resources CP Capacity Features Specialty engines: zIIP, zAAP, ICF, IFL, SAP Time elements Test duration = 10 days Real activation = 90 days 2 day grace period Expiration date set to 1 through 5 years Tokens Number of Tests = 5 (default) Up to 15 can be ordered Number of Real activations = 1 • Order process limits • Total CP Capacity features = number of net new engines + number of permanent engines changing capacity level • No limit to the resources ordered • Number of zIIPs or zAAPs can not exceed total number of permanent + temporary CPs • No more than 15 tests per record • Machine limits • Can not decrement capacity level • Can not remove permanent engines from configuration • No Tests while in Real activation • No Tests if number of Real activations equals zero • Auto deactivation of activated resources upon time limit • If any resource can not be removed all resources stay active • Ability to remove resources checked every 24 hours. • Contract terms and conditions • To be used only for replacement capacity within an enterprise • Priced for H/W. No additional IBM S/W charges

16. CBU Comparison – z9 versus z10

17. z10 Capacity for Planned Event Resources CP Capacity Features Specialty engines: zIIP, zAAP, ICF, IFL, SAP Time elements Test duration = NA Real activation = 3 days No grace period No Expiration date Tokens Number of Tests = 0 Number of Real activations = 1 • Order process limits • No more than 1 real activation per record • Machine limits • Can not decrement capacity level • Can not remove permanent engines from configuration • Auto deactivation of activated resources upon time limit • If any resource can not be removed all resources stay active • Ability to remove resources checked every 24 hours • All dormant resources are available for use during the activation • Contract terms and conditions • To be used only for replacement capacity within an enterprise • Priced for H/W use BUT like CBU, no additional IBM S/W charges

18. z10 Capacity for Planned Event (1) • Replacement Capacity • Replaces lost capacity within a customer’s enterprise for planned down time events • Push/Pull planned outages • Planned Data Center moves and relocations • CP capacity details are NOT managed by feature codes • Any available and dormant resources may be used • Normal specialty engine rules are not managed/enforced for activation • For example, • One CP required for each zIIP and zAAP (1 zIIP + 1 zAAP per 1 CP permitted) • Not enforced

19. z10 On/Off Capacity on Demand Resources CP Capacity % MSU Specialty engines: zIIP, zAAP, ICF, IFL, SAP Time elements Test duration = NA Real activation = Unlimited 1 hr grace period Expiration date set to 180 days Tokens Number of Tests = 0 Number of Real activations = Unlimited MSU days. Limit Tokens: MSU days, per type Specialty Engines day • Order process limits • Temporary CP capacity up to 100% or purchased capacity using MSU rating as metric • Number of temporary zIIPs or zAAPs can not exceed total number of permanent + temporary CPs • Number of temporary IFLs up to the total of purchased IFLs • Number of temporary ICFs plus permanent ICFs not to exceed 16 • Machine limits • Can not decrement capacity level. Positive increase in speed steps (processor speed) required • Can not remove permanent engines from configuration • Positive increase in MSUs with temporary activations • Contract terms and conditions • H/W and S/W charges • Allows 1 x 24 Hour test record per machine registered

20. z10 On/Off CoD Terms Definition • Billing Window • 24 hour billing period • billing is done based on peak usage of resources within this period • billing is done at the end of each billing window • Activation Period • Consists of one or more full billing windows • Time from first activation of any resource of a record until the end of the billing window where the last resource of this record was deactivated • Grace Period • Grace time at beginning and end of each billing window to protect customer from being charged for an entire billing window if he increases the activation levels a little too early or deactivates his resources a little too late • Default set to 60 minutes per order process – but could be any other number • 1 hour after start of billing window: post-grace-period • 1 hour prior end of billing window: pre-grace-period • Attention! No grace period at start of first billing window in an activation period !!

21. System z10 Capacity on Demand Summary Note: Upgrades are nondisruptive only where there is sufficient hardware resource available and provided pre-planning has been done * Additional terms and conditions apply

22. System z Capacity Resource Availability by Server * Not supported for some memory upgrades Note: Upgrades are nondisruptive only where there is sufficient hardware resource available and provided pre-planning has been done

23. Learning Points – System z Capacity on Demand • On-line Permanent Upgrade • Permanent upgrade performed by customer (previously referred to Customer Initiated Upgrade - CIU) • Capacity Backup (CBU) • For disaster recovery • Concurrently add CPs, IFLs, ICFs, zAAPs, zIIPs, SAPs • Pre-paid • Capacity for Planned Event (CPE) • To replace capacity for short term lost within the enterprise due to a planned event such as a facility upgrade or system relocation • Predefined capacity for a fixed period of time (3 days) • Pre-paid • On/Off Capacity on Demand (On/Off CoD) • Production Capacity • Supported through software offering – Capacity Provisioning Manager (CPM) • Payment: • Post-paid or Pre-paid by purchase of capacity tokens • Post-paid with unlimited capacity usage • On/Off CoD records and capacity tokens configured on Resource Link • Customer Initiated Upgrade (CIU) • Process/tool for ordering temporary and permanent upgrades via Resource Link • Permanent upgrade support: • Un-assignment of currently active capacity • Reactivation of unassigned capacity • Purchase of all PU types physically available but not already characterized • Purchase of installed but not owned memory

24. zEND Thank you ! Bob Neidig neidig@us.ibm.com