The daily edition.

Scope and Architectural Overview

This article covers Job Entry Subsystem (JES) batch initiator architecture, class routing, and spool queue lifecycle in Rocket Enterprise Developer / Enterprise Server 12.0 for Linux/UNIX.

In mainframe z/OS batch processing, workload concurrency is managed by JES initiators that drain input job queues based on assigned job classes. Rocket Enterprise Server implements mainframe-compatible batch processing using specialized Service Execution Processes (SEPs) known as Batch Initiators (or simply "initiators"), as described in Set Up the ESJCL Enterprise Server Region.

Understanding how initiators match job classes and how spool queues transition is essential for avoiding stalled batch streams, sizing throughput concurrency, and executing administrative interventions.

Static Initiator Definitions via DEFINE JES

Initiators can be defined statically in the resource definition database so they start automatically whenever the enterprise server region initializes. As documented in DEFINE JES, static initiators are configured using resource definition entries:

DEFINE JES(INIT1) GROUP(BATCHGRP)
       DESCRIPTION(BATCH INITIATOR FOR CLASSES A THROUGH D)
       TYPE(INITIATOR)
       CLASSES(ABCD)

Key attributes include:

• JES(name): A unique 1- to 8-character alphanumeric identifier.
• GROUP(groupname): The resource group containing the definition (which must be included in the region's startup list).
• TYPE(Initiator|Printer): Specifies whether the process is an execution initiator or an output writer printer process.
• CLASSES(string): An alphanumeric string containing the job classes serviced by this initiator (e.g., CLASSES(ABCD0) or CLASSES(abcdefghijklmnopqrstuvwxyz0123456789)). Each class must be composed of characters A-Z or 0-9.

An initiator checks its assigned classes sequentially when selecting the next available job from the spool.

Spool Queue Lifecycle: From Input to Complete

As documented in Managing and Viewing Spool Queues, jobs submitted to Enterprise Server pass through five distinct queue states in the spool:

1. Input: Jobs that have been parsed and are waiting to execute. Jobs remain in the Input queue whenever no active initiator is configured with a matching CLASS (or when all matching initiators are busy).
2. In Hold: Jobs placed in a hold state (via TYPRUN=HOLD on the JCL JOB card or manually held by an administrator). Held jobs will not be selected by an initiator until explicitly released.
3. Dispatch: A transient state indicating a job has been scheduled to a specific initiator process but has not yet initiated step execution.
4. Active: Jobs currently executing inside an initiator SEP.
5. Complete: Execution finished. The Complete queue houses output datasets categorized into Output (waiting for a batch printer matching the output class), OutHold (held output), and Printed.

Dynamic Initiator Control via casout

While static definitions handle standard region startup, administrators can dynamically start, stop, and inspect initiators at runtime without modifying the resource database using the casout command-line utility:

# Start an initiator servicing classes E, F, and G on region JCLT
casout /rJCLT /iEFG

# List all active initiators, printers, and IMS MPR processes
casout /rJCLT /v

# Terminate an initiator process by its operating system PID
casout /rJCLT /t14076

# Dynamically modify a queued job's class to route it to an available initiator
casout /rJCLT /m0000123:B

Dynamic initiators started via casout /i persist only for the duration of the current region session and terminate when the region shuts down.

Operational Nuances and Concurrency Sizing

• Single Job Serial Execution: Each batch initiator process is strictly single-threaded, executing only one JCL job at a time. The number of concurrent batch jobs a region can process is directly determined by the number of active initiator SEPs.
• Class Starvation: If long-running batch jobs are submitted to the same class as high-priority short jobs, configuring separate dedicated initiators for distinct classes (e.g., dedicated Class A initiators for short online batch, Class B for long-running batch) prevents queue starvation.
• Security Authorization: Running casout commands requires execute permission against the casout entity in the OPERCMDS security class. Additionally, managing job queues, viewing SYSOUT, or modifying job classes requires appropriate authority under the JESSPOOL and casrdo44 resource classes.
• Separation from Output Printers: An initiator SEP only processes job execution. Output datasets (SYSOUT) require batch printer SEPs (TYPE(PRINTER) or started via casout /b<classes> /n<printer-name>) to drain the Complete queue.

Documentation Takeaway

In Rocket Enterprise Server 12.0 for Linux/UNIX, batch workload throughput is determined by initiator SEPs matching JCL JOB card classes: static initiators configured with DEFINE JES establish baseline capacity, jobs stall in the Input spool queue if matching classes are unassigned, and administrators can dynamically balance processing queues using casout to spawn class-specific initiators or retarget queued jobs.