Canceling

Job Cancellation

Enhanced Definition

Canceling, in the z/OS context, refers to the premature termination of a running job, started task, or TSO user session before its normal completion. This action is typically initiated by an operator, system administrator, or an automated system process, often in response to an error, resource contention, or operational necessity.

Key Characteristics

- Immediate Termination: A cancel command typically stops the execution of the target address space quickly, releasing its allocated CPU, memory, and I/O resources.
- Operator Intervention: Most cancellations are initiated by a z/OS operator using console commands like CANCEL or FORCE.
- Resource Release: Upon cancellation, the system attempts to free all resources (e.g., enqueues, memory, open datasets) held by the terminated job.
- Data Integrity Risk: If a job is canceled while performing updates to datasets or databases, it can leave data in an inconsistent or corrupt state, requiring recovery procedures.
- Differs from ABEND: While both terminate a job abnormally, an ABEND (ABnormal END) is a program-initiated termination due to an internal error, whereas a CANCEL is an external intervention.
- System-Initiated: In some cases, z/OS components like Workload Manager (WLM) or system recovery processes might automatically cancel jobs that violate service goals or cause system instability.

Use Cases

- Runaway Jobs: Terminating a job that is consuming excessive system resources (e.g., CPU loop, infinite I/O) and impacting overall system performance.
- Deadlock Resolution: Canceling one or more jobs involved in a resource deadlock to free up critical resources and allow other jobs to proceed.
- Incorrect Job Submission: Stopping a job that was submitted with incorrect JCL, parameters, or is processing the wrong data.
- System Maintenance: Clearing the system of active workloads in preparation for planned system outages, IPLs, or hardware maintenance.
- Priority Override: Freeing up resources held by a lower-priority job to allow a higher-priority, critical workload to execute.

Related Concepts

Canceling is closely related to JES (Job Entry Subsystem), as JES manages the lifecycle of batch jobs, and a cancel command interacts with JES to terminate a job. It contrasts with an ABEND, which is an internal program error, while a cancel is an external operator or system action. The decision to cancel a job often stems from issues like resource contention (e.g., a job holding an exclusive enqueue) or a job failing to meet its WLM (Workload Manager) service goals. Post-cancellation, recovery and restart procedures are often necessary to ensure data integrity and complete the intended processing.

Best Practices:

Investigate Before Canceling: Before issuing a CANCEL, attempt to diagnose the job's behavior using commands like DISPLAY A,jobname or DISPLAY GRS,C to understand resource usage and enqueues.
Use CANCEL Before FORCE: Always try the CANCEL command first. FORCE is a more aggressive termination that can bypass some cleanup routines and should be reserved for unresponsive jobs.
Be Mindful of Data Integrity: Understand the potential impact on data integrity, especially for jobs performing updates to critical datasets or databases (e.g., DB2, IMS). Plan for potential recovery or backout.
Monitor Enqueues: Before canceling, check if the job holds critical system-wide enqueues (DISPLAY GRS,C). Canceling such a job without careful consideration can impact other active workloads.
Log and Analyze: Document all job cancellations, including the reason and time, to identify recurring issues, improve JCL, or refine operational procedures.
Operator Training: Ensure operators are well-trained on the proper use of CANCEL and FORCE commands, understanding their implications and the appropriate scenarios for their use.