A fix is available
APAR status
Closed as program error.
Error description
When running z/OS 2.5, the SRM algorithm that performs SQA shortage processing is never run. This results in: - RSM'S RPB compression routine not being called - ENF 4 never being issued - messages IRA100E IRA101E IRA102I IRA103I and IRA104I never being issued. The ENF 4 not being issued can result in an increase in ESQA usage due to MMSB control blocks not being freed.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All users of z/OS 2.5 (HBB77D0). * **************************************************************** * PROBLEM DESCRIPTION: * * When running z/OS 2.5, the SRM algorithm that performs SQA * * * * shortage processing is never run. This results in: * * * * - RSM'S RPB compression routine not being called * * * * - ENF 4 never being issued * * * * - messages IRA100E IRA101E IRA102I IRA103I and IRA104I never * * * * being issued. * * * * * * * * The ENF 4 not being issued can result in an increase in ESQA * * * * usage due to MMSB control blocks not being freed. * * * **************************************************************** * RECOMMENDATION: * **************************************************************** With z/OS 2.5 APAR OA61240, algorithms are only scheduled when running under the SRM timer pop. The intent of the change was to prevent timed algorithms from running on a vertical low processors and holding the SRM lock for a prolonged period of time. This change resulted in the SQA algorithm never running on a z/OS 2.5 system. Prior to the change, the IRARMSQA algorithm in IRARMST3 could get called either when running under the SRM timer pop or from internal sysevent processing. In order for the algorithm to only run periodically, the intent was for the algorithm not to run but to only get rescheduled when the routine got called from internal sysevent processing. However, the check to determine which path to take was not correct, so instead of running the algorithm when running under a timer pop, the algorithm is getting rescheduled. This results in the SQA algorithm always being rescheduled and never being run on a z/OS 2.5 system.
Problem conclusion
IRARMST3 has been updated to properly run the IRARMSQA algorithm when running under the SRM timer pop. Since IRARMSQA should now only get control when running under the timer pop, the path to reschedule the algorithm is no longer used.
Temporary fix
Comments
APAR Information
APAR number
OA63906
Reported component name
SRM - SYS RSRCE
Reported component ID
5752SC1CX
Reported release
7D0
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2022-10-07
Closed date
2022-11-10
Last modified date
2022-12-05
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UJ09603
Modules/Macros
IRARMST3 IRARMCTL
Fix information
Fixed component name
SRM - SYS RSRCE
Fixed component ID
5752SC1CX
Applicable component levels
R7D0 PSY UJ09603
UP22/11/23 P F211
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M"},"Platform":[{"code":"PF054","label":"z Systems"}],"Version":"7D0"}]
Document Information
Modified date:
05 December 2022