Avoiding resource contention

This section describes how to avoid resource contention between ZDT/IMS Edit/Browse sessions and other concurrently executing processes at your installation.

When a user starts an Edit or Browse session, ZDT/IMS starts a batch message processing (BMP) program or a DL/I batch processing program. Ordinarily, the BMP or DL/I batch processing program continues to run until the user exits from the Edit or Browse session. These programs have periods of inactivity when they are waiting for a user response and periods of activity when they are processing the user response.

We need to consider measures you can take to reduce resource contention when the programs are active and when they are inactive. However, the latter measures are more important because, for the majority of the time, the programs just wait for a user response.

Inactive Edit and Browse sessions

Two types of resource contention are considered here:

  • Lock contention
  • Contention with processes that use the /DBRECOVERY command

These are discussed in turn.

Lock contention

Lock contention occurs when a concurrently executing program attempts to acquire a lock that the inactive Edit or Browse session is holding. The way to avoid it, is to get ZDT/IMS to release all locks before it returns control to the user.

There are two types of locks that need to be considered:

  • Locks for unmodified data
  • Locks protecting updates

Before returning control to the user, ZDT/IMS issues a RLSE call which releases all locks held for unmodified data, so we can restrict our attention to locks protecting updates.

Only Edit sessions hold locks protecting updates. If you want ZDT/IMS to release any locks protecting updates that the Edit session holds, before returning control to the user, then you should set AUTOSAVE=Y, EDITFREQ=1 and UAUTOSAV=N when you customize the ZDT/IMS installation module. You can specify these settings for some IMS™ subsystems, so all locks protecting updates are released when the user is editing databases in those subsystems, and specify different settings for other IMS™ subsystems, where it is not as critical that these locks are released.

You can also specify different settings for BMP and DLI mode. For more information on how to code these parameters, see Specifying selected processing options and ZDT/IMS options.

Note: If you set AUTOSAVE=Y, EDITFREQ=1 and UAUTOSAV=N, editing changes are committed when the user presses Enter. Thus these settings preclude users from using the UNDO and CANCEL commands to discard their editing changes.

Contention with processes that use the /DBRECOVERY command

The contention described in this section occurs when the Edit or Browse session runs in BMP mode.

A process that uses the /DBRECOVERY command to deallocate a database cannot be run while an inactive Edit or Browse BMP is accessing this database. The process can be run when the user exits out of the Edit or Browse session. However, at most installations, processes that use the /DBRECOVERY command to deallocate databases are run at night after the user has gone home, so they won't always be available to do this.

Some utilities, such as the Online Reorganization Facility, support pausing BMPs and this allows them to use the /DBRECOVERY command to deallocate the databases that the BMPs are accessing. However, a BMP can only be paused when it issues a checkpoint, so if the inactive Edit or Browse BMP is to be paused, it would have to be awakened periodically to issue a checkpoint.

There are two installation options that you can use to stop this type of resource contention occurring - a time-based checkpointing option and a timeout option.

If the time-based checkpointing option is selected, then the Edit/Browse BMP issues checkpoints while it is waiting for a user response. With this option selected, utilities that support pausing BMPs are able to pause inactive Edit/Browse BMPs, allowing them to use the /DBRECOVERY command to deallocate the databases that the Edit/Browse BMPs are accessing.

To select the time-based checkpointing option for an IMS™ subsystem, use the CHKPINTVL parameter on the HFM1POPI macro statement to specify the time interval between checkpoints. For information on how to code this parameter, see ZDT/IMS options.

If the timeout option is selected, then the Edit/Browse session is timed out after a period of inactivity. With this option selected, you are able to run processes that use the /DBRECOVERY command to deallocate databases that inactive Edit/Browse BMPs are accessing, once the Edit/Browse BMPs are timed out.

To select the timeout option for an IMS™ subsystem, use the TIMEOUTI parameter on the HFM1POPI macro statement to specify the time period that a user has to respond before an Edit/Browse BMP is timed out. For information on how to code this parameter, see ZDT/IMS options.

Active Edit and Browse sessions

Typically locks held while the Edit or Browse session is active are not responsible for any resource contention, because the locks are usually held for a very short period of time and a very small number of resources are locked at any time. There are exceptions, however. The CHANGE ALL and REPEAT ALL commands can hold a large number of locks for long periods of time, so their usage needs to be controlled. If you want to control their usage for an IMS™ subsystem, you should set AUTOSAVE=Y, and UAUTOSAV=N and use the CHGAFREQ parameter to specify the checkpoint frequency that is to be used during Change All and Repeat All operations. For more information on how to code these parameters, see Specifying selected processing options and ZDT/IMS options. Also, you can use the MAXGN parameter to limit the number of DL/I calls that can be issued when searching a database. For more information on how to code this parameter, see Controlling access to the subsystems and ZDT/IMS options.