Using the Datacom QUIESCE_DBID processing commands

Products

• Datacom
• Datacom/AD
• Datacom/DB

Issue/Introduction

Datacom has had the QUIESCE command available for several releases to be able to suspend maintenance activity within the MUF. This command applies to all the databases in the MUF at the same time, and has provided significant benefits to many customers.

To further improve this sort of processing, we have recently developed a set of commands that allow maintenance activity to be suspended for a defined subset of databases, allowing other databases to be used without interruption. This article explains these commands under the QUIESCE_DBID umbrella, and gives an example of their use.

Environment

z/OS

Resolution

First, the documentation topic QUIESCE_DBID is the overview of the process, and discusses the three parts used for this to work. It is not a command of its own, but just a topic. The three commands are:

• QUIESCE_DBID_ALLOW - This is a MUF Startup Option that must be activated before using QUIESCE_DBID processing.
• QUIESCE_DBID_SET - This is a console command or a DBUTLTY-executed command to identify which DBIDs will be processed when the next command is issued.
• QUIESCE_DBID_APPLY - This is a console command or a DBUTLTY-executed command to initiate the Quiesce processing for all the DBIDs specified in the "SET" command, or to turn off the Quiesce processing to resume normal operation again.

Next, the standard Quiesce processing takes place across the MUF, and suspends maintenance updates for all DBIDs while it is in effect. Here, the Quiesce_DBID processing also takes place across the MUF, but only applies to the individual DBIDs identified as eligible for Quiesce processing via the "SET" command. 

One of the questions asked is how the process is different when working with a single database and with multiple databases. The simple answer here is that the process is the same. The only difference is the list of DBIDs on the "SET" command has either one or more than one DBID. This is described further in the syntax diagram for the "SET" command.

Now, let me give you an example of this process.

1. Before starting the MUF, a MUF Startup Option needs to be present:
   QUIESCE_DBID_ALLOW  YES
   which enables Quiesce processing for individual DBIDs during this MUF operation.
2. At some point prior to the time when the Quiesce is needed, a command needs to be issued to the MUF to define the list of individual databases that will later be processed. The command can be issued directly from the console using a command:
   /F DJMUFDF,QUIESCE_DBID_SET YES,31-40,255
   (here, to process DBID 31 through 40 and also 255), or it can be issued through DBUTLTY using the CONSOLE OPTION2 function like this:
   COMM OPTION=CONSOLE,OPTION2='QUIESCE_DBID_SET YES,31-40,255'
   (to issue the same command as above). To use only a single DBID, the command is similar-- QUIESCE_DBID_SET YES,255 -- to enable DBID 255 to be Quiesced later. To turn off DBIDs from being processed with the next command, use the "NO" parameter instead of yes, such as QUIESCE_DBID_SET NO,38 -- if DBID 38 was previously defined, but you do not want to Quiesce it with the next command.
3. Now, since you have predefined the DBIDs to be processed, you would issue a command to the MUF to Quiesce maintenance activities at the next transaction boundary. The MUF will then suspend processing for that predefined list of DBIDs. Again, you can either issue the command directly from the console or via the DBUTLTY CONSOLE OPTION2 function. The commands are very simple: QUIESCE_DBID_APPLY TXN when you want to suspend updates against this list of DBIDs at the next transaction boundary, or QUIESCE_DBID_APPLY OFF when you are finished your outside activity and want to resume normal database processing again. Note that the full-MUF command QUIESCE has the ability to suspend updates at the Request boundary, but this QUIESCE_DBID process will only operate at the application transaction boundary.

There are a number of messages produced when the "APPLY" command is processed, and these are noted in the APPLY command documentation. In this section, you can see an example set of messages along with an explanation.

This is a brief explanation of the Quiesce_DBID process. The important thing to remember here is that whatever databases you define in the QUIESCE_DBID_SET command are the ones that will be processed when you issue the QUIESCE_DBID_APPLY command. You can only have one set of DBIDs active at a time in a MUF, and only after you have issued the "APPLY TXN" and then the "APPLY OFF" commands, you can add or remove DBIDs using the "SET" command once more.

Additional Information

As always, please contact Broadcom support for Datacom if you have further questions.