IBM's MVS and z/OS operating systems use a job entry subsystem (JES) to receive jobs into the operating system, schedule them for processing by MVS or z/OS, and to control their output processing.
There are three job entry subsystems; Master, JES2 and JES3. The Master subsytem is used during system initialization and for starting system tasks that must run outside of the control of the primary JES; in particular, it is used to start the primary JES.
The other two job entry subsystems have very little in common, and in fact jobs written to run on one usually require small Job Control Language changes before they can be run on the other.
JES2 (Job Entry Subsystem 2) is descended from Houston Automatic Spooling Priority[1][2] (HASP), developed by the programmers of IBM as self-initiative and eventually owned and supported by IBM for NASA in the mid 1960s. JES3 (Job Entry Subsystem 3) is similarly descended from the Attached Support Processor[nb 1][3] (ASP), which was IBM's initially-preferred system for OS/360 "unit record I/O". In the 1970s a notable installation of ASP was at Princeton University controlling an IBM 360/91 mainframe.
JES3 Main Device Setup (MDS) has more control over data sets shared between systems than JES2, and JES3 Dependent Job Control (DJC) has more provisions for scheduling jobs with dependencies on each other than JES2. With the widespread use of sophisticated job scheduling software, DJC has become less important.
HASP is defined as: a computer program that provides supplementary job management, data management, and task management functions such as: scheduling, control of job flow, and spooling. HASP remains within JES2 subsystem as the prefix of most module names and the prefix of all messages sent by JES to the operator. JES2 is a functional extension of the HASP II program that receives jobs into the system and processes all output data produced by the job.
Simply stated, JES is a task that runs under MVS that provides the necessary functions to get jobs into, and output out of, the MVS system, and to control the scheduling of their execution. It is designed to provide efficient spooling, scheduling, and management facilities for the MVS operating system. But none of this explains why MVS needs JES. Basically, by separating job processing into a number of tasks, MVS operates more efficiently. At any point in time, the computer system resources are busy processing the tasks for individual jobs, while other tasks are waiting for those resources to become available. In its most simple view, MVS divides the management of jobs and resources between the JES and the base control program of MVS. In this manner, the JES manages jobs before and after running the program; the base control program manages them during processing.
Contents |
OS/360's job input and print queuing had limited operational flexibility and performance. This was addressed by two field-developed packages: Houston Automatic Spooling Priority (HASP), and Attached Support Processor (ASP).
HASP originally managed job scheduling and print and punch output for a single OS/360 computer, such as a single 360/65. "Multi Access Spool" capability was added for to let peer computers share a common job queue and print/punch output queues. HASP was developed by IBM Federal Systems Division contractors at the Johnson Space Center in Houston. In MVS, HASP became the standard part of system, Job Entry Subsystem 2 (JES2). It was many years before the HASP labels were removed from the JES2 source, and the messages issued by JES2 are still prefixed with $HASP.
ASP stood for Attached Support Processor, and was developed to provide efficient use of multiple OS/360 systems with a shared workload. It allowed one central system to distribute jobs to multiple connected systems. Typically, a small mainframe such as a 360/40 (the support or global system) controlled one or more 360/65 or larger processors (main or local systems). The computers were connected through selector channels on each host attached to channel to channel adapters, for 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. ASP evolved from the design of the 7094/7044 Direct Coupled System, using data channel to data channel communication. It 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. ASP became JES3.
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.