Internal Reader

Enhanced Definition

The Internal Reader is a facility within the Job Entry Subsystem (JES) that allows an executing program or system component to submit Job Control Language (JCL) directly to JES for processing. It provides a programmatic interface for job submission, bypassing the need for an external card reader, magnetic tape, or a spool file. This mechanism is crucial for automated and integrated batch processing within z/OS.

Key Characteristics

- Programmatic Submission: Jobs are submitted via system calls or API interfaces (e.g., SVC 34 or JES macros like JES2 $ADD or JES3 IJJINTR) from an active program, rather than through physical input devices.
- Direct to JES: Submitted JCL streams are placed directly into the JES input queue, where they become eligible for selection by initiators and subsequent execution.
- No Physical Device: Unlike external readers, the internal reader does not require a dedicated physical input device or a network connection; it's a logical interface.
- Security Context: Jobs submitted via an internal reader inherit the security context (user ID) of the submitting program or address space, which is critical for resource authorization.
- Reader Name: Jobs submitted through an internal reader are typically identified in the JES spool by a specific reader name, often INTRDR, allowing for easy identification of their origin.
- Synchronous/Asynchronous: Submission can be synchronous (program waits for JES acknowledgement) or asynchronous (program continues, JES processes submission independently).

Use Cases

- Automated Batch Processing: A CICS transaction, a DB2 stored procedure, or another batch job might submit follow-up batch jobs based on specific conditions, data changes, or completion of a previous task.
- System Utilities and Tools: System management utilities or third-party tools can use the internal reader to submit maintenance jobs, data migration tasks, or system clean-up processes.
- Dynamic JCL Generation: Applications that dynamically construct JCL based on runtime parameters or user input can use the internal reader to submit these jobs without writing the JCL to an intermediate dataset.
- Operator Commands: System operators can use JES commands (e.g., $SJ in JES2) to submit JCL directly from the console, which internally leverages the internal reader facility.
- Subsystem Integration: Major z/OS subsystems like CICS, DB2, and IMS frequently use the internal reader to integrate their online processing with batch reporting, data loading, or utility execution.

Related Concepts

JES (Job Entry Subsystem): The internal reader is an integral part of JES (JES2 or JES3), serving as a primary entry point for jobs into the system. It works in conjunction with JES initiators, which select and execute jobs from the queues populated by the internal reader.
JCL (Job Control Language): The internal reader's sole purpose is to accept and process JCL streams, translating them into executable work units for the z/OS operating system. It's an alternative to submitting JCL via external readers or Remote Job Entry (RJE).
Security (RACF/ACF2/TSS): The security profile of the submitting program's user ID is paramount, as it dictates the authorizations for the internally submitted job, controlling access to datasets, programs, and other system resources.
External Readers: In contrast to external readers (which process JCL from physical devices like card readers or network connections), the internal reader provides a software-driven, automated method for job submission, offering greater flexibility and integration capabilities.

Best Practices:

Secure Submitting Programs: Ensure that programs utilizing the internal reader run under a user ID with the *least necessary privileges* to prevent unauthorized job submissions or privilege escalation.
Robust Error Handling: Implement comprehensive error checking and recovery logic in programs that submit jobs via the internal reader to handle submission failures, JCL errors, or abends of the submitted job gracefully.
JCL Validation: If JCL is dynamically generated, implement validation routines to check for syntax errors or logical inconsistencies *before* submission to minimize job failures and resource waste.
Monitoring and Logging: Establish clear monitoring procedures for jobs submitted via internal readers, including logging submission details, job IDs, and completion status, especially for critical automated workflows.
Resource Management: Be mindful of the potential for internal readers to rapidly submit a large number of jobs; implement controls to prevent overwhelming JES queues or system resources.