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
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
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
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