z/OS and Friends: What Is the JES Programming Dimension and Why Is It Important?
In the latest from "z/OS and Friends," Joe Gulla looks at the programming side of JES2, including the phases of job processing and how Job Control Lanuage (JCL) was created to "feed the beast"
This is the second article in this two-part series on the Job Entry Subsystem (JES). The first part introduced the operational aspect of JES2, and this article will continue the discussion with the programming dimension of JES2. First, let me explain a bit of history.
JES2 is descended from the Houston Automatic Spooling Priority (HASP) program, which provided supplementary job management, data management and task management functions. This included scheduling, control of job flow and spooling. HASP persists within JES2 as the prefix string for most module names and for all messages sent by JES2 to the operator. For example, “$HASP100 JOB(MYJOB) USER(USERID) DEVNAME(INTRDR)”. This message indicates a job named “MYJOB” submitted by user “USERID” has been received by JES2. This is a simple job submission confirmation. However, these messages, like so many others, were originally designed to be displayed on the operator console. Today, these messages are typically suppressed from display at the system console but still go to the system log and are candidates for automation.
Programming Aspect of JES2
The programming dimension of JES2 (right side of figure 1) is handled by application programmers who create and maintain the JCL for their applications. JCL may also be the domain of production scheduling from computer operations.
Three topics below help to illustrate the programming side of JES2.
1. Phases of Job Processing
The z/OS base control program and JES2 share responsibility in a modern mainframe computer. JES2 is responsible for job entry. The base control program handles device allocation and actual job running. Next, JES2 handles job exit including output processing that might include printing. The steps in the handling and processing of jobs have phases—Input, Conversion, Processing, Output, Hard-copy and Purge. Want to learn more? Here is the next level of detail.
2. Job Control Language (JCL)
For several years, I had the job of teaching MVS Concepts, JCL and Utilities. A two-and-a-half-day “stand up class.” I taught it at IBM customer centers or at customer locations that were undergoing a migration to IBM mainframes. The customer location classes were often challenging because the students were not excited about moving to a new computing platform that required learning many new terms and processes.
When we got to JCL, the learning sometimes got intense, even heated. I used humor to teach. I would say, “What is so hard about JCL, there are just three statements—JOB, EXEC and DD”. This is true. At some point, I would have to back up to 10,000 feet and visit or revisit the “big picture” and then move back to the details about JCL.
The BIG Picture
JCL was created to feed the beast. The beast being the mainframe computer with its hungry CPU and supporting memory and external storage. The mainframe was set up to take action, but an interface with the outside world was needed, so JES and JCL were the solution that was created. At the time JCL was created, applications needed programs that gathered inputs, sorted them and edited them. Next, they performed operations on the data, so-called “transforming data into information,” then produced outputs (or inputs to the next step in a multi-step process).
That is the whole show. No online transaction update or processing was possible as that came later. If you look at it in that historical context, it is a pretty good solution, and all you have to do is master three statements. JCL is still alive and well used with batch jobs and other work that enters the system. By the way, Customer Information Control System (CICS) transactions are not jobs but the software that runs the transactions is a long-running job or started task in the z/OS system. Often much more than one job.
Back to JOB, EXEC and DD Statements
JOB tells JES that this is the beginning of a JCL stream. It is also needed because most companies had some kind of chargeback mechanism, and the JOB statement allows for accounting information to be supplied.
EXEC is needed because it specifies what program is to be executed. Applications use programs that are written for specific purposes like data validation. They also use other programs, called utilities, as needed to sort, copy and create files with specific characteristics. I appreciate the program IEFBR14, which does (almost) nothing but return to the OS after it is invoked. In assembly language, “BR” means Branch to the address in a register. Branching to the address in general register 14 is the standard way to end a program. Pretty useful that it facilitates the creation or deletion of datasets while going through the JES Processing phase.
DD is needed to name the location of data for input and/or output. It answers the questions in what data set is the data for something like weekly payroll processing.
3. Other Inputs
JES2 and JES3 have statements you can add to your JCL stream. They are called Job Entry Control Statements (JECL), and they have a special prefix of /* (versus // for JCL). Here are six examples of 13 possible JES2 statements.
| JECL Statement | Purpose |
| /*$command | Enters JES2 operator commands through the input stream |
| /*JOBPARM | Specifies certain job-related parameters at input time |
| /*MESSAGE | Sends messages to the operator via the operator console |
| /*NETACCT | Specifies an account number for a network job |
| /*NOTIFY | Specifies the destination of notification messages |
| /*OUTPUT | Specifies processing options for sysout data set(s) |
JES2 and JES3 Have Differences
IBM provides two kinds of job entry subsystems: JES2 and JES3. In many cases, JES2 and JES3 perform similar functions, but most installations use JES2. Both JES2 and JES3 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. Some significant differences between the two JES systems include:
1. In a Mainframe Installation That has Only One Processor
JES3 provides tape setup, dependent job control and deadline scheduling for users of the system. JES2 in the same system would require its users to manage these activities through other means.
2. In an Installation With a Multiprocessor Configuration
The differences here are mainly in how JES2 exercises independent control over its job processing functions. Within the configuration, each JES2 processor controls its own job input, job scheduling and job output processing.
3. In Cases Where Multiple z/OS Systems are Clustered (sysplex)
JES2 can be configured to share spool and checkpoint data sets with other JES2 systems in the same sysplex. This configuration is called Multi-Access Spool (MAS). In contrast, JES3 exercises centralized control over its processing functions through a single global JES3 processor which provides all job selection, scheduling and device allocation functions for all of the other JES3 systems.
In 2019, IBM announced that JES3 is planned to be included in z/OS 2.4 and z/OS.next, but not beyond that, customers affected can get more information by emailing JES3Q@us.ibm.com. z/OS.next is the currently available z/OS, 3.1.0, originally released in September 2023. There is migration assistance available from IBM. There are other industry solutions, and an alternative JES3 is available—JES3plus from Phoenix Software.
What is Next?
Next month, I’ll focus two articles on CICS, a product that is hugely important and has helped many customers build reliable real-time systems.