INGRCJSP (AOFRSD01)
Purpose
You can use the INGRCJSP automation routine for JES2 spool recovery processing. It responds to JES2 spool shortage messages by initiating the recovery process for JES2 spool shortage. It responds to JES2 spool full messages by initiating the recovery process for JES2 spool full to downgrade the problem of excessive spool usage.
The INGRCJSP routine does the following:
- Makes linear and first order predictions of spool usage, based on actual and historical values.
- Posts the spool status to the status display facility (SDF).
- Determines the target of recovery processing as the difference between the actual warning threshold for track groups and the buffer value from the configuration file. The spool shortage condition is considered as relieved if the recovery process achieves this target.
- Initiates pass processing to execute the recovery commands of the configuration file, as defined with the JES2 SPOOLSHORT or JES2 SPOOLFULL policy item. The pass processing itself is done by the AOFRSD09 automation routine, which is issued every retry interval. The retry interval is taken from the configuration file.
You define recovery commands and configuration parameters for JES2 recovery processing, such as buffer value and retry interval, using automation policy item JES2 SPOOLSHORT for spool shortage recovery processing and JES2 SPOOLFULL for spool full recovery processing.
For further information about the JES2 SPOOLSHORT and JES2 SPOOLFULL automation policy items see IBM Z® System Automation Defining Automation Policy.
INGRCJSP should be called from the NetView automation table.
Syntax
Restrictions
- Processing in INGRCJSP is only done if it is called from NetView automation table by JES2 messages HASP050 or HASP355.
- Message HASP355 is only processed if it reports a shortage of track groups (TG).
Usage
HASP050 JES2 RESOURCE SHORTAGE OF TGs - nnn% UTILIZATION REACHED
HASP355 SPOOL VOLUMES ARE FULLHASP050
indicates that JES2 has a shortage of track groups and the current spool utilization exceeds the
current TGWARN value on this JES. TGNWARN is defined in the SPOOLDEF statement in the JES
initialization member and can be changed dynamically. HASP355 indicates that a request for JES2 direct access spool space cannot be processed because all available space has been allocated to JES2 functions or no spool volumes are available. Therefore the recovery targets in this case are based on a figure of 100% spool utilization.
You should code TGWARN in the SPOOLDEF statement in the JES initialization member so that SPOOLSHORT recovery is initiated before a SPOOLFULL condition is reached. If you do not do this the recovery process may become unpredictable.
When resetting after a SPOOLFULL condition, the problem is downgraded to a SPOOLSHORT condition. SA z/OS expects the SPOOLSHORT recovery that was previously running to activate and try to downgrade the problem to an OK. Without the prior SPOOLSHORT recovery, the spool status remains in SPOOLSHORT after a successful SPOOLFULL recovery.
The NetView automation table entries for JES2 messages must respect the one character prefix in front of the message identifier of JES2 messages that identifies the issuing JES.
The spool status is posted to SDF under the SPOOL generic, with the name of the subsystem as its specific name. To have these displayed on an SDF panel, you need status fields for xxxx.SPOOL, elements 1 through n, where n is the number of different subsystems that use the spool.
