Skip to content
CA Datacom Core - 15.1
Documentation powered by DocOps

Back Up Data Area

Last update March 13, 2019

The BACKUP Data Area option of DBUTLTY reads the specified area (or all areas of a database for a "base-level backup") and writes a sequential output data set. A backup can also be made of a data area that either INCLUDEs or EXCLUDEs specific tables. The output data set record format is variable blocked.

Note: Since a MRDF-supported virtual area exists only in the MUF memory, you cannot perform a backup of the data without MULTUSE=YES. If you execute the backup of a virtual table without MULTUSE=YES, the backup accesses the disk area either unloading no records or unloading any records as they existed in the area before it became virtual. You can perform a backup of a covered area since CA Datacom®/DB writes to both the area in memory and the DASD copy.

In Simplify mode, the function requires MUF to be enabled. This provides control and protection. If MUF is not enabled, this function should wait for MUF to enable. If you are required to execute the function without MUF enabled, for example when you need to allow restart to execute, the function has to be made to follow a function that can only run with MUF not enabled, or it must follow a function to acknowledge MUF is not enabled with SET OPTION1=MUF_NOT_ENABLED. It is possible (but not recommended) to use SET OPTION1=MUF_ENABLED_OR_DISABLED.

A BACKUP without MULTUSE=YES and without SEQ=PHYSICAL requires the database to be closed. If the database is open with no users, it is automatically closed. A BACKUP with SEQ=PHYSICAL automatically causes a COMM STATS to the database before execution, to record current statistics and control information to the CXX and data area control block. It also forces the pipeline of write pendings for the data area.

The following topics are discussed on this page:

When to Use

Use the BACKUP data area option to perform the following:

  • Create an unloaded copy of a data area for input to the LOAD function to reorganize the data area in Native Key sequence.
  • Create a backup of a table that is to be moved to another data area after appropriate changes to CA Datacom® Datadictionary™ definitions.
  • Create a backup of the data area that can be used in a future forward recovery operation if the data area becomes damaged.
  • Retrieve the data in a data area after the Index has become damaged.

Native Sequence Backups

The native sequence backup uses the Native Key defined to each table in a data area to reorganize the data area in Native Key sequence. You cannot use the native sequence for a backup if the Native Key is also defined as the direct access key.

A native sequence backup of a data area is not allowed if the database is open for update by any other task. Once a Native Sequence backup begins, CA Datacom®/DB does not allow an open for update.

With a Native Key sequence, the FIRSTKEY= and LASTKEY= optional keywords can be used to selectively include or exclude data from BACKUP output file. This can be used for building test data, purging old data, or selecting segments of CA Datacom® tables for offline processing.

When using Native Key sequence you can do a parallel backup.

Physical Sequence Backups (Not Continuous Operation)

Create a physical sequence backup for later use in restoring a damaged database. A noncontinuous operation backup (UPDATE=YES) in physical sequence can be made only if the database is not open for update.

Backups During Continuous Operation

To perform a backup while processing continues, specify a physical sequence backup and UPDATE=NO in the command. The UPDATE=NO parameter allows the database to be updated or an update job might start during the backup. You are not blocked from performing an INIT or LOAD function during the backup. Allowing maintenance during a backup can result in backup data that cannot be used without a forward recovery. (See RECOVERY (Rebuild a Database) and Administrating for details about recovery.)

Compression

If CA Datacom®/DB compression or user compression is being used, the data can be written expanded or compressed. If the backup is being done with a following load which changes the type of compression, the backup should be expanded. Backing up compressed data generally runs faster.

Effects of Reorganization on Recovery

The forward and backward recovery operations require that record location information in the database exactly match the record location information that existed at the time the maintenance was performed. A reorganization of the database causes new record location information to be assigned. Therefore, any reorganization causes Recovery File(s) (RXX) created prior to the reorganization to be unusable.

Note: Reorganization occurs during a backup when RECID=YES is not specified.

Backup for Forward Recovery

To use forward recovery, you must restore the records in the database to the same locations at which they resided at the time the recovery records were logged. A backup containing the records that can be restored correctly can be obtained in one of two ways:

  • Create a backup in physical sequence that contains record location information (RECID=YES).
  • Create a backup in Native Key sequence or physical sequence with RECID=NO and immediately restore it. This reorganization invalidates any Recovery Files (RXX) that were made prior to the backup. However, you can use any Recovery Files created beyond this point to restore the database after reloading this backup.

Non-DBUTLTY Backups

A physical sequence backup can also be obtained using any other physical backup utility. The DBUTLTY LOAD function does not accept a non-DBUTLTY backup as input. If the MUF was active and the database was not disabled when restoring data from this type of backup, the Index must be rebuilt using the DBUTLTY RETIX (Index Retrieve) function.

Backing Up Compressed Data Areas (Physical Sequence, UPDATE=NO)

When backing up compressed data areas, if the area is being updated, records may move from one disk location to another and can be duplicated or lost. To prevent this from occurring, use the DBUTLTY LOCK and UNLOCK functions. The LOCK function prevents records from moving until the UNLOCK is issued. First, issue the lock, run the backup, and then issue the unlock. UPDAT requests that cause records to move wait for the unlock. For more information, see LOCK (Lock a Data Area) and UNLOCK.

This procedure assumes only one MUF instance is enabled when the lock is issued. If there is more than one MUF instance that can open the area for update, lock each MUF intance. No protection is provided if a MUF is disabled at the time of the lock, then subsequently enables and opens the area for update while the backup is in process.

Restoring a Damaged Index

If the Index becomes damaged or cannot be used, then a backup in physical sequence provides a means of re-creating the area without accessing the Index. You can use a physical sequence backup of a data area even if the Directory (CXX) entries describing the database were destroyed and rebuilt.

Backup Format

The backup format is not the same as that of the CA Datacom®/DB area itself, and you cannot use it except as input to a data load.

I/O or other errors result if you attempt to use a physical sequence backup with record location information (RECID=YES) as the source for a load of data:

  • To a different device type.
  • To a smaller extent of the same device type.
  • To a different block size.
  • When concatenated input files are used.
  • If the REMAP= keyword of the LOAD function is used.
  • If table partitioning is being used, and data records are moved to new partitions.
  • If loading compressed data as uncompressed or uncompressed as compressed.

Master List Requirements

The data area BACKUP function uses a form of GSETL/GETIT or GSETP/GETPS command for reading the data blocks. This includes reading multiple blocks per I/O. You can allocate sequential buffers with the SEQBUFS= keyword.

Table IDs

The Table IDs are written during backup as part of the output sequential records. CA Datacom®/DB uses these Table IDs during the LOAD function to identify the record. The Table ID cannot differ from the definition in force at the time of the LOAD using the default LOADID=YES. If the table IDs differ, LOAD might match on table names using LOADID=NO.

Databases Accessed by SQL Statements

If your site uses SQL, backing up the data areas of either the DATA-DICT or Data Definition Directory (DDD) databases without backing up the Directory can result in loss of synchronization which is critical for SQL operations. To retain synchronization, you must back up the DATA-DICT database, the DDD database, and the Directory.

Successful Execution Requirements and Controls

Environmental Requirements when MULTUSE=NO and either SEQ=NAT or SEQ=PHY,UPDATE=YES

  • The database may not be open for update anywhere.
  • The database may or may not be open in any MUF for read.
  • The database may or may not have any table in unloading status.

Environmental Controls when MULTUSE=NO and either SEQ=NAT or SEQ=PHY,UPDATE=YES

  • The database will be opened for unloading status.
  • The utility has no knowledge about current ACCESS database or area status.
  • The utility sets no ACCESS database or area status.

Environmental Requirements when SEQ=PHY (UPDATE=NO default)

  • The database may or may not be open update or read or unloading anywhere.
  • The database will not be opened for read or update or unloading.
  • This option has no requirements, it provides no protection.

Environmental Requirements when SEQ=PHY,UPDATE=NO, Simplify NO, or MUF down

  • The database may or may not be open for update or read or unloading anywhere.
  • The database is not opened for read or update or unloading.
  • This option has no requirements, it provides no protection.

Environmental Requirements when SEQ=PHY,UPDATE=NO, Simplify YES, and MUF enabled (this includes MULTUSE=YES, MULTUSE=NO or omitted)

  • The database may be open for update or will be opened.

Environmental Requirements when MULTUSE=YES (except SEQ=PHY,UPDATE=NO above)

  • The database may or may not be open for update in the connected MUF.
  • The database may not be open for update in another MUF or Single User job.
  • The database may not have any table in unloading status.
  • The database ACCESS must be set OPTIMIZE and WRITE/READ/UTLTY.
  • The area ACCESS must be set WRITE/READ/UTLTY.
  • The area may have no table in an open URT with UPDATE=YES.
  • The area may not have any other MULTUSE=YES utility executing.
  • When MULTUSE=YES, this function is not allowed against a Data Sharing MUF if more than one is executing.

Environmental Controls when MULTUSE=YES

  • The database will be opened by MUF for update.
  • The database will have no unloading status set.
  • The utility sets ACCESS area READ (utility set).
  • The utility sets BACKUP executing this MUF this database area.

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 Administrating. 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 create a backup of a data area, execute DBUTLTY using the following command. You can code multiple EXCLUDE= or INCLUDE= keywords.

Back Up All Areas in Database Native (z/OS)

►►─ BACKUP ─┬──────────────────┬─ DBID=n,DDNAME=bbbbbbb ──────────────────────►
            └─ BLKSIZE=nnnnn, ─┘

 ►─┬───────────────────────┬─┬────────────────────┬─┬────────────────┬────────►
   └─ ,CMPRS= ─┬─ YES ◄ ─┬─┘ │ ┌────────────────┐ │ └─ ,SEQBUFS=nnn ─┘
               └─ NO ────┘   ├─▼─ ,EXCLUDE=ccc ─┴─┤
                             │ ┌────────────────┐ │
                             └─▼─ ,INCLUDE=ccc ─┴─┘

 ►─ ,SEQ=NATIVE ──────────────────────────────────────────────────────────────►◄

Back Up Single Area in Database Native (z/OS)

►►─ BACKUP AREA=aaa, ─┬──────────────────┬─ DBID=n,DDNAME=bbbbbbb ──────────►
                      └─ BLKSIZE=nnnnn, ─┘

 ►─┬───────────────────────┬─┬────────────────────┬─┬───────────────┬───────►
   └─ ,CMPRS= ─┬─ YES ◄ ─┬─┘ │ ┌────────────────┐ │ └─ ,FIRSTKEY=n ─┘
               └─ NO ────┘   ├─▼─ ,EXCLUDE=ccc ─┴─┤
                             │ ┌────────────────┐ │
                             └─▼─ ,INCLUDE=ccc ─┴─┘

 ►─┬──────────────┬─┬───────────────────────┬─┬────────────────┬────────────►
   └─ ,LASTKEY=n ─┘ └─ ,MULTUSE= ─┬─ NO ──┬─┘ └─ ,SEQBUFS=nnn ─┘
                                  └─ YES ─┘

 ►─ ,SEQ=NATIVE ────────────────────────────────────────────────────────────►◄

Back Up Data Area Physical (z/OS)

►►─ BACKUP ─┬─────────────┬─┬──────────────────┬─ DBID=n,DDNAME=bbbbbbb ──────►
            └─ AREA=aaa, ─┘ └─ BLKSIZE=nnnnn, ─┘

 ►─┬───────────────────────┬─┬────────────────────┬───────────────────────────►
   └─ ,CMPRS= ─┬─ YES ◄ ─┬─┘ │ ┌────────────────┐ │
               └─ NO ────┘   ├─▼─ ,EXCLUDE=ccc ─┴─┤
                             │ ┌────────────────┐ │
                             └─▼─ ,INCLUDE=ccc ─┴─┘

 ►─┬────────────────────────────┬─┬──────────────────────┬────────────────────►
   └─ ,IOERROR= ─┬─ NOSKIP ◄ ─┬─┘ └─ ,RECID= ─┬─ NO ◄ ─┬─┘
                 └─ SKIP ─────┘               └─ YES ──┘

 ►─┬────────────────┬─ ,SEQ=PHYSICAL ─┬───────────────────────┬───────────────►◄
   └─ ,SEQBUFS=nnn ─┘                 └─ ,UPDATE= ─┬─ NO ◄ ─┬─┘
                                                   └─ YES ──┘

Command

  • BACKUP
    Invokes the BACKUP function.

Required Keywords

  • DBID=
    Identifies the database for the area to be read.
    • Valid Entries:
      Valid DATACOM-ID of an existing database
    • Default Value:
      (No default)
  • ,DDNAME=
    Specifies the 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. 

    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 Administrating .

Optional Keywords

  • AREA=
    Identifies the data area to be backed up. If you omit this keyword, each area in the database is opened, backed up, and closed, in turn.

    Note: If you specify MULTUSE=, you must also specify an area name.
  • BLKSIZE=
    Indicates the block size for the output data set.
    If you specify a block size with this parameter, the utility ignores any BLKSIZE parameter in the JCL. If you do not specify a block size with this parameter, the utility uses the BLKSIZE specified in the JCL if one exists. In the absence of either this parameter or a specification in the JCL, the utility uses a default as specified in the following.

    Note: If the block size is not large enough to contain the largest record in the area (see formula below), DBUTLTY terminates normally.

    Calculate the minimum block size for the output data set as follows:
    A + C + 30
    Where:
    A is the length of the largest record in the area,
    C is 0, if the data is not compressed, or
    C = (A/128) + 1, if the data is compressed.

    • Valid Entries:
      A 1- to 5-digit number
    • Default Value:
      The default for BLKSIZE= when running z/OS is 0 (zero), which defaults to the z/OS default. That default is large and optimized for the particular device type, that is, the most optimal default for sites executing this operating system.
  • ,CMPRS=
    Specifies, for compressed tables, whether the output is to remain compressed or is to be expanded. This parameter has no effect on tables that are not defined with compression.
    • YES
      Specifies that DBUTLTY write the data "as is" from the area to the sequential output file. That is, a compressed table remains compressed on the output data set.
    • NO
      Specifies that DBUTLTY write the data in expanded form to the sequential output file. The NO option should be used only when the data being produced is intended to be used as input to a user-written program or if the table is to be redefined with a different combination of CA Datacom®/DB compression and user compression options than the current definition.
    Note: You must not specify CMPRS=NO and RECID=YES.
  • ,EXCLUDE=
    Specifies the name of the table that is not to be backed up. To indicate more than one table, code the EXCLUDE= parameter more than once.
    Tables that are excluded lose their data when DBUTLTY reloads from that backup. Use the EXTRACT function instead of the BACKUP function for single table recovery.
    This parameter is mutually exclusive with the INCLUDE= parameter.
    If neither EXCLUDE= nor INCLUDE= is specified, all the tables are backed up.
    • Valid Entries:
      Specify a table name within the area (or database if omitting AREA=)
    • Default Value:
      (No default)
  • ,FIRSTKEY= and/or ,LASTKEY=
    These keywords allow you to select a segment of a table or area by Native Key (SEQ=NATIVE) value to be processed for BACKUP. The BACKUP function normally defaults to include the full Native Key range from low values to high values. FIRSTKEY= overrides the default starting position while LASTKEY= overrides the default ending position, limiting the records retrieved for output to the BACKUP file. If one keyword is specified and the other is not specified, a default value is selected for the missing keyword. Normal CA Datacom® key lengths are from 1 through 180 bytes. The key value data entered for FIRSTKEY= and LASTKEY= can be from 0 (zero) through 59 bytes long. You only need to code the number of positions of the key value that are significant to you, but be aware that the value coded is left justified regardless of key field data type. The utility pads the low order or remaining positions of the key value with low values on FIRSTKEY= and high values on LASTKEY=. To back up the entire area in one step, specify neither FIRSTKEY= nor LASTKEY=. Alternately, you could specify FIRSTKEY=00 and/or LASTKEY=00 which causes processing to start at low values and end at high values. The length of zero indicates that the padded key values (low values and high values) are to be used.
    The data is not edited or interpreted. Therefore, if the key value data you need to enter is in binary, you must set up the JCL using a hexadecimal mode display and enter the key value data in hexadecimal. This data can contain blanks, commas, and any other special characters. CA Datacom®/DB cannot edit this data for syntax, so the control statement can look invalid, especially when it includes blanks or commas or key value data containing English words. For example, FIRSTKEY=12121212121212 means the length is 12, key value is 121212121212. Another example, FIRSTKEY=10FIRSTKEY10 means the length is 10, key value is FIRSTKEY10.
    • Valid Entries:
      A 2-byte length (in the range of 00 through 59) followed by a character string of key value bytes (for the length specified) that represents the key value.
    • Default Value:
      The starting/ending position of the full Native Key range from low values to high values.
  • ,INCLUDE=
    Specifies the name of a table to be backed up. To indicate more than one table, code the INCLUDE= parameter more than once.
    This parameter is mutually exclusive with the EXCLUDE= parameter.
    If neither INCLUDE= nor EXCLUDE= is specified, the entire area is backed up.
    • Valid Entries:
      Any table name within the area
    • Default Value:
      (No default)
  • ,IOERROR=
    (Not valid if AREA= keyword is omitted.) Specifies how CA Datacom®/DB is to handle I/O errors during a backup. Specify this option only for a physical sequence backup.
    A value of SKIP causes CA Datacom®/DB to issue a console message, produce a Master List dump, and skip the block in which an I/O error occurs when the utility encounters an I/O error while reading a data block.
    The utility does not skip I/O errors to other data sets or the control block of the data area. When an I/O error does occur and the SKIP value is in force, the utility exits with a good completion code since this value overrides the error condition.
    If an I/O error does not occur and the value SKIP is in force, DBUTLTY issues a warning message at the end of the execution. The utility abends with a user 4 abend code. This prevents accidental skipping of records.
    In either case, the backup is a correct, complete backup. If a skip does occur during the backup, the Master List dump and warning message provide a basis for reconstructing the missing information.

    Note: IOERROR=SKIP is not recommended and exists only to assist you in salvaging as much data as possible, if all backup tapes are defective. Frequent backups eliminate the risk associated with lost data and are preferable to the IOERROR option.
  • ,LASTKEY=
    See the description of FIRSTKEY=/LASTKEY= given previously.
    If DEVICE=TAPE (either TAPE or the Snnn form), LABEL= specifies whether tape labels are to be processed. We recommended that labeled tapes always be used.

    Note: LABEL= has no effect when DEVICE=DISK.
  • ,MULTUSE=
    (For area level DBUTLTY control only.) If you specify MULTUSE=, you must also specify an area name.
    For more information about area level DBUTLTY control, see Area Level DBUTLTY Control.
    • Valid Entries:
      NO or YES
    • Default Value:
      NO
  • ,RECID=
    Specifies whether the record location information is to be backed up as part of each output record.
    To create a physical sequence backup that can later be used with a forward recovery operation, specify RECID=YES.
    Note the following:
    • You must not specify CMPRS=NO and RECID=YES.
    • If you specify RECID=YES, make certain that the value for the table's RECOVERY attribute is YES in the CA Datacom® Datadictionary™ definition for the table.
    • Not valid if SEQ=PHYSICAL is not specified.
    • When converting a data area to the Unique Row Identifier (URI) format, the backup used as input to the DBUTLTY LOAD function must be created with RECID=NO.
    • Valid Entries:
      NO or YES
    • Default Value:
      NO

    If DEVICE=TAPE (either TAPE or the Snnn form), YES indicates the tape is to be rewound before OPEN and after CLOSE. NO indicates no rewind before OPEN or after CLOSE. NO allows the stacking of backups on one tape.

    Note: REWIND= has no effect when DEVICE=DISK.
  • ,SEQ=
    Indicates the sequence in which the input data is to be processed and written to the backup data set. For details on retrieval sequence, see Backup Format.
    • NATIVE
      Specifies that DBUTLTY read the Index and retrieve the data in Native Key sequence. When using SEQ=NATIVE, you can use the FIRSTKEY=/LASTKEY= optional keywords to select only a portion of the table or area. One of the uses of FIRSTKEY=/LASTKEY= involves doing parallel backups.
    • PHYSICAL
      Specifies that DBUTLTY not read the Index. The output has no logical sequence but does follow the physical track sequence.
    • Valid Entries:
      NATIVE or PHYSICAL
    • Default Value:
      NATIVE
  • ,SEQBUFS=
    With MULTUSE=YES specified, if necessary to ensure best performance DBUTLTY overrides the SEQBUFS= value either specified or defaulted. If SEQBUFS= is omitted (invoking the default value) or specified as a value 0-128 (even numbers only), the MUF treats this as though 128 was specified (or defaulted). This directs the MUF to allocate 128 private sequential buffers for use by this function. If SEQBUFS= is specified as a number 130-256 (even numbers only) the MUF treats this as though 256 was specified and uses the common data pools (64 blocks per I/O).
    When MULTUSE= is omitted or specified as NO, SEQBUFS= is edited and ignored, and DBUTLTY executes with the best performance by using either the available data buffers (specified with the DATANO= parameter in the DBMSTLST macro) or available private sequential buffers.
    • Valid Entries:
      0 to 256 (even numbers only)
    • Default Value:
      128
  • ,UPDATE=
    Indicates whether the database can be open for update at the start or during the backup. When using MULTUSE=YES the area level controls apply when backing up an area. 

    Note: Only valid if SEQ=PHYSICAL.

Example JCL - Native Key Sequence

The following JCL shows the command to back up the data area DEM in database 001 to the output data set, OUT1, and to output the data in Native Key sequence and compressed form using default values.

Note: Use the following as a guide to prepare your JCL. The JCL statements are for example only. Lowercase letters in a statement indicate a value you must supply. Code all statements to your site and installation standards.

 //jobname    See the previous note and JCL Requirements.
 //       EXEC PGM=DBUTLTY,REGION=2M
 //STEPLIB    See the previous note and JCL Requirements.
 //CXX      DD DSN=cxx.data.set,DISP=SHR           Directory data set
 //OUT1     DD DSN=pay.bkup,DISP=(,CATLG),         Output data
 //            UNIT=tape
 //SYSIN    DD *                                   Command Input
           BACKUP    SEQ=NATIVE,AREA=DEM,DBID=1,DDNAME=OUT1
 /*

Sample Report

Following is a sample report page. For an example report header, see Sample Report Headers.

Sample Report BACKUP Data Area - Native Key Sequence (14.0)

                    CONTROL CARD(S)
                    .........1.........2.........3.........4.........5.........6.........7.........8
                    BACKUP AREA=DEM,DBID=1,DDNAME=OUT1
 
                    FUNCTION=BACKUP
                       AREA=DEM
                       DBID=1
                       DDNAME=OUT1

This page of the report shows the following:

  • The command exactly as entered.
  • An analysis of keywords encountered and expected. Any errors found are flagged with a note in the left margin.
  • Any messages related to syntax processing.

      TABLE         RECORDS          OUT COMPRESSION      ROW SIZE
      PNC                 5            NONE                     14
      PNM                 3            NONE                     23
      POH                 5            NONE                     20
      POL                 4            NONE                     19
      TOTAL              17

This page of the report shows the following:

  • Confirmation that the request completed correctly. Seventeen records were backed up from the tables in the area. Any errors encountered during processing are noted with messages here.
  • OUT COMPRESSION is the format of the tables' output records. It can say NONE, if the output is not compressed. it can say DB, if the output is compressed with DB compression. Otherwise, it is the name of the compression routine and the 8 characters of the compression user value. Some examples with CA Datacom® Presspack follow:
    • PRESSPAK RDTC01
    • PRESSPAK WEAK
    • PRESSPAK DCTF03
    • PRESSPAK DCTRNA
    • PRESSPAK STRONG

Example JCL - Physical Sequence

The following JCL shows the command to back up the data area ACT in database 010 to the output data set, OUT2. Output the data in physical sequence and in compressed form (default).

Note: Use the following example as a guide to prepare your JCL. The JCL statements are for example only. Lowercase letters in a statement indicate a value you must supply. Code all statements to your site and installation standards.

 //jobname    See the previous note and JCL Requirements.
 //       EXEC PGM=DBUTLTY,REGION=2M
 //STEPLIB    See the previous note and JCL Requirements.
 //CXX      DD DSN=cxx.data.set,DISP=SHR           Directory data set
 //OUT2     DD DSN=act.bkup,DISP=(,CATLG),         Output data
 //          UNIT=tape
 //SYSIN    DD *                                   Command Input
            BACKUP   AREA=ACT,DBID=10,DDNAME=OUT2,SEQ=PHYSICAL
 /*

Sample Report

The following example shows a sample report page. For an example report header, see Sample Report Headers.

Sample Report BACKUP Data Area - Physical Sequence (14.0)

                    CONTROL CARD(S)
                    .........1.........2.........3.........4.........5.........6.........7.........8
                    BACKUP AREA=ACT,DBID=10,DDNAME=OUT2,SEQ=PHYSICAL
 
                    FUNCTION=BACKUP
                       AREA=ACT
                       DBID=10
                       DDNAME=OUT2
                       SEQ=PHYSICAL

This page of the report shows the following information:

  • The command exactly as entered.
  • An analysis of keywords encountered and expected. Any errors found are flagged with a note in the left margin.
  • Any messages related to syntax processing.

      TABLE         RECORDS          OUT COMPRESSION      ROW SIZE
      ACT                 3            NONE                     31
 
      TOTAL               3

This page of the report shows the following information:

  • Confirmation that the request completed correctly. Three records were copied from the single table in the area. Any errors encountered during processing are noted with messages here.
  • OUT COMPRESSION is the format of the tables' output records. It can say NONE, if the output is not compressed. It can say DB, if the output is compressed with DB compression. Otherwise, it is the name of the compression routine and the 8 characters of the compression user value. Some examples with CA Datacom® Presspack follow:
    • PRESSPAK RDTC01
    • PRESSPAK WEAK
    • PRESSPAK DCTF03
    • PRESSPAK DCTRNA
    • PRESSPAK STRONG
Was this helpful?

Please log in to post comments.