Understanding errors in MVS
- 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.
- 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.