IMS repository function coexistence considerations

When you specify the EXPORTNEEDED control statement on the Create RDDS from Log Records utility (DFSURCL0), it is recommended that you run the same version of the DFSURCL0 utility as the version of the IMS that produced the IMS logs being used as input. For example, use the IMS 14 DFSURCL0 utility with IMS 14 log data sets. Otherwise, the results can be unpredictable.

Automatic export to the IMSRSC repository is supported only by an IMS 14 Resource Manager (RM) or later. Any lower-level RM systems that receive a request to update the repository for an automatic export will fail. IMS Version 12 APAR PI27283 and IMS Version 13 APAR PI27285 are open for the coexistence to not support RM to handle the AUTOEXPORT parameter. It is recommended that you enable automatic export to the IMSRSC repository only after all RM systems have been migrated to IMS 14.

An IMS change list is created only if the command master IMS is IMS Version 13 or later and the RM that processes change list requests is at V13 (1.6) level or higher.

Two possible scenarios for keeping stored resource definitions synchronized across multi-version IMSplex systems are shown as follows:

Scenario 1: Making attribute changes in a mixed environment of IMS systems that use RDDS and IMSRSC repository

In this scenario:

• IMSA is running IMS Version 13, using DRD with an RDDS.
• IMSB is running IMS 14, using DRD with an RDDS.
• IMSC is running IMS 15 and using DRD with an IMSRSC repository.
• All three IMS systems are in the same IMSplex and using shared queues.

The following steps illustrate changing an attribute of a transaction and storing its resource definition for scenario 1.

1. Check for work in progress by issuing a QRY TRAN SHOW(WORK) command. Either wait for the work to finish or address the work in progress.
2. When the transaction is not in use, an attribute of a transaction is changed on each IMS system by issuing an UPDATE or CREATE command.
3. IMSA and IMSB store the changed resource definition into their respective RDDSs by issuing the EXPORT DEFN TARGET(RDDS) command. IMSC stores the changed resource definition into its IMSRSC repository by issuing the EXPORT DEFN TARGET(REPO) command.

   If AUTOEXPORT=AUTO is enabled, the changes are written to the system RDDS at IMSA and IMSB at the next checkpoint and to the IMSRSC repository for IMSC at the next checkpoint.

4. Work for the transaction is restarted.

Important: During migration to IMS 15, IMSRSC repository is enabled if the DFSDFxxx member has AUTOEXPORT=AUTO explicitly defined and autoexport export to the IMSRSC repository is enabled after IMS 15 is cold started. Any resource definition changes (creates and updates) will be automatically exported to the IMSRSC repository at the next checkpoint.

If you do not want to enable the autoexport to the IMSRSC repository, you must remove the AUTOEXPORT= parameter in the DYNAMIC RESOURCES section of the DFSDFxxx member and let it default to AUTO or you must modify the member to either of these values:

• AUTOEXPORT= NO for no autoexport
• AUTOEXPORT = RDDS for autoexport to the RDDS

To enable autoexport to the IMSRSC repository, you must modify the AUTOEXPORT= parameter in the DYNAMIC RESOURCES section of the DFSDFxxx member to specify AUTOEXPORT=AUTO or AUTOEXPORT=REPO. In Scenario 1, if IMSC has AUTOEXPORT=AUTO explicitly specified, autoexport to the IMSRSC repository is enabled. To disable autoexport, modify the DFSDFxxx member for IMSC to specify AUTOEXPORT= NO.

Scenario 2: Changing a transaction definition on one IMS and propagating the change to the other IMS systems

In this scenario:

• IMSA is running IMS Version 13, using DRD with an RDDS, and using an IMS 15 CSL.
• IMSB is running IMS 14, using DRD with an RDDS, and using an IMS 15 CSL.
• IMSC and IMSD are running IMS 15 and are using DRD with a single IMSRSC repository.
• All four IMS systems are participating in shared queues.

The following steps illustrate changing an attribute of a transaction and storing its resource definition for scenario 2.

1. Check for work in progress by issuing a QRY TRAN SHOW(WORK) command. Either wait for the work to finish or address the work in progress.
2. When the transaction is not in use, change an attribute of the transaction on IMSC by issuing an UPDATE command.
3. Store the changed transaction definition in the IMSRSC repository for IMSC and IMSD by issuing either of the following EXPORT command from IMSC.

   EXPORT DEFN TARGET(REPO) SET(IMSID(IMSC,IMSD)) 
   EXPORT DEFN TARGET(REPO) SET(IMSID(*)) 

4. Update the runtime definition of the transaction on IMSD by importing the stored resource definition from the IMSRSC repository by issuing the IMPORT DEFN SOURCE(REPO) command
5. Export the changed transaction definition from IMSC to a non-system RDDS by issuing the EXPORT DEFN TARGET(RDDS) command.
6. Update the runtime definition of the transaction on IMSA and IMSB by importing the stored resource definition from the non-system RDDS by issuing the IMPORT DEFN SOURCE(RDDS) command.
7. Export the changed transaction definition from IMSA and IMSB to their respective system RDDSs by issuing the EXPORT DEFN TAEGET(RDDS) command.
8. Work for the transaction is restarted.

Coexistence with IMS Version 13