Dynamic Load Module Considerations

When writing new load module or updating an existing module to support dynamic processes, you need to consider the following things:

The data areas that the modules access. You need to consider the following questions:
- Does the module accesses a data area that has been created by the installation?
- How are these data areas created?
- What points to the data area?
- Is the area dynamically obtained or is it an area within the load module?
If the exits and tables only access JES2 and z/OS® data areas, this is not a concern. Also, if the data area is contained within the module and there are no external pointers to the data area, then that also is not a concern. However, if the data area is installation specific and the address is obtained using a pointer external to the load module (such as the $UCT pointer in the $HCT), then you need to consider:
- How is the data area set up? If it is only used by this module, then is a $$$$LOAD routine needed to initialize it?
  Note: See $$$$LOAD Routine for a description of the $$$$LOAD routine.
- Does the code deal with the case where the data area already exists (or does it create a second data area)?
- Is the data area in common storage?
- Does it need to be deleted when this module is deleted or when JES2 terminates? Is a $$$$DEL routine needed to free the data area?
  Note: See $$$$DEL Routine for a description of the $$$$DEL routine.
- Does anything special need to be done if the module is refreshed instead of being deleted?
- If the data area is in the load module, are there pointers that need to be cleared if the module is deleted or refreshed?
- If the data area is managed by an exit 24 (JES2 initialization) and exit 26 (JES2 termination) pair, should that processing be moved to a $$$$LOAD and a $$$$DEL routine?
In general, $$$$LOAD and $$$$DEL routines can solve most data area problems to enssure the proper flexibility to alter the data area as needed.
The creation of installation PCEs (subdispatchable units in the JES2 address space) or DTEs (subtasks in the JES2 address space). If the PCEs or DTEs are defined using dynamic tables or traditional table pairs, the appropriate PCE or subtask is started as part of normal JES2 initialization. However, with dynamic load modules, the installation code decides attaching and detaching the PCEs or DTEs as needed. In general, the simplest way to deal with PCEs and DTEs is to use the appropriate $PCEDYN or $DTEDYN macro to detach the old (existing) PCEs or DTEs in the $$$$DEL routine and reattach them in the $$$$LOAD routine. To ensure that the PCEs can be attached after initialization, be sure to code the DYNAMIC=YES keyword on the $PCETAB macro that defines the PCE.

You also need to consider some other things when creating dynamic load modules:

If you are converting an existing exit to be dynamic, is there logic in exit 24 (post initialization) that should be moved to a $$$$LOAD routine?
If you are converting an existing exit to be dynamic, is there logic in exit 26 (JES2 termination) that should be moved to a $$$$DEL routine?
Does the installation module include code that front ends or replaces a JES2 service? Front ending is the process of replacing the address of a JES2 service in the $CADDR, $PADDR, $HCT or other data area, with the address of a routine in the module and then calling the JES2 service only after the installation routine runs. If so, care must be taken to ensure that the routine addresses are updated if the installation load module is refreshed or deleted. This is especially true at JES2 termination processing since some are called after installation load modules are deleted at JES2 termination.
Note: IBM® recommends that you do not front end IBM services. Designing a function that requires front ending IBM services could limit your ability to exploit future IBM functionality to refresh IBM services dynamically.
Traditional (non-dynamic) tables that are set in the $MCT data area (or other table pairs) must be updated as modules are loaded or deleted. In general, use of non-dynamic tables can be converted to dynamic tables (which JES2 will automatically process). Otherwise, code can be added to the $$$$LOAD and $$$$DEL routines to handle updating these pointers.

If your load module cannot support dynamic processes, there are a number of options to prevent unintended processing:

Setting DYNAMIC=NO on the $MODULE statement of the load module will prevent all dynamic processing for this load module. Initialization processing is not affected. Any $$$$LOAD or $$$$DEL routines in the module will be called out of JES2 initialization and termination processing.
From a $$$$LOAD routine, set the LMT2NDYN bit in flag byte LMTFLG2. The LMT of the module being loaded is passed to the $$$$LOAD routine in the $CSVPARM data area. If done during initialization, this has the same effect as setting DYNAMIC=NO on the $MODULE. However, if the module was not loaded during initialization, using this technique allows the module to be loaded after initialization but not deleted or refreshed later.
If you can support dynamic processes but there are tables or routines in your module that cannot be deleted, then you can set a return code 8 from a $$$$DEL routine. This prevents the module from being physically deleted. You should be careful not to set it for every call to the $$$$DEL routine since if the module is refreshed multiple times, you only need to keep the first copy of the load module in storage. The $$$$DEL processing should determine if the specific copy of the module that being deleted is the one that needs to remain.