Introduction The Job Entry Subsystem (JES) is a #11 IN A SERIES subsystem of the z/os operating system that is responsible for managing jobs. The two options for a job entry subsystem that can be used with z/os are known as JES2 and JES3. JES2 and JES3 processing of a job is similar in many ways. This article will primarily describe processing for JES2 since it is more pervasive than JES3. But we will also describe some of the differences between JES2 and JES3 near the end of this article. JES 1 manages jobs and their resources primarily before and after their execution. During execution, z/os manages jobs, with only some communication between z/os and JES as jobs execute (more on this later). The majority of jobs presented to z/os is batch 2 jobs, but realize that a TSO 3 user session and certain operator commands that start work (started tasks) also result in a z/os job being created. Prior to job execution, JES prepares a job for z/os execution by converting its external JCL representation into an internal form recognized by z/os. After a job completes execution, JES is responsible for the creation of any hardcopy output associated with a job (e.g. printed output) and its distribution (e.g. if the output is not needed locally where the job ran, it may be sent to a remote location for printing). The division of responsibility between JES and z/os leads to more efficient use of resources when processing a batch workload. JES Basics Before we describe how a JES processes jobs, we will describe some key concepts. 1 When the generic term JES is used in this article, it refers to either JES2 or JES3 2 See ECI No. 4 3 See ECI No. 10 Job class A job class provides a way for a z/os installation to create job categories with specific characteristics. For example, some of the jobs that will be run may have a high business priority and are expected to finish quickly. There may be other jobs that are high priority, but will consume a considerable amount of CPU resource and take a long time to complete. And still others that use primarily I/O resources. Job characteristics can be associated with a JES job class and then when an end user wants to run a job, the job can be assigned to a class that has the characteristics that best match those of the job. JES2 supports 35 job classes each named with a single character (A Z and 0 9); JES3 allows up to 255 job classes to be defined. Every job to be run is assigned a job class; either explicitly using JCL or implicitly by JES (using a default job class). Installation rules for assigning a particular job to a job class are enforced to prevent all users from selecting a job class for a job with extremely desirable characteristics (e.g. high priority). Job class characteristics and the rules for using job classes are usually unique to a particular z/os installation. So you need to consult a local document or person to understand what they are for your installation. Initiator An initiator is an address space and program logic provided by z/os that is used to run a job. A system programmer determines what job class(es) each initiator is eligible to run. Initiators can be either JES managed or managed by the workload manager component of z/os (WLM managed). If JES managed, initiators are usually started and stopped manually by an operator using a command at a console. If WLM managed, WLM will start and stop initiators based on the workload in the z/os configuration. In either case, the number of initiators determines the maximum number of jobs that can be executing at any one time. When an initiator is started, it requests a job to run. JES selects a job of a class that the requesting 2012 Angelo F. Corridori http://idcp.marist.edu Page 1 of 5
initiator can run and gives it to the initiator to run. When a job ends, the idle initiator again requests a job to run and the cycle starts again. Note that when a job ends, the initiator address space is reused (i.e. it is not stopped); this avoids the overhead associated with starting/stopping an address space each time a job starts/stops. Spool Spool is an acronym that stands for simultaneous peripheral operations on line ; which is not very descriptive so there is no need to memorize it. Think of the spool as an area of disk owned and controlled by JES. JES uses the spool as a high speed buffer to store job related information (e.g. JCL, in stream data sets, control blocks, output data sets, etc.) as well as its own data needed to manage jobs (control blocks, queues, etc.). Occasionally the acronym spool is used as a verb (e.g. spooling ); when used this way it refers to the movement of data to/from the spool data set. Internal Reader An internal reader is special data set that programs and TSO users can use to submit jobs to JES. For example, if a TSO user wants to submit a data set containing the JCL for a job to JES for processing, the TSO user enters the SUBMIT command to cause the user data set to be sent to the internal reader where JES then proceeds to process the job just as if it had been entered through a real device (like a card reader). JES job Flow The normal flow of a job as processed by JES can be described as six stages. Input During input processing, JES takes jobs presented for processing in the form of JCL statements, and copies the jobs (including any datasets provided with the JCL (known as an in stream data set )) to the spool. The source of jobs can be real devices, like a card reader (which is not very common today) or an internal reader(s). Conversion JES uses the z/os converter/ interpreter program to convert a JOB s JCL to an internal text format that the z/os job scheduler recognizes and stores this converted JCL on the JES spool. If the original JCL referred to any other JCL that is needed (e.g. JCL statements in a JCL procedure library), they are retrieved and merged with the original JCL prior to conversion. If there are no errors in the conversion process (i.e. no JCL errors are found), the job is ready to proceed to the next stage, execution. If JCL errors were found in the job, the job is not a candidate for execution and is instead moved ahead to the output stage where error messages and any other output will be processed. Execution JES maintains a queue of jobs waiting for execution. JES responds to an initiator request for a job to execute by selecting one of the ready and waiting jobs. JES job selection is based on class (remember, an initiator only runs jobs of a class that has been assigned to it), priority, and other factors. Once selected, z/os builds control blocks to represent the job using the internal text formatted data created in the conversion stage. Before allowing a program in the job to get control, the initiator allocates the resource(s) needed (as identified in the JCL) by that program so that any resources (e.g. an input data set) are sure to be ready when the program begins execution. This helps ensure that once the program goes into execution, it is not held up waiting for needed resources. During job execution, z/os is in control and JES has only a minor role to play until execution of the job is completed. However, z/os and JES do communicate via the subsystem interface, a formal interface between z/os and its subsystems. z/os may make requests of JES during job execution such as requesting data from a data set that was originally 2012 Angelo F. Corridori http://idcp.marist.edu Page 2 of 5
provided with the JCL and that JES stored on the spool during the input processing stage. Or JES will capture output records that are destined for a unit record output device like a printer or punch and store them on the spool. z/os will also notify JES of various events such as job completion so that JES knows when to resume managing a job. Once a job completes execution, it moves to the output stage. another benefit of storing output on the spool; the output can be selected for processing in any order instead of the order it was produced. Output may be produced locally (for example on a locally attached printer) or it may be sent over a network link to a remote site for processing. After all of the output for a job has been completed, the job moves on to the purge stage. Output Data sets destined for a unit record output device (referred to as SYSOUT data sets) were stored on the JES spool during execution. While this seems like an unnecessary extra step, there are actually several benefits of using the spool as a buffer to store output data sets generated by jobs. First, it improves overall system performance during job execution since writing data to the spool (disk) is faster than writing to a device like a printer. Second, it helps make most effective use of output devices like a printer in two ways. The output device can be driven at maximum speed since there is no need to wait for an output record to be generated by a program and the output device is only tied up while a data set is processed, not for the entire elapsed time needed by a job to generate the output. And finally, the output data sets can be viewed and examined while on the spool before being committed to an output device. If the output is not correct or determined to be not needed, the data can be discarded without actually being sent to an output device (e.g. printed). Examination of output on the spool is usually done with a program like the Spool Display and Search Facility (SDSF). During the output stage for a job, JES analyzes the characteristics of a job s output on the spool and groups output with similar requirements (e.g. output class (which is not the same as its job class), set up requirements, etc.). JES then queues the output for hardcopy processing during the hardcopy stage. Hardcopy output When an output device like a printer is available, output from a job is selected to be processed (e.g. to be placed on a printer) based on its output class, priority (within class), and other factors. This is Purge The purge stage is responsible for eliminating a job from the system. The spool space that was used by a job is released and the job number is no longer in use and can be reused. JES2 compared to JES3 Differences between JES2 and JES3 become very noticeable in a multiple z/os configuration (which means a multiple JES configuration as well). In such a configuration using JES2 (called a multi access spool (MAS)), the relationship between the multiple JES2 instances is that of peers; that is, each JES2 instance is independent of the others and each JES2 runs jobs on its own. In the case of multiple JES3 instances, the relationship between JES3 images can be described by a master/slave relationship. That is, one of the JES3 images (referred to as the global processor ) takes on the responsibility for job selection, scheduling, and device allocation for the entire configuration and the remaining JES3 instances (referred to a local processors ) simply execute jobs under the direction of the global processor (or server). Another area where JES2 can differ from JES3 involves resource management and in particular job resources and server scheduling. JES3 can be more heavily involved in the management of jobs and their resources during execution than JES2. For example, JES3 main device scheduling (MDS) has more control over data sets shared among z/os images and it can manage the allocation of devices for the entire job prior to beginning execution (instead of on a job step basis as is done by JES2). JES3 also has more sophisticated execution scheduling (called generalized main scheduling 2012 Angelo F. Corridori http://idcp.marist.edu Page 3 of 5
(GMS)) for a multi z/os image configuration than does JES2. And JES3 also provides dependent job control which JES2 does not. However, with the advent of ISV scheduling programs, some of these differences have become less significant over time. Other JES Concepts We have covered some basic JES concepts as well as how a typical job flows through the job entry subsystem. The remainder of this article will describe some other concepts you are likely to encounter as you work with a JES. Initialization Stream (aka Init Deck) Each JES processes a set of statements during its initialization to obtain the resources it will have to work with as well as set various parameters that control its processing. The initialization stream consists of statements, usually coded by a system programmer, that define resources that the JES can use (e.g. spool space, I/O devices, etc.). It is also used to establish the number of JES managed initiators as well as the relationship between initiators and the job classes they are allowed to process. Many of the choices specified in the initialization stream and set during initialization can be modified as the JES runs using operator commands. Checkpoint JES periodically copies key job, output queue, control blocks and other data to a checkpoint storage area. The checkpoint storage can be a data set on disk or, in the case of JES2 in a Parallel Sysplex, a storage area (structure) within the coupling facility. The objective of periodically copying information to a separate checkpoint storage area is to ensure that JES is able to continue running in the event of a hardware or software failure or if it cannot continue to run, that it can be quickly restarted without loss of information. Starts z/os must be active before a JES can be started (either automatically or via an operator command). There are several different start types for JES; they are generally known as cold, warm, and hot starts. In the case of JES3, there are some additional and unique start types due to the nature of the relationship between global and local processors. For example, there is a local start which is used to start JES3 on a local processor. Each JES start type is designed to be used in specific situations. For example, the very first time JES is started, a cold start can be used to format the spool data set(s). Thereafter, a cold start is to be avoided so as to not lose critical data kept on the spool. Warm and hot starts are not as disruptive as a cold start and are used when initially bringing a z/os image into a configuration or after a failure. In general, a hot start is the least disruptive start type and is preferred over a cold or warm start if possible. JECL Each JES has a job entry control language (JECL) that lets an end user include JECL statements within the JCL for a job. These JECL statements provide directives and/or information to the JES. For example, using JECL you can send a message to an operator, enter a JES2 or JES3 operator command, or select an execution node (server) for a job. Exits An exit refers to a defined point (called an exit point ) in the JES processing for a job where control can be passed from JES to a program supplied by a system programmer. The purpose of locally supplied program (the exit routine) is to allow the standard JES processing to be customized or tailored to some extent to meet specific needs of a business not met by standard JES processing. For example, an exit routine can be provided that will insert a business logo on a print separator page or validate the accounting information supplied with a job or perform other unique processing for a business. Exits are not the only way to customize JES processing; other techniques are available that are simpler to 2012 Angelo F. Corridori http://idcp.marist.edu Page 4 of 5
implement and maintain. Exit points are documented in the JES publications. Summary A job entry subsystem is essential for being able to efficiently process batch work. Either JES2 or JES3 must be used in conjunction with z/os. While JES2 is more pervasive in the marketplace, JES3 has some unique multi system capabilities that have a loyal following. Both JES2 and JES3 share responsibility with z/os for processing a job with the JES most heavily involved prior to and after the execution of the job s programs. We will explore other aspects of Enterprise Computing in subsequent articles. 2012 Angelo F. Corridori http://idcp.marist.edu Page 5 of 5