MVS Job Entry Subsystems

Precursors OS/360's batch job processing had limited operational flexibility and performance, which was addressed by two field-developed packages called the Houston Automatic Spooling Priority (HASP) and the Attached Support Processor (ASP). HASP HASP was developed by IBM Federal Systems Division contractors at the Johnson Space Center in Houston. By attaching an IBM 7040 as a peripheral, processor throughput was more than doubled. In a typical ASP configuration, a small mainframe such as a 360/40 called the support system controlled one or more 360/65 or larger processors called main systems. The computers were connected through selector channels on each host attached to channel-to-channel adapters in an early form of short distance, point-to-point computer networking. ASP required the purchase of an additional computer to manage input and output of the hosts running the job workload, which was economically justified by the high cost of standalone byte-multiplexor channels needed to drive printers and punched card reader devices; the 360/50 and smaller systems had a built-in byte multiplexor channel, whereas the faster 360/65 and larger systems required a relatively expensive standalone unit. Using ASP made it possible to avoid the cost of the byte multiplexor channel, and offloading the job scheduling, print, and card handling also offloaded those functions from the larger machines. Increased reliability was another advantage to offset the added hardware cost. One or more main systems could fail or be taken offline for maintenance without taking down the whole complex. ASP was primarily targeted at large government agencies and defense contractors that might have as many as six 360/65s all being scheduled and managed by a separate ASP machine. An uncommon variant, local ASP (LASP), was a single large machine with the ASP functions running on the same machine. In the 1970s, a notable installation of ASP was at Princeton University controlling an IBM 360/91 mainframe. In 1973, IBM rewrote ASP and renamed it JES3, supporting MVS only. Originally the JCL for the Master subsystem was in an IBM provided load modules, but in current versions of MVS through z/OS, it can be provided as a member of the system parameter library (PARMLIB). Customization Source code was provided to IBM customers for both ASP and HASP, and many customers made substantial enhancements to these programs, some of which were incorporated into the official product. Far more installations made use of HASP than ASP, and in contemporary z/OS systems, there are many more JES2 installations than JES3. Because of their unique history, IBM continues to ship JES2 and JES3 source code instead of object code, unlike most components of the operating system. To improve maintainability and serviceability of user-written enhancements, JES provides a set of exit points that pass control from the JES to user programs at key points of processing. These extensions can provide custom functionality such as special commands, custom print page headings, and non-standard job processing. Current development In 2017, IBM released a statement of direction for JES2 to be the "strategic" JES, meaning that all future development efforts will be focused on JES2 rather than JES3. In October 2019, Phoenix Software International announced that it had licensed the JES3 source code from IBM and would be taking over its maintenance and enhancement. == Types of subsystem ==

A subsystem is either the Master subsystem (MSTR), a primary JES started under the control of MSTR or a secondary JES started under the control of the primary JES. The primary JES is responsible for running, e.g., APPC sessions, batch jobs, system tasks, TSO logons, except • The Master Subsystem • The primary JES • Tasks explicitly directed to MSTR • Workloads for testing a secondary JES. == Subsystem interface (SSI) ==

The Subsystem interface (SSI) is a common interface for several dozen subsystems. The SSI is responsible for routing IEFSSREQ invocations to the proper subsystem, e.g., MSTR, JES2. Various system components, e.g., Allocation, invoke SSI in order to allow subsystems to control processing. == Subsystem datasets ==

Jobs may allocate datasets implemented by a subsystem either explicitly with a SUBSYS= keyword or implicitly. Subsystem datasets can be accessed directly with an ACB/RPL interface or indirectly with a DCB and the Compatibility Interface (CI). SYSIN A System Input (SYSIN) dataset is defined by a DD * or DD DATA statement processed by a primary or secondary JES. The owning JES maintains the data on SPOOL and provides access via ACB/RPL. SYSOUT A System Output (SYSOUT) dataset is defined by a DD SYSOUT= statement processed by a primary or secondary JES or an equivalent dynamic allocation. The owning JES maintains the data on SPOOL and provides access via ACB/RPL. The MSTR subsystem can allocate SYSOUT datasets managed by a different subsystem. == Converter/Interpreter (C/I) ==

The Converter/Interpreter (C/I) is a highly modified version of the Reader/Interpreter (R/I) of OS/360 and SVS. A subsystem may invoke the C/I as a unit or may invoke the Converter and Interpreter separately. Converter The converter parses an input stream and converts the JCL into internal text. Roughly, each syntactical element has a key and a value. Range checking of the values is generally deferred to the Interpreter. The Converter is responsible for merging cataloged procedure into the job stream. Interpreter The Interpreter does validity checking on text units and compiles them into control blocks. Depending on the subsystem invoking the Converter, the output control blocks may reside in System Work Area (SWA) or in SPOOL datasets. == Master subsystem (MSTR) ==

The master subsystem (MSTR) only processes system tasks, not batch jobs. In particular, MSTR process the START of the primary JES. There is an operand on the START command to force a started task that would normally run under the primary JES to run under MSTR. == Job Entry Subsystem/2 (JES2) ==

== Job Entry Subsystem/3 (JES3) ==