The MERGE ARCHIVE utility is used to merge the archived journal files of data sharing group members that are sharing update access to data. It can also be used to merge archive and local mode journal files to simplify a subsequent recovery operation.
The MERGE ARCHIVE utility is used to merge the archived journal files of data sharing group members that are sharing update access to data. It can also be used to merge archive and local mode journal files to simplify a subsequent recovery operation.
The output file created by the merge utility can be used as input to the ROLLFORWARD, ROLLBACK, EXTRACT JOURNAL, and MERGE ARCHIVE utility statements.
The merge utility also produces a report identifying global quiesce points within the set of merged journal images.
Under certain circumstances, this utility must be used if members of a data sharing group are sharing update access to data.
For more information about when the use of this utility is mandated, see Backup and Recovery in the
CA IDMS Database Administration Section
This article describes the following information:
You Need This Privilege
merge archived journal files
  ►►──── MERGE ARCHIVE ─┬─ COMPLETE ───┬───────────────────────────────────►                       └─ INCOMPLETE ─┘  ►────────────┬──────────────────────┬───────────────────────────────────►◄               └─ REPORT ─┬─ FULL ◄───┤                          ├─ TERSE ───┤                          └─ SUMMARY ─┘  
    Indicates that all journal files that contain images needed for recovery have been included as input. To complete transactions that are incomplete at the end of the process, additional checkpoint records will be written to the merged output file:
    • For incomplete distributed transactions whose state is InDoubt, additional distributed and local checkpoint records will be written if a matching section recovery control input file entry is provided.
    • For local (that is, non-distributed) transactions still active at the end of the process, an ABRT checkpoint record will be written.
    The output file may then be used as input to the ROLLBACK, ROLLFORWARD, or EXTRACT JOURNAL utility functions.
    Indicates that only a subset of the journal files have been included as input. The journal files are merged, but no additional checkpoints are generated. The output file can be used only as input to an EXTRACT JOURNAL or a subsequent MERGE ARCHIVE. You should not use the output file as input to ROLLBACK or ROLLFORWARD.
    Specifies the amount of detail that is to appear on the report produced by the merge utility.
  • FULL
    Specifies that all details are to be reported. This includes for every transaction: checkpoints, database statistics, and area usage. All details of a distributed transaction record are reported. This includes local transaction ids with program names, external transaction ids, and resource manager interests. Additionally, transactions active at the end of the process are listed and the time of the last global quiesce point is identified. FULL is the default if no REPORT option is specified.
    Indicates that only transaction checkpoints and summary information is produced. For distributed transaction records: external transaction ids and resource manager interests are not included in the report.
    Indicates that only final summary information is produced.
Processing flow
MERGE ARCHIVE uses two input files: SYS001 and JRNM01 and one output file: SYS002. It proceeds by sorting the contents of SYS001 in chronological sequence and then merging the results of the sort with the contents of JRNM01. The resulting merged journal images are then processed and written to SYS002. Control records are also written to SYS002 indicating the range of images for each member that are included on the merged file and an indication of whether or not the output file was created with the COMPLETE option.
Input files
SYS001 is used to supply input that is not in chronological sequence. Typically, archive files from one or more data sharing members are concatenated together as input to SYS001, although it is also possible to include one or more merged files as input. The order of concatenation is not relevant.
JRNM01 is used to supply a single merged archive file. Multiple files cannot be concatenated as input to JRNM01. If no merged archive file exists, then JRNM01 should be specified as dummy.
Incremental merging
To minimize recovery time, journal files can be merged periodically and the output from each merge operation used as input to a subsequent MERGE ARCHIVE.
When merging journal files incrementally, specify the INCOMPLETE option on every MERGE ARCHIVE execution except the final one. The final merge operation before executing a ROLLFORWARD or ROLLBACK utility statement must specify the COMPLETE option.
Using disk files
It is possible to use disk files for merged journal files. This can be beneficial for incremental merging, since all intermediate merged files can reside on disk. Only the final merged file (the one created with the COMPLETE option) may need to be written to tape so that ROLLFORWARD or ROLLBACK can process it.
Incomplete transactions
If a transaction is encountered whose initial checkpoint record (BGIN) is not contained on the input files being processed, a warning message is written that will result in a return code of 4. This is not necessarily an error, since missing journal images can be merged at a later time; however, the missing journal records might need to be provided before the merged file can be used for recovery purposes. For more information, see the ROLLFORWARD or ROLLBACK utility commands.
MERGE ARCHIVE and Distributed Transactions
MERGE ARCHIVE reports on distributed transactions and supports the use of input and output section recovery control files. If COMPLETE is specified, the input section recovery control file is used to complete InDoubt distributed transactions. If an output section recovery control file is included in the JCL, an entry will be written for each incomplete distributed transaction encountered. For more information, see JCL Considerations and the "Common Facilities for Distributed Transactions" section.
For considerations associated with distributed transactions during recovery operations, see the
CA IDMS Database Administration Section
JCL Considerations
When submitting a MERGE JOURNAL statement through the batch command facility, in addition to the standard JCL required for the batch command facility, you must also include statements to define:
  • SYS001 to point to the concatenated set of archived journal files or merged journal files
  • JRNM01 to point to a single merged journal file. If no such file exists, JRNM01 must be specified as DUMMY
  • SYS002 to point to the merged output file. The output file will have the block size that is specified for the archive journal file in the DMCL used for the merge
  • Any sort work files needed by your local sort
To use a section recovery input control file, include a CTRLIN file definition or DD statement in the IDMSBCF execution JCL. To use a section recovery output control file, include a CTRLOUT file definition or DD statement in the IDMSBCF execution JCL. The format of these files is fixed block with a record length of 80.
For more information about the generic JCL used to execute the batch command facility, see the section for your operating system in this section.
The following statement directs the MERGE ARCHIVE utility to create a merged output file of all archived journal records and to write ABRT checkpoint records for any transaction still active when all input has been processed.
merge archive complete;
Sample Output
The following is output generated after submitting a MERGE ARCHIVE statement to the batch command facility.
More Information
  • For more information about section recovery, see the
    CA IDMS Database Administration Section
  • For more information about data sharing, see the
    CA IDMS System Operations Section