Exit routines need to be packaged into load modules before they can be loaded into the system and tested.

Modules that contain exit routines which execute in the JES2 main task or subtask environment can be linkedited into a load module; these exits should be loaded into private storage. Modules that contain exits in the user or functional subsystem environment can be linkedited together and must be in either LPA or CSA; these exits must be loaded into common storage. Do not linkedit multiple exit points that must be loaded into different areas of storage into the same load module.

You can also link edit your exit routines with HASJES20. When you package your exit routines in this manner, it is required that you use a collection of weak external names for the module names. These names should be the same as the label used on the $MODULE macro of your exit routine. For HASJES20 the “weak external names” are as follows: HASPXJ00, HASPXJ01, ..., HASPXJ31.

You may choose to use one of these packaging techniques exclusively, or you may choose to use both methods in combination, assembling and link editing some routines into the standard JES2 load modules and assembling and link editing others separately and then loading them at initialization. Creating separate load modules for your exit routines is recommended. JES2 never makes unconditional direct references to external addresses or entry points in installation-written code. The association between exit routines and JES2 source code is resolved during initialization, or when processing JES2 commands that dynamically change the installation exit environment (for example, $T EXIT(nnn)).

Figure 1 illustrates a separately linkedited load module for an exit routine and the MIT and MITETBL structure associated with it. JES2 initialization uses this load module and the information in the MIT and MITETBL to initialize the exit routine in the system. The next topic describes this initialization process.

Figure 1. Exit Routines Load Module