Jobs & job queues

A job is a unit of work with an execution environment, such as user identity, library list, job attributes, and runtime resources. Interactive, batch, and server jobs have different entry paths but all run within work management.

Identify a job by its qualified number/user/name, not just its short name. Many jobs can share the same name. When reporting a failure, retain that qualified identity with the timestamp so another developer can inspect the correct execution.

SBMJOB submits work for batch processing. Submission places a job into a job queue under the selected job attributes; it does not guarantee the program has started or finished successfully. A subsystem must be able to select and run the job.

Treat accepted submission, started execution, and business completion as separate events. A scheduler or parent process should use an explicit completion signal if later work depends on the result.

Example

SBMJOB CMD(CALL PGM(APP/NIGHTLY)) JOB(NIGHTLY) JOBQ(APP/BATCHQ)

A job queue holds jobs waiting to begin execution. An output queue holds spooled output waiting for a writer or other processing. A completed job can leave output in an output queue after its active execution has ended.

When someone says the report is stuck, establish whether the generating job has not run, is still running, or has produced a held spooled file. Each case has different evidence and a different owner.

Example

*JOBQ → pending work
*OUTQ → spooled output

Check the job and job queue hold status, the subsystem’s activity, whether the queue is attached to the expected subsystem, and maximum-active limits. Then inspect routing and other required execution resources.

Distinguish a job still on a queue from an active job waiting on a lock or message. Repeated submissions create duplicates without repairing the cause. Record the original qualified job identity, find the admission constraint, and release only the intended work when appropriate.

The submitted job may have a different user profile, initial library list, job description, current library, CCSID, date attributes, or overrides. It also lacks interactive assumptions such as a terminal response.

Compare the actual job attributes and resolved objects. Make the batch wrapper establish its environment explicitly and use noninteractive error reporting. Do not fix the difference by adding excessive authority or assuming the submitter’s current runtime state is copied wholesale.

MSGW indicates a message-related wait, LCKW a lock wait, and DEQW a dequeue wait. These are investigation clues, not automatic errors. A consumer waiting for its next queue entry may be behaving normally.

Correlate status with expected workload, call stack, and recent messages. For MSGW inspect the inquiry and approved reply; for LCKW find the resource and holder; for DEQW verify whether work is expected and whether the producer is active.

A job description supplies many starting attributes for a job. A class describes execution attributes such as run priority and time slice for the routing step. A subsystem description defines work-entry and resource-routing configuration.

These objects influence different stages of job setup and execution. Diagnose the path from submission parameters to job description to subsystem routing and class rather than changing one global default. Confirm the effective runtime value because overrides and configuration can alter the initial settings.