z/OS and Friends: JES—One of the Most Important Base Elements of z/OS
Joe Gulla explains how the Job Entry Subsystem (JES) contributes to the overall functionality of z/OS, outlining the five main characteristics of JES2
Early in my programming career, I didn’t know about the Job Entry Subsystem (JES). Never heard of it and never created my own Job Control Language (JCL). When I discovered JES and became a JCL wizard, I immediately appreciated two things about it.
Two Things about JES
First, JES has a nearly perfect name. It is a subsystem (a privileged class of programs) and it is focused on job entry, which means getting jobs, work for z/OS, into the system. I thought that a more “perfect name” might include more of what JES does, including job entry, job scheduling and output handling using the spool dataset (JEJSOHUSD). I think we know why the name is JES—it is simpler that way.
Second, JES is a great example of the division of duties now commonly deployed in software architecture. At the time JES was created, this division of duties approach was emerging and “under development.” By “commonly deployed architecture,” I mean that there are so many functions that are required of a general-purpose computer that the commonly acceptable way to supply the needed functionality is to break the functions into smaller chunks. Since JES is about Jobs, it has the get-the-work-into-the-system, schedule-the-work and manage-the-output chunks. This is a gross simplification, but you get the idea. z/OS is full of base elements like JES that contribute their part in making z/OS highly functional and responsive.
Many Parts in an Operational and Programming Framework
There are a lot of parts in JES to consider, things that make it up, and I will use them to create a description of JES functionality. Here is a diagram of JES that defines two sides that I will use in this and the next article. From this point on, I will use JES2 for my ongoing discussion, as JES3 will be discussed in the next article. In all candor, JES2 and JES3 have many functions in common, the main difference being the context or handling of some of those functions. The differences are subtle but easily explained, as you will see in the next article.
Operational Dimension of JES2
The operational aspects of JES2 are the domain of system programmers and computer operations. What are the operational parts? I will discuss five main characteristics of JES2 to help tell one side of this job entry base element story.
1. Started Task
JES2 is a started task (STC) with subsystem privileges and is defined in the IEFSSN (subsystem) member of SYS1.PARMLIB — SUBSYS SUBNAME(JES2) PRIMARY(YES). JES2 has its own JCL just like other STCs and jobs. WAIT A MINUTE! If JES2 has its own JCL and JES2 is not running, what “handles” the JES2 JCL? Interesting question, right? Moving on …
Other started tasks and jobs need JES2 to be initialized and running so it starts up early in the initial loading of the system. In the past, the system operator issued the start command to bring it up. Today, automation software usually does the job. After JES2 is running, the automation software starts up all its dependent jobs and started tasks, for example, z/OS Cryptographic Services (ICSF), Open MVS (OMVS), Automation Manager, System Automation Data Store, NetView, Spool Display and Search Facility (SDSF), SDSFAUX (SDSF Add-on), Resource Measurement Facility (RMF), Resource Access Control Facility (RACF), Time Sharing Option (TSO), Hierarchical Storage Manager (HSM), IBM Health Checker for z/OS (HZSPROC), Transmission Control Protocol/Internet Protocol (TCPIP) and Virtual Telecommunications Access Method (VTAM). In total, there are dozens of programs supported as shown in this IBM Z System Automation policy documentation. Automation support includes start-up, recovery and shutdown using an order that reflects the dependency of the related systems. There is also automated resource recovery associated with the jobs and started tasks. The software responds to resource-related error messages or initiates active monitoring of resources, not unlike what a human operator would do.
2. Initialization Parms
JES2 has a set of start-up parameters that are used to bring it up with attributes and behaviors that are specific to the customer needs. The granularity of the input parms has grown over the years as these definitions are the main way that mainframe customers can tailor the operations of the software. The parms include the answers to questions like what job and output classes are used and what are the local devices supported by JES2? JES2 is flexible, so most initialization parms can be changed or added dynamically through operator commands, but there are a few that are not dynamic. Check out the z/OS JES2 Initialization and Tuning Guide, page 4, Table 2 for a detailed view of the JES2 Initialization Parameters.
3. Operator Commands
Operators and automation software can communicate with JES2 while it is up and running. The operator commands are line-mode inputs. The commands themselves start with $ followed by characters that represent an action, for example, $P O JOBQ, /Q=S, /Days >4, which means purge class S output files older than 4 days. If operators are expected to issue commands like this to do housekeeping duties, there will invariably be a cheat sheet. However, automation software can have traps set for JES2 messages that indicate that housekeeping needs to be done and automatically do it. Of course, it only does it if permitted to do it through the administration of the automation product. All this needs to be coordinated human-to-software and software-to-human.
4. SDSF
The Spool Display and Search Facility (SDSF) is an optional feature of z/OS. With it, operators and other authorized users can use a display screen to interact with z/OS and JES2 instead of line-mode commands. It has an easy-to-use interface that helps you display and control jobs and output, devices, system resources, system information, system log messages (and action messages), address space storage and data sets used by the z/OS like Authorized Program Facility (APF) and the Link List, a concatenation of data sets containing load modules (LNKLST).
You invoke SDSF from TSO or ISPF and you are off to the races (if you have the security authorization to ride a horse). Below is a screen capture of the main SDSF panel. It tells you what you can do—DA, I, O, H, ST, etc.—just put those commands where it reads Command Input ===>
5. Resources
There are a number of important JES resources or attributes to know about. Three examples include the multi-access spool, network and SMF.
Multi-Access Spool
This is where output goes. A JES2 Multi-Access Spool (MAS) is a configuration within a z/OS sysplex where multiple JES2 systems can share the same spool data sets, allowing them to access and process job output from any system within the sysplex. The main benefits are load balancing, high availability and simplified management.
Network
JES2 leverages networks as needed. Networking supports the ability to transfer jobs between different mainframe systems (nodes) across a network using the Network Job Entry (NJE) protocol. This allows for distributed job submission and execution across a network of z/OS systems, supporting both SNA and TCP/IP protocols for communication.
SMF records
Records are generated so that analysis can be done on the operation of the JES2 system. To monitor JES2 activity using RMF, primarily look at SMF record types 26 (Job Purge), 43 (JES2 Start), 45 (JES2 Withdrawal), and 47 (JES2 Signon/Start Line), which are all considered part of the RMF record range (typically SMF record types 70-79) and provide detailed information about JES2 job management and system events.
What is Next?
In the next article, I’ll continue the discussion of JES with the programming aspects of JES and a survey of the history of JES and a JES2 and JES3 comparison.