Consider the new default value for the LOADxx DYNCPADD keyword that indicates how many CPUs z/OS is prepared to dynamically add

Description

Before z/OS V2R1, through PARMLIB member LOADxx you could enable that CPUs be added to the configuration over the life of the IPL if the hardware supported such addition. The default was for all CPUs that could be configured to the LPAR, which was the minimum supported by the z/OS release (for example, 100) and the machine (for example, 80), and which could be asked for explicitly by DYNCPADD ENABLE. In z/OS V2R1, the LOADxx keyword DYNCPADD now supports a 1-4 character decimal value nnnn that indicates how many CPUs z/OS is able to dynamically add over the life of the IPL. The default has changed to 16.

Table 1 provides more details about this migration action. Use this information to plan your changes to the system.

Table 1. Information about this migration action
Element or feature: BCP.
When change was introduced: z/OS V2R1.
Applies to migration from: z/OS V1R13.
Timing: Before the first IPL of z/OS V2R2.
Is the migration action required?

Yes, if the LOADxx DYNCPADD value is omitted (defaulted) and the default number of CPUs (16) z/OS will be able to dynamically add over the life of the IPL is not sufficient.

Recommended, if you specify DYNCPADD ENABLE, which provides maximum flexibility but also results in maximum storage usage and overhead.

Target system hardware requirements: All system z hardware (z10 EC/BC and later hardware) that supports dynamic CPU addition.
Target system software requirements: None.
Other system (coexistence or fallback) requirements: When specifying the maximum number of CPs that z/OS can dynamically add with LOADxx DYNCPADD nnnn, this LOADxx cannot be shared with pre-V2R1 systems; that is, the nnnn parameter of DYNCPADD is not recognized by pre-V2R1 systems.
Restrictions: None.
System impacts: Specifying DYNCPADD nnnn or taking the DYNCPADD 16 default allows z/OS to determine the number of CPUs that z/OS must be prepared to be dynamically added for the life of the IPL. Because z/OS can know the maximum CPU id that can be dynamically added for the life of the IPL at IPL, z/OS can obtain CPU array related storage based on the maximum number of CPUs that can be activated for the life of the IPL.
Related IBM® Health Checker for z/OS® check: None.

Steps to take

Follow these steps:
  1. If the default limit of 16 CPUs that can be dynamically added is not sufficient, then indicate on your LOADxx DYNCPADD the number you desire. The maximum number of CPUs that can be added over the life of the IPL will be capped by the minimum between the highest CPU id hardware and the z/OS release supports.
  2. Review the changed messages associated with two digit CP IDs. Update any necessary automation or operator procedures to accommodate the two digits. Before z/OS V2R1, there was only one digit used for CP IDs. The messages that will now contain 2 byte CP ids are the following:
    • BLW007W MULTIPLE ACR ATTEMPTS BY CPU id
    • IEA020W AN FRR STACK POINTER FOR CPU xxxx IS DAMAGED, THE ERROR MASK IS abcdefghijklmnopqrst
    • IEA796E ACR HAS TAKEN CPU x [LOGICALLY] OFFLINE BECAUSE text
      text inserts that are updated include:
      • CPU x CHECKSTOPPED.
      • CPU x REACHED ITS vv MACHINE-CHECK THRESHOLD.
      • CPU x'S TOD CLOCK COULD NOT BE SYNCHRONIZED.
      • CPU x'S CLOCK COULD NOT BE SYNCHRONIZED TO THE ETR
    • IEE178I AUTOMATIC RECOVERY IS IN PROGRESS. NO OPERATOR ACTION IS REQUIRED.
      • [PROCESSOR (y) DETECTED AN EXCESSIVE DISABLED SPIN LOOP WAITING FOR event FROM PROCESSOR (x)]
      • [An event OCCURRED WHEN PROCESSOR (y) TRIED TO SIGNAL PROCESSOR (x)]
    • IEE331A PROCESSOR (y) IS IN AN EXCESSIVE DISABLED SPIN LOOP WAITING FOR event. REPLY U OR SPIN TO CONTINUE SPIN, REPLY ABEND TO TERMINATE WORK ON PROCESSOR (x) WITH RETRY REPLY TERM TO TERMINATE WORK ON PROCESSOR (x) WITHOUT RETRY OR STOP PROCESSOR (x) AND REPLY ACR
    • ISN011I CPU nnnn HAS BEEN ADDED

Reference information

For more information, see the following references: