Area Level DBUTLTY Control

Area level DBUTLTY control gives you the option of performing a mix of utility functions on different areas of a database at the same time, by moving control from a Single User environment to a MUF environment.
datacom150
Area level DBUTLTY control gives you the option of performing a mix of utility functions on different areas of a database at the same time, by moving control from a Single User environment to a MUF environment.
This feature requires that the database be optimized in the MUF, which is done by
not
having the ACCESS MUF startup option specified as NOOPT for this database.
Contents
MULTUSE= Keyword
The MULTUSE= keyword, for area level DBUTLTY control, is an option in the following DBUTLTY functions:
  • BACKUP for Data Areas
  • EXTEND for Data Areas
  • EXTRACT
  • INIT for Data Areas
  • LOAD for Data Areas
  • Forward RECOVERY
  • REORG
  • REPLACE
  • RETIX
The following gives details about using MULTUSE= in the previously listed functions:
  • EXTEND and INIT for Data Areas
    Specifying MULTUSE=YES in the EXTEND and INIT functions for data areas allows a single area in a database to be initialized or extended with no disabling of the other areas in the database. When MULTUSE=YES, the functions execute in a new format that is a combination of MUF and Single User modes. The database involved must be able to be opened for update in the MUF address space. The area, however, must have no tables open. Once begun, the functions do not allow other tasks to open any tables in the area being processed. Other tables in the database, but not in the area, may be open for read or update in the same MUF. The actual data set open is performed in the utility region, and the JCL requirements are applied to the utility region.
    The operating system performs the catalog portion of the DD statement DISP option when the DD statement is removed. This occurs at job step termination. Therefore, if you were to create a new data set with an INIT, or to change the volume list during an extend, do not expect the MUF to correctly open this area until after the step completes. This restricts the DBUTLTY functions that succeed when following a catalog change.
    When you specify or allow the default of MULTUSE=NO in the INIT or EXTEND functions for data areas, the functions execute without area level control in MUF, that is, completely Single User in mode.
  • LOAD and RETIX
    In LOAD and RETIX functions that do not use the KEYNAME= keyword, specifying MULTUSE=YES allows a single area in a database to be loaded or have its index rebuilt, with no loss of read and update access to other areas in the database. When MULTUSE=YES, the functions execute in a new format that is a combination of MUF and Single User modes. The database involved must be able to be opened for update in the MUF address space. The area, however, must have no tables open. If the database is currently open,
    Datacom/DB
    closes this area with the area close (you would need to close the area yourself
    only if
    the database is open and you need the MUF to close it, so that any type of open data set lock can be released, which could be necessary to scratch and reallocate the data set). Once started, the functions do not allow other tasks to open any tables in the area being processed. Other tables in the involved database, but not in the area, may be open for read or update in the same MUF.
    With MULTUSE=YES:
    • The area is first opened in MUF for the LOAD or RETIX.
    • The area is also opened in Single User mode.
    • The data area processing occurs in the utility address space.
    • The key build/sort occurs in the utility address space.
    • The index load/merge occurs in the MUF address space. Packages of index entries (about 32k bytes) are sent from the utility to the MUF.
    MULTUSE=YES affects several other options. The SORT option becomes required and is an error to be specified as 0. The AREA= keyword becomes required. The following options must be in effect: URI=YES, OPTIMIZE=NO, VERIFY=NO, and LOADDUPS=NO.
    When MULTUSE=NO is specified or is allowed to default in the LOAD and RETIX functions, the functions execute without area level control in MUF, that is, the database involved may not be open for update, and all processing executes in the Single User mode.
  • RECOVERY (forward only)
    Using MULTUSE=YES in the RECOVERY OPTION=FORWARD function of DBUTLTY allows a single area in a database to be recovered with no disabling of the other areas in the database. Other forward recovery functionality executes in Single User mode.
    For area level DBUTLTY control, three keywords must be provided, MULTUSE=YES, DBID=, and AREA=. The three are a set, that is, if one of the three is specified, the other two must also be specified. When all are provided, the RECBASE and RECJOB functions are not allowed. Using the three area level control keywords, recovery works at the same level as the LOAD, RETIX, INIT, EXTEND, and REORG utility functions.
    When MULTUSE=YES is specified, the area involved must be able to be opened for update in the MUF. Once begun, the function prevents other opens for the area. Tables in other areas may be open for other utilities and user applications based upon normal rules. This recovery does not add log records. If it fails, it is necessary to restore the data area again and restart the recovery, the same as would be required when running any of the other forms of forward recovery.
    Following are the rules for execution for forward recovery with MULTUSE=YES:
    • Database must be open for update in the MUF or able to be opened.
    • No table in the area may have an open for update user.
    • No table in the area should have a read user.
      Datacom/DB
      does, however, allow it.
    • Area may not currently be being processed by another MULTUSE=YES forward recovery, INIT, EXTEND, LOAD, RETIX, or REORG.
    • The area should be set with ACCESS STATUS=UTLTY.
      Datacom/DB
      does not, however, absolutely require it.
    In forward recovery, if you specify MULTUSE=NO, or allow the function to default to it, the database involved must be able to be opened for update by the utility address space. This means it is not open for update by any other address space, including a MUF. Also, the database should not be open for read, even though
    Datacom/DB
    does allow it.
  • REORG
    Area level DBUTLTY control allows a single area in a database to be reorganized with no disabling of the other areas in the database.
    With MULTUSE=YES, the data-spaces containing index information are defined with a global scope, making them available to the MUF. When MULTUSE=YES, the index phase must occur in MUF with full interaction with other tasks processing the index and sharing the same buffer pool. Each task does single block reads. The area being reorganized cannot have other users for REORG to start and, once started, it does not allow other users to open.
  • REPLACE
    The REPLACE function has table level control, but it interacts with area level controls. For example, if replacing a single table in an area, the area cannot be used by the LOAD function.
Database ACCESS
Database ACCESS controls all access (User Requirements Table open) to a database in a MUF, with the exception of the RESTART process done during the MUF enable.
  • ACCESS STATUS=WRITE
    Allows all types of access.
  • ACCESS STATUS=OFF
    Denies all types of access.
  • ACCESS STATUS=READ
    Allows User Requirements Table opens, with UPDATE=NO specified or defaulted.
  • ACCESS STATUS=UTLTY
    Allows all DBUTLTY functions and denies all OPENS that are not DBUTLTY, except the DBUTLTY function DBTEST with PGM=DBTSTPR, as it executes as though it is not part of DBUTLTY.
Database ACCESS is set by three processes:
  • MUF startup options,
  • A console command, and
  • The DBUTLTY function ACCESS.
A temporary, internal, parallel form of ACCESS=OFF is done during a CATALOG from
Datacom Datadictionary
.
The database level of ACCESS is typically done to stop, in an orderly fashion, access in a MUF because:
  • It has the ability to wait for the completion of active jobs, and
  • It usually precedes both Single User forms of DBUTLTY functions or other processes, such as volume copies or restores.
    DBUTLTY Single User functions without Simplify do not know about the ACCESS status of any MUF, nor are they dependent upon any current status.
Following is an example of database ACCESS used to reorganize an entire database, without Simplify. In the example, the DBUTLTY functions BACKUP, INIT, and LOAD each execute in Single User mode with no knowledge of any MUF or its ACCESS status, and therefore do not require them. However, ACCESS helps ensure correct execution of the utility set because it verifies that no other job, which could either update data that would be lost or cause the INIT to fail with a return code 46, can open the base between the BACKUP and INIT.
  1. Use ACCESS to stop new jobs and wait on current jobs:
    ACCESS STATUS=OFF,DBID=1,USERS=WAIT
  2. Use COMM CLOSE to close the database:
    COMM OPTION=CLOSE,DBID=1
  3. Use BACKUP to back up the entire database:
    BACKUP DBID=1,...
  4. Use INIT to initialize the Index Area (IXX):
    INIT AREA=IXX,DBID=1
  5. Use LOAD to load the reorganized data:
    LOAD DBID=1,FORMAT=BACKUP,...
  6. Use ACCESS to allow new user jobs:
    ACCESS STATUS=WRITE,DBID=1
Area Level ACCESS
Area ACCESS controls all access (User Requirements Table open) to a data area (and the table(s) the area contains) in a MUF, with the exception of the RESTART process done during the MUF enable.
  • ACCESS STATUS=WRITE
    Allows all types of access.
  • ACCESS STATUS=OFF
    Denies all types of access.
  • ACCESS STATUS=READ
    Allows User Requirements Table opens, with UPDATE=NO specified or defaulted.
  • ACCESS STATUS=UTLTY
    Allows all DBUTLTY functions and denies all OPENS that are not DBUTLTY, except that the DBUTLTY function DBTEST with PGM=DBTSTPR, as it executes as though it is not part of DBUTLTY.
Area level ACCESS is set by the DBUTLTY function ACCESS, controlled by users. The area level of ACCESS is usually done to stop, in an orderly fashion, access in to a MUF area. It usually precedes a DBUTLTY function at the data area level that needs to execute in the MUF.
A temporary, internal, parallel form of the ACCESS STATUS=UTLTY function is done by other
Datacom/DB
functions such as LOAD with MULTUSE=YES. The LOAD, in this case, validates that its requirements are met then sets the area in the protected status, thereby preventing other opens to any table in the area for the duration of the LOAD. The LOAD with MULTUSE=YES does not require the area level ACCESS.
Following is an example of an area ACCESS to reorganize an area in the MUF with no loss of access to other areas in the MUF. In the example, the utility functions BACKUP and LOAD each execute in the MUF. The ACCESS function is not required, but if used it ensures correct execution of the utility set by ensuring that no other job, which could either update data that would be lost or cause the LOAD to fail with a return code 88, can open the base between the BACKUP and LOAD
  1. Use ACCESS to stop new jobs and wait on current jobs:
    ACCESS STATUS=UTLTY,DBID=1,AREA=DEM,USERS=WAIT
  2. Use BACKUP to back up the DEM area:
    BACKUP DBID=1,AREA=DEM,MULTUSE=YES,...
  3. Use LOAD to load the reorganized data:
    LOAD DBID=1,FORMAT=BACKUP,AREA=DEM,MULTUSE=YES,...
  4. Use ACCESS to allow new user jobs:
    ACCESS STATUS=WRITE,DBID=1,AREA=DEM
If there is an attempt to open (a user application open or a utility open) a table in an area that is contrary to a user-executed DBUTLTY ACCESS with the AREA keyword, return code 88(002) is generated. If there is an attempt to open a table in an area that is contrary to a DBUTLTY execution in the MUF, return code 88(003) is generated. For example, an 88(003) would be received if a data area was being initialized using the MULTUSE=YES keyword, and there was an attempt by a user application or a utility to open a table in the area.
COMM CLOSE Function
The COMM CLOSE function of DBUTLTY either closes all data sets in a database and closes the definitions in the Directory (CXX), or it closes a single area of an open database.
Specifying the AREA=
name
keyword requires that the DBID= keyword be specified. You would need to use this feature only if the MUF has the area open and you want to initialize, extend, or load it through DBUTLTY and uncatalog it.
The ability to CLOSE an area does not exist as a console command.
Dynamic System Table
The MUF_ACCESS_AREA (MFN) Dynamic System Table contains information about area level DBUTLTY access.