DCMT VARY Commands › DCMT VARY DMCL › DCMT VARY DMCL Usage

DCMT VARY DMCL Usage

Using a New Copy of the Database Load Module

DCMT VARY DMCL NEW COPY allows programs running under the DC/UCF system to benefit from changes made to the database definition without having to recycle the system. For example, an area can be added to an existing segment while the system remains active.

When a DCMT VARY DMCL NEW COPY command is issued, CA IDMS applies changes to the database definition that have been made by the following DDL statements:

• CREATE/ALTER/DROP AREA
• CREATE/ALTER/DROP BUFFER
• CREATE/ALTER/DROP FILE
• CREATE/ALTER/DROP SEGMENT
• CREATE/ALTER/DROP DISK JOURNAL

Additionally, CA IDMS loads a new copy of the database name table. In certain situations the system must be cycled in order to fully enable changes made to the DMCL. The system must be cycled in order to:

• Implement changes made to the journal buffer.
• Implement changes made to buffer and/or file definitions that are used for native VSAM files.
• VARY in a DMCL generated under a release level that is different from that of the current DMCL.
• Remove or replace all active disk journal files at the same time.

In some cases these changes may appear to be honored when the DMCL is varied New Copy, but will not actually be in effect until the Central Version is restarted.

Impact of Change Tracking

If change tracking is in use, a DCMT VARY DMCL NEW COPY command can only be issued if change tracking is active or disabled. We recommend that change tracking be active in systems in which new copies of DMCLs are to be varied online.

Note: For more information, see Recovery Considerations and DMCL Changes.

What DC/UCF Does in Response to a New Copy Command

In response to a DCMT VARY DMCL NEW COPY command, CA IDMS performs the following actions:

• Compares the contents of the runtime DMCL with the new DMCL load module, identifying entities that have been added, changed or removed. Changes to entities are detected by comparing their timestamps.
• Displays all of the changes to the user.
• Unless NOPROMPT was specified, issues the following prompt: 'Continue with Vary DMCL Yes or No?'. Specifying No negates the changes and allows the system to run as before. Specifying Yes causes the changes to be incorporated into the runtime DMCL as described in the following steps.
• Quiesces those areas and disk journals that have been removed or impacted by a change.
• Updates the runtime DMCL to reflect the new DMCL load module.
• If change tracking is active, writes an image of the new runtime DMCL to the SYSTRK files.
• Swaps to a new active journal file and writes the timestamp from the new DMCL load module to the active journal file.
• Reopens the disk journals, buffers, files, and areas using the definitions contained in the new runtime DMCL. New areas are opened in the mode specified in the DMCL and existing areas are opened in the mode they were in prior to the vary operation.

When quiescing access to impacted entities, the following actions are taken:

• Areas that have been dropped or modified are varied offline.
• Their associated files are closed and de-allocated.
• Buffers that have been dropped or modified or whose associated files are changing are closed.
• Disk journals that have been dropped or modified are varied offline.

Note: If areas or disk journals must be varied offline, the vary operation could have a lengthy completion time. Before responding Yes to the prompt, note the areas affected by the change and the transactions that are accessing those areas. If disk journals are being changed, look for transactions that may depend on those journal files for recovery. Look especially for long-running transactions that do not issue frequent commits.

Recovery Considerations and DMCL Changes

If change tracking is active when a DCMT VARY DMCL NEW COPY is issued, CA IDMS ensures that any subsequent warmstart uses the correct data sets and DMCL definition by recording the new definition in the SYSTRK files. If a failure occurs prior to writing the new DMCL to SYSTRK, the system restarts using the old DMCL definition and data sets. Otherwise, the system restarts using the new definition and data sets. If the write to SYSTRK fails because of an I/O error or out-of-space condition, the vary operation continues but change tracking is varied inactive, and manual intervention is needed to restart the CV in the event of a failure. Therefore, you should correct the cause of the failure and vary change tracking active as soon as possible. If the CV fails before these corrective actions are taken, specify IGNORE_SYSTRK_DMCL=ON in the SYSIDMS file when restarting the system, and ensure that the execution JCL does not reference obsolete data sets. If IGNORE_SYSTRK_DMCL=ON is not specified, warmstart fails due to a mismatch between the timestamp in the DMCL and that recorded on the journal files.

If change tracking is disabled or not in use when a DCMT VARY DMCL NEW COPY is issued, manual intervention may be necessary to ensure correct recovery in the event that a subsequent warmstart is needed. The necessary actions depend on when the failure occurs:

• If the failure occurs before the timestamp of the new DMCL was recorded in the journal files, warmstart fails due to a mismatch between the timestamp in the DMCL load module and the timestamp recorded in the journal. The old DMCL load module must be restored, and the system restarted with JCL that reflects the data sets in use at the time of the failure.
• If the failure occurs after the new DMCL timestamp was recorded in the journal files, no timestamp mismatch occurs. However, before restarting, the JCL may need to be adjusted so that obsolete DD statements do not override files whose data set names were changed by the DCMT VARY DMCL command.
• In either case, if change tracking was disabled at the time of the failure, IGNORE_SYSTRK_DMCL=ON must be specified in the SYSIDMS file when restarting the system.

Modifying DMCL-wide Memory Cache Parameters

DMCL VARY MEMORY CACHE allows dynamically changing options to control where and how much memory cache storage can be allocated.

Note: A dynamic change to memory caching through DCMT VARY DMCL applies only to files that are opened AFTER the DCMT VARY DMCL command was issued.

Example:

• A DMCL has MEMORY CACHE LOCATION ANYWHERE STORAGE LIMIT 800 GB
• At some point, 648 GB memory cache is in use.
• A DCMT V DMCL STORAGE LIMIT 500 GB is issued. At that moment, more memory cache storage is in use than allowed. However, no files are closed. That is, 648 GB storage remains in use. Any new request to open a file in memory cache fails. To free up memory cache storage, close one or more files with DCMT VARY FILE.