gtpm6m0p | Main Supervisor Reference |
System alerts consist of 2 functions:
Entries that loop without relinquishing control are removed from the system by the application loop timeout mechanism. However, entries that relinquish control in an indefinite loop are detected by the long-life ECB detection program.
This detection does not occur automatically for all ECBs. Each ECB is created with its CE1LML (maximum permitted lifetime) field set to X'FF', which prevents long-life detection. To enable long-life detection for any given entry, the application program must issue the LONGC macro.
When a long-life entry (in other words, a looping entry) is detected, message ECBL01 is sent to the operator. The operator can request that a looping ECB be scheduled to EXIT by use of the ZECBL command with the E parameter (ZECBL E). The ECB address specified on the ZECBL E command must be a system virtual address. If a looping ECB that is scheduled to exit by ZECBL E command is dispatched again it is exited with system error dump number 0000D3.
If a looping entry scheduled to exit by the ZECBL E command does not exit in 1 minute, it is determined to be hung; it has lost control and will not be dispatched again (possibly waiting for an event that will never occur). Hung ECBs cannot be removed from the system, but message ECBL01 is sent to the operator whenever a new hung entry is detected.
The ZECBL command can be used to display all looping and hung entries, or to display an individual entry. The information provided by ZECBL D includes the ECB address, program name and address, PSW address, wait count, record hold count and maximum, and current ECB lifetime.
The time-initiated alerts function provides system operators with the capability of automatically starting system functions and maintaining operator communications. The operator adds a message to the time-initiated message table by specifying when the message is to be started and, optionally, the destination of the message. For example, if a user performs disk capture at a particular time every day, a message to remind the operator at the DASD functional support console to start the capture is put into the time-initiated message table. If a system function such as displaying pool counts periodically is required, the command to display pool counts is put into the table.
The contents of the table are controlled by the operator; there are options in the command support to add a message, display a single message or all the messages, delete a message from the table, and reinitialize the table.
The operator can add time-initiated messages or stage-initiated messages to the table. A time-initiated message is one that is initiated at a specified time. Stage-initiated messages are processed during periods of system operation when time cannot be used to control the processing. System stages have been defined to identify these periods:
Messages are processed when a stage is entered or when a stage is left.
The time-initiated message table is a fixed file record (FACS record type #TIMRI); there are no overflow records. The record size is variable and is determined by the user based on estimates of how many messages will be in the table at any one time, and the lengths of the messages. The table record has a 28-byte header, and each message in the table record has an 18-byte header. The table record is defined in the DSECT macro TI0MT.
In a loosely coupled complex, there is 1 record per processor; the record ordinal number is the same as the processor ordinal number. In a multiple database function system, there is 1 record associated with each subsystem. It is not necessary for records to be allocated for all subsystems in the system. The records must be allocated at system generation time by coding the appropriate RAMFIL macros. If the records are not allocated, it is assumed that the time-initiated alerts function is not active, and processing is not performed for it.
The command is ZSTIM. The add, display, cancel, and reinitialize options are described in detail in TPF Operations.