CL handling for unmonitored messages

The system provides default monitoring and handling of any messages you do not monitor.

Many escape messages can be sent to a program or procedure that calls commands, programs, and procedures. You might want to monitor and handle the escape messages that pertain to the function of your program or procedure. However, you might not want to monitor and handle all of the messages.

Default handling assumes that an error has been detected in a program or procedure. If you are debugging the program or procedure, the message is sent to your display station. You can then enter commands to analyze and correct the error. If you are not debugging the program or procedure, the system performs a message percolation function.

Message percolation is a two-step function that completes the following tasks:

If the program or procedure has a Monitor Message (MONMSG) command for the escape message, the message percolation action stops, and the system takes the action that is specified by the Monitor Message (MONMSG) command. Message percolation continues until either finding a Monitor Message (MONMSG) command, or until finding the nearest control boundary. This means that the escape message does not percolate across control boundaries.

The function check processing begins by finding the control boundary before finding a program or procedure with a Monitor Message (MONMSG) command that applies to the message. The system considers the action on the original escape message complete. The system then sends the function check message (CPF9999) to the program or procedure that is the target of the original escape message. If that program or procedure has a Monitor Message (MONMSG) command for the function check message, it takes the action that is specified by that command. Otherwise, the system sends an inquiry message to the workstation operator if the job is an interactive job. The workstation operator can reply with one of the following replies:

R
Retry the failing command in the program or procedure.
I
Ignore the message. Continue processing at the next command in the program or procedure.
C
Cancel the program or procedure and percolate the function check to the previous program or procedure on the call stack.
D
Dump the call stack entry for the failing program or procedure, cancel the program or procedure, and percolate the function check to the previous program or procedure on the call stack. This is the default action if the workstation operator enters no reply, or if the job is a batch job.

The system does not percolate the function check across the control boundary. If any reply causes the function check to move across an activation group boundary, this stops further action on the function check. The system cancels all program or procedures up to the activation group boundary, and sends the escape message CEE9901 to the prior call stack entry.

You can monitor for function-check escape messages so that you can either clean up and end the program or procedure, or continue with your program or procedure.

Note: If the message description for the unmonitored escape specifies a default action, the default handling program is called before the function check message is sent. When the default handling program returns, function check processing begins.

The following figure shows how CL monitors for messages and notifies the workstation user of a function check for default handling.

REQTEXT