Monitor exceptions

DFS3258A LAST OLDS IS BEING USED--NEED ARCHIVE

In addition to sending an ALERT to the STATUS/EXCEPTION display an EXEC can issue a /DIS OLDS command to capture the status on the Journal log and then allocate an extra Online Log Data Set, if available.

DFS0845I xxxxxxxx DATASET LIMIT REACHED, DDNAME= yyyyyyyy

An EXEC can respond to IMS message, DFS0845I, by issuing the /BROADCAST or MVS SEND commands to broadcast a warning to the MVS console and the database staff when a database is full.

DSNM002I IMS xxxx DISCONNECTED FROM SUBSYSTEM yyy, RC=rc

When DB2 is down, an EXEC can send an ALERT to the STATUS/EXCEPTION display with an interpretation of the return code. Or, the DBA for DB2 can be notified if DB2 terminated abnormally.

DFS0769I SELECTIVE DISPATCHING - resource

In response to this message, an ALERT can be sent to the STATUS/EXCEPTION display. /DIS POOL DCC and /DIS QUEUE commands can be issued to capture the status on the Journal log. MainView for IMS plots of the pools, SAPs, and transaction arrival rates can be written to the Image log.

RM xxxxW or WM xxxxW -- MainView for IMS monitor warnings

These messages are written when a user-specified threshold defining a resource (such as input queue length) or workload (such as response time) exception is exceeded. The text of the message defines the condition, and both the measured value and the threshold are available for analysis. RM xxxxW and WM xxxxW denotes when the threshold is exceeded and RM xxxxI and WM xxxxI denotes when the ALERT no longer exists.

Sometimes direct action will be possible, such as starting another message region. Very often, it would be valuable to have the EXEC log Performance Management displays, such as pools, scheduling, queuing, or program isolation (PI), to the Image log for exception condition analysis. This captures system status at the time of the exception.

Another possibility is to start new monitors to gather more detailed information, which will then be available for online viewing when analyzing the exception. For example, in response to the message AVG RESP TIME BY TRANS (TOTAL), send an ALERT to the STATUS/EXCEPTION display and start MainView for IMS monitors to collect response time by class.

Key exception values, such as response time, can also be saved in global variables for use in other EXECs. The RM xxxxI or WM xxxxI message, which indicates that a warning condition no longer exists, can be used to reset the global variable or, delete a warning on the STATUS/EXCEPTION display.

IMS security violation message

In response to a violation, an EXEC can lock that node.

RWARN -- route ALERTs to Global Screen

If operations is monitoring several systems, you might want to set up one global ALERT screen to show exceptions from all systems. An EXEC can be written to route the ALERT to a remote systems and that remote system can post the ALERT to a global ALERT screen.

Ensure that MSDBs are loaded at startup

You can write an EXEC to ensure that required MSDBs are successfully loaded at startup. The EXEC will issue a /DIS DB command for all required MSDBs. The command responses returned to the Journal will be identified by a format identifier (FID) of D03.

An EXEC named D03 can check the status of each MSDB to ensure that it is available as all the response segments are returned within the same EXEC and can be accessed via local variables LINE1 through LINE x. If not, a warning message can be sent to the STATUS/EXCEPTION display or, if necessary, IMS can be brought down immediately with the appropriate /CHE command.

DBRC warning messages

To ensure that a DBRC warning message such as DFS485W RECOVERY DATA FOR dbxyz might BE MISSING FROM RECON is not overlooked at the console, write an EXEC that sends a message to the STATUS/EXCEPTION display.

You can write another EXEC that verifies periodically that a spare RECON is available. Do this by issuing the DBRC command /RML DBRC='RECON STATUS' and capturing the response line that is identified with RECON3. Then check this line for the word SPARE.

DSNM004I RESOLVE INDOUBT ENTRY(S) ARE OUTSTANDING FOR SUBSYSTEM xxxx

In response to the DSNM004I message, an EXEC can issue the following command to display the INDOUBT entries:

/SSR -DISPLAY THREAD * TYPE INDOUBT

The EXEC submits the jobs IMSINDBT and DB2INDBT. This message can be sent to the Operations Supervisor, the IMS DBA, the DB2 DBA, and the IMS and DB2 systems programmers. It can also be sent to the STATUS/EXCEPTION display, colored in red with an alarm.

Note: IMS and DB2 databases may be out of sync. This condition occurred at hh.mm.ss on yyddd. Check the output of the display thread command on the Journal log for the thread(s) involved. Check the output of job IMSINDBT for the X'5501FE' records written to the IMS Log for recovery. Check the output of job DB2INDBT for DB2 indoubt recovery information written to the DB2 log.