Questions have arisen requesting details on SO15901, written for Common Services for z/OS r15.0 to prevent a potential CAIRIM overlay. Although categorized as a hyper, customers are not sure if it applies to their environment and if they should apply it.
Fix defined as a HYPER due to the potential to overlay storage beyond the originally allocated storage. Storage is allocated once during the initial execution of CAS9 (CAIRIM).
• Impact of the overlay is the unknown
• Times when no adverse symptoms witnessed
• Other times when the system was adversely impacted
• As with all overlays, results are unpredictable and difficult to identify
Common Services for z/OS running on a z/OS image with more than 64 (x'40') processors
Common Services for z/OS r15.0
Client was configuring on and off large numbers of CPU's (much larger than 64). The problem arises from the counts in the following fields returned from the CSCRI function.
1 SI22V2TotalLCPUCount Current total CPUs
2 SI22V2ConfiguredLCPUCount Configured CPUs
3 SI22V2StandbyLCPUCount Standby CPUs
4 SI22V2ReservedLCPUCount Reserved CPUs
5 SI22V2DedicatedLCPUCount Shared CPUs
6 SI22V2SharedLCPUCount Shared CPUs
How the CPU information is used by CAIRIM not easily explained.
• Code design has existed for many years (>16 yrs)
• Problem just recently reported by a single customer
• CPU information not really used for any functionality within CCS or any CA MF product
Fix written in 2 parts
Please refer to the Common Services for z/OS r15.0 for details on the CAIRIM(REFRESH(LMP)) Initialization Statement