Job Entry Subsystem 2/3

Template:Short description Template:Redirect Template:Requested move notice Template:More citations needed A Job Entry Subsystem (JES) is a component of IBM's MVS (MVS/370 through z/OS) mainframe operating systems that is responsible for managing job-like workloads, e.g., batch, TSO sessions. There are two primary Job Entry Systems, called JES2 and JES3. They are designed to provide efficient execution of, e.g., batch jobs, interactive sessions. Starting with z/OS 3.1, released in September 2023, IBM z/OS no longer includes JES3, and comes with JES2 only – JES3 sites must either migrate to JES2, or license JES3plus from Phoenix Software International, who has taken over future support and development of JES3 from IBM.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> In addition, there is a Master Subsystem responsible for tasks that do not run under the control of a primary JES, e.g., the primary JES itself.

Job processing is divided into several phases to provide parallelism through pipelining. These phases include input processing where jobs are read and interpreted, the execution phase where jobs run, and output processing where job output is printed or stored on DASD. Jobs that are in the same phase of execution are usually said to reside on a particular queue; for example, jobs that are currently executing are on the execution queue.

To improve I/O efficiency, JES performs spooling, which provides multiple jobs with simultaneous access to a common storage volume. JES uses a structure called a checkpoint to backup information about currently executing jobs and their associated output. The checkpoint can be used to restore jobs and output in the event of unexpected hardware or software failures.

Although JES2 and JES3 provide the same core functionality, there are certain features that may be present in one JES but not the other. Because of these differences, one JES may be favored over the other in certain customer installations. JCL is used to define jobs to both JES2 and JES3, but small changes usually need to be made to the JCL to get a job written for one JES to run on the other. A common issue was that JES3 checked that all datasets listed in the JCL existed before execution or that there was a prior step where the dataset was defined as NEW,CATLG. JES2 did not insist on this, allowing the job to run even though it would fail when the step using it failed to find it.

History

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

{{#invoke:Labelled list hatnote|labelledList|Main article|Main articles|Main page|Main pages}} HASP was developed by IBM Federal Systems Division contractors at the Johnson Space Center in Houston.<ref name=HASPIIV3M1/><ref name=GC27-0052/> It originally managed job scheduling and print and punch output for a single OS/360 computer. Multi Access Spool capability was added to let peer computers share a common job queue and print/punch output queues.Template:Citation needed

With the introduction of System/370 in 1972, IBM rewrote HASP to become a standard part of the system and renamed it Job Entry Subsystem 2. JES2 was introduced in OS/VS2 in Release 2, also known as MVS, in 1973.<ref name=VS2Intro/> It was many years before the HASP labels were removed from the source code, and the messages issued by JES2 are still prefixed with $HASP. Several JES2 commands continue to support specification of either JES2 or HASP to maintain backwards compatibility.<ref name=jes-deathmatch-2018-april/>

ASP

{{#invoke:Labelled list hatnote|labelledList|Main article|Main articles|Main page|Main pages}}Template:More citations needed section ASP initially stood for Attached Support Processor,Template:Efn<ref name=GH20-1173/> and was developed to provide efficient use of multiple systems with a shared workload. It allowed one central system to distribute jobs to multiple connected systems; ASP could run a mixture of OS/360, SVS and 7090 emulation on a 360/65 main processor, but onlyTemplate:Efn OS/360 and SVS on other S/360 and S/370 models.. ASP was announced in March 1967,<ref name=pugh-1991/>Template:Rp and that year was reported to be "running very stably".<ref name=computer-world-1967/>

ASP evolved from the design of the 7094/7040 Direct Coupled System, using data channel to data channel communication.<ref>Template:Cite journal</ref> By attaching an IBM 7040 as a peripheral, processor throughput was more than doubled.Template:Citation needed

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;Template:Citation needed 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.Template:Citation needed

Increased reliability was another advantage to offset the added hardware cost.Template:Citation needed 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.Template:Citation needed 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.Template:Citation needed

In 1973, IBM rewrote ASP and renamed it JES3, supporting MVS only.<ref name=VS2Intro />

Alternatives

There was also a JES in OS/VS1 that was often referred to as JES1.<ref name=ibm-systems-journal-13-3-253/><ref name=gc20-1752-0/> In addition, the master (MSTR) subsystem, which is built into MVS, can start jobs that run outside of the control of the primary JES, including the Master Scheduler and the primary JES itself.<ref>Template:Harvnb "The master subsystem is a collection of routines that perform functions required to initiate certain system tasks. Job scheduling normally initiates a task or a user job using the services of a job entry subsystem to obtain and interpret the job's JCL. But, certain system tasks are initiated when a job entry subsystem is not available. These tasks include the master scheduler, which is the first initiated task in the system, and job entry subsystems. In fact, any subsystem defined as such at SYSGEN time is initiated via the master subsystem rather than via a job entry subsystem."</ref> 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.Template:Citation needed Far more installations made use of HASP than ASP, and in contemporary z/OS systems, there are many more JES2 installations than JES3.Template:Citation needed 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.Template:Citation needed

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.Template:Citation needed 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.<ref name=ibm-announcement-letter-2017/> IBM has reassured customers that JES3 will continue to be supported until an end-of-support date is announced.<ref name=listserv-ibm-main-august-2017/><ref name=watsonwalker-july-2017/> In February 2019, IBM announced that z/OS 2.5 (expected to be released in 2021) will be the last version of z/OS to include JES3.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>Template:Cite press release</ref>

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 onder the control of the primary JES.

Subsystem interface (SSI)

The Subsystem interfaceTemplate:Sfn (SSI) is a common interface for several dozen subsystems. The SSI is responsible for routing IEFSSREQ invocations to the proper subsytem, e.g., MSTR, JES2.

Converter/Interpreter (C/I)

Template:Stub-section The Converter/InterpreterTemplate:Sfn (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 subsystemTemplate:Sfn (MSTR) only processes system tasks, not user jobs. In particular, MSTR process the START of the primary JES.

See also

• System Display and Search Facility (SDSF) most common utility to interact with JES2

References

JES3Intro

Template:Cite book

Template:Cite book

LogicVol3

Template:Cite manual

ABCs2

Template:Cite book

z/OS implementation and daily maintenance, defining subsystems, IBM Job Entry Subsystem 2 (JES2) and JES3, link pack area (LPA), LNKLST, authorized libraries, System Modification Program/Extended (SMP/E), and IBM Language Environment®

ABCs13

Template:Cite book

JES3

External links

• Template:Cite manual
• Template:Cite manual