DCMT VARY Commands › DCMT VARY ADSO › DCMT VARY ADSO Usage › Changing the Area Status

Changing the Area Status

Disposition of Active Transactions

When you issue a VARY AREA command without the IMMEDIATE option to change the area status, any transactions already accessing the area in a conflicting mode are allowed to finish before the command takes effect and appropriate buffers are flushed. The system issues a message to the operator's console indicating that the area is quiescing.

Forcing an Immediate Vary

When varying an area's status to RETRIEVAL, TRANSIENT RETRIEVAL, or OFFLINE, the change in status can be forced by specifying the IMMEDIATE option. If specified, CA IDMS:

• Cancels all tasks that conflict with the VARY.
• Terminates all user sessions with no active task if they conflict with the VARY (by performing the equivalent of a DCMT VARY LTERM lte-name RESOURCES DELETE).
• Varies all predefined system run units offline if they conflict with the VARY (by performing the equivalent of a DCMT VARY RUNUNIT ru-name OFFLINE).

After the status change has occurred, predefined run units that were varied offline are varied online unless:

• The area was varied OFFLINE, since the run units will be unable to access the area.
• The QUEUE run unit was varied offline, since it requires the DDLDCRUN area in update mode.

If either of these conditions apply, the appropriate system run units must be varied online by explicitly issuing a DCMT VARY RUN UNIT command once their corresponding areas are made available.

UPDATE Option Opens First File of Area

Varying an area to UPDATE causes DC/UCF to the open the first file of the area.

Notify Locks and Varying Areas

CA IDMS deals with a VARY request for an area that has outstanding notify locks as follows.

• If the area status is changing to RETRIEVAL or TRANSIENT RETRIEVAL, the VARY occurs regardless of if any notify locks exist for db-keys in the area.
• If the area status is changing to UPDATE, the VARY occurs immediately. However, since it is possible that the area was updated externally while it was in RETRIEVAL mode to this CV:
  • Subsequent tests of a notify lock that existed at the time of the VARY indicate the prefix and data have been modified.
  • The restoration of currencies associated with the area that were saved prior to the VARY results in a task abend if the area is readied in an update mode.
• If the area status is changing to OFFLINE, the VARY waits until all notify locks have been released.

Varying Transient Retrieval Areas

An area whose status is transient retrieval cannot be varied directly to retrieval or update mode. You must first vary the area OFFLINE, and then vary it to the desired mode.

Changing the Area Status Permanently

A permanent area status is one that is retained until it is changed by another DCMT VARY command, or until the system journal or SYSTRK files are formatted. The area status is retained across normal shutdowns and across abnormal terminations, provided the warmstart option of the area in the DMCL specifies MAINTAIN CURRENT STATUS.

Note: The permanence of an area status has no effect on physical area locks. It only affects the mode in which the area is accessed when the system is next started. If the DC/UCF system is shut down normally, all physical area locks held by the system are removed, regardless of whether the area status of the system was assigned as UPDATE PERMANENT.

If change tracking is in use for the DC/UCF system, permanent area statuses are recorded in the SYSTRK files. Status entries are identified by area name and are deleted when their associated area is no longer in the runtime DMCL. A vary that affects the permanent status of an area fails if change tracking is inactive and receives a warning if it is disabled.

If change tracking is not in use for the DC/UCF system, permanent status entries are recorded in the system journals and are identified by page group and low-page number. If a page group or low-page number of an area is changed, an existing permanent status entry cannot be matched against the area. If this happens, the usage mode of the area defaults to the usage-mode specified in the DMCL and the orphaned status entry for the area remains in the journals until they are formatted. It is also possible for an orphaned status entry to be misapplied to a new area with a matching low page number and page group.