CL handling for unmonitored messsages

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

Default handling assumes that an error has been detected in a procedure. If you are debugging the 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 procedure, the system performs a message percolation function.

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

• Moves the escape message one step earlier in the call stack.
• Checks to see if the procedure has a Monitor Message (MONMSG) command for the escape.

If the procedure has a Monitor Message (MONMSG) command for the escape, 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 procedure with a Monitor Message (MONMSG) command which applies to the message. The system considers action on the original escape exception complete. The system then sends the function check message (CPF9999) to the procedure that was the target of the original escape. If that procedure has a Monitor Message (MONMSG) for the function check message, then 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 operation can reply with one of the following replies:

R

Retry the failing command in the procedure.

I

Ignore the message. Continue processing at the next command in the procedure.

C

Cancel the procedure and percolate the function check to the next previous procedure on the call stack.

D

Dump the call stack entry for the failing procedure, cancel the procedure, and percolate the function check to the next previous procedure on the call stack. This is the default action if entering 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 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 procedure
• Continue with some other aspect of your procedure

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