This chapter describes considerations and methods associated with migrating from JES3 to JES2. The first part of this chapter discusses some of the considerations that you might use in the assessment of migration. The second part of this chapter discusses the discovery process in terms of gathering data for analysis to build a business case.

In this chapter the following topics are discussed:

Each installation analyzes their needs regarding JES management. One factor that might help with the decision to migrate from JES3 could be to consider your current configuration with a goal in mind. For example, today your configuration might have separate JESPLEXs on multiple LPARs on separate CPCs. These could have vastly different or similar workloads on them. A goal might be to combine some of that workload to run together based on business needs or capacity exploitation. That being said, it would be simpler to run that new mixed workload in its entirety within either JES2 or JES3.

Through mergers and acquisitions, installations end up with multiple JES systems in their environments. Consider an example of four distinct environments from four different companies who merge. Three of them utilize JES2 and one uses JES3. Based on certain processing requirements it might be desirable to combine batch workloads for business reasons. A need to combine jobs might be focused on capacity workload balancing or system affinity to a particular LPAR. Being able to relate workloads under the same JESPLEX would be of benefit from a system and application management standpoint.

Figure 5-1 shows an example of a billing application that is normally executed in a JES2 environment. But it needs to also run a batch function in the Customer Information Application that executes in the JES3 environment.

To create a solid business case to migrate, you need to do some analysis to set the scope of the effort. In order to accomplish this, there needs to be an understanding, at an application level, as to the magnitude of impact. There are several things that you might want to do in the discovery phase of this migration effort, examples of which are outlined in this chapter. The more you can find out about the systems targeted for migration, the higher the probability of success you will have. This step is vital in figuring out the scope of change for planning purposes.

One of the first things is create an inventory of the JES3 systems that are the subject of migration. This becomes important for later analysis. Review the JES3 functions and features currently being used today so that a corresponding action can be implemented in the JES2 target system. Some things to consider are:

In addition, identifying actual JECL in use for JES3 would be beneficial to analyze as well. Using third-party ISV products or creating a user exit can yield good results for finding this type of information. This helps quantify the scope of changes that might be needed for the target system.

In creating an exit, you want it to be called early in the routine to capture JCL statements before them being modified by any other part of the exit. Here is an example of an exit:

See Appendix A, “Sample JES3 exit to analyze JECL usage” on page 227 for example code of this exit.

IATUX33 was used for this exit and provides a basic scanning for JES3 JECL being called. It tracks events using the existing CNXTRKR component of z/OS. The output of which is not highly formatted due to limitations of 28 bytes. The //*DATASET and //*ENDDATASET do not call IATUX33; therefore, these are not tracked by this exit. A good reference to more information about the tracker component is in z/OS V1R13.0 MVS Planning: Operations, SA22-7601.

To turn on the exit:

To turn if off:

You can clear the Tracker by turning if off and then on.

You can display the data with:

Things to note are the sysid, job name, job number, user ID, and JECL statements.

Here is some sample output from an IATUX33 exit code. As you can see, this can be a useful tool to help identify JECL that could need changing.

Here is what it looks like if it found five //*MAIN cards, three //*PROCESS cards, and one //*ENDPROCESS card.

We have 28 bytes to put into INFORMATION and four bytes for VALUE.

At the time of this writing, the format is to start each entry with “JES3 JECL: “, then write out four characters to identify the JECL called. See Table 5-1 for mapping.

Trying to find out this information without an exit is error prone and time consuming but not insurmountable. Other methods to try to track down JES3 functions comprise multiple steps. The first thing that you can do is review the Initialization deck for JES3 and see if certain functions are defined. MDS or high water setup are examples of this. The problem is even if you identify functions active within a JES3 system, not all applications might be using them. In this case, you must find other avenues to locate information. An additional way is to review the syslog or schedulers for information. Then, use compare software to identify JECL statements. Finally, since there is not an easy automated way to do this analysis without an exit of some kind, it might be necessary to meet with the application teams individually asking them to help inventory what they are using. This can take a long time especially if there are hundreds or thousands of applications to review.

We cover some of the more common JES3 functions from the JECL that will need attention for migration. There will be some items that are not supported by JES2 and other items that might need to be changed to work in JES2. For more information, see Chapter 6 in ABCs of z/OS System Programming Volume 13, SG24-7717:

Also, see the SHARE presentation z/OS Basics: JES2/JES3 JCL/JECL Differences, SHARE Anaheim, Aug. 2012:

See Chapter 4, “JECL and JCL differences” on page 55 of this book for more details about the JECL differences.

One of the more prominent areas to deal with in a migration from JES3 to JES2 centers around the JES3 //*MAIN card. While many parameters might transfer to a JES2 /*JOBPARM or the //JOB statement, some have no corresponding parameter. So it is necessary for the installation to perform a mapping of these parameters to JES2 and JCL. In addition, some items have no equivalent. Some more common parameters that need to be addressed are:

Table 5-2 provides a summary of the parameters.

If you use this in JES3, you will probably have to set up your ALLOCxx member to allow for the fact that JES2 does not provide equivalent functions. For example, how will the system react when a job looks for an offline device?

This function uses the //*NET cards to define dependencies between jobs in a Dependent Job Control (DJC) network. JES3 sets up a network of dependent jobs and executes them in a specific order. If there needs to be a change in one of the network jobs, they all have to be resubmitted. These jobs are also not eligible to be registered with Automatic Restart Manager (ARM).

There is no corresponding function within JES2; therefore, action will be taken to set these jobs up within your installation’s job scheduling package, TWS, CA-7, ESP, with all the triggering, dependency information consolidated in one place. Also, there are products that assist with migration activities. See 10.16.1, “Migration assistance products” on page 142.

The //*FORMAT card is used to tell JES3 what SYSOUT data sets are to be printed. There is special processing with this statement for SYSOUT data sets. The PR suffix of the Format statement applies to only SYSOUT data sets printed by JES3. The statement is ignored for data sets set to a TSO user ID or processed by an external writer.

In place for //*FORMAT statements for JES2, simply code an //OUTPUT statement additionally supplying the destination of the output.

The //*PROCESS statement is used by JES3 to control how a job processes. The job that specifies this only receives the JES3 processing specified on the //*PROCESS statement. It calls a JES3 Dynamic Support Program (DSP) from the DSP dictionary where that process needs to reside. This is a function that is probably best handled by means of an enterprise scheduler product.

The //*ROUTE XEQ statement is used to send input streams to network node for execution on that node. In JES2, //XMIT, /*XMIT, or /*ROUTE XEQ can be used. Under JES2, there might be other job definition statements recognized by the destination node as well. The //XMIT JCL statement transmits a job input stream or other job definition statements. It transmits all records following the XMIT JCL statement to one of the following:

The /*XMIT transmits a job input stream or other job definition statements. This is very similar to the //XMIT statement.

The /*ROUTE XEQ transmits the entire job input stream to execute at the destination. This transmits all records in the job.

For more information about JECL and JCL, refer to Chapter 4, “JECL and JCL differences” on page 55.

Additional components might need to be analyzed to create a plan on how they will be retrofitted into the new target JES2 environment. Review items will include but are not limited to:

While this is not a complete list, it will help in the discovery analysis assessment. This information can be evaluated in helping to determine if you move to the next phase of planning. This discovery analysis process will help you scope the migration effort if you choose to move forward. Again, a business case will be set forth as the reason why a migration effort is in the best interest of the organization. Use the sources listed in “Related publications” on page 235 for more information about JES2 and other documentation to assist in your evaluation.

The development of both JES2 and JES3 took place decades earlier than the IBM Parallel Sysplex. While both work in or with a Parallel Sysplex, JES2 is aligned more with the sysplex natural design of symmetry. JES3 has a global (master) architecture that is not as aligned with the symmetric view that a sysplex has. This becomes more evident in an IBM GDPS® sysplex where the functions are spread across physical sites; in JES2 you do not have to worry where the global is.

There are different reasons that an installation might want to consider migrating to JES2. Regardless, there will be a sound business case to merit the migration. Among the reasons might be to simplify systems software management. By doing so, there would not be a need to maintain two sets of software components (SMPE data sets, applying APARs, PTFs, and other maintenance, including ISV products) for similar JES functionality. This not only consolidates system products in what seems an ever increasing inventory, but helps in the reduction of technical debt. In this case, it reduces dual maintenance.

The term technical debt is a metaphor for the eventual consequences of poor or evolving software architecture or software development. A classic example might be hardcoding functions in programs, which tightly couples them within the application and makes it more expensive and harder to add new functionality. Whereas, if the function was loosely coupled, and certain functions externalized, there would be less work to do and thus less expense in performing the change. Perhaps a user could just make changes themselves via a user interface and the new function is available in significantly less time. This reduces the time to market scenario, which is very important to businesses today. By reducing technical debt, the overall effectiveness and operational excellence of the installation can be improved.

In addition, there might be an associated cost reduction because JES3 is an optional extra cost item with z/OS. This cost varies from customer to customer based on MSUs among other criteria. With TCP NJE as a direct replacement for SNA NJE, this mitigates the use of BDT as well since BDT performed NJE for SNA to a JES3 platform.

Also, there might be other JES3-related products that are not relevant or needed. Alternatively, there might be the need to purchase products to offset functionality that is lost in either JES3 or associated products. In this case, an installation needs to find other means to accomplish similar function. An example might be perhaps using FTP/SFTP or XCOM as alternatives. Evaluation of the functions provided by some of the ISV products would need to be reviewed and validated. This is true since SDSF is now available with JES3 in later releases of z/OS.