RRS_Storage_NumLargeLOGBlks

Description:

Monitor the level of virtual storage usage in the RRS address space to prevent a terminating failure.

Reason for check:

If the count of large log buffer blocks in RRS grows too big then RRS might encounter a terminating failure.

z/OS® releases the check applies to:

z/OS V1R7 and later.

User override of IBM values:

The following sample shows the defaults for customizable values for this check. Use this sample to make permanent check customizations in an HZSPRMxx parmlib member used at IBM Health Checker for z/OS startup. If you just want a one-time only update to the check defaults, omit the first line (ADDREPLACE POLICY) and use the UPDATE statement on a MODIFY hzsproc command. Note that using non-POLICY UPDATEs in HZSPRMxx can lead to unexpected results and is therefore not recommended. End of change

ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]
UPDATE
CHECK(IBMRRS,RRS_STORAGE_NUMLARGELOGBLKS)
ACTIVE
SEVERITY(HI),INTERVAL(0:05),DATE('date_of_the_change')
PARM('1000')
REASON('Your reason for making the update.')

Parameters accepted:

The threshold for number of large message blocks in use by RRS; in the range of '0' to '99999999'. The threshold for number of transaction related blocks in use by RRS; in the range of '0' to '99999999'. The default is '1000'.

Debug support:

Verbose support:

Reference:

For more information, see z/OS MVS Programming: Resource Recovery.

Messages:

This check issues the following exception messages:

ATRH020E

See the ATRH messages in z/OS MVS System Messages, Vol 3 (ASB-BPX).

SECLABEL recommended for multilevel security users:

SYSLOW - see z/OS Planning for Multilevel Security and the Common Criteria for information on using SECLABELs.

Ouptut:

ATR020E - The current number of large log buffer blocks in RRS
is currblks which exceeds current threshold of maxblks
 
Explanation: The number of large message blocks being processed
within RRS at this time has exceeded the threshold specified in
the health check.  This can be an indication of a potential
storage usage failure in RRS.
 
System Program Response:
Use the available RRS data collection techniques (panels,
console display command, or batch program) to assess the level
of transaction activity in RRS and determine if it is unusual or
unexpected.
 
If the level of activity is determined to be a problem then use
the data collection methods to determine if it is a problem with
a specific work manager then check with that work manager
function for problems.
 
If not a work manager problem then use the data collection
methods to determine if it is a problem with a specific resource
manager.
 
If it appears to be neither a specific work manager nor a
specific resource manager problem then monitor RRS using this
health check until either the exception is resolved or the count
continues to grow.