This chapter describes the operational differences between JES3 and JES2 and the changes that need to be considered from an operational perspective. The following topics are covered:

The behavior of JES2 and JES3 reflect their history and the fact that JES3 was designed from the beginning to work in a configuration with multiple systems. JES2, alternatively, was designed to work in a single-system environment, then subsequently enhanced to work in an environment with multiple systems. Additionally, the early development, when the fundamentals of both products were established, was carried out by different parts of IBM. As a result, the operating environment in JES3 is quite different from that in JES2. For example, JES3 presents the operator with a single system image, while the systems in a JES2 environment appear as independent systems. Also, partially because of the centralized design of JES3 and partially because of the independent development, the command set used by the two products is also completely different. This chapter describes these, and other, operational considerations.

All JES-related work in a JES3 complex is controlled by the Global. The pre-execution setup work is done by the Global, and the decision about which main each job will run on is also controlled by the Global. In fact, if you refer to Table 3-1 on page 54, you will see that, apart from the actual execution of the job, nearly all other activity from the point the job is initially submitted through to when it is purged is controlled by the Global. From an operator’s perspective, this gives a JES3 complex very much of a single system image. Even though the work is being run on all systems in the complex, all operator interactions are with the Global.

By contrast, in a JES2 environment, every system is independent. The only aspect of JES2 operations that has a single system image feel to it, is anything to do with management of the checkpoint (because all systems in the MAS use the same checkpoint) and management of files in the spool (because all systems typically share the same set of spool data sets). All other aspects of controlling the environment are managed separately on each system.

For example, a printer could be attached to any member of the MAS and must be controlled from that member. And if you want to change the number of available initiators on a system, you would do that from that system.

Technically, this is not very difficult. However, it does require a change in mindset, and might take some time for the operators to get used to. Try to configure your test systems to look like the production systems to give the operators a chance to get used to the different way of managing the environment before migrating the production systems to JES2.

Perhaps the most obvious difference between JES2 and JES3 from an operator’s perspective is that the commands used to control the two environments are completely different. Many of the concepts are common across both JESs (the idea of a spool, print queue, execution queue, starting and stopping initiators, starting printers, managing the NJE network, and so on), but the commands used to control the environments look very different.

Fortunately, most installations use additional products, such as System Display and Search Facility (SDSF), to manage their JES environment. For those products that support both JES2 and JES3, the operators can continue to use a tool they are familiar with.

Nevertheless, it is not possible to completely shield the operators from the underlying commands, and there will be some actions that require issuing JES2 commands directly, rather than using a tool like SDSF. Therefore, it is important that the operators and system programmers are familiar with the JES2 command set. They will also need to understand that some concepts that they are familiar with in JES3 will not carry over to the JES2 environment.

The following sections contain a brief description of the differences. A summary list of the more useful and common commands and their differences can be found in Appendix B, “Comparison of JES3 and JES2 commands” on page 233. There is also a valuable comparison of JES3 to JES2 commands on the following website:

JES3 commands entered by the operator on any system in a JES3 complex are generally directed to the Global processor regardless of which system in the complex they are issued on. JES3 commands usually start with * for Global processing, or 8 for Local processing. The JES3 Global processes any commands that are directed to it and returns the response to the operator on whichever system entered the command.

In a JES2 environment, the commands are always processed on the system they are entered on, unless you use the MVS ROUTE command to route them to another system. JES2 commands are prefixed by the console character that is defined by the CONCHAR= parameter on the CONDEF statement in the initialization deck. The default, ‘$’, is used in most installations. Unlike JES3 commands, spaces are ignored within the command when entering JES2 commands.

You can also stack multiple commands by entering a ‘;’ between the commands, for example:

Like JES3, JES2 uses filtering in its commands and does keyword limiting. For example, the command $T O JOBQ,/FORMS=123,FCB=456 would modify all output with FORMS=123 and change it to FCB 456. Filtering is required on some commands and parameters so that any commands that would result in massive changes are verified before execution. For example, if an operator missed the ‘/’ in the above command, the response would indicate that a filter is required.

In JES3, this is achieved by having defaults limiting the output for the command and using N=ALL to override.

There is a subtle difference in the JESs in how syntax checking is performed on JES commands.

In JES3, the command is syntax checked before executing the command, while in JES2 the command is syntax checked during its execution.

For example, an operator enters the following command on a JES3 system. See Example 9-1.

On a JES2 system, the syntax is checked during execution and can be stacked using the ‘;’ command as shown in Example 9-2.

In this example, you can see that even though the second of the three commands contained a syntax error (it should have contained LONG instead of LIST), it is ignored and the parser continues with the third command in the stacked string.

MVS originally had just 16 route codes for console messages. You can use route codes to control which messages are sent to a physical console. However, it was felt that 16 route codes did not provide sufficient granularity, so the number of route codes was increased to 128, with route codes 43 - 128 being used by JES3. Through the JES3 inish deck, you can cause messages pertaining to the various JES3 functional areas, systems (mains), and devices to be assigned to particular route codes, allowing the messages to be easily partitioned to specific operator consoles. No such capability exists within z/OS or JES2. JES3 console support and JES3 exploiting MCS console support is far better at subsetting responsibilities among operators than z/OS and JES2. Of course, back in the 1970's there were far more processes (mounting tapes and controlling printers) that required manual intervention. Also, the use of automation was only in its infancy then. While this capability still exists in JES3, most installations probably no longer require it, and the use of automation consoles is probably a more effective means to inform operators about any manual intervention that might be required.

OPERLOG is similar to JES3 DLOG in that it provides a consolidated log for all systems in a sysplex. Because DLOG does not exist in JES2, and OPERLOG is common to JES2 and JES3, start the migration to OPERLOG now to get the operators familiar with the new format in advance of the migration to JES2.

Another thing that you need to consider is any processing that you do that involves SYSLOG or console messages in general. Message Processing Facility (MPF) is cognizant of whether it is operating in a JES3 complex. If MPF on a JES3 Local processes a message, a bit gets set in the message and the message will then be ignored by MPF on the Global. If the message is not looked at by MPF on the Local, it will be looked at by MPF on the Global. The reason for this behavior is that the MPF that is the closest to the message issuer is best equipped to make a decision about the message, but some messages might be best handled across the complex (because there are complex-wide ramifications) by MPF on the Global. There is no comparable hierarchy provided in a JES2 environment. IBM recommends that IBM NetView® in a JES3 environment be set up similarly, with decisions that can be made at the local level being handled on the Local, and decisions that require a wider purview be handled by NetView on the Global. Tivoli System Automation is organized like JES3 with a “master” system even when running in a solely JES2 environment. In that respect, it provides a “single system image” that is more akin to how JES3 works.

Automation support and operations will need to be involved in all aspects of a migration from JES3 to JES2. Review each section in this chapter for potential changes to any current automation routines you have. This includes startup, shutdown, and recovery of any JES-related tasks. Begin by examining the initialization messages for JES3 (IAT3011 for start type) and JES2 ($HASP492 start has completed) to the more complex DSI and checkpoint reconfiguration dialog. Most automation products have a separate built-in base configuration and setup for each of the JESs, but if not, you might also need to refer to Appendix B, “Comparison of JES3 and JES2 commands” on page 233.

System Display and Search Facility (SDSF) is a z/OS product that now supports both JES2 and JES3. SDSF originally supported only JES2. The initial JES3 support in SDSF was limited to a subset of JES3 functions, but as of z/OS 1.13, nearly all SDSF functions are available to both JESs.

To extend the product to work with JES3, significant enhancements have been provided such as a JES3 Spool Data Set Browse (SDSB) application programming interface.

Indeed, SDSF (Program Number 5694-A01), a feature of IBM mainframes running z/OS, enables users and administrators to view and control various aspects of mainframes’ operation. These include jobs in execution, job output, status of UNIX System Services processes, system information, workload scheduling, and log files.

SDSF displays data on panels. Commands and actions that you enter on the panels let you monitor and control jobs and system resources. The SDSF Primary Option Menu lists the panels that you are authorized to use. The objects, displayed on the SDSF panels, are initiators, printers and punches, jobs, SYSIN/SYSOUT data sets, and so on. Information for the objects is extracted using formal JES3 or MVS programming interfaces, for example SubSystem Interface calls. Actions against objects are also invoked through formal programming interfaces or operator commands. Most actions generate MVS or JES commands. In a JES3 environment, the MVS system authorization facility (SAF) is required for SDSF security. When a request is made to access a resource, and the profile that protects the resource is not defined, or the associated class is not active, SDSF fails the request. All SAF profiles must be defined and activated in all of the classes that are used for SDSF security.

Most SDSF panels display information in a tabular format. You can scroll the information up, down, right, and left.

SDSF tries to find a balance between providing a common look and feel across the two JESs and supporting the functions that are unique to a particular JES. For example, the SDSF main menu for a JES3 system is shown in Figure 9-1.

And the corresponding main menu panel for SDSF on a JES2 system is shown in Figure 9-2.

You can see that there are small differences between the two, reflecting the differences between JES2 and JES3. For example, the JES2 menu does not have an option for JOB Zero, and JES3 does not have an option for Spool Offload or Resource Monitor, two functions that do not exist on JES3. And where a JES2 system has a MAS option, JES3 has an equivalent JP option to show the systems in the JESPlex.

Obviously, as you drill down within each option, the information that is presented, and the commands that can be used, will be different, reflecting the unique attributes of each JES.

One positive change that you will notice in the JES2 version of SDSF is that far more information is presented about the NJE configuration. Because JES3 uses BDT for SNA/NJE, and BDT does not provide interfaces for SDSF to retrieve the information, very little information is available on the JES3 NJE panels if you are using SNA/NJE. JES2 does not need BDT for SNA/NJE, so SDSF is able to provide a lot more information in its NJE displays.

There are two types of writers in JES3:

A hot writer is invoked by the operator using an *X command. The command can either be issued by the operator or by JES3, depending on how the DEVICE associated with the writer is defined to JES3. If the DEVICE specifies NO for the DYNAMIC keyword in the JES3 initialization deck, the writer is controlled exclusively by the operator. If the DYNAMIC keyword specifies YES and a nonzero value for the timeout, the writer is eligible for an automatic *X by JES3. The writer notifies you when it is waiting for work and remains available for processing, as shown below. The writer waits for as long as the timeout period defined for the device. If no new work becomes available, it will then terminate. You control the writer using the *X, *S, *R, and *C commands. The operator can use the *F,W command to restrict a device to be started only as a hot writer or to change the associated timeout value. If the device is defined with the DYNAMIC keyword set to YES and a timeout value of zero, the device is eligible for a dynamic writer.

A dynamic writer is a writer that JES3 output service starts and its associated device is based on the availability of an output device and the current output data set requirements. After JES3 initialization, the operator must use the *S command the first time you use a device associated with a dynamic writer. After that, printing begins automatically for properly prepared devices that are in the ready state. The operator can use the *S, *R, and *C commands to control dynamic writers while they are active. The dynamic writer will stop immediately after no suitable output is available for processing.

Operations support needs to be aware of the differences in the JES configurations and the implications of monitoring and starting a JES subsystem on each of the respective systems.

In a JES3 environment, operators must know where the JES3 global resides or will be residing and that there is only one system that is designated global at any one time. The initial start of a designated JES3 global system after an IPL will be either a Hot Start or Hot Start Refresh depending on any JES3 initialization stream changes. However, if the start type of the JES3 global is a WARM or COLD, all other systems in the JES3plex must be shut down and IPLed as well. For any of the JES3 local systems, the only option is a local start.

In a JES2 environment, all systems are independent of each other and would not be affected during IPL and start up, even if any other system is having problems unless the affected system also holds the checkpoint lock. This could be either via a hardware reserve or a flag in the lock that denotes the system that is holding the lock. Operations would need to be aware of the process to recover from this situation. A sample procedure for checkpoint lock recovery can be found in Chapter 4, “Checkpoint Dataset Definition and Configuration” in z/OS JES2 Initialization and Tuning Guide, SA22-7532.

From an operator’s perspective, there are only two types of JES2 starts: COLD and WARM. A COLD start is the initial start to format spool and would rarely, if ever, be performed on any subsequent starts. After that, all starts of JES2 are WARM. The reference to other JES2 start types, for example quick or hot, describe if the checkpoint data set is being read and how JES2 was shut down previously, but all are responded to using the same PARM=’WARM,NOREQ’ command.

There might be some instances of errors in the JES2 initialization parameters that result in a WTOR being issued and the operator having to decide how to proceed. Generally speaking, the operator can continue by replying to the WTOR with the corrected parameter statement. An example of this is shown in Figure 9-3.

Automation setup needs to be included as part of the migration checklist. See 10.14, “Automation” on page 141.

The JES2 Checkpoint Reconfiguration Dialog is a procedure that is unique to JES2 due to the criticality and dependency of the checkpoint data sets. It is an interaction with the operator that consists of a series of displays and operator responses. The purpose of the Checkpoint Reconfiguration Dialog is to let the operator move the checkpoint to a different location.

The dialog is typically initiated either by the system programmers when they need to move the checkpoint for some reason, by JES2 itself if it detects a problem with the checkpoint data sets.

Before invoking the dialog, operations would need to be familiar with the setup and configuration of the checkpoint data sets.

A sample JES2 command $D CKPTDEF can be used to display the setup of the checkpoint data sets in the configuration and the sample output of the display can be found in Figure 9-4 for data sets on DASD and Figure 9-5 for structures in the coupling facility (CF).

As shown, it is recommended for an installation to include a primary and alternate checkpoint data set for any errors that occur in the primary and have two NEW Checkpoints for maintenance. The primary checkpoint might also be a structure in the CF and its backup on DASD.

For example, to invoke the checkpoint reconfiguration dialog, the command $T CKPTDEF,RECONFIG=YES is entered as shown in Figure 9-6 with a sample response.

The applicable options to reply are shown as valid responses and the reply would be based on the action required.

A recommendation is to automate the recovery for the checkpoint data sets. The init parm as shown in Example 9-3 can be used.

No matter how the JES2 configuration is designed, operations and system programmers need to become familiar with this critical procedure. For further reference in a typical configuration, the procedure is referenced in detail in z/OS JES2 Initialization and Tuning Guide, SA22-7532.

This procedure would be used in the case of moving the primary and alternate checkpoints to different volumes for maintenance and would be initiated with the command shown in the previous section.

This would occur if there is an I/O error on one of the primary checkpoint data sets. It would be assumed that responses to the WTORs would require assistance from the system programming team to respond.

In JES3, NJE nodes are started automatically when networking is started to another node or when the operator command *NJE NAME=nodename is entered.

In JES2, NJE lines and nodes are not automatically started, so a $S N command might need to be entered (via automation) or put in the automatic command processing or included in JES2PARM. JES2 in z/OS 1.10 introduced a function called Network Monitor that performs an automatic restart of NJE connections at a designated time interval, with a default of every 10 minutes.

A clean, or normal, shutdown of each JES subsystem is preferred and is described.

Two types of procedures might be needed for JES3 global shutdowns based on the requirements and setup of the installation: Normal and Dynamic System Interchange (DSI).

On the JES3 Global, shutting down the JES3 address space would be done with the *RETURN command. It shuts down JES3 and related address spaces and quiesces JES processing for all systems in the JESplex.

If the installation cannot tolerate a JES3 Global outage for longer than the time of a system shutdown and IPL, a Dynamic System Interchange (DSI) procedure needs to be considered or invoked. This procedure can be found in detail in the JES3 commands manual. Each installation must be aware of any applications or configurations that are dependent on the usage of the Global system when this is performed. For example, the JES3 Global system might be the host for the primary AOMGR system or IBM Tivoli Workload Scheduler (TWS) system and operations need to make some changes when this is done. Practicing this procedure, and the reverse procedure to DSI back, is recommended as it might be required in emergency situations to avoid any extended outage.

A shutdown of JES3 on any local system only affects JES processing on that system. All JES3 local address spaces are recycled after a Hot start with refresh in order to pick up any changes from the inish deck.

A normal or orderly shutdown of JES2 implies that you will also be performing a shutdown of the system since a majority of tasks that were submitted under the JES2 subsystem will still be executing on the system. The normal shutdown procedure would include an initial $P JES2 command to start draining the queues. The operator would then proceed to shut down or stop all remaining address spaces. To determine what is remaining, the operator would enter a
$D JES2 command as shown in Example 9-4.

The operator would proceed to shut down all the address spaces remaining and then enter the $P JES2 command again.

If there are still tasks remaining, and the operator or automation cannot determine what remains, JES2 can be shut down using the $P JES2,ABEND command.

Dynamic changes can be made to most of the parameters in either JES configuration. The main difference currently is that there is limited functions to add and deleted JES3 spool volumes, which can be done in a JES2 configuration.

Also, dynamic changes made on JES2 systems might or might not remain across JES2 restarts.

In a JES3 environment, CDS displays the &SYSNAME of all the system names in the sysplex since the &SYSPLEX variable is not supported. When migrating to JES2, the &SYSPLEX variable can then be used.

A recommended positioning move is to convert your DASD configuration to SMS-managed volumes. If this is not done, you will notice that the behavior of DFSMShsm in a JES2plex or mixed JESplex is not quite the same and would need to take this into consideration as well to avoid any unexpected anomalies.

For installations that have not migrated to SMS-managed volumes, the following needs to be reviewed.

In JES2, there are two types of pools: Data set and volume pools, also known as user-defined pools.

In JES3, there is a third type of pool, other than the user-defined pools, known as the general pool. The general pool is composed of primary volumes that are online to the system at HSM startup time for all systems that reference the HOSTMODE=MAIN and the automatic recall attribute. When the primary HSM starts, no further primary volumes can be added using the ADDVOL command or removed using the DELVOL command since these volumes might contain data sets that are being used by jobs by any system in the JESplex.

Even if all volumes and data sets in the installation are SMS-managed, the following still needs to be reviewed for migration purposes.

For any SMS-managed temporary data sets that are not deleted at the end of the job, for example, as a result of a system outage, DFSMShsm attempts to delete them during its backup processing. However, in a JES3 installation, they must be at least two days old before it can be deleted. If migrating to JES2, this might cause some data sets to be deleted earlier than expected when the installation was in a JES3 configuration.

One of the inherent differences in the JESs has always been that duplicate job names and TSO logons are not allowed in JES3. Now in z/OS V2R1 JES3 allows duplicate TSO logons. In JES2, these can be allowed by changing to the parameter DUPL_JOB=NODELAY. If this enabled when the migration is done, there are possible side effects that might or might not be expected in your installation.

Another difference between the two JESs is the location of the job number and job names in message displays. Example 9-5 on page 132 shows the output from a JES3 command to display information about a job. As you can see, in JES3, the job number (JOB62993) is displayed as part of the message text.

Example 9-6 shows the output of an equivalent command in JES2. In JES2, the job number (TSU20886) is shown in the prefix of the message rather than in the HASP890 message text. Operators would need to be aware of where to find this information, and any automation routines or installation-written programs that process syslog would need to be aware of the change.

When JES3 starts, each JES3 passes the symbols on that system, and the value of those symbols, to the other JES3s. This is because in JES3, the JCL for a started task could get interpreted on one system, but be executed on another. So JES3 needs to know the symbols on all systems so that the correct values can be substituted.

If you update a system symbol using IEASYMUP or a similar tool, the updated value does not get propagated to the other systems. So, in a JES3 complex, JCL that gets interpreted on other systems would continue to contain the previous value of the symbol, rather than the current, correct value as updated by IEASYMUP.¹

On a JES2 system, the conversion and interpretation for started task JCL always happens on the system that the started task will run on, so there are no concerns about out-of-date system symbol values being used.

Checkpoint/restart is a function in DFSMSdfp that allows a job to be check pointed at certain intervals so that if the system fails, it can be restarted from the point of the most recently processed checkpoint and avoid a rerun of the entire job.

The difference in the JESs for checkpoint/restart processing is where it is referenced. In JES3 it is specified by the FAILURE= parm on the //*MAIN statement, and in JES2 RESTART=YES on the /*JOBPARM statement.

One of the features for checkpoint processing is a job journal. A job journal consists of a sequential data set on spool with related control blocks for processing if the job is eligible for automatic restart.

In JES2 and JES3, the journal can be specified on the CLASS statements or referenced with RESTART on the RD parameter on the JOB or EXEC statement. However, in JES3, there is another way of specifying JOURNAL=YES by placing it on the MAIN JCL statement, which can override the CLASS statement entry. When the system is restarted, the operator is sent message IEF225D asking if the job should be restarted.

Therefore, during migration, review any JCL that uses FAILURE= or JOURNAL=YES on the //*MAIN STATEMENT and ensure that the class it will use on JES2 has this defined and that the proper RESTART is placed on the /*JOBPARM statement.

To summarize, either set up job classes that require journaling in JES2 or use the RD= parameter of JCL.

There are parameters and commands in JES2 to assist in automating startup of NJE network components including LINES, LOGONs, and NETSERVs. These include using START=YES, RESTART=YES, CONNECT=YES parameters and $E NET, $Z NET, and $S NET commands.

In a JES3 environment, the names for printers are defined on the JNAME= parameter on the DEVICE statement. They can be any 1 - 8 character name with no leading slash (/) and can be grouped with other printers using a Device Group statement (DGROUP).

When converting to JES2, the printer names are defined consecutively as PRT(nnnn) for local printers or Rnnnn.PRn for RJE printers. So for example, the name of the first printer defined is PRT1 or PRT(1) and it can be modified using the $T PRT1 command.