DBUTIL



DBUTIL

     The DBUTIL program performs several different functions according to the
 command you enter. Each DBUTIL command is described separately on the
 following pages.

SYNTAX

     :RUN DBUTIL.PUB.SYS
>>command

Commands:

Enter one of the following: 

HELP VERIFY ADDINDEX EXIT
CREATE SET DROPINDEX
ERASE ENABLE REBUILDINDEX
MOVE DISABLE REDO
PURGE RELEASE DO
DEACTIVATE SECURE LISTREDO
ACTIVATE SHOW DETACH

DBUTIL commands can be abbreviated to the first three characters or less.
For example, >>CREATE can be abbreviated to >>C or >>CRE.
Enter the HELP command for the minimum abbreviation for each command.
When using the >>CREATE, >>PURGE, or >>ERASE command, you can bypass
the command prompt by specifying the full command as an entry point
with the RUN command; for example,

:RUN DBUTIL.PUB.SYS,CREATE

If you use an entry point, TurboIMAGE/XL prompts you for the database name
and, optionally, for the maintenance word, as follows:

Database name: database-name [/maint-word]

Parameters:

database-name is the name of a TurboIMAGE/XL database root file catalogued
in the current session or job's account and logon group.

maint-word is an optional ASCII string, one to eight characters long
with no commas or semicolons, that defines a password to be
 used by anyone other than the database creator to enable them
 to execute certain DBUTIL commands, and operate other utilities.
 (The database creator can also define or change the maintenance
 word by using the >>SET command).

In job mode, the database name and maintenance word, if any, must be in the record
immediately following the RUN command. To perform any DBUTIL command except >>SHOW,
>>HELP, or >>EXIT, you must have exclusive access to the database or database-access file.

ACTIVATE

Activates the database-access file for use with DBOPEN. Before using this command,
read the description of remote database access in chapter 9 of the TurboIMAGE/iX
Database Reference Manual.

This command should be used to prepare a database-access file before accessing
a remote database residing on another HP 3000.

Syntax:

>>A[CTIVATE] database-access-file-name

Example:

ACTIVATE ORDDBA

where ORDDBA is the database-access-file-name Parameter.

Parameters:

database-access-file-name is the name of the database-access file that you
 created with an editor.

The database-access file (created on the local system) can have any legal
MPE/iX file name and is not dependent on the database name.

Unexpected Results:

TurboIMAGE/XL checks that the following conditions are not violated:

·File code is 0.
·Record length does not exceed 128 characters.
·File is unnumbered.
·File has at least three records.

An appropriate error message is returned if any of these conditions is violated.
If all of the conditions are satisfied, DBUTIL prints the message:

Verification follows:

and the syntax of the file is checked record by record. The monitoring messages
associated with the file records are of the form:

FILE command: <result>
DSLINE command: <result>
HELLO command: <result>

where <result> is "Looks good" if there are no errors associated with the record.
Appendix A of the TurboIMAGE/iX Database Reference Manual lists the record errors
(results) that would cause the file to be rejected.

Example:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>ACT ORDDBA Enter abbreviated form of ACTIVATE command and database-access file name.
Verification follows
FILE command: Looks good
DSLINE command: Looks good
HELLO command: Looks good
HELLO command: Looks good
ACTIVATED
>>

DBUTIL checks the structure of the file named ORDDBA for correct format and activates
the file. You will not be able to edit the file unless you deactivate it using the
DBUTIL >>DEACTIVATE command.

ADDINDEX


The ADDINDEX command updates the root file, and adds the associated B-Tree index file.
When using the ALL option and there is no master dataset, a warning is generated, but
the command is considered to be successful.

Syntax:

>>ADDI[NDEX] database-name [/maint-word] FOR {ALL | setnamelist | setnumlist }

Example:

>>ADDINDEX ORDERS FOR ALL

where ORDERS is the database name.

Parameters:

database-name is the name of a TurboIMAGE database.

maint-word is the maintenance password.

setnamelist is the list setname [,...]

setnumlist is the list setnum[,...]

ALL means all master data sets for the database.

Example:

>>ADDINDEX ORDERS/secret FOR ALL

Found 4 master datasets.
Adding index to set# 1 (#entries = 162,730, capacity = 218,987)
Adding index to set# 2 (#entries = 84,164, capacity = 188,517)
Adding index to set# 3 (#entries = 18,784, capacity = 21,943)
Adding index to set# 4 (#entries = 783, capacity = 2583)
Done.

If the data set is big and DBUTIL is interactive, a progress report at an
interval of every 5% will be displayed.

5% done ...
10% done ...

It is always displayed on the same line. It will be overwritten by the next permanent line.
Adding index to ... or Done.

CREATE

Creates and initializes a file for each data set in the database.
Once the Schema Processor has created the root file, the database creator must
build a file for each data set in the database using the >>CREATE command.
DBUTIL initializes each data set to zeros and saves it as a catalogued MPE/iX file
in the same logon group as the root file, on the device classes specified in the schema.

The data set names are created by appending two digits to the root file name. If the
root file is named XXXX, then the first data set defined in the schema is named XXXX01,
the second data set is named XXXX02, and so on. In order to save files for the maximum
of 199 data sets per database, files are incremented from XXXX01-99, XXXXA0-A9, XXXXB0-B9,
up to XXXXJ9.

To execute the DBUTIL program to create and initialize the database, you must be the
database creator; that is, you must log on with the same user name, account and group
that was used to run the Schema Processor and create the root file. After DBUTIL has
created and initialized the database files, it prints a confirmation message on the
list file device and prompts for another command.

The CREATE command has been enhanced to create the required chunk control and chunk
data files for jumbo data sets. To specify a jumbo data set, the JUMBO option must be
included in the schema before defining a jumbo data set. Then any data set whose capacity
is greater than 4GB automatically becomes a jumbo data set.

The CREATE command does an implicit ADDINDEX command for each dataset marked by DBSCHEMA
as indexed.

Syntax:

>>C[REATE] database-name [/maint-word]

Example:

CREATE ORDERS

where ORDERS is the database name.

Parameters:

database-name is the name of a TurboIMAGE/XL database being created.

maint-word is the maintenance word that can be defined by the database creator
 when the database is created. To access the database, anyone other
 than the database creator must supply this word.

Example: (Session Mode)

:RUN DBUTIL.PUB.SYS Initiate DBUTIL executions.
.
.
.
>>CREATE ORDERS Respond to DBUTIL prompt with >> CREATE command and database name.
Database ORDERS has been CREATED
>>

DBUTIL creates, initializes, and saves files named ORDERS01, ORDERS02, and so forth,
one file for each data set. These constitute the empty database.

Example: (Job Mode)

:JOB MGR.ACCOUNTA Initiate job.
:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
CREATE ORDERS Enter >>CREATE command and database name.
EXIT Terminate DBUTIL.
:EOJ Terminate job.

After the data files are created and initialized, DBUTIL prints the following message
on the list file device:

DATABASE ORDERS HAS BEEN CREATED

NOTE

>>CREATE will fail if the native language defined for the database is not supported
at the system level. (Refer to appendix A or the Native Language Support Programmer's
Guide for more information.)

DEACTIVATE

Deactivates the database-access file to allow modifications to the file or to disallow
remote database access.

This command is used before you change the contents of the database-access file.
(Refer to chapter 9 of the TurboIMAGE/iX Database Reference Manualfor more information
about accessing remote databases.)

If DBUTIL successfully deactivates the file, it prints a confirmation message on the
list file device.

Syntax:

>>DE[ACTIVATE] database-access-file-name

Example:

DEACTIVATE ORDDBA

where ORDDBA is the database-access file name.

Parameter:

database-access-file-name is the name of the database-access file to be deactivated.

Example:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>DEACTIVATE ORDDBA Enter a >>DEACTIVATE command and the database-access file name.
DEACTIVATED
>>

DETACH

The DETACH command detaches the database from the DBEnvironment(s) the database
is attached to. You can use one command of DBUTIL to detach a given database from
all of the DBEnvironments to which it is attached; you do not have to specify each
DBEnvironment name.

If you copy your database to a different account or different group, then issue
a DETACH command for the copied database, you will get an error stating that the
detach failed from dbename.group.account (ATCERR 32052). It is because the DETACH
of the database triggers a lookup of the TC file (which contains the names of the
DBE to which the database is attached). However, DBUTIL's subsequent verification
of the original DBE shows the name of the original database (not the name of the
copied database) as the one attached to this DBE. Due to this discrepancy, the
following things happen:

·DBUTIL reports an error and does not perform a real detach of the copied database.
·The attached flag in the rootfile (copy) as well as the entry in the TC file is
cleared, in spite of the error.
·The original production database still remains attached to the DBE.

The DETACH command updates the root file. Therefore, use caution when copying an
attached database.

Syntax:

>> DET[ACH] database-name [/maint-word]

Example:

>>DETACH ORDERS

where ORDERS is the database name.

Parameters:

database-name is the name of the database.

maint-word is the maintenance password.

Example:

>>DETACH ORDERS/secret

Database has been detached from these HP SQL DBEnvironments:
NEWDBE.BTRTESTS.IMAGESQL
TEMDBE.BTRTESTS.IMAGESQL
>>

DISABLE

Disables the access, automatic deferred output, data prefetching, dumping, ILR,
indexing, MUSTRECOVER, logging, and recovery options.

Syntax:

>>DI[SABLE] database-name[/maint-word] FOR option[,option...]

Example:

DISABLE ORDERS FOR LOGGING,RECOVERY

where ORDERS is the database name, and LOGGING and RECOVERY are the options.

Parameters:

database-name is the name of a TurboIMAGE/XL database root file created in
 the current session or job's account and logon group.

maint-word is the maintenance word defined by the database creator when
 the database is created with DBUTIL. This word must be supplied
 by anyone other than the database creator.

option is an option from the list provided and described below.
 More than one option can be specified.

ACCESS disables user access to the database.

AUTODEFER disables automatic deferred output for the database.
 AUTODEFER must be disabled if ILR or roll-back recovery is to be
 enabled for a database.

DSEM disables the use of Dependency Semaphore employed to increase
concurrency of modification intrinsics (DBPUT, DELETE, and DBUPDATE
with CIU ON).

DUMPING disables the automatic dumping of the user's stack and the database
 control block in the event of a TurboIMAGE/XL abort. Unless requested
 by Hewlett-Packard support representatives, under most circumstances
 dumping should be disabled. When enabled, DUMPING creates files
 (before TurboIMAGE/XL aborts) that can prove helpful in determining
 the cause of such problems as a corrupted control block.

HWMPUT disables DBPUT action of placing entries at the high-water mark first,
 instead of at the delete chain head.

ILR disables Intrinsic Level Recovery facility.

INDEXING disables third-party indexing (TPI) for the database.
 Third-party indexing provides the capability to do generic key searches,
multiple keyword retrievals, and sorted sequential searches on any database.
Refer to your vendor documentation for information on TPI.

LOGGING disables the database roll-forward logging facility. Roll-back and
 MUSTRECOVER must be disabled first.

MUSTRECOVER disables the MUSTRECOVER option for the database. Logging is not affected
by disabling MUSTRECOVER. If the database needs recovery when you disable
 MUSTRECOVER, you are prompted to confirm the DISABLE command. If you respond
 to continue, the consistency of the database cannot be guaranteed. To ensure
 database consistency, respond with N, recover the database, and then disable
 MUSTRECOVER after recovering the database.

PREFETCH disables the prefetching of data blocks required by the DBPUT and DBDELETE
 intrinsics under certain conditions. Refer to "Coordinating Additions to a
 Database" or "Coordinating Deletions from a Database" in chapter 4 of the
TurboIMAGE/iX Database Reference Manual for additional information.

RECOVERY disables the database roll-forward recovery facility.

ROLLBACK disables the database roll-back logging facility. However, logging will
 not be automatically disabled. To disable logging, use the
>>DISABLE database name FOR LOGGING command. Otherwise, logging (roll-forward)
 will remain enabled.

Default Conditions:


Access is Enabled
Autodefer is Disabled
Dumping is Disabled
HWMPUT is Disabled
ILR is Disabled
Indexing is Disabled
Logging is Disabled
Mustrecover is Disabled
Prefetch is Disabled
Recovery is Disabled
Roll-Back is Disabled

Example:

:RUN DBUTIL.PUB.SYS
.
.
.
>>DISABLE ORDERS FOR ACCESS
Access is Disabled
>>

DROPINDEX

The DROPINDEX command drops the associated B-Tree index file and updates the root file.
When using the ALL option and there is no master dataset, a warning is generated, but
the command is considered to be successful.

Syntax:

>>DROPI[NDEX] database-name [/maint-word] FOR {ALL | setnamelist | setnumlist }

Example:

>>DROPINDEX ORDERS FOR 2

where ORDERS is the database name and 2 is set# 2.

Parameters:

database-name is the name of a TurboIMAGE/XL database.

maint-word is the maintenance password.

setnamelist is the name of the set list.

setnumlist is the number of the set list.

ALL means all master data sets for the database.

Example:

>>DROPINDEX ORDERS/secret FOR 2

Dropping index from set# 2 (#entries = 84,164, capacity = 188,517)
Done.

ENABLE

Enables the access, automatic deferred output, data prefetching, dumping, ILR,
indexing, MUSTRECOVER, logging, and recovery options.

Syntax:

>>EN[ABLE] database-name[/maint-word] FOR option[,option...]

Example:

ENABLE RETAIL FOR LOGGING

where RETAIL is the database name and LOGGING is an option.

Parameters:

database-name is the name of a TurboIMAGE/XL database being enabled.

maint-word is the maintenance word defined by the database creator when the
 database is created with DBUTIL. This word must be supplied by
 anyone other than the database creator.

option is an option from the list provided and described below.
 More than one option can be specified.

ACCESS enables user access to the database.

AUTODEFER enables automatic deferred output for the database. With deferred
 output the MPE/iX transaction manager is not used to log database
 modifications to the transaction manager log file. Instead, AUTODEFER
 uses the MPE/iX file system default mode. This mode keeps data pages
in memory for as long as possible until either lack of memory or the
 closing of a file causes the pages to be written to disk. In this mode
 a system failure can cause the loss of database integrity. ILR is not
 compatible with AUTODEFER; therefore, deferred output should be used
 only in a batch situation where the database has been backed up prior
to batch processing. ILR must be disabled prior to enabling AUTODEFER.
AUTODEFER can be used to increase I/O performance by disabling
Transaction Management (XM). However, ILR and roll-back recovery must
 be disabled. You must consider performance and the ability to recover
data when determining whether to use AUTODEFER. Roll-forward logging
 can be used to preserve consistency.

DSEM enables use of Dependency Semaphore for increased concurrency of
 modification intrinsics (DBPUT, DELETE, and DBUPDATE with CIU ON).

DUMPING is an option for Hewlett-Packard support use, development, and
 debugging only. When enabled, the TurboIMAGE/XL abort procedure
 copies the user's stack and the database control blocks to files
 if a TurboIMAGE/XL procedure aborts.

HWMPUT enables DBPUT action of placing entries at the high-water mark first,
 instead of at the delete chain head.

ILR enables the Intrinsic Level Recovery facility. TurboIMAGE/XL maintains
structural integrity without ILR enabled.

INDEXING enables third-party indexing (TPI) for the database if not already done
 by the third-party software when configuring the database for TPI.
Third-party indexing provides the capability to do generic key searches,
 multiple keyword retrievals, and sorted sequential searches on any database.
 Refer to your vendor documentation for information on TPI.

LOGGING enables the database roll-forward logging facility.

MUSTRECOVER enables the MUSTRECOVER option for the database. If logging is not
 already enabled, it is automatically enabled when MUSTRECOVER is enabled.
 While MUSTRECOVER is enabled, the database cannot be accessed after a
 system failure until the database is recovered with roll-forward or
 roll-back recovery.

PREFETCH enables the prefetching of data blocks required by the DBPUT and DBDELETE
 intrinsics under certain conditions. Refer to "Coordinating Additions to
a Database" or "Coordinating Deletions from a Database" in chapter 4 of the
TurboIMAGE/iX Database Reference Manual for additional information.

RECOVERY enables the database for recovery.

ROLLBACK enables the database roll-back logging facility. A warning displays
 if the log file does not exist, and the database remains disabled for
roll-back recovery. If logging is not in effect already, it will be
 enabled automatically.

Default Conditions:

Access is Enabled
Autodefer is Disabled
Dumping is Disabled
HWMPUT is Disabled
ILR is Disabled
Indexing is Disabled
Logging is Disabled
Mustrecover is Disabled
Prefetch is Disabled
Recovery is Disabled
Roll-Back is Disabled

Example:

:RUN DBUTIL.PUB.SYS
.
.
.
>>ENABLE ORDERS FOR RECOVERY
Recovery is Enabled
>>

ERASE

Reinitializes all data sets in the database to their empty condition and resets
all flags except the access, PREFETCH, and recovery flags (refer to the discussion
of the DBUTIL >>ENABLE command earlier in this chapter).

The data sets remain as catalogued MPE/iX files. To execute DBUTIL to reinitialize
the data sets, you must be the database creator or supply the correct maintenance word.

This utility function should be performed before data that was saved by DBUNLOAD is
loaded back into the database unless it was re-created.

After DBUTIL has completely reinitialized the data sets, it prints a confirmation
message on the list file device.

NOTE

The ERASE command erases any associated B-Tree index (.idx) files,
but will not delete them.

Syntax:

>>ER[ASE] database-name [/maint-word]

Example:

ERASE ORDERS/SELL

where ORDERS is the database name and SELL is the maint word.

Parameters:

database-name is the name of a TurboIMAGE/XL database being erased.

maint-word is the maintenance word defined by the database creator when
the database is created with DBUTIL. This word must be supplied
 by anyone other than the database creator.

Example:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>ERASE ORDERS/SELL Enter >>ERASE command, database name, and
maintenance word.
Database ORDERS has been ERASED
>>

DBUTIL reinitializes all the data sets in the ORDERS database to binary zeroes.
With the exception of the access, PREFETCH, and recovery flags, the database flags
are reset to their default conditions. The logging and MUSTRECOVER options are disabled
if they were previously enabled.

NOTE

The execution of utilities is not logged. If you use DBUTIL to erase the database,
the >>ERASE command automatically disables logging, ILR, third-party indexing,
MUSTRECOVER, and roll-back recovery.

EXIT

Terminates DBUTIL execution.

Syntax:


>>E[XIT]

Example:

>>CREATE ORDERS Create a database.
Database ORDERS has been CREATED

>>EXIT If no other DBUTIL functions are to be performed,
terminate DBUTIL with >>EXIT command.
END OF PROGRAM

HELP

Displays each of the DBUTIL commands. 

Syntax:

>>H[ELP] [commandname]

Parameter:

commandname is the name of a specific DBUTIL command whose format you want
to display. The name can be abbreviated to the minimum command
abbreviation permitted by DBUTIL.

If you do not specify a command, the >>HELP command lists the names of all valid
DBUTIL commands.

If you specify a command, the correct syntax for that command is displayed.

Example:

>>HELP
Commands are:

ACTIVATE ADDINDEX CREATE DEACTIVATE DETACH
DISABLE DROPINDEX ENABLE ERASE EXIT
HELP MOVE PURGE REBUILDINDEX RELEASE
SECURE SET SHOW VERIFY REDO

Commands may be abbreviated.
For help on a particular command type: 'HELP command name'.

>>HELP CREATE

C[REATE] database name [/maint word]

>>

MOVE

Moves TurboIMAGE/XL files across devices within the same volume set.

Syntax:

>>M[OVE] file-name TO device

Example:

MOVE ORDERS05 to DISC2

where ORDERS05 is the file name and DISC2 is a device.

Parameters:

file-name is a TurboIMAGE/XL root file, data set, or ILR file.
 Enter the file name only; no group/account specification is allowed.
The user must be the creator of the file.

device is the class name of the MPE/iX device or the number of the logical device
to which the TurboIMAGE/XL file should be moved. The device must be a member
 of the volume set on which the database resides.

Discussion:

It is recommended that you store the database with the DBSTORE command prior to
executing a MOVE command. This precaution is advisable in the event a system failure
 occurs during the move operation. When a move has been initialized, the process checks
the root file flag to determine if the database has been modified since the last backup
 copy was made. The program prompts the user to continue or to terminate the MOVE command
 and proceed with a DBSTORE of the database before moving TurboIMAGE/XL files to another
 device. If the user responds NO to the continue prompt, the following message is printed
 on the terminal:

MOVE operation stopped.

The following steps outline the process involved in moving TurboIMAGE/XL files from
one device to another. The move process does the following:

1. Retrieves information from the old file. Old indicates the file on the
 originally specified device.

2. Checks the device specified by the user for validity and existence, and
 determines if there is sufficient space for the new file. (New indicates
the file being moved to another device.)

3. Checks the root file to determine the database state.

4. Copies the old file to the new file.

5. Sets the flag in the root file.

6. Purges the old file, then saves the new file.

7. Resets the flag in the root file.

For jumbo datasets, the MOVE command enables you to move either the chunk control
 file or a specific chunk data file to a different device.

The MOVE command does not allow a B-Tree index (".idx") file to be moved.

Example:

>>MOVE ORDERS05 to 3
Database last stored on FRI, SEP 22, 1989, 8:32 PM
Database has been modified since last store date.
The database should be backed up before doing a MOVE operation.
Do you still want to continue the MOVE operation (Y/N)? Y
Starting file copy ...
... file copy completed.
Purging old copy of file "ORDERS05"
New copy of file "ORDERS05" saved as a permanent file
File "ORDERS05" moved to device 3

The data set ORDERS05 has been moved to logical device number 3.
This file is the INVENTORY data set and was originally assigned device class
named DISC2 in the schema.

To obtain a listing of where all the data sets for the database reside, do a

>>SHOW ORDERS DEVICE

PURGE

Purges the root file and all the data sets of the referenced database.
If you use third-party indexing, the >>PURGE command also purges any existing
third-party index files regardless of third-party indexing being enabled or disabled.

Purging removes the files from the catalog and returns the disk space to the system.
As with >>ERASE, you must be the database creator or must provide the maintenance word
to use DBUTIL with the >>PURGE entry. Before running the DBRESTOR program to restore a
database, use this utility function to purge the database.

If DBUTIL successfully purges the database, it prints a confirmation message on the
list file device.

NOTE

The PURGE command purges any associated B-Tree index (.idx) files.

Syntax:

>>P[URGE] database-name [/maint-word] [DETACH]

Example:

PURGE ORDERS/SELL

where ORDERS is the database name and SELL is the maint word.

Parameters:

database-name is the name of a TurboIMAGE/XL database being purged.

maint-word is the maintenance word defined by the database creator when the
 database is created with DBUTIL. This word must be supplied by anyone
 except the database creator when using DBUTIL to access the database.

DETACH is an option specific to the IMAGE/SQL users.
 This option detaches the database from all ALLBASE/SQL database
 environments (DBEnvironments) to which it is attached via IMAGESQL.
 When DETACH is not used, the database is purged without detaching
 from the DBEnvironment(s). For more information, refer to the
 IMAGE/SQL Administration Guide.

Unexpected Results

The following messages are printed if an unexpected situation occurs (refer to
appendix A of the TurboIMAGE/iX Database Reference Manual for other error messages):

Example:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>PURGE ORDERS Enter >>PURGE command and database name assuming there is
no maintenance word.

The next messages are returned if you are using IMAGE/SQL, and the DETACH option
is used with the >>PURGE command.

Database has been detached from these HP SQL DBEnvironments:
DBEname.group.account
DBEname.group.account

Database has been PURGED

DBUTIL confirms that the user is logged on with the same user name, account,
and group which were used to create the database. It then determines whether
the root file exists and if so, purges the root file and any files named
ORDERS01, ORDERS02, and so forth. Even if the root file does not exist,
any data sets with file names based on the root file name are purged.

REBUILDINDEX

REBUILDINDEX rebuilds the B-Tree index file for a specified dataset that should
have an index file.

When using the ALL option and there is no master dataset, a warning is generated,
but the command is considered to be successful.

The KSAM file built by REBUILDINDEX has the Native Language Support language
specified to match the language of the database, if the key is a text (X or U) data type.

Syntax:

>>REBUILDI[NDEX] database-name [/maint-word] FOR {ALL | setnamelist | setnumlist }

Example:

REBUILDINDEX ORDERS FOR 3

where ORDERS is the database name, and 3 is set# 3.

Parameters:

database-name is the name of a TurboIMAGE/XL database.

maint-word is the maintenance password.

ALL means all master data sets for the database.

setnamelist is the name of the set list.

setnumlist is the number of the set list.

Example 1:

>>REBUILDINDEX ORDERS/secret FOR SalesrepName,Region,District

Example 2:

>>REBUILDINDEX ORDERS/secret FOR 3
Rebuilding index for set# 3 (#entries = 18,784, capacity = 21,943)
Done.

REDO

Redo the previous command or the previous nth command.
Redo follows exactly the MPE/iX REDO syntax. REDO, LISTREDO, and DO work
for DBUTIL the same was as the MPE/iX commands.

Syntax:

>>REDO [n]

Example:

>>REDO 8

where 8 is the eighth previous command.

Parameter:

n is the backwards count of the command being repeated.

RELEASE

Suspends file system security provisions for the database root file and
data sets, allowing access to the database from other groups and accounts.
If you use third-party indexing, the >>RELEASE command suspends the file
system security provisions for any existing index files.

Syntax:

>>R[ELEASE] database-name

Example:

RELEASE ORDERS

where ORDERS is the database name.

Parameter:

database name is the name of a TurboIMAGE/XL database.

Discussion

The >>RELEASE command suspends file system security provisions for all of
the database files at the file, group, and account levels, but leaves
TurboIMAGE/XL security and MPE/iX privileged file security intact.
Releasing the file system security allows the database to be accessed by
users from other groups and accounts, without relinquishing the privacy
of all other files in the database group. Only the creator of the database
can release security. In addition, the group's home volume set must be mounted.

The database file security remains suspended until the creator issues a
>>SECURE command. Suspension remains valid after job termination, or system
failure followed by a system boot.

The RELEASE command applies to the associated B-Tree index (.idx) files.

SECURE

Restores security provisions that were released by a >>RELEASE command for
the database root file and data sets. If you use third-party indexing, the
>>SECURE command restores the security provisions for any existing index files.

Syntax:

>>SE[CURE] database-name

Example:

>>SECURE ORDERS

where ORDERS is the database name.

Parameter:

database-name is the name of a TurboIMAGE/XL database being secured.

Discussion:

The >>SECURE command reinstates the file system security provisions for
the entire database. These security provisions can only be suspended by
the >>RELEASE command. Only the creator of the database can successfully
issue the >>SECURE command. In addition, the group's home volume set must be mounted.

The SECURE command applies to the associated ".idx" files.

SET

Changes or removes the maintenance word; only the database creator can change
or remove the maintenance word. The >>SET command also sets the log identifier
into the root file, modifies access class passwords, sets a subsystem flag, and
sets the critical item update (CIUPDATE) option. For databases that will be
migrated to MPE V, the >>SET command specifies the number of input/output
buffers to be allocated by TurboIMAGE in the Database Buffer Area Control
Block (DBB) depending on the number of users concurrently accessing the database.

Syntax:

>>SET database-name [/maint-word]{BUFFSPECS=num buffers (from-users/to-users) [,num buffers(from-users/to-users)] ...
LOGID=log-identifier
MAINT=maint-word
SUBSYSTEMS={NONE
READ
RW }
PASSWORD classnum=[password]
LANGUAGE=language-id
CIUPDATE=(DISALLOWED
ALLOWED
ON }
BTREEMODE1={ON
OFF}[,[WILDCARD=]c] }

Example:

SET ORDERS MAINT=SELL

or

SET ORDERS/SELL CIUPDATE=DISALLOWED

where ORDERS is the database name and SELL is the maintenance word.

Parameters:

database-name is the name of a TurboIMAGE/XL database root file catalogued
 in the current session or job's account and logon group.

maint-word is the current maintenance word for the database, and must be
 given by anyone using DBUTIL to access the database other than
 the database creator.

BUFFSPECS is for MPE V compatibility only, because the TurboIMAGE/XL buffer
 specifications are fixed. For databases that will be migrated to
 MPE V, it sets the number of buffers to be allocated by TurboIMAGE
 in the Database Buffer Area `Control Block (DBB). Refer to "Moving
 from MPE/iX to MPE V" in appendix H for a discussion of BUFFSPECS
 and a description of its parameters.

LOGID sets the MPE/iX log identifier. The log identifier is obtained
 using the MPE/iX GETLOG command. Note that DBUTIL prompts for
 the logid password specified in the GETLOG command before it
 checks the validity of the log identifier. Entry of the correct
 logid password causes the valid log identifier to be stored in
the root file and used whenever the logging capability is enabled.
However, if the log identifier is left blank, it is removed from the database.

MAINT sets the maintenance word for the database. The maintenance word
 is the new maintenance word for the database. If omitted, the
 currently defined maintenance word is removed and the database
 has no maintenance word. Only the database creator can change
 or remove the maintenance word.

SUBSYSTEMS sets subsystem access to the database. The following options are valid:

NONE is the option used to prohibit use of any subsystem (for example, QUERY)
  on TurboIMAGE/XL.

READ is the option that allows only read access to the database by subsystems.
  The subsystem checks the root file flag to determine what access a
 subsystem is allowed.

RW is the option that allows read/write access to the database by subsystems.
 The subsystem checks the root file flag to determine what access a subsystem
 is allowed.

PASSWORD sets the password. The following parameters are used with the PASSWORD
 parameter:

classnum is the access class whose password is being changed.
It can be a number from 1 to 63, inclusive.

password is the new password being assigned to a particular access class.
  Up to 8 characters are allowed. If omitted, any password previously
 assigned to that class is removed. (You must be the database creator.)

LANGUAGE sets the native language for the database.
The following parameter is used with the LANGUAGE parameter:

language id is the number that identifies the native language.
Refer to the Native Language Support Programmer's Guide for name and
 number information. The message "Language changed" appears after using
 the >>SET command to change the language ID. This command can be issued
only on a virgin root file or an empty database.

NOTE

When reloading the database, the language must match the language ID stored
in the backup media. A DBLOAD issued in a job fails if the language of the
media differs from the database language. A DBLOAD in session mode provides
 a prompt to allow you to complete the DBLOAD operation when you reply Y.

CIUPDATE sets critical item update for the database.
  The following option settings are valid:

DISALLOWED prevents any process from using the critical item update option
on this database.

ALLOWED indicates that programmatic enabling of the option is possible
 through a call to DBCONTROL mode 5, but programs that do not make
 this call are prevented from using critical item update on this
 database. Programs that enable the option do so temporarily for
  the duration of the process but can subsequently disable it through
 a call to DBCONTROL mode 6.

NOTE:
ALLOWED is now the default setting.
 It was DISALLOWED in releases prior to C.07.00.

ON allows all processes to use the critical item update option on
this database without the need to call DBCONTROL mode 5.
 Any process can explicitly disable the option temporarily for
  the duration of the process through a call to DBCONTROL mode 6
but can subsequently enable it through a call to DBCONTROL mode 5.
 This setting allows the critical item update option to be disabled
in selected programs while enabling it for the majority.

Critical item update is useful for those processes that need to
 update the values of detail data set search or sort items; master
 data set key items cannot be updated regardless of the CIUPDATE setting.

BTREEMODE1 sets the root file flag for B-Trees to ON or OFF.
If it is ON, then a DBFIND mode 1 on ASCII types having a B-Tree index
 (explicit or implicit) and having the wildcard character in the argument
will be treated as a B-Tree search. If set to OFF, then a DBFIND mode 1
 will not be treated as a B-Tree search, even if the item has a B-Tree.
 See chapter 11 of the TurboIMAGE/iX Database Reference Manual,
"B-Tree Indices," for more detailed information on BTREEMODE1.

WILDCARD is set with any printable ASCII character for c.
 When doing a B-Tree DBFIND, mode-1-style arguments are scanned to
 find the first occurrence of the current wildcard character in the
argument text. If the wildcard is not found, a non- B-Tree search
is done (even if the DBFIND mode was 21). If the wildcard is found,
 the rest of the argument text is ignored.

NOTE

This does not match the functionality of "@" in commands such as
the MPE LISTF, but does match the functionality of current TPI implementations.
If the wildcard character is found at character k+1 (1-based), then
the qualified entries will consist of all keys that match the argument
 in character positions 1..k.

When not doing a B-Tree find (even when mode=1 and BTREEMODE1=ON;
 or mode=10), the entire argument, including any wildcard characters,
will be treated as the actual argument for a DBFIND mode 1.

The length of the argument may not exceed the item length.

Example 1:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>SET ORDERS MAINT Remove current maintenance word.
Maintenance word changed
>>

Example 2:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>SET ORDERS CIUPDATE=ON Indicates that processes can update the values of detail data set search or sort items in the ORDERS database without a need to do DBCONTROL mode 5.
CIUPDATE is ON. DBUTIL confirms the setting.

Example 3:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL.
.
.
.
>>SET ORDERS BTREEMODE1 = ON,% Sets BTREEMODE1 option on for B-Tree search for
DBFIND mode 1 on X or U type having a B-Tree
index (explicit or implicit) and in the presence of a wildcard character in the argument. Sets the wildcard character as % in the ORDERS database.

SHOW

Displays information about the database on a terminal or line printer.
This can include a list of processes that have the database open, the status
of locks in the database, the log identifier and flags, the current buffer
specifications, and the setting for the critical item update option.
Displays the capacity expansion information for the database and the data sets.

If you are using IMAGE/SQL, displays the names of any ALLBASE/SQL database
environments (DBEnvironments) to which the database is attached.

This command should be used with care because it obtains exclusive control
of the database for several seconds preventing all other access.

Syntax:

>>SH[OW] dbname [.group[.account]][/maint-word] {ALL
BUFFSPECS
CAPACITY
CIUPDATE
DEVICE
FLAGS
INDEX
INDEXES
INDICES
LANGUAGE
LOCKS
LOGID
LOGINFO
MAINT
PASSWORDS
SUBSYSTEMS
USERS } [OFFLINE]

Example:

SHOW ORDERS/SELL ALL OFFLINE

where ORDERS is the database name and SELL is the maint-word.

Parameters:

dbname is the name of a TurboIMAGE/XL database root file catalogued
 in the current session or job's account and logon group.
If you have account manager (AM) capability, you can qualify
 the database with the group name. If you have system manager (SM)
 capability, you can qualify the database with the group and account name.

group is the group where the database resides.
 To qualify the database name by group, you must have AM or SM capability.
 If you have AM capability and want to qualify the database name by group,
 the database must have a maintenance word as you will be required to supply one.

account is the account where the database resides.
 To qualify the database name by account, you must have SM capability.

maint-word is the current maintenance word for the database.
The database creator or the user with SM capability can omit the
maintenance word.

ALL displays all the information provided with MAINT, BUFFSPECS, LANGUAGE,
 LOCKS, USERS, LOGID, SUBSYSTEMS, FLAGS, and the last-stored date.
 Displays number of detail data sets using dynamic capacity expansion
 and if dynamic capacity expansion is used for master data sets. Also,
 if the database is attached to any ALLBASE/SQL database environments
 (DBEnvironments) via IMAGESQL, the DBEnvironment names are displayed
 (refer to the IMAGE/SQL Administration Guide for information).

BUFFSPECS displays the current buffer specifications which can be either the
 TurboIMAGE/V default setting or the values specified with the
 DBUTIL >>SET command for those databases that will be migrated to MPE V;
 the TurboIMAGE/XL default setting is not displayed. Refer to the
 discussion of BUFFSPECS in the earlier section on the >>SET command
and also in "Moving from MPE/iX to MPE V" in appendix H.

CAPACITY displays, for all data sets, capacity information including dynamic
 capacity fields. Information includes: data set name, type, number
of entries, entries as a percentage of the maximum capacity for the
 data set, maximum capacity, current capacity, initial capacity,
 incremental number of entries and whether or not dynamic capacity
expansion is used.

CIUPDATE displays the setting for the critical item update option.
Valid settings are DISALLOWED, ALLOWED, and ON.

DEVICE displays the TurboIMAGE/XL root and data sets and where files
 reside (device class name or logical number) for a database.

FLAGS displays the state (enabled or disabled) of the logging, roll-back,
 ILR, recovery, restart, subsystem access, AUTODEFER, access, dumping,
 HWMPUT, PREFETCH, MUSTRECOVER, and third-party indexing (TPI) options.
 If MUSTRECOVER is enabled, the flags option also displays a message
 if the database needs recovery. In addition, it displays the last
 database store date, and information on whether the database has
been modified since the last-stored date (DBSTORE flag).

INDEX INDEXES INDICES
displays the B-Tree indices for the database.

LANGUAGE displays state of the native language declaration for the database.

LOCKS displays the status of locks currently obtained (or requested).

LOGID displays the current MPE/iX log identifier for the database.

LOGINFO displays information about all types of logging available with TurboIMAGE/XL.

MAINT displays the maintenance word, if any.

PASSWORDS displays the access class numbers from 1 through 63 together with
the passwords assigned to them. (You must be the database creator.)

SUBSYSTEMS indicates whether subsystems, including user programs, can access
 the TurboIMAGE/XL database and, if access is allowed, whether it
 is read only or both read and write. Subsystem access is enforced
 by the subsystem.

USERS displays a list of the processes that have the database open with
 the program file name and other information. (Refer to examples below.)

OFFLINE requests that the information be listed on the line printer.
 The formal designator for the list file is DBUTLIST.
 (Passwords and maintenance word will not be printed.)

The >>SHOW database name USERS command can be executed at any time.
The remaining >>SHOW commands can be executed at any time except when another
process has the database opened in an exclusive access mode (mode 3 or 7).

Example (Show Users):

:RUN DBUTIL.PUB.SYS
.
.
.
>>SHOW ORDERS USERS

1 2 3 4 5

PIN PATH EXECUTING PROGRAM JOBNUM MODE

21 1 INVENTRY.IMAGE.DATAMGT #S116 1
22 1 BROWSE.IMAGE.DATAMGT #S118 5
28 1 BROWSE.IMAGE.DATAMGT #S112 5
29 1 INVENTRY.IMAGE.DATAMGT #S115 1
31 1 ORDENTRY.IMAGE.DATAMGT #S117 1

Example Discussion

The columns of information are described as follows:

1 The Process Identification Number (PIN).
 This is a number assigned to a process by the operating system when the
process is created. The table above indicates that the process has opened
 the ORDERS database.

2 The access path number.
The access paths for each process are numbered consecutively beginning with 1.
Refer to the discussion of access paths in chapter 4 of the TurboIMAGE/iX
 Database Reference Manual.

3 The name of the program file, its group and account.

4 The number of the job or session in which the process is running.

5 The access mode in which the database is open.

DBUTIL does not call DBOPEN so it is not listed as an executing program.

Example (Show All)
.
.
.
>>SHOW ORDERS ALL Display all information for ORDERS database.
For database ORDERS

MAINTENANCE WORD: SELL

Access is enabled.
Autodefer is disabled.
Dumping is disabled.
Rollback recovery is disabled.
Recovery is enabled.
ILR is disabled.
Mustrecover is enabled.
Logging is enabled.
Prefetch is disabled.
Indexing is disabled.
HWMPUT is disabled.
Restart is disabled.
Database last stored using True-Online Backup and
logfile NLOG001 on WED, MAR 26, 1997, 8:07 AM.
Database has been modified since last store date.
Shadowing is disabled.
Subsystem access is READ/WRITE.

CIUPDATE is allowed.
Dynamic capacity expansion is not used.
Database has at least one indexed dataset.
BTREEMODE1 is off, wildcard = "@".

Logid: NLOGID is valid.
password is correct.

XM log set : default XM user log set
for volume set MPEXL_SYSTEM_VOLUME_SET
XM log set type : circular
XM log set size : 32 megabytes

The language is 0 - NATIVE-3000.

Buffer specifications:
50(1/120)

No other users are accessing the database.

>>

where volname is the name of the volume set in which the database resides.

Example Discussion

The listing above indicates that the current buffer specifications provide
for 50 buffers to be allocated when there are between 1 and 120 concurrent
users of the database. On TurboIMAGE/XL the buffer specifications remain fixed,
so the information shown in the above listing is useful only for databases that
will be migrated to an MPE V system. The list above also shows that the database
is enabled for roll-forward recovery, logging, MUSTRECOVER, and user access.
It shows that the database was backed up using TurboSTORE/iX 7x24 True-Online
Backup (with ONLINE=START or ONLINE=END option), and the logfile in use at the
time was NLOG001. In the example, PREFETCH and third-party indexing (TPI) are
disabled, critical item update (CIUPDATE) is allowed, and the restart flag is
disabled. The restart flag is set by DBRECOV when the user has requested to
suspend recovery between log files. The logid is shown, the password is verified,
and the maintenance word is displayed. The messages that appear during the SHOW
command can vary depending on what information is available on the database.
If the maintenance word and logid are not present, the following messages display:

Logid is not present.

Maintenance word is not present.

The message regarding the transaction manager (XM) log set will also vary.
The following message is printed if the database is not attached to transaction manager:

XM log set: this database is not attached to an XM log set

The following message is printed if the database does not support NLS:

This database has been created before support of Native Languages.

If an error has occurred during dynamic roll-back recovery, the following message is displayed:

Database is logically inconsistent.

The following message is printed if the database is attached to an ALLBASE/SQL
database environment (DBEnvironment) via the IMAGESQL utility:

Attached to these HP SQL DBEnvironments:
DBEname
DBEname

The following message is printed if the third-party indices are registered
in the DBEnvironments.

Third Party Indexes are registered in these HPSQL DBEnvironments:

DBEname
DBEname

Refer to the IMAGE/SQL Administration Guide for more information.
The example displays, "Dynamic capacity expansion is used for 2 detail sets.
Enable this feature for new databases by using the capacity parameters for
detail data sets. See chapter 3 for more information. Enable this feature
or existing databases by using DBChange Plus or a third-party utility.
Refer to the MPE/iX Release 5.0 Communicator for information on using DBChange Plus.

Example (Show Capacity)
.
.
.
>>SHOW ORDERS CAPACITY

No. of %Max --------------Capacity-------------- Dyn
Data Set Name Type Entries Cap Maximum Current Initial Increment Exp
(Hashing)

CUSTOMER M 20 10 200 200 200 0 NO
DATE-MASTER A 111 53 211 211 200 0 NO
PRODUCT M 15 5 300 300 200 0 NO
SALES D 100 2 5012 140 140 70 YES
SUP-MASTER M 60 3 2000 600 400 200 YES

INVENTORY D 4998 1 500000 5000 5000 10000 YES
>>
The example shows Maximum, Current, Initial and Increment Capacities.
The "%Max Cap" column shows how full the data set is as a percent of the maximum
capacity for that set. "Dyn Exp" column shows whether dynamic capacity expansion
is enabled or not. Enable this feature for new databases by using the capacity
parameters when defining data sets. See chapter 3 for more information. Enable
this feature for existing databases by using DBChange Plus or a third-party
utility which supports this feature.

Format of Show Device List

The following example lists the TurboIMAGE/XL files for the ORDERS database,
along with the data set names and the device where each resides. In the
following example, the root file ORDERS and the data sets are shown.
The file devices are listed as specified with the device class names.
The ORDERS05 data set was moved using the DBUTIL >>MOVE command to logical
device number 3; the device class name is displayed.

Example (Show Device):

>>SHOW ORDERS DEVICE
For database ORDERS

Volume set: volname

MPE/iX File Name Data Set Name Device

ORDERS.IMAGE.DATAMGT DISC
ORDERS01.IMAGE.DATAMGT Date-Master DISC1
ORDERS02.IMAGE.DATAMGT Customer DISC1
ORDERS03.IMAGE.DATAMGT Product DISC1
ORDERS04.IMAGE.DATAMGT Sup-Master DISC2
ORDERS05.IMAGE.DATAMGT Inventory DISC3
ORDERS06.IMAGE.DATAMGT Sales DISC2

>>

where volname is the name of the volume set in which the database resides.

Format of Show Indices

The following example lists the data set names, type, and whether they are indexed.

Example (Show Indices):

>>SHOW ORDERS INDICES
For database ORDERS

Data Set Name Type Indexed?

DATE-MASTER A YES
CUSTOMER M YES
PRODUCT M YES
SUP-MASTER M YES

4 indexed datasets

>>
Format of Show Locks List

DBUTIL lists the locking information sequentially by locking level:
database locks followed by data set locks, followed by data entry locks.
The names of locked entities (for example, the database, data set, or
lock descriptor for data entries) appear in uppercase followed by a list
of other processes waiting at that locking level. DBUTIL indicates in
lowercase the reason each process is waiting. This message is preceded
by a hyphen so that it can be identified on terminals or listings from
a line printer without lowercase.

If the term (PENDING) appears after a locked entity, it indicates that
the lock has been obtained but control cannot be returned to the caller
until other locks have been released. The same process identification will
appear elsewhere in the list together with an explanation of why it is waiting.

Infrequently, the term (TEMP) may appear. TurboIMAGE/XL places a temporary
lock on a data set while it processes an existing data entry lock request.
Temporary locks occur only when a user requests data entry locks on different
items. Whenever the lock item changes, TurboIMAGE/XL must wait until all
existing locks on the current lock item are cleared before it places a lock
on the new lock item. During the wait the lock is termed "TEMP." These locks
are held very briefly and only under rare circumstances. The Process
Identification Numbers (PINs) and job/session numbers listed are the same as
those shown by MPE/iX commands, such as SHOWJOB and SHOWQ.

Example 1 (Show Locks):

.
.
.
>>SHOW ORDERS LOCKS OFFLINE List the status of locks requested and held in the ORDERS database on the line printer.

The line printer listing looks similar to this:
HP30391C.00.00 TurboIMAGE/XL: DBUTIL THURS, SEP 21, 1989, 5:06 PM

For database ORDERS

PIN/ PROGRAM
LOCKED ENTITY - ( - waiting process) PATH NAME JOBNUM
1
DATA SET SALES 30/1 BROWSE #S126
2
-waiting for data set unlock: 17 INVENTRY #S128
-waiting for data set unlock: 32 ORDENTRY #S129
-waiting for data set unlock: 21 ORDENTRY #S118

3
DATA SET CUSTOMER 30/1 BROWSE #S126
DATA SET INVENTORY 30/1 BROWSE #S126

Example 1 Discussion

1 Indicates process 30 (program BROWSE executing in session 126)
has the SALES data set locked through access path 1.

2 Shows a queue of processes waiting for the SALES data set to unlock.
 For example, in the first line, process 17 (program INVENTRY executing
 in session 128) is waiting. Because it is listed first in the queue,
 it will be the next process to resume execution after the SALES data set
 is unlocked. It could be waiting to place a lock on the data set or entries in the set.

3 Indicates process 30 (program BROWSE, session 126, access path 1) has the
CUSTOMER data set locked. No processes are waiting for the lock to be released.

Example 2 (Show Locks):

Here is another example of a locking list that might appear when the
>>SHOW LOCKS command is entered.

HP30391C.00.00 TurboIMAGE/XL: DBUTIL THURS, SEP 21, 1989, 5:15 PM

For database ORDERS

PIN/ PROGRAM
LOCKED ENTITY - ( - waiting process) PATH NAME JOBNUM
1
DATABASE (PENDING) 22 BROWSE #S118
-waiting for zero locks within database:22 BROWSE #S118

2
DATA SET INVENTORY 29/1 INVENTRY #S115

3
SALES: QUANTITY<= 50 28/1 BROWSE #S112
4
CUSTOMER: CUST-NAME = DON'S MERCANTILE 31/1 ORDENTRY #S117

Example 2 Discussion

1 Indicates process 22 (program BROWSE, session 118) has requested
 a lock on the database and yet it cannot continue until existing
locks held in the database are released. In this example, the reason
 for the pending lock is listed on the line below.

2 Indicates process 29 (program INVENTRY, session 115, access path 1)
 has the INVENTORY data set locked.

3 Indicates that process 28 (program BROWSE, session 112, access path 1)
 has all entries in the SALES data set with QUANTITY less than or equal to 50 locked.

4 Indicates process 31 (program ORDENTRY, session 117, access path 1)
 has all entries in the CUSTOMER data set with LAST-NAME equal to
 DON'S MERCANTILE locked.

All subsequent requests for locks must be made to wait until process 22
 releases its database lock.

VERIFY

Reports whether a remote database-access (RDBA) file is activated or
deactivated and checks the validity of the RDBA file.

Syntax:

>>V[ERIFY] database-access-file-name

Example:

VERIFY ORDDBA

where ORDDBA is the database-access file name.

Parameter:

database-access-file-name is the name of a remote database-access file.

Example:

:RUN DBUTIL.PUB.SYS Initiate DBUTIL execution.
.
.
.
>>VERIFY ORDDBA Enter >>VERIFY command and database-access file name.
Database-access file
ORDDBA is ACTIVATED
>>

When an RDBA file is activated, it is changed to a privileged file and
cannot be edited; it is changed back to an editor file when it is deactivated.

EXAMPLE(S)

     -

ADDITIONAL INFORMATION

Commands: