BACKUP (Create Backups) › BACKUP CXX (Back Up Directory) › How to Use

How to Use

You can execute this command in either Single User or with the MUF active. In Simplify mode, however, to provide current accurate information and to control (prevent) inappropriate executions, MUF is always intended to run enabled. If MUF is not enabled, it is a best practice to allow it to enable using the DELAY68= option of the DBSIDPR module. For details about the DBSIDPR module, see the CA Datacom/DB Database and System Administration Guide. If you know that the MUF is not enabled, and if you do not intend to enable it, and if you must force the execution of this BACKUP, declare the MUF is not to be used either by performing the BACKUP after another function that executes only with MUF down, or by following a function to establish that environment using SET OPTION1=MUF_NOT_ENABLED, which disables any DELAY68= and forces execution with MUF not enabled.

To back up your Directory, execute DBUTLTY using the command:

Back Up Directory (z/OS)

►►─ BACKUP AREA=CXX,DDNAME=dddddddd ─┬───────────┬─────────────────────────────►◄
                                     └─ ,DBID=n ─┘

Command

BACKUP

Invokes the BACKUP function.

Required Keywords

AREA=CXX

Identifies the area to be backed up as the Directory.

,DDNAME=

Specifies the z/OS JCL DDname for the output data set. This name must match the corresponding name in your JCL.

A DDNAME is not acceptable for sequential input or output files if it is a name reserved for a CA Datacom area. Names with the following patterns are therefore not acceptable for DDNAME=:

• 3-byte names that end with XX, meaning they are reserved as either current or future CA Datacom control areas.
• 6-byte names that end with what could be a database ID from 001 through 999.
• 7-byte names that end with what could be a database ID from 1000 through 9999.

  The DDNAME= value is verified for acceptability to protect you from unintentionally causing data corruption. The DDNAME check is the default but optional. You can prevent the DDNAME check by using a DBSIDPR parameter (DBUTLTY_EDIT_DATA_SET=) for individual MUF environments. However, we recommend that you allow the DDNAME check.

  The data corruption risk involves not the DDNAME itself but the content of the data set. For example, suppose that you used the CXX DDNAME as the output of a backup. You then copied the CXX DD statement and changed the DDNAME of the copy to be acceptable, avoiding the DDNAME= error. The backup would, however, then overlay the CXX data set, which is not the intent of a backup.

  If you specify an unacceptable name for DDNAME=, message DB10059E is generated. For more information about DB10059, see the CA Datacom/DB Message Reference Guide.

  Note: We recommend that you allow DDNAME= check protection. You can, however, disable DDNAME= protection. To disable protection, assemble the DBSIDPR module used for this CA Datacom environment and specify NONE for the DBUTLTY_EDIT_DATA_SET= parameter. The default is DBUTLTY_EDIT_DATA_SET=FULL_1, which allows DDNAME= protection. For more information about DBSIDPR and DBUTLTY_EDIT_DATA_SET=, see the CA Datacom/DB Database and System Administrator Guide.

  Valid Entries:

  Any name valid to z/OS JCL specifications

  Default Value:

  (No default)

Optional Keywords

,DBID=

Identifies the database to be backed up. If not specified, the function backs up the entire CXX. With DBID= specified, the only output is the designated database. Only one DBID can be specified and only once, that is, you cannot specify a range of databases.

Valid Entries:

DATACOM-ID of the database

Default Value:

(No default)