Considerations for using dynamic resource definition

To ensure that your use of dynamic resource definition (DRD) is successful, be aware of these usage considerations.

In addition to the requirements and restrictions that are associated with using DRD, consider the following issues:

• Before enabling dynamic resource definition or shared queues, evaluate any existing DFSINSX0 exit routines. The DFSINSX0 exit might need to be changed so that it checks whether LTERM creation is allowed before it accesses the USEQDATA parameter list that is related to LTERM processing. If LTERM creation is not allowed, the USEQDATA buffer address (INSXAUSQ) is zero.

• In an IMSplex with multiple IMS™ systems, some having DRD enabled, the command INITIATE OLC PHASE(PREPARE) TYPE(MODBLKS) is allowed so that the IMS systems that do not have DRD enabled can perform online change processes.
• The online change process is enabled and DRD is not enabled when:
  • MODBLKS=OLC is specified in the DFSCGxxx member of the IMS PROCLIB data set
  • MODBLKS=OLC is specified in the COMMON_SERVICE_LAYER section of the DFSDFxxx member of the IMS PROCLIB data set
  • A value is not specified for the MODBLKS= keyword in either member.
• In a shared EMH queues environment, a CREATE PGM command creates the application program, even if there are messages on the shared EMH queues for the application program. If the messages are placed on the shared EMH queues because the program was defined as Fast Path on another IMS, but this program is being created as non-Fast-Path on this IMS, this IMS is unable to access the messages on the shared EMH queues.
• If you are using the IMSRSC repository in an Extended Recovery Facility (XRF) environment, both the active IMS and alternate IMS must have the same definitions for using the repository.

  The active IMS reads the resource definitions from the repository during cold start if AUTOIMPORT=AUTO or AUTOIMPORT=REPO is specified in the DFSDFxxx member of the IMS PROCLIB data set. The alternate IMS obtains its runtime definitions from the checkpoint log record of the active IMS. After takeover, the alternate IMS can export to, and import, delete or query from the repository. The UPDATE IMS command is processed, both at the active IMS and alternate IMS, to dynamically change the usage of the repository.

  In an XRF environment, if the active IMS is enabled with the repository, the alternate IMS must also be enabled with the repository. Resource definitions for both the XRF active and the XRF alternate must be maintained in the repository. Issue the EXPORT DEFN TARGET(REPO) command with the SET(IMSID()) keyword to specify the IMS IDs of both the active and the alternate systems. Use this process so that the resource definitions can be defined or modified in the repository for both the active an alternate at the same time. Alternately, the EXPORT DEFN TARGET(REPO) command can be issued for the active system only and another EXPORT DEFN TARGET(REPO) command be issued on the alternate after a takeover. However, in this scenario, if the alternate must be cold-started as the new active before the EXPORT command is issued, any resource definition changes made by the old active system in the repository are not available for the new active system. Issue the DELETE DEFN TARGET(REPO) command with the FOR(IMSID()) keyword to specify the IMS IDs of both the active and the alternate systems. If this is not done, the resource definition becomes available at the next cold start or during an IMPORT command for the IMS that it is not deleted from.

• If you are using the repository in a DBCTL warm standby system, both the active DBCTL and warm-standby DBCTL must have the same definitions for using the repository.

  The warm-standby DBCTL registers to RM during its initialization and connects to the repository.

  During emergency restart command processing on the warm-standby DBCTL, any IMS change lists are read from the repository.

• All the DRD commands that work on application program resources and descriptors can be issued in DB/DC, DBCTL, and DCCTL environments.
• The MODBLKS DD statement is not required for MODBLKS=OLC or MODBLKS=DRD in an FDBR system.
• If you are not running with DRD enabled, any changes you make to the MODBLKS resources (database, transactions, programs, and routing codes) by using the type-1 commands persist across a warm or emergency restart, but they do not persist across a cold start. In a non-DRD environment, the control blocks that are used to manage the resources (DDIRs, PDIRs, SMBs, and RCTEs) are loaded from the MODBLKS data set at cold start. If a type-1 command is issued to change the attribute of a resource (such as the database access type or the transaction class), the internal control blocks are updated and the changes are recovered across a warm or emergency restart. If you perform a cold start, however, the control blocks are reloaded from the MODBLKS data set, and, unless you have updated your MODBLKS data set, the updated attributes revert to the original values.

  If you are running with DRD enabled, any changes you make by using the type-1 or type-2 commands persist across a warm or emergency restart. They also persist across a cold start if the updated resource definitions are exported to either an RDDS or the repository, and then imported from the RDDS or repository during cold start. When you export the resource definitions to an RDDS or the repository, you export all the current attribute values. If you have changed the value of one of the attributes by using a type-1 or type-2 command (such as the database access type or the transaction class), the updated attribute is exported. The updated attribute values are then imported during cold start if you have automatic import enabled.

• During a cold start, the partition status or access state is copied from the HALDB master. If you export the HALDB master status to the RDDS or the repository, the status of the master and its partitions is obtained from the RDDS or the repository.