This chapter describes the considerations for products that might be impacted by the migration from JES3 to JES2. As one can imagine, there are many products that interact with JES (including products that run on platforms other than z/OS). It would be impossible to create an all-inclusive list of every product. However, to help you identify products that might require your attention, we have listed categories of products, which are based on the type of function they provide.

There are many products, both from IBM and from other vendors, that interact with JES. This chapter presents the different categories that these products fall into. It would not be possible to provide a complete list of all these products, but we hope that listing the different types of products will help you identify all the products in your environment that might be affected.

As you identify each product, consider whether it would still be required after the migration is complete. It might be that the function is no longer required, or, in fact, the product could be removed even if you do not proceed with the migration. Or, it might be that the function provided by the product is provided by some other product in a JES2 environment, an example would be BDT. If the product is no longer required, you can add any cost savings that might result from removing the product to the financial part of your migration plan. From a technical perspective, removing the product means that you do not need to worry about migrating it. It might also make your software management processes a little simpler if there is one less product to manage.

If you determine that the product will still be required, you need to investigate whether any changes will be required to the product in order for it to work with a different JES. Potentially, there might be a separate JES2 version of the product. In that case, you need to determine the financial considerations, and what, if any, migration actions are required. You also need to determine if there will be any changes to the user interface as a result of changing the underlying JES.

You also need to generate a list of any JES exits that might be required by any of these products. Hopefully you are using a standard version of the exit, and the product provides both a JES3 and a JES2 version of the exit. Or, even better, perhaps it does not require an exit at all when running in a JES2 environment.

Take this opportunity to ensure that all products are on supported releases. Enabling new functions in a product (for JES2 support) might uncover problems that you have not encountered before, so it is important that you get support from the vendor. You also need to check to ensure that no new license keys are required as a result of changing the JES.

The remainder of this chapter describes the different categories of products that you are likely to have.

Printing and output management is probably the category that has the largest number of products that interact closely with JES. The good news is that because there are more JES2 than JES3 installations, it is likely that any product you have will work with both JES2 and JES3.

If you use products that exploit JES3 functions such as //*FORMAT PR or PU, work with the vendor to determine what the considerations are for using that product with JES2. Table 4-10 on page 66 provides information about replacing //*FORMAT statements with // OUTPUT statements. However, you need to look at exactly how the //*FORMAT statements are being used and understand any specific requirements of the product in order to get identical results when it is used with JES2.

Another area to review is JES3 printers. A //*FORMAT DEST = NODE.REMOTE will be treated in JES2 as NODE.USERID. JES2 makes no distinction and will be in the same network SYSOUT data set header.

In other terms, JES3 JECL allows a //*FORMAT statement to specify JES3 processing instructions for SYSOUT data sets that are printed. These instructions permit special processing of SYSOUT data sets, such as:

Thanks to the SYSOUT order of overrides, Figure 10-1, a specific FORMAT statement overrides all the other statements, so a specific destination can be expressed for a given DD of a given job step.

On the contrary, JES2 allows only NODE.USERID to be specified as a destination for the entire set of DDs of a specific job step.

Most other end-user externals will not have to change.

If using an output archiving product, be careful of keywords on a JES3 //*MAIN card such as ORG=, that you might be using as an alternative archiving qualifier.

Some products allow one to control spooled output processing, enabling users to view and manage all types of output including batch jobs, started tasks, TSO users, APPC jobs, active tasks, held and non-held output across the input, execution, and output queues. Users can control job output through comprehensive browse, cut and paste, sort, find, print, copy to disk data set, hold, requeue, and delete capabilities. They generally provide functions to both JES2 and JES3 in a comprehensive and equivalent manner. As mentioned in 9.5, “System Display and Search Facility” on page 123, such is now the case also for SDSF.

Batch schedulers such as IBM Tivoli Workload Scheduler (TWS) are likely to have a close relationship with JES.

For one thing, it is probable that they will exploit some JES exits to enable them to monitor job-related activity in JES. Review the product installation guide to determine which exits the product requires, both for JES3 and for JES2. It is possible, although unlikely, that you are not using the function in the scheduler that requires the exits. Determine if you are using the product’s JES3 exits today; if you are, have you modified them or just used the standard exits as provided by the product? This will help you determine what you will need to do in the JES2 environment.

If you are still using Dependent Job Control or Deadline Scheduling under JES3, you will need to find some alternative way to provide that functionality under JES2. The most obvious tool to deliver that functionality is your batch scheduler. Ideally, you will start migrating from those JES3 functions over to the batch scheduler in advance of the migration. Functions such as Deadline Scheduling might require enabling specific features in the batch scheduler, such as the Workload Service Assurance feature in TWS.

Another reason that the scheduler requires your attention is that it is probably the repository for all your production JCL. Scan the production jobs to see if they use any of the capabilities documented in Chapter 4, “JECL and JCL differences” on page 55. If they do, create a plan to migrate those jobs to a mechanism that works in both JES2 and JES3.

Some batch schedulers have a JCL checker integrated into the product. Such JCL checkers typically provide the ability to specify local standards. You might be able to use that function to identify JCL that will not function in the same way in a JES2 environment. At a minimum, you need to tell the JCL checker if it is operating in a JES3 or JES2 environment so that it can treat any JECL it encounters accordingly.

Finally, do not forget to check for any remote scheduling that might be in use. Determine if jobs are being submitted via RJP or NJE. If they are, you will need to check if the jobs being submitted will work in your target JES2 environment.

All IBM mainframe printers support both JES2 and JES3. Refer to Table 4-11 on page 68 for Forms Control Buffer (FCB) considerations.

If you have non IBM JES3-managed printers, consult your vendor to determine if there are any considerations for using the printer with JES2 instead of JES3.

Any non System z product that emulates an NJE or RJP device to communicate with JES must be reviewed for use with running in JES2 versus JES3.

Any product that builds JCL “under the covers” and submits it to your system must be checked. It is unlikely that such products are generating JES3 JECL unless you customized them to do so, so hopefully it will be easy to address any products that are doing this type of thing.

The challenge could be in identifying those products. If the product submits the job through the internal reader, it is difficult to differentiate that job from any other job on the system. You might look at the security ID associated with any started tasks, and then look for jobs submitted under those IDs. Any package that runs under CICS or IMS might submit jobs using the CICS or IMS security ID, so you could look for that as well.

Do not forget to investigate products that run on other platforms that generate JCL for use on z/OS. For example, some software products are client-based and might run on Windows but they interface with z/OS or other vendor software.

SDSF is IBM’s product for viewing and controlling the contents of the spool (see 9.5, “System Display and Search Facility” on page 123). It is also used for starting and stopping JES-managed devices, the NJE network, initiators, and so on. In order to do these things, the product needs to communicate with JES. For many years, SDSF only worked with JES2; now it also works with JES3.

There are similar products from other vendors as well that would also be expected to have an equally close relationship with JES. Such is the case with output viewing software, which equally runs in a JES2 or JES3 environment.

Any product or installation-written program that reads SMF records containing information that is provided by JES2 or JES3 will need to be changed. These are described in more detail in Chapter 16, “Accounting and chargeback considerations” on page 207, but we include them in Table 10-1 for the sake of completeness.

A good starting point would be to look in your SMFPRMxx member to see which of these record types are being collected today. Obviously, if a record type is not being collected, you do not need to worry about any migration efforts for that record type. However, even if you are collecting a given record type, that does not necessarily mean that it is being processed by any programs. Speak to the group that is responsible for processing SMF data to see if they use any of the record types shown in Table 10-1 on page 139. If they do, they need to take actions to process the JES2 version of the records rather than the JES3 version.

JES3 exits, and the JES2 equivalents (if one exists) are described in Chapter 8, “User exits” on page 109. In this chapter, we only mention JES3 exits because any product that uses JES3 exits will need to at least be reviewed, and possibly changed, as part of the migration to JES2. Also, scanning the list of used JES3 user exits might help you spot a product that you might otherwise have missed.

For information about how to determine if a given user exit is being used, refer to 8.1, “JES3 user exits” on page 110.

There are a number of products that provide a JCL checking function. Most products are compatible with either JES2 or JES3, and most of them support customization to let you specify installation standards. These could be used to help flag jobs that use JES3 JECL statements that would need to be addressed before a migration to JES2. The product might also require recustomization at the time of the cutover to tell it that it is now operating in a JES2 environment.

It is unlikely that an application software control product (such as SCLM by IBM) will have a close relationship to the type of JES that is being used. If there are any issues, they are most likely to be related to the use of JECL statements to route the output to a SYSOUT archiving product. Take a few minutes to check the JCL that gets submitted by your application software control product to ensure that it does not use any JCL or JECL statements that would have to be changed before migrating to JES2. Examples would include makefiles, build scripts, and any scripts, where JCL is dynamically built and submitted.

There might be other products that need to know if they are running in a JES2 or JES3 environment.

One example is DFSMShsm. In the ARCCMDxx member, if you are using JES3, you must include a SETSYS JES3 statement (if SETSYS JES3 is not specified, HSM defaults to JES2). HSM uses the information about which JESx is being used to determine which pool configuration rules to use.

If you have products that provide similar functions to DFSMShsm, they might have a similar requirement to know which job entry subsystem they will work with.

Another case is RMF. RMF uses information about which job entry subsystem is being used in order to collect subsystem delay information. Specify the subsystem type (JES3 or JES2) on the RESOURCE statement in the ERBRMF04 member.

Finally, the SMFPRMxx member contains a SUBSYS parameter that lets you tailor SMF processing for address spaces associated with that subsystem. If you use this capability, your SMFPRMxx member will contain a statement something like:

Assuming that you want SMF to continue to work in the same way after the migration to JES2, all you need to do is replicate those statements and change “JES3” to “JES2”.

In addition to formal automation products, automation could include such elements as System Rexx execs, JES commands that are issued from jobs, Tivoli NetView for z/OS, and so on. System automation software products typically include scripting languages or REXX execs to assist in managing day-to-day operations. Many of these products are used on JES3 and JES2 systems. The JCL and code scripts they execute will need to be reviewed for possible changes when doing a migration.

Finally, do not forget to check any installation-written ISPF tools that you might have. Examples would be jobs to run program compiles, print files, generate RACF or performance reports, and so on. Check the standard ISPF data set concatenations, especially the ISPF table and skeleton data sets for JES3 JECL statements that would need to be converted.

When considering a migration from JES3 to JES2, one of the significant costs will be in identifying and modifying JCL/JECL that will not produce the wanted results in a JES2 environment, and in replacing JES3 functions that do not exist in JES2.

Of course, one way to address this is to create your own set of tools to assist with the migration effort. An alternative is to purchase products that will do this for you. Whichever path you choose, the things that your tools will need to address include the following:

There are products in the marketplace that can assist in making the migration from JES3 to JES2 easier and less time consuming. In addition, these products typically provide a rich set of system management functions. Two vendors that are mature in this space are:

These products take different approaches to migration from JES3 to JES2. A key note to make is these products are designed to run in only JES2 environments. They typically will read in and manage current JES3 JCL/JECL statements and translate them to the appropriate JES2 constructs along with other parameters at execution time to be run in a JES2 environment.

The zOSEM product, which stands for z Operation System Environment Manager, is ISPF panel driven to build criteria on how JES3 JECL will be managed running unchanged JES3 JCL in a JES2 environment. In addition, zOSEM allows for a way to manage JES exits and has a feature to better manage HSM.

Thruput Manager AE works on a proprietary script language similar to REXX to manage the execution of JES3 JECL conversion at run time. This product also helps with HSM management performance as well as managing peaks for a 4-hour rolling average.

The product that best fits your requirements will vary with your environment and which functions your shop is using today and in the future.

Remember to create a list of potential products and exits that your installation might be using today. This list will then be reviewed for functionality differences for JES2.