HP 3000 Manuals HP 3000 Manuals
Utility Program Operation (contd)
Error Messages (contd)
>>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.
Syntax
>>ER[ASE] database name [/maint word]
For 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.
>>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:
HELP CREATE ERASE PURGE DEACTIVATE
ACTIVATE VERIFY SET ENABLE DISABLE
SHOW EXIT RELEASE SECURE MOVE
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] TurboIMAGE/XL file name TO device
For 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.
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 index files regardless of 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.
Syntax
>>P[URGE] database name [/maint word] [DETACH]
For 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 ALLBASE/Turbo CONNECT
(ATC) product. This option detaches the database
from all ALLBASE/SQL database environments
(DBEnvironments) to which it could be attached via
ATC. When DETACH is not used, the database is
purged without detaching from the DBEnvironment(s).
For more information, refer to the ALLBASE/Turbo
CONNECT Administrator's Guide.
Unexpected Results
The following messages are printed if an unexpected situation occurs
(refer to appendix A for other error messages):
---------------------------------------------------------------------------------------------
| | |
| Message | Meaning |
| | |
---------------------------------------------------------------------------------------------
| | |
| No root file, >>PURGE operation proceeding | DBUTIL was unable to locate the root file, |
| | but will attempt to purge data set, if any. |
| | |
---------------------------------------------------------------------------------------------
| | |
| Data set XXXXk has been purged | DBUTIL successfully purged the root file |
| | and the n data sets of the database. |
| | However, DBUTIL also discovered and purged |
| | an unexpected data set named XXXXk, where k |
| | is a number greater than the number of data |
| | sets defined for the database (n). |
| | |
---------------------------------------------------------------------------------------------
Table 8-1. (cont.)
---------------------------------------------------------------------------------------------
| | |
| Message | Meaning |
| | |
---------------------------------------------------------------------------------------------
| | |
| Data set XXXXk is missing | DBUTIL successfully purged the root file |
| | and all existing data sets but data set |
| | XXXXk is unexpectedly missing. In this |
| | case k is less than the number of data sets |
| | defined for the database. |
| | |
---------------------------------------------------------------------------------------------
| | |
| Incomplete purge | An error occurred while DBUTIL was |
| | attempting to purge the database and any |
| | Third-party indexing files. The specific |
| | error message is printed above this one. |
| | Some of the data sets and, if applicable, |
| | index files have been purged. |
| | |
---------------------------------------------------------------------------------------------
| | |
| Detach failed from DBEname | This message is returned if you are using |
| | the ALLBASE/Turbo CONNECT (ATC) product. |
| | DBUTIL was unable to detach the |
| | TurboIMAGE/XL database from the ALLBASE/SQL |
| | database environment (DBEnvironment) to |
| | which it was attached. However, DBUTIL |
| | will continue executing the >>PURGE |
| | command. For more information, refer to |
| | the ALLBASE/Turbo CONNECT Administrator's |
| | Guide. |
| | |
---------------------------------------------------------------------------------------------
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 the ALLBASE/Turbo CONNECT
(ATC) product, 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.
>>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
For example:
RELEASE ORDERS
where ORDERS is the database name.
Parameter
database name is the name of a TurboIMAGE/XL database being
released.
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.
>>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
For 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.
>>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=maintenance word }
{ {NONE} }
{SUBSYSTEMS={READ} }
{ {RW } }
{ }
{PASSWORD classnum=[password] }
{LANGUAGE=language id }
{ {DISALLOWED} }
{CIUPDATE={ALLOWED } }
{ {ON } }
For 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.
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. This is the
default setting.
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.
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.
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=ALLOWED Indicates that processes can first call DBCONTROL mode 5 to enable them to update the values
of detail data set search or sort items in the ORDERS database.
CIUPDATE is allowed. DBUTIL confirms the setting.