Understanding errors in MVS

Certain errors, which your program or the system can detect, trigger the system to interrupt your program and pass control to your recovery routine (or routines) if you have any; if you do not have any recovery routines, the system abnormally ends your program. This information uses the term abnormal end when your program ends for either of the following reasons:

Your program encounters an error for which it has no recovery routines
Your program encounters an error for which its recovery routines are not successful.

The errors for which you, or the system, might want to interrupt your program are generally those that might degrade the system or destroy data.

The following are some examples of errors that would cause your recovery routine (if you have one) to get control:

Unanticipated program checks (except those resolved by SPIE or ESPIE routines; see Processing program interruptions (SPIE, ESPIE) and “Program Interruption Services” in z/OS MVS Programming: Assembler Services Guide for information about SPIE and ESPIE routines.)
Machine checks (such as a storage error that occurs while your program is running)
Various types of CANCEL (such as operator or time out)
An error when issuing an MVS™ macro or callable service (for example, specifying parameters that are not valid)

Each of the above errors has associated with it one or more system completion codes. All system completion codes are described in z/OS MVS System Codes. You can write your recovery routine to specifically handle one or more of these system completion codes, or define your own user completion codes and handle one or more of them. Completion codes associated with errors are also referred to as abend codes.

As stated earlier, the system can detect errors, but your program also can detect errors and request that the system pass control to recovery routines. To do so, your program can issue either the ABEND macro or the CALLRTM macro.

Use the ABEND macro to request recovery processing on behalf of the current unit of work. Your program might choose to issue the ABEND macro if it detects an impossible or illogical situation and cannot proceed further. For example, your program might be passed parameters that are not valid, or might detect something in the environment that is not valid. Your program might also choose to issue the ABEND macro so that its recovery routine can get control to save serviceability information.

Use the CALLRTM macro to request recovery processing on behalf of a particular task or address space. Your program might do this if, for example, the program is sharing resources with another task, and that task appears to have stopped processing while holding an exclusive ENQ on a resource. Your program might issue the CALLRTM macro to signal the system to pass control to a recovery routine so the resource can be freed.