MVS uses a job entry subsystem (JES) to receive jobs into the operating system, schedule them for processing by MVS, and to control their output processing. JES2 is descended from HASP (Houston automatic spooling priority). 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 as the prefix of most module names and the prefix of all messages sent by JES2 to the operator.

JES2 (job entry subsystem 2) is a functional extension of the HASP II program that receives jobs into the system and processes all output data produced by the job. So, what does all that mean? Simply stated, JES2 is that component of MVS that provides the necessary functions to get jobs into, and output out of, the MVS system. It is designed to provide efficient spooling, scheduling, and management facilities for the MVS operating system. (Refer to "Spool Data Sets and Spooling" in topic 2.1.1 for a full definition of Spooling.)

But, none of this explains why MVS needs a 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, JES2 manages jobs before and after running the program; the base control program manages them during processing (1).

During the life of a job, both JES2 and the base control program of MVS control different phases of the overall processing. Generally speaking, a job goes through the following phases:

• Input

• Conversion

• Processing

• Output

• Print/punch (hard copy)

• Purge

Except for processing, all the job phases are controlled by JES2.

These phases are explained in more detail in Chapter 3, "JES2 Job Processing and Function."

JES2 initialization statements give the system programmer a single point of control to define an installation's policies regarding the degree of control users have over their jobs. For example, consider the confusion an installation would experience if users were allowed to define their own job classes and priorities. Very likely, all users would define all their jobs as top priority, resulting in no effective priority classifications at all. So, although a user can use job control language (JCL) options to define a priority, a JES2 initialization statement (defined by the system programmer) determines whether JES2 acknowledges that priority.

This same type of control (validation of user specification and provision for a default) extends to many JCL definitions. For example, JES2 can specify the maximum time a particular job is allowed to run, the storage a job may consume, the number of copies of output a job can print, and the type of paper (form) on which the output prints.

An installation has the ability to allow its users to override system and JES2 specifications at three distinct levels (user-specified JCL, installation-specified JCL, and JCL defaults). The following list shows the hierarchy of control, from highest priority to lowest priority, of user JCL, JCL defaults, and JES2 defaults:

• 1. JCL specification on a user job.

  The user JCL overrides:

• 2. JCL default, which MVS uses if there is no user definition or the user specification is disallowed.

  The JCL default overrides:

• 3. JES2 default, which MVS uses if:

No JCL default exists

The user specification is disallowed or undefined

The JCL default definition is not supported.

Note that the user can override the JCL defaults and the JCL defaults can override the JES2 specifications, but the ability to override is either permitted or disallowed by specifications that only the system programmer can control. This structure thereby puts the system control in the hands of the system programmer, not the individual user who is submitting the job. JES2 becomes the base for input and output specifications that can then be overridden, as allowed by your installation, through the JCL and job submittor.

IBM provides two JESs from which to choose: JES2 and JES3. In an installation that has only one processor (computer), JES2 and JES3 perform similar functions. That is, they read jobs into the system, convert them to internal machine-readable form, select them for processing, process their output, and purge them from the system. However, for an installation that has more than one processor in a configuration, there are noticeable differences in how JES2 exercises independent control over its job processing functions. That is, within the configuration, each JES2 processor controls its own job input, job scheduling, and job output processing. In contrast, JES3 exercises centralized control over its processing functions through a single global JES3 processor. This global processor provides all job selection, scheduling, and device allocation functions for all the other JES3 systems. The centralized control that JES3 exercises provides: increased job scheduling control, deadline scheduling capabilities, and increased control by providing its own device allocation. To gain a more complete understanding of the functional differences between JES2 and JES3, refer to JES2 V4 Initialization and Tuning Guide and JES3 V4 Initialization and Tuning Guide.

The remainder of this book provides an overview of the processing configurations that JES2 supports, the functional capabilities of JES2, the ability to customize JES2 to meet your specific processing needs, and the means by which JES2 communicates its status through messages and diagnostic information. Each topic is discussed briefly here.

JES2 Configurations

You can run MVS in your installation in many processing configurations that range from a single base control program with a single JES2 that is completely isolated from other processing systems to one that is a part of a worldwide processing network. The choice of configuration complexity is yours and generally is a dynamic one that grows as your business needs grow. Basic configurations are:

• Single-processor

• Multiple-system (multi-access spool)

• Poly-JES

• Remote job entry (RJE)

• Network job entry (NJE)

These are discussed in greater detail, with examples, in Chapter 2, "Scope of Control and Configurations."

JES2 Functions

To manage job input/output responsibilities for MVS, JES2 controls a number of functional areas, all of which you can customize to your installation's need. Some of the major functional areas and processing capabilities are:

• Getting work into and out of MVS (input/output control)

• Maximizing efficiency through job selection and scheduling

• Offloading work and backing up system workload

• Supporting advanced function printers (AFPs)

• Running multiple copies of JES2

• System security.

Each of these is discussed in Chapter 3, "JES2 Job Processing and Functions."

Customizing JES2

JES2 has the flexibility to fulfill an installation's unique processing needs. An installation can virtually control every JES2 function. You can perform many customization tasks when JES2 is installed, and you can dynamically customize JES2 whenever your processing needs change. JES2 provides initialization statements, commands, IBM-supplied exit points, the ability to add installation-defined exit points that require minimal source code modification, and the ability to change many commands and system messages, all without the need to modify the IBM-supplied code. Refer to Chapter 4, "Tailoring Your JES2 System," for a more complete description of these customization facilities.

Interacting with JES2

No large data processing system or subsystem can continually operate independently of system programmer or operator intervention. A two-way communication mechanism between the operator and JES2 is required. Based on system workload and device requirements, JES2 must communicate its status to the operator and/or system programmer. JES2 issues messages to communicate job and device status, problem situations, system resource constraint situations, and performance status. Through commands, you can request current status and through the use of various tools you can obtain further information to diagnose and correct problem and system failure situations. Chapter 5, "Interacting with JES2," provides an overview of these topics.

This chapter answers the following questions:

• How does JES2 manage its work? Where does JES2 store its data, and how does JES2 provide data

• Integrity?

• What is spooling?

• What is checkpointing? What processing configurations does JES2 support? What is a multi-access spool complex?

• What is poly-JES?

• What is remote job entry?

• What is network job entry?

The control that JES2 has over certain data sets and devices allows MVS to offload work to JES2. The means by which JES2 maintains these data sets is unique to JES2. Furthermore, the configurations in which JES2 operates range from simple to rather complex. This chapter provides a basic understanding of the JES2 operating configurations; it is important to your complete understanding of the following chapters.

JES2 Data Set Control

JES2 maintains copies of its data sets that contain job and output queues (that is, lists of jobs to be processed by MVS) on direct access storage devices (DASD). Future work is added to these queues and JES2 selects work for processing from them. These data sets and queues must remain current and accurate to maintain system integrity and performance. The following is a discussion of the JES2 spool and checkpoint data sets and the processing JES2 uses to maintain them.

Spool Data Sets and Spooling

Simultaneous peripheral operations online (spool) has several meanings as used in this book and throughout JES2 documentation. Spooling is a process by which the system manipulates its work. This includes:

• Using storage on direct access storage devices (DASD) as a buffer storage to reduce processing delays when transferring data between peripheral equipment and a program to be run.

• Reading and writing input and output streams on an intermediate device for later processing or output.

• Performing an operation such as printing while the computer is busy with other work.

Spool also refers to the direct access device that contains the spool data sets. This definition is generally apparent from the context of its use and should not cause any misunderstanding in the following sections of this book or other JES2 documentation.

Spooling is critical to maintain performance in the MVS-JES2 environment. As noted previously, spooling provides simultaneous processing and a temporary storage area for work that is not yet completed. Once JES2 reads a job into the system, JES2 writes the job, its JCL, its control statements, and its data to a spool data set until further processing can occur.

This chapter answers the following questions:

• During the life of a job, what processing does JES2 do for MVS?

• What are some of the major JES2 functions that make it special?

JES2 is responsible for all phases of job processing and monitors the processing phase. This chapter outlines the six phases and presents an overview of some of the major JES2 functions.

Phases of Job Processing

The base control program and JES2 share responsibility in the MVS system. JES2 is responsible for job entry (input), the base control program for device allocation and actual job running, and finally JES2 for job exit (output).

The job queues contain jobs:

• Waiting to run - conversion queue

• Currently running - execution queue

• Waiting for their output to be produced - output queue

• Having their output produced - hard-copy (print/punch) queue

• Waiting to be purged from the system (following completion of all

• processing) - purge queue.

Input Phase

JES2 accepts jobs (in the form of an input stream) from input devices such as card readers, remote terminals, or other programs. Input streams can also come from other nodes in a job entry network and from internal readers. An internal reader is a program that other programs can use to submit jobs, control statements, and commands to JES2. Any job running in MVS can use an internal reader to pass an input stream to JES2, and JES2 can receive multiple jobs simultaneously through multiple internal readers.

MVS uses internal readers, allocated during system initialization, to pass to JES2 the job control language (JCL) for started tasks, START and MOUNT commands, and TSO LOGON requests.

The system programmer defines internal readers used to process all batch jobs other than STCs and TSO requests. JES2 initialization statements define these internal readers which JES2 also allocates during its initialization processing. The internal readers for batch jobs can be used for STCs and TSO requests, if not processing jobs.

As JES2 reads the input stream, it assigns a job identifier to each job and places each job's JCL, optional JES2 control statements, and SYSIN data onto DASD data sets called spool data sets. JES2 then selects jobs from the spool data sets for processing and subsequent running. Refer to "Spooling" in Chapter 2, "Scope of Control and Configurations" for an explanation of spool data sets and the concept of spooling.

Conversion Phase

JES2 uses a converter program to analyze each job's JCL statements. The converter takes the job's JCL, merges it with JCL from a procedure library (such as SYS1.PROCLIB), and converts the composite JCL into converter/interpreter text that both JES2 and the job scheduler functions of MVS can recognize. JES2 then stores the converter/interpreter text on the spool data set. If JES2 detects any JCL errors, JES2 issues messages, and the job is queued for output processing rather than run. If there are no errors, JES2 queues the job to run according to its priority within its job class. JES2 supports multiple converters; therefore, jobs may not always be processed in a first-in-first-out (FIFO) order.

Processing Phase

In the processing phase, JES2 responds to requests for jobs from the MVS initiators. JES2 selects from a job queue jobs that are waiting to run and sends them to MVS.

By recognizing the current processing phase of all jobs on the job queue, JES2 can manage the flow of jobs through the system.

JES2 Job Scheduling: To process the jobs on the job queue, JES2 communicates with an initiator. An initiator is a system program that either the operator starts or that JES2 starts automatically when the system is initialized. An initiator starts a job by allowing it to compete for system resources with other jobs that are already running.

The initiator requests a job from JES2. JES2 selects jobs based on the job class(es) that are assigned to the initiator and the priority order in which the job classes should be searched. When JES2 selects a job, it passes it to the initiator. Associating each initiator with one or more job classes in this way allows an installation to control job selection to encourage a more efficient use of available system resources.

After JES2 selects the best job from available jobs and passes the job to the initiator, the initiator invokes the interpreter to build control blocks from the converter/interpreter text that the converter created for the job.

The initiator then allocates the resources specified in the JCL for the first step of the job. This allocation ensures that the devices are available before the job step starts running. The initiator then starts the program requested in the JCL EXEC statement.

Priority Aging: When all initiators are busy, throughput of certain jobs might fall below normal expectations. To help in these situations, JES2 uses the additional scheduling function of priority aging. Priority aging can help ensure that jobs that have been waiting to run have a chance of being selected to run before those jobs that just entered the system. By using priority aging, an installation can increase the priority of a waiting job. The longer the job waits, the higher its priority becomes, up to a limit, and the greater its chances of being selected to run.

JES2-Base Control Program Interaction: JES2 and the base control program communicate constantly to control system processing. The communication mechanism, known as the subsystem interface, allows MVS to request services of JES2. For example, a requestor can ask JES2 to find a job, do message or command processing, or open (access) a SYSIN or SYSOUT data set. Further, the base control program notifies JES2 of events such as messages, operator commands, the end of a job, or the end of a task.

Output Phase

JES2 controls all SYSOUT processing. SYSOUT is system-produced output; that is, all output produced by, or for, a job. This output includes system messages that must be printed, as well as data sets requested by the user that must be printed or punched. After a job finishes, JES2 analyzes the characteristics of the job's output in terms of its output class and device setup requirements; then JES2 groups data sets with similar characteristics. JES2 queues the output for print or punch processing.

Hard-Copy Phase

JES2 selects output for processing from the output queues by output class, route code, priority, and other criteria. The output queue can have output that is to be processed locally or output to be processed at a remote location (either an RJE workstation or another node). JES2 handles each of these situations in different ways:

• Local Output:

  When output is to be processed at a local or remotely-attached output device, JES2 uses these local and remotely-attached output devices to produce a job's output. JES2 queues a job's print and punch data sets on the output queue for the local and remote output devices. The active devices, that are attached locally or through RJE connections, select the output data sets with characteristics that best match their selection criteria.

• Network Job Entry Output:

  Job output passing through to another JES2 node resides on the network output queue. JES2 selects a job's output from the network output queue for transmission to another node based upon the priority and the desirability of reaching the output-processing node over the available transmission line. After the receiving node signals that it has accepted total responsibility for the output, the transmitting JES2 node releases the resources used to represent the output. After processing all the output for a particular job, JES2 puts the job on the purge queue.

Purge Phase

When all processing for a job completes, JES2 releases the spool space assigned to the job, making the space available for allocation to subsequent jobs. JES2 then issues a message to the operator indicating that the job has been purged from the system.

JES2 Capabilities and Functions

JES2 (in conjunction with VTAM (*)) is the link between the Time Sharing Options/Extensions (TSO/E) user and MVS. As such, it is very externally oriented. That is, it is visible to the data processing personnel and provides the ability to specify and tailor many installation-specific functions through JES2 initialization statements and JES2 commands. These statements and commands are analogous to the knobs, buttons, and handles with which you control a machine. You set them, knowing what response the machine will provide, but you need not be concerned with how the button sets the gears and belts in motion.

This section provides an overview of the following major functions JES2 provides to manage its job input/output responsibilities for MVS; all of which are under system programmer control:.

• Getting work out of MVS

• Selecting work to maximize efficiency

• Offloading work and backing up the system

• Supporting advanced function printers

• Providing security.

All are discussed in greater depth in JES2 V4 Initialization and Tuning Guide.

(*) VTAM is a trademark of IBM Corporation.

Getting Work Out of MVS

As the central point of control over the job output (or exit) function, JES2 controls output devices: local and remote printers, punches, and card readers. You can use JES2 initialization statements to define each device. All are directly under JES2's control with the exception of those printers that operate under the Print Services Facility (PSF). These printers provide all-points-addressable capabilities, and although defined by JES2, are driven by PSF. PSF thereby assumes the processing overhead that JES2 typically performs to support printer operation. (Refer to "Supporting Advanced Function Printers," for an introduction to PSF.)

Printed and punched output can be routed to a variety of devices in multiple locations. The control JES2 exercises over its printers ranges from the job output classes and job names from which the printer can select work to such specifications such as the forms on which the output is printed. This control allows the system programmer to establish the job output environment most efficiently without causing unnecessary printer backlog or operator intervention.

Through JES2, the installation defines the job input classes, reader specifications, and output device specifications. As a result, JES2 is the central point of control over both the job entry and job exitphases of data processing.

Selecting Work to Maximize Efficiency

To minimize contention for output devices, JES2 allows the installation to define work selection criteria that can be specific for each output device (local and remote printers and punches and offload devices). The work selection criteria on the respective device initialization statements define the:

• Specification of job and output characteristics that JES2 considers when selecting work for an output device

• Order of importance (priority) of the selection characteristics

• Characteristics of the printer and job that must match exactly.

JES2 initializes the setup characteristics of a device based on the specifications supplied on a device (printer/punch) initialization statement.

A job's output is grouped based on the data sets' output requirements. These requirements are defined by the job submitter with the job's job control language (JCL) or by JES2-supplied defaults.

When selecting work to be processed on a device, JES2 compares the device's characteristics to the output requirements associated with the pieces of work awaiting processing. In addition, JES2 compares each piece of work against all others to determine the best match for the device. If work output requirements are found that match a device's characteristics, JES2 sends the output associated with that piece of work to that output device. If a piece of work and an output device cannot be paired, the work will not be selected for output until the operator changes the output device specifications or the output requirements for the piece of work.

Work selection control provides efficient use of output devices by allowing them to print or punch specified output classes without requiring continual operator intervention of setup characteristics such as forms or print trains (the piece of hardware that carries the print type). Also, when too much work is adversely affecting system performance, the system programmer or operator can specify work to be offloaded (that is, moved off the work queues and temporarily out of contention for system resources. Refer to the next topic, "Offloading Work and Backing Up the System" for an explanation of offloading.)

Offloading Work and Backing Up the System

All input jobs and system output are stored on spool. JES2 gives your installation the capability to offload data from and later reload data to the spool. This is useful if you need to:

• Preserve jobs and SYSOUT across a cold start, which entails the total rebuilding of work and output queues.

• Migrate your installation to another release of JES2. (You can use spool offload to reload the spool to the new or previous release.)

• Converting to another DASD type for spool.

• Archive system jobs and SYSOUT.

• Relieve a full-spool condition during high-use periods. (You can reload at a later time.)

• Provide a back-up for spool data sets.

• Back-up network connections.

Many selection criteria can be used to limit the scope of the spool offload operation. For example, work can be selected based on: a system on which the job is to run, job number, job disposition (for example, only held data sets), destination, class, or many other criteria. These selection criteria can be changed by operator command following your initial specification with JES2 initialization statements.

Providing Security

Security in a data processing environment involves controlling and auditing access to resources that are important to your installation. In the JES2 environment, these resources include:

• JES2-owned data sets Input (from nodes, remote workstations, readers, offload devices, and commands)

• Job names

• System input/output residing on spool (SYSIN/SYSOUT) Output (to nodes, printers, punches, remote workstations, and offload devices).

JES2 provides a basic level of security for some of these resources through initialization statements. For example, each node in a network can be defined as having a certain level of control over work at each of the other nodes in the system, which can give one operator limited control over each of the other nodes. This level of control is based on mutual agreement between the nodes and the degree of trust one node has for the other's security procedures.

The control available through initialization statements can be broadened by implementing several JES2 exits available for this purpose. You can implement a more complete security policy by using the system authorization facility (SAF) component of the base control program and a security product such as Resource Access Control Facility (RACF). SAF provides a link to the security product to define any additional security controls your installation may require.

JES2 passes information to SAF to perform password validation, to request authority to access a resource, and to determine security information in various environments. When SAF and the security product indicate a decision on a security request, JES2 bypasses its own security processing.

Supporting APPC

JES2 processes SYSOUT data sets for APPC transaction programs, which are application programs that communicate with other APPC transaction programs through the Advanced Program-to-Program Communication/MVS (APPC/MVS). For details about APPC/MVS, see MVS/ESA SP V4 Planning: APPC Management. SYSOUT processing is the only function JES2 provides for APPC transaction programs.

This chapter answers the following questions:

• How does the data processing staff communicate with JES2?

• How much control do operators have over JES2 once it is running?

• Are there ways to automate some of the routine processing needs?

• If JES2 experiences problems, how will it inform the operator?

• Are there any tools available to assist diagnosis and recovery?

JES2 Operations

To help you maintain your overall work environment, JES2 provides an interactive means to control much of its function and the devices under its control. Although the JES2 environment is initially determined through initialization statements, you can alter many of those definitions as the system's workload changes or your installation adds new devices or needs to redefine its overall configuration. JES2 provides commands to request current status of devices and functions and JES2 responds with informational messages. Based on those messages, the operator, system programmer, or automated operations program, such as NetView or Automated Operations Control/MVS (AOC/MVS), can issue further commands to change processing (such as, implement a newly written exit routine), start or stop a printer, or start diagnostic functions (such as the JES2 trace facility). Much of the processing can be changed without disrupting the remainder of the system. The following sections provide a brief overview of the control you have over JES2. (Refer to JES2 V4 Commands for an explanation of JES2 commands, and JES2 V4 Messages for the text and explanation of JES2 messages.)

Operator Control

Almost all JES2 initialization statement definitions can be changed by operator commands. These commands are available to both operators and system programmers to allow them to change current definitions. The system programmer can implement certain security features or customization techniques to limit the degree of control an individual or group can have over the operating system.

As your JES2 complex becomes more sophisticated, you might connect your system to others to form a network of systems. You can use operator commands to control the lines that connect the separate systems as well as defining the separate systems to yours. This is typically a very dynamic environment, as different systems are added or deleted from the network due to maintenance, hardware reconfiguration requirements, workload balancing, or the need to access a data base at a different location. JES2 permits you to use commands to alter most of your original network definition, as required.

If this dynamic control were not available, the operator or system programmer would need to change the initialization data set definition, stop JES2 processing, and then restart the system so those changes can take effect. This is, of course, required when redefining some areas of processing, but it denies system users valuable time.

Stopping and Restarting JES2

However, there are instances when JES2 must be stopped and restarted either by a warm or cold start. For example, redefining the number of systems in a network job environment requires a warm start. A warm start is a restart of JES2 that does not cause the current work and output queues to be rebuilt, but does provide the required changed information to be propagated and used by all necessary components. A warm start is far superior to a cold start.

The definition (or redefinition) of some JES2 facilities and resources require that the JES2 system be totally shut down. JES2 must be restarted with a cold start to allow all component systems to be aware of the changed facilities and resources. A cold start is a JES2 restart that causes all current work and output queues to be lost and rebuilt with new data. The time to restart JES2 in this manner is based on the work in the system and, if not scheduled, cause a disruption in data processing services.

JES2 Commands

JES2 processes its initialization statements and commands in a way that allows most initialization statements to be changed by operator command. The following is a partial list of the control that JES2 commands have over JES2 processing. Operator commands can be used to:

• Add function and functional subsystems

• Modify previously defined processing, such as: output definition, the dynamic alteration of the checkpoint definition, enabling installation-defined exits, offload devices, printer and punch characteristics, and job characteristics

• Delete function, and network systems, exits, and diagnostic traces

• Start, stop, and halt devices under JES2's control

• Assign units to local printers, punches, card readers, and lines or reassign units to these devices

• Display current facility and device definition.

All JES2 commands are entered using standard MVS command interfaces (such as through an MVS console or within the JES2 initialization data set). The command prefix character, which defaults to a dollar sign ( $ ), distinguishes JES2 commands and messages from other components of the operating system. For commands, the prefix character defines the scope of the command as being JES2 only; for messages, the prefix character is informational in that it designates that the message was issued by the JES2 component.

JES2 Messages

Similar to all components of the MVS operating system, JES2 maintains its own set of informational and error messages. Each is typically prefixed by $HASP. That is, the HASP prefix is constant; however, you can change the dollar sign ( $ ) to another character. You must alter the prefix character for a secondary JES2 (which you might have if, for example, the primary JES2 supports normal production work while the secondary supports a test system). To distinguish between messages issued from the two systems, JES2 provides the ability to set the symbol to another unique character. The prefix symbol can also be changed to provide for national language support. For example, the pound sterling symbol ( £ ) is often the symbol of choice in England.

There are approximately 500 JES2 messages in the range $HASP000 to $HASP949. (Each is documented in JES2 V4 Messages.) Message text ranges from the $HASP000 message that simply reads OK (indicating that your request was received) to messages, such as $HASP095 JES2 CATASTROPHIC ERROR, CODE=$K04, that indicate JES2 has experienced a serious error that needs to be corrected immediately if processing is to continue. To assist the operator or system programmer, documentation for each message contains information such as: an explanation of the message text, the action that the operating system takes, and the recommended operator and/or system programmer responses.

Message numbers in the range $HASP950 through $HASP999 are reserved for your use. You can add installation-written messages by using the JES2 message build facility or the table pair facility. (Refer to JES2 V4 Customization for details on implementing the table pairs and the message build facility through use of JES2 macros.)