iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The safe recovery path depends on where the failure occurred. A JES2 spool-volume failure, an application data-set I/O error, and a program abend are different incidents. First preserve the job evidence and determine whether SYSOUT still exists. If the problem is a JES2 spool volume, use the IBM-documented operator responses at $HASP853; if output is still held, manage it through authorized SDSF or JES2 OUTPUT functions before submitting the job again. Do not assume that rerunning a business job is safe until its checkpoint and duplicate-update rules have been checked.
Start by identifying the failure domain
JES2 uses spool to store job input and output. A batch step’s SYSOUT is normally allocated to spool so that JES2 can process it later. That architecture makes a spool outage look like an output problem, but it does not make every output or storage error a spool failure. The first useful question is: which component reported the error?
- JES2 spool or checkpoint storage: messages mention a spool volume, JES2, a spool I/O path, or a JES2 checkpoint. Follow the site operator procedure and IBM’s “Recovering from SPOOL volume failure” procedure for the installed z/OS release.
- Application data set: the message identifies a particular DD name, data-set name, catalog, volume, SMS service, or allocation. This requires the storage and application runbooks, not a spool-volume command.
- Program or step failure: a condition code, abend, or application message identifies the failing program. Output may be perfectly healthy even though the job must be restarted or resubmitted.
- Another job-entry subsystem: the procedure below is for JES2. It does not establish equivalent commands or recovery behavior for JES3 or a non-z/OS scheduler.
Record the job name and job ID, system and member, failing step, DD name, message IDs, return code or abend, output class, destination, and the time of the event. Preserve the JESMSGLG, JESJCL, JESYSMSG, operator messages, and any application log that your site normally retains. This evidence tells an operator whether the failure happened before output was created, while output was being written, or after output had already reached a queue.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Understand what can and cannot be recovered
There are two separate recovery questions:
- Can the existing output be retrieved? SYSOUT that remains on spool may be viewable, copied, released, redirected, or deleted, subject to authorization and security-label rules.
- Can the business job be run again safely? That depends on the application’s checkpoint design and on whether the failed run made partial external updates. JES2 recovery documentation does not define a universal restart point for every program.
An output error does not prove that the data is lost. Conversely, a job that appears in an output queue does not prove that every external update completed. Treat output preservation and application restart as separate decisions.
#1 Best Overall
Use the job’s output queues before regenerating anything
IBM’s “Processing the Output of a Batch Job” documentation describes the authorized OUTPUT workflow for inspecting and managing held SYSOUT. A site commonly performs these actions through SDSF panels or the JES2 OUTPUT command, depending on its security model and operating practice.
Inspect held and completed output
- Locate the job by job name and job ID, then list its output elements and their current class, destination, and disposition.
- Open the system messages and application data sets separately. A JES2 message stream can confirm an allocation or spool problem, while an application report may show that useful business output was already produced.
- Check whether an output element is held, awaiting processing, already processed, or marked for deletion. Do not treat a visible job entry as proof that all of its SYSOUT is still readable.
- Confirm that your user ID and security label permit access. IBM notes that both authorization and security-label checks can restrict viewing or managing output.
Manage output only after confirming its state
Authorized OUTPUT functions can display or copy held SYSOUT, release it for processing, change its output class or destination, or delete it. Copy a required report to an approved destination before changing its disposition. If output is needed as evidence, keep it held until the incident owner has recorded the relevant messages and hashes or other integrity checks required by local policy.
If output has already been purged, an OUTPUT command cannot recreate it. The only remaining options are an application restart, a controlled rerun, a backup or archive, or a business-approved reconstruction. Check retention settings before promising that a report can be recovered.
Free tools Windows power users keep installed
One-click scans. No signup required.
Know the JES2 output dispositions
JES2 has normal and abnormal output dispositions. IBM documents the disposition values HOLD, KEEP, LEAVE, PURGE, and WRITE. The exact value in effect determines whether output is available after a normal completion or an error.
Rank #2
| Disposition | Operational effect | Use when |
|---|---|---|
HOLD |
Leaves output held for operator or authorized user action instead of sending it through normal processing. | Output must be inspected, copied, or approved before release. |
KEEP |
Allows normal output processing and retains the output on spool afterward. | The site needs a processed copy available for later viewing or reprocessing. |
LEAVE |
Leaves the output on spool rather than completing the normal output-processing path. | Local procedures require the queue entry to remain available for a later operator decision. |
PURGE |
Discards the output without retaining it for later processing. | Retention is not required and immediate removal is permitted. |
WRITE |
Writes the output through its output-processing path and then purges it. | A delivered copy is sufficient and spool retention is not required. |
Sites can set different normal and abnormal dispositions, and operator commands can change a held element’s class, destination, or disposition. Read the current setting for the specific job; a policy that keeps output after a normal completion may purge it after an abnormal completion. IBM’s “Specifying output disposition” and “Changing output disposition through operator commands” documentation covers these controls for the cited z/OS releases.
Recover from a JES2 spool-volume failure
The following procedure applies when the evidence identifies a JES2 spool-volume problem. Coordinate every action with the site’s JES2 operator and incident procedure; the commands can affect many jobs.
1. Halt the affected volume when required
IBM states that JES2 halts paths to a spool volume in error the next time data is requested. For an I/O request failure caused by another condition, IBM directs the operator to issue $Z SPL to halt the volume. This is an operator action for JES2 spool handling, not a general-purpose command for an application data-set failure.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →2. Read the warm-start messages
During an all-member warm start, JES2 can issue $HASP424 and then $HASP853 for a spool volume that requires a decision. The response must reflect the physical and logical state of the volume, the need to inspect its contents, and the site’s recovery authority.
Rank #3
| Response | What it does | When it is appropriate |
|---|---|---|
GO |
Allows JES2 to continue with the volume mounted inactive. Jobs that have space allocated on that volume remain unavailable until an operator starts the volume. | The volume may be recoverable, or its contents must be examined before deciding whether to activate it. |
PURGE |
Removes jobs that have any space allocated on the permanently damaged volume. | Only when the volume is confirmed permanently damaged and the incident authority accepts loss of those jobs and their spool data. |
QUIT |
Terminates JES2. | When the local recovery plan requires stopping JES2 rather than proceeding with either volume option. |
PURGE is not a quicker form of GO. It destroys the spool allocations for every affected job and should be used only for a permanently damaged volume. Record who authorized the response and why before entering it.
3. Examine jobs allocated on the volume
After choosing GO, the volume remains inactive until an operator starts it. IBM documents $S SPL for starting the spool volume after examination and approval. To identify affected work, use the following display commands with the actual volume serial in place of volser:
$D JOBQ,SPL=(V=volser)displays jobs currently allocated on that spool volume.$D A,ALL,X,DEV,V=volserdisplays active jobs with space on the volume.
These displays support impact analysis; they do not decide whether a business job can be rerun. Compare the affected job IDs with the output queue, checkpoint records, and application incident notes.
4. Start or replace the volume only under the site procedure
If storage personnel establish that the device, path, or volume is recoverable, follow the site’s repair and validation steps before issuing $S SPL. If the volume is irretrievably damaged, preserve the affected-job list and use the approved purge or replacement process. Do not improvise a JES2 restart sequence from an application runbook.
Rank #4
Decide whether to restart, resubmit, or stop
The spool procedure tells you what happened to JES2 storage, not where an application should resume. Make the job decision with the application owner.
Restart from a checkpoint
Use a checkpoint restart only when the program’s runbook identifies a valid checkpoint and explains how to reconcile records written before the failure. Confirm that the checkpoint itself is available and that input positioning, sort work, database commits, and external messages are consistent.
Resubmit the complete job
A full resubmission may be correct for a read-only report or an idempotent workload. It can be unsafe when the original run updated a database, sent files, posted transactions, or produced a report that downstream systems already consumed. Obtain business approval and define how duplicate output or duplicate updates will be detected.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not rerun yet
Stop and escalate when the failing step’s completion status is unknown, when the job used non-repeatable external effects, or when the incident has not established whether output was delivered. Preserve the original job evidence and let the application and storage owners determine the next action.
Best Value
- Murach's Mainframe COBOL
- Mike Murach & Associates
- ABIS BOOK
Common cases and the correct branch
| Observed condition | Next action | What not to assume |
|---|---|---|
| JES2 reports a spool-volume error and output is missing from the normal queue. | Follow the $HASP853 decision, identify jobs on the volume, and inspect held output after the volume is safely available. |
That the application must be resubmitted immediately. |
| A report appears in held SYSOUT. | Use authorized SDSF or OUTPUT functions to view or copy it, then release or redirect it only after approval. | That a held report is already delivered to its intended recipient. |
| The message names an application DD or data set, not JES2 spool. | Engage storage and application owners; verify allocation, volume, catalog, permissions, and program-specific recovery. | That $Z SPL or a spool-volume response will repair the data set. |
| The volume is confirmed permanently damaged. | Use the authorized PURGE path only after recording affected jobs and accepting their loss. |
That PURGE preserves SYSOUT for later recovery. |
| The job abended after making external updates. | Follow the application’s reconciliation and checkpoint procedure before restart or resubmission. | That an identical rerun is harmless. |
Prevent a repeat incident
Set retention for the evidence you actually need
Review normal and abnormal dispositions together. A setting that writes and then purges output may satisfy delivery requirements while leaving nothing for post-incident inspection. Conversely, retaining every output indefinitely consumes spool capacity. Define which classes, jobs, and failure paths require HOLD, KEEP, or LEAVE, and who may release or delete them.
Use spool fencing where appropriate
IBM describes JES2 spool fencing as allocating a job’s track groups from a specified number of spool volumes. The objective is to limit the jobs affected by permanent loss of one volume, not to make the volume immune to failure. Have a JES2 administrator size and test the configuration against throughput, capacity, and recovery objectives.
Make restart rules explicit
Each critical batch application should document its checkpoint frequency, commit boundaries, restart parameters, duplicate-output handling, and reconciliation steps. The runbook should state whether a report can be regenerated, whether a partial file must be quarantined, and which operator or business owner authorizes resubmission.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Exercise the operator workflow
Test that operators can locate a job by ID, identify held SYSOUT, display jobs on a spool volume, recognize $HASP424/$HASP853, and distinguish GO from PURGE. A tabletop exercise should include a job with retained output and another with an application data-set failure so that staff practice choosing the correct branch.
Incident checklist
- Capture job name, job ID, system, member, step, DD name, messages, return code or abend, output class, destination, and timestamps.
- Classify the fault as JES2 spool, application data set, program logic, or another subsystem.
- Preserve JES and application logs before changing queues, restarting JES2, or resubmitting work.
- Inspect held and completed output through authorized SDSF or OUTPUT functions; verify user-ID and security-label access.
- Confirm the job’s normal and abnormal output dispositions and whether output was already processed or purged.
- For a JES2 spool-volume failure, follow the local response to
$Z SPL,$HASP424, and$HASP853. - Choose
GO,PURGE, orQUITbased on volume recoverability and incident authority; never usePURGEmerely to clear an alert. - Use
$D JOBQ,SPL=(V=volser)and, where relevant,$D A,ALL,X,DEV,V=volserto identify affected jobs. - Ask the application owner whether checkpoint restart, full resubmission, or no rerun is safe.
- Document the final disposition, recovered output, lost output, affected jobs, and preventive changes.
What a successful recovery looks like
Recovery is complete when the incident team can account for the failed volume or data set, identify which SYSOUT survived, preserve or deliver the required output, and make an explicitly approved application restart decision. JES2 commands restore control of spool processing; they do not certify business data. Keep that boundary clear, and an output or storage error can be handled without turning a recoverable report into a duplicate transaction or an avoidable data loss.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
