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

Document ID : KB000018810
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

The location from which we load 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.

Solution:

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 & 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:

  1. 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 we 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.

  2. If a job is run online, 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 we 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.

  3. 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 you can set a LOADLIST, a DICTNAME and a VERSION, all of which affect how we search for a load module.

    To clarify how all of these factors are applied, let's look at an example using the default loadlist SYSLOAD. SYSLOAD is defined as follows:

    LOADLIST SYSLOAD  Type      Version    Dictnode/Dictname 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.

  1. With SYSLOAD we will always search at least one dictionary loadarea before searching a loadlib for any dictionary-eligible modules.

  2. If a version is specified using DCUF TEST or in a profile, we will check the first three entries for the load module in question; if there is no version specified we will disregard the first three entries.

  3. If a user has specified a specific DICTNAME by any of the means outlined in the steps above, we will search there first, as indicated by the dictname USER-DEF entry in the loadlist. We look for a Program Definition Element that specifies the DICTNAME that is set.

  4. If we do find a matching PDE and it is marked enabled we will use it. If the PDE is marked for New Copy we will load a new copy, otherwise we will use the copy currently in the pool.

  5. If we do not find a matching PDE and Null PDEs are allowed for the type of module we want to load, then we 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.

  6. If the module is not yet found we will search the default dictionary loadarea using the same process noted above, but now the PDE will be one with blank DICTNAME. If found we use that load module.

  7. If the load module is still not found, then we search 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 you have 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.