This chapter contains an approach to spell out the similarities and the differences between the JES3 user exits you might be running and how they could be implemented into JES2 exits.

 

Table  on page 113 contains a list of all the JES3-provided user exits and a brief description of the purpose of the exit.

The first step is to identify if you are using the exit or not. Some exits might be written by your installation, others might be provided by products that need to communicate with or monitor JES3: a batch job scheduler, for example.

All JES3 user exits are called IATUXnn. You do not have to do anything in JES3 to tell it that you want to use a given user exit. You simply assemble and link edit the user exit and place the module in a load library that is accessible to JES3. It is strongly recommended that you use SMP/E to manage your JES3 user exits because the macros that they use can be changed by JES3 service. If you do use SMP/E, SMP/E can be used to determine which exits you are using.

If you are not using SMP/E to manage the exits, use the *I_X_M=IATUXnn command to display information about every JES3 exit. The response to this command, as shown in Example 8-1, reports the load module size, the link edit date, and the number of times the load module has been used. This information helps you determine if the exit is in use or not. Note that the IBM provided exit stubs are not all the same size. Some are x’40’ bytes, some are x’80’ bytes, and some are other sizes. The IBM provided stubs reside in SYS1.SIATLIB and SYS1.SIATLPA.

Before you do any work to create a JES2 version of an existing JES3 exit, we strongly recommend reviewing the function of the exit to determine if you still require that function or not. Also, verify that the function provided by the exit would still be required following the migration to JES2 - might be JES2 or some other product provides that function without requiring an exit? Test and updating user exits is one of the most time-consuming activities during system upgrades, so the more exits you can eliminate, the better.

Using Table 8-1, identify the JES2 exit points that correlate to the exit functions that you will still require after the migration.

Because the source code for JES3 is delivered with the product, it is possible that you have made changes to the source. In the past, a common example of such a change was to provide the ability to log on using the same TSO ID on more than one system in the JES3 complex. However, z/OS V2R1 provided that ability to JES3, and it was already available in JES2.

Take an inventory of any changes that you made to the JES3 source, and whether those changes would still be required following a migration to JES2.

You will probably need to change MPFLSTxx to cater for JES2 rather than JES3 messages.