DFSMPLxx member of the IMS PROCLIB data set
Use the DFSMPLxx member of the IMS PROCLIB data set to make z/OS®, IMS, or user-written program modules that are not automatically preloaded into the IMS control region resident in IMS regions.
Making some modules resident can improve throughput and response time for transactions frequently referred to if sufficient virtual storage is available with high-performance paging DASD. Ordinarily, preloading modules is advantageous only for MPPs and for message-driven Fast Path regions, and only when the preloaded modules are reentrant.
- If CANCEL_PGM=Y is specified, the program modules that are specified on the DFSMPLxx member are deleted from working storage areas after the program has run. For the program modules that are specified on the DFSMPLxx member to remain loaded when CANCEL_PGM=Y is specified, use the EXCLUDE=proclib_member_name parameter with CANCEL_PGM=Y to exclude the program modules from the delete process.
- Pseudo wait- for-input (PWFI) and wait-for-input (WFI) application programs that are resident in IMS dependent regions cannot be refreshed dynamically. For details, see the UPDATE PGM command.
Program modules can be made resident in either an IMS region or LINKPACK. This topic explains how to make program modules permanently resident and provide some rules for doing so.
Making modules resident in a region
- Only serially reusable z/OS, IMS, or user-written program modules can be resident in a region.
- Only program modules used for transactions serviced by the region involved, should be made resident in that region. Program modules should be resident for only the duration of the region.
- z/OS and IMS modules that execute in a dependent region can reside in that dependent region.
Modules made resident in a region are in the region JOBPACK and are called without repeating the overhead of searching STEPLIB/JOBLIB, LINKPACK, and SYS1.LINKLIB. The overhead of fetching the module into virtual storage is encountered only at region initialization time.
Making modules resident in LINKPACK
In an operating environment where there are several batch regions or a combination of online and batch regions, it can be advantageous to place some of the frequently used IMS and access method modules in the operating system LPA. Programs made resident in LPA should be those that can be shared among all regions. This saves virtual storage space. The modules to be included must exist in either a LNKLSTxx member of SYS1.PARMLIB (or its concatenations, one of which should be IMS.SDFSRESL) or SYS1.SVCLIB.
Initial access of LPA resident program modules can be slow, because the region JOBPACK and STEPLIB/JOBLIB are searched before LPA is searched. Subsequent access can be at CPU speeds if the region JOBPACK has not been purged by z/OS virtual storage management (as when sufficient virtual storage is not available to satisfy a user GETMAIN for space). Although the modules are physically residing in LPA (and are shared among multiple regions), the overhead involved in searching program libraries and LPA is only experienced at region initialization time.
Although some real storage can be saved by putting the DL/I action modules into LPA, it is not recommended that an installation place IMS modules into the LPA. Doing so makes it difficult to execute different versions of IMS concurrently. Also, when maintenance is applied to modules in LPA, another initial program load of the z/OS system is required.
The IMS module preload function
The z/OS task under which modules are preloaded varies based on the IMS region type. Table 1 shows IMS region types and associated z/OS tasks.
| IMS region type | z/OS task |
|---|---|
| Control (CTL) | Physical Log |
| Message (MSG) non-reentrant modules | Program Control |
| Message MSG reentrant modules | Region Control |
| Batch Message (BMP) | Region/Program Control |
| Batch (DLI) | Region/Program Control |
| Fast Path (IFP) | Region/Program Control |
| Java batch processing region (JBP region) | Region/Program Control |
| Java message processing region (JMP region) | Region/Program Control |
DFSMPLxx control statement
- Use the IMS PROCLIB data
set allocated before Stage 2 of IMS system
definition and the z/OS utility
IEBUPDTE to create members of the IMS PROCLIB
data set that identify modules to be preloaded.
Related reading: See z/OS MVS™ Data Administration: Utilities.
Member names must be DFSMPLxx. The record format is:- Position
- Contents
- 1-71
- Module names, separated by a comma
- 72-80
- Ignored
The first name on a record can have leading blanks. The last name on a record is denoted by a comma followed by one or more blanks; the last name on the last record is followed by one or more blanks.
No limit exists for the number of module names that can be specified. If a preloaded module has ALIAS names that are ordinarily invoked by z/OS LINK (that is, application programs in DLI BMPs and MPPs), those ALIAS names should also be specified for preload.
- Bind the application program modules using the IMS reentrant DL/I language interface. The true
attributes must be specified; for example, if reusable only, do not
specify
RENT.
The IMS DL/I language interface is not reentrant. Any IMS application programs that were designed to be reentrant or serially reusable can use the module preload function after being bound with the IMS language interface.
- In the step execution JCL, do both of the following:
- Insert a DD statement for IMS.PROCLIB with the ddname PROCLIB.
- Specify the correct member of the IMS.PROCLIB data set in the EXEC statement parameter.
If an invalid member name is specified, or if the record format is incorrect, no modules are loaded but a message is issued and initialization continues.
The member name should be unique unless overridden by the IMS procedure.
For a description of the EXEC statement parameters, see DFSMPR procedure.