Recovery Actions for a JES2 Spool or Checkpoint I/O Problem

About this task

If the problem occurred during JES2 initialization and message $HASP289 was issued, reply TERM. Then restart JES2 with the RECONFIG start option.
If the problem is in the checkpoint data set, do the following:
1. Make sure that the checkpoint data set was allocated with DSORG=PSU.
2. Make sure that defragmentation programs were not run against volumes containing the checkpoint data set. Defragmenting a checkpoint volume is a prime cause of spool problems.
3. If JES2 displays the reconfiguration dialog, the problem is in a backup checkpoint data set. Replace the damaged data set as soon as is convenient.
If the problem is in the spool volume, enter a $ZSPL command for each volume that is in error. This will do the following:
- Prevent JES2 from trying to allocate any more space from the volume.
- Prevent all jobs that currently have space allocated from the volume from being selected for work (conversion, execution, printing).
If a system-wide warm start is done eventually without the volumes that had errors, JES2 issues the following messages:
```
HASP424 volume NOT MOUNTED
HASP853 REPLY GO, QUIT, OR PURGE.
```
Do one of the following:
- If the volume is thought to be recoverable, reply GO. This will cause the volume to come up in an inactive state. The jobs that have space allocated from this volume will not be available for work (same as above after issuing $ZSPL). JES2 will not attempt to use any space from the volume until a $SSPL command is entered.
- If the volume is permanently damaged, reply PURGE to this message. Reply PURGE only if you are certain that the volume cannot be recovered. Replying PURGE will cause all jobs with any space allocated from the volume to be purged. The system issues no messages or warnings to indicate that this has happened.