Using Loadlists, DCUF and signon to determine where to load a module, in batch and online

Products

IDMS IDMS - Database

Issue/Introduction

The location from which IDMS loads a module is influenced by several things: loadlists, DCUF commands, signon options, profiles, etc. This document outlines how these are prioritized in loading a module.

Environment

Release: All supported releases.

Resolution

Loadlists are the overriding factor in determining where modules will be loaded from at run-time, including subschemas, access modules, dialogs, maps, programs, etc. One of the potential entries in a loadlist is a user default dictionary, indicated by the parm USER-DEF in the loadlist entry. If that is included in the loadlist, then the dictionary specified by a DICTNAME parameter will be considered as part of the loadlist evaluation. Loadlists and DCUF commands may also be used to control which version number of a module to load. The location that is used to load a particular load module will not depend on the particular program or tool being executed; it will depend on the environment in which it is run, and various specifications, as follows:

For batch jobs run under the CV,
1. If the userid which is running the job is associated with a profile that specifies a LOADLIST, then that user-defined Loadlist will be used to search for the load module.
2. If the userid running the job is not associated with a profile, then IDMS will use the system default loadlist SYSLOAD to determine the search sequence for load modules.
3. If the loadlist chosen by the above two steps includes a DICTNAME USER-DEF entry, then various factors can determine which dictionary is used as the user default:
  1. If DICTNAME is specified in a SYSIDMS DICTNAME parameter, the specified dictionary will be used as the USER-DEF dictionary unless it is overriden by one of the steps below;
  2. If a task includes the DICTNAME parm on the BIND RUN-UNIT that dictionary will be considered the USER-DEF, and will override any dictname specification on the SYSIDMS;
  3. If DICTNAME is part of the signon statement (as for some of the IDMS batch compilers), that will be used as the USER-DEF dictionary, and will override any specification on the BIND RUN-UNIT. or the SYSIDMS.
If a batch job is run in CV-mode, it will use loadlists similar to that noted above, but with a couple of differences:
1. If the userid which is running the job is associated with a profile that specifies a LOADLIST, then that user-defined Loadlist will be used to search for the load module.
2. If the userid running the job is not associated with a profile, then IDMS will use the system default loadlist SYSLOAD to determine the search sequence for load modules.
3. If the loadlist chosen by the above two steps includes a DICTNAME USER-DEF entry, then various factors can determine which dictionary is used as the user default:
  1. If DICTNAME is specified in a DCUF statement, the specified dictionary will be used as the USER-DEF dictionary unless overridden as outlined below;
  2. If a task includes the DICTNAME parm on the BIND RUN-UNIT; or if DICTNAME is part of the signon statement (as for some of the IDMS batch compilers), that dictionary will be considered the USER-DEF, and will override any specification on the DCUF.
Local jobs use no loadlist at all but will follow the search sequence indicated by SYSLOAD (the default loadlist provided at install time).

For online tasks and batch jobs run through CV, the above rules will apply to all programs and tasks equally, in the absence of anything else to override that. It's possible for different users to have different values for the USER-DEF dictionary, or the same user to load modules from different places, if they have different DICTNAME specifications. For the same user in the same session, without any explicit overrides as noted above, then all tasks executed by that user will load modules from the same place. The only other way to force different tasks to use a different subschema would be to change the loadlist that it was using, by setting a new default at the system level or by associating a new one with the user profile. There is no way for the same user to use different subschemas (or different versions of some other load module) for two tasks, such as DMLO and OLQ, without changing their profile, as these are both controlled by the same loadlist.

Other factors can also influence where a load module is loaded from. With DCUF, set a LOADLIST, a DICTNAME and a VERSION, all of which affect how IDMS searches for a load module.

To clarify how all of these factors are applied, look at an example using the default loadlist SYSLOAD. SYSLOAD is defined as follows:
```
                   Type       Version    Dictnode/Dictname

LOADLIST SYSLOAD Dict      USER-DEF            USER-DEF
                 Dict      USER-DEF            SYST-DEF
                 Loadlib   USER-DEF
                 Dict      00001               USER-DEF
                 Dict      00001               SYST-DEF
                 Loadlib   00001
```

Here is an example of how the above rules apply when using SYSLOAD.

With SYSLOAD, IDMS will always search at least one dictionary loadarea before searching a loadlib for any dictionary-eligible modules.
If a version is specified using DCUF TEST or in a profile, IDMS will check the first three entries for the load module in question; if there is no version specified it will disregard the first three entries.
If a user has specified a specific DICTNAME by any of the means outlined in the steps above, IDMS will search there first, as indicated by the dictname USER-DEF entry in the loadlist. It looks for a Program Definition Element that specifies the DICTNAME that is set.
If IDMS finds a matching PDE and it is marked enabled, it will use it. If the PDE is marked for New Copy it will load a new copy, otherwise it will use the copy currently in the pool.
If IDMS does not find a matching PDE and Null PDEs are allowed for the type of module it wants to load, then it will build a PDE from Null PDE and search the dictionary load area. If the module is found, the PDE becomes permanent and that load module is used.
If the module is not yet found, IDMS will search the default dictionary loadarea using the same process noted above, but now the PDE will be one with blank DICTNAME. If found, it uses that load module.
If the load module is still not found, then IDMS searches the loadlib DD (either CDMSLIB or an alternate Version loadlib DD if a TEST version is set).

So using SYSLOAD, if the load module in question exists in a dictionary loadarea as well as in a loadlib, the only way to force IDMS to load from loadlib is to disable the dictionary PDEs for any dictionary where it may reside. If there is a LOADLIST defined to the system that only searches loadlib, then setting that LOADLIST will also work, but only for the users who set that loadlist, unless that LOADLIST is set in sysgen to be the system default loadlist.

If there is a problem loading a particular record, and research is being undertaken to determine where the subschema is being loaded from, it is also worth considering whether the CLOD task or a batch CLEANUP utility was run against this segment before attempting the process. If not, it is possible that the program is attempting to process logically deleted records (LDELs) which are outdated and therefore do not match the current subschema.