RRS_Storage_NumTransBlks

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 transactions that RRS is managing 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 shows the default keywords for the check, which you can override on either a POLICY statement in the HZSPRMxx parmlib member or on a MODIFY command. This statement may be copied and modified to override the check defaults:

UPDATE
    CHECK(IBMRRS,RRS_STORAGE_NUMTRANSBLKS)
    ACTIVE
    SEVERITY(HI),INTERVAL(0:05),DATE('date_of_the_change')
    PARM('10000')
    REASON('Your reason for making the update.')

Parameters accepted:

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

Debug support:

Verbose support:

Reference:

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

Messages:

This check issues the following exception messages:

ATRH014E

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.

Ouptput:

ATR014E The current number of active RRS transactions is
currtrans which exceeds the current threshold of maxtrans
 
Explanation:
The number of transactions being managed by RRS at the current
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.