Input Queue
In the z/OS environment, an Input Queue is a temporary storage area where incoming work, such as JCL streams for batch jobs or transaction requests for online systems like CICS and IMS, is held awaiting processing. It acts as a buffer, decoupling the submission of work from its execution, ensuring orderly processing and preventing system overload.
Key Characteristics
-
- Workload Buffering: It temporarily stores submitted jobs, transactions, or messages, preventing the processing systems from being overwhelmed by bursts of incoming requests.
- Managed by Subsystems: For batch jobs, it's primarily managed by the Job Entry Subsystem (JES2 or JES3). For online transactions, CICS and IMS have their own internal input queues or message queues.
- Prioritization and Scheduling: Entries in an input queue can often be prioritized (e.g., via
JOB CLASSandPRTYin JCL) to influence their order of selection for execution. - Spooling Mechanism: For JES-managed jobs, the JCL and associated input data are typically spooled to direct access storage (DASD) within the JES spool space.
- Persistent Storage: While temporary in nature, the data in input queues (especially for JES) is typically written to disk, providing persistence across system restarts for jobs not yet processed.
- FIFO or Priority-Based Retrieval: Work is usually processed in a First-In, First-Out (FIFO) manner within a given priority level, or strictly by priority across all entries.
Use Cases
-
- Batch Job Submission: When a user submits a JCL stream (e.g., via TSO/ISPF, a network connection, or an internal reader), it enters the JES input queue to await selection by an initiator.
- CICS Transaction Entry: Online users entering transactions (e.g.,
CECI, custom application transactions) have their requests placed into CICS's internal queueing mechanisms before being dispatched for processing. - IMS Message Processing: Messages destined for IMS applications, whether from terminals, other applications, or external systems, are placed into IMS message queues for subsequent processing by Message Processing Programs (MPPs).
- Automated Workload Scheduling: External schedulers often place JCL into the JES input queue at predefined times or upon specific event triggers, ensuring jobs run according to a schedule.
Related Concepts
The Input Queue is fundamental to the Job Entry Subsystem (JES), which manages the flow of jobs into and out of the z/OS system. It works in conjunction with JES Initiators, which select jobs from the input queue based on class and priority, and Spooling, which is the underlying mechanism for storing job streams and output. For online systems, it's a core component of the Transaction Manager (CICS) or Message Processor (IMS), ensuring orderly processing of incoming requests and interacting with Dispatchers that allocate system resources. It contrasts with the Output Queue, which holds job output after execution.
- Monitor Queue Depth: Regularly monitor the number of jobs or transactions in the input queue to identify potential backlogs or system bottlenecks before they impact performance.
- Optimize Job Classes and Priorities: Assign appropriate
JOB CLASSandPRTYvalues to jobs to ensure critical workloads are processed ahead of less urgent ones, preventing queue starvation for high-priority items. - Implement Robust Error Handling: Ensure that applications or JCL submitted to the input queue have proper error handling to prevent malformed input from causing system issues or infinite loops.
- Capacity Planning: Periodically review input queue growth trends to ensure sufficient JES spool space or CICS/IMS queue resources are available to handle peak workloads.
- Secure Job Submission: Implement security measures (e.g., RACF profiles) to control who can submit jobs to the input queue and what job classes they can use, preventing unauthorized resource consumption.