Skip to content

Chapter 11: DMSII Reorganizations and Rollbacks

This chapter discusses how to accommodate reorganizations(page213) and rollbacks(page213) on the DMSII database.

Prepare for a DMSII Reorganization

Use this procedure before you reorganize your DMSII database.

To prepare for a DMSII reorganization

  1. Run WFL/DATABRIDGE/BACKUPTAILORED to create copies of the DESCRIPTION file and DMSUPPORT library with the update level as the last node in the file titles. This ensures that Databridge has access to the previous layout information (in the old DESCRIPTION file) to correctly process the audit trail files created before the reorganization. For instructions, see Save with Update Level (WFL).

  2. Make the necessary changes to the DASDL and then compile the new DASDL, using the method you normally use at your site.

    When the DASDL is finished compiling, a message states that a database reorganization is required. For example, if the database is BANKDB and the update level is 51, the DASDL compile creates the file DESCRIPTION/BANKDB with update level 52. (The file DMSUPPORT/BANKDB with update level 52 is also created if the DASDL is set to compile DMSUPPORT automatically.)

  3. Compile DMSUPPORT if it was not set to compile automatically when you compiled the DASDL. The DMSUPPORT compile creates the file DMSUPPORT/BANKDB with the next update level (52 in our example).

  4. Run WFL/DATABRIDGE/BACKUPTAILORED to back up the new DESCRIPTION/BANKDB and DMSUPPORT/BANKDB files with the next update level in the filename.

  5. Generate the reorganization program using BuildReorg, choosing global control options (INQUIRYONLY, EXCLUSIVE, OFFLINE, and USEREORGDB), as needed.

    Important

    If you use USEREORGDB, be aware that RSNs in the records that USEREORGDB creates will change when the new records are merged into the live database. This creates problems in the client database when records get updated, if the RSNs are used as keys. Starting in DMSII 55.1 (MCP 14.0), the BuildReorg GENERATE statement lets you specify the option KEEPRSN, which prevents these RSNs from changing.

    For example,

    GENERATE EMPLOYEES KEEPRSN;

  6. Compile and run the DMSII reorganization program.

    The reorganization closes the current audit file and opens a new one. Then, it copies the old DESCRIPTION and DMSUPPORT files before it installs the new DMSUPPORT library.

  7. If you have a tailored Support Library, update the GenFormat parameters and custom VIRTUAL and/or ALTER data set code, as needed.

  8. If you use Databridge Span for replication, perform the procedure in Complete a DMSII Reorganization.

If you use the Databridge Administrative Console, see "DMSII Reorganizations and Rollbacks" in the Databridge Client Administrator's Guide.

Complete a DMSII Reorganization

If you use Databridge Span for replication, follow this procedure after a DMSII database reorganization occurs.

To complete a DMSII reorganization

  1. Complete the steps in Prepare for a DMSII Reorganization, which include creating backup copies of the current DESCRIPTION file and DMSUPPORT library.

  2. Run Databridge Span. When it detects the reorganization, Databridge Span stops and displays the following message:

    Databridge Engine: >> [0020] Table reorganization required for datasetname; DMS dataset level = updatelevel, Table level = clienttablelevel <<

    If the DESCRIPTION/databasename file has a different update level than the audit file, DBEngine tries to read one of the following files (in the order shown):

    • DESCRIPTION/databasename/audit_file_update_level
    • *audit_file_update_level/DESCRIPTION/databasename

    If the DMSUPPORT library has a different level than the audit file, DBEngine tries to read one of the following files (in the order shown):

    • normal_DMSUPPORT_title/audit_file_update_level
    • audit_file_update_level/normal_DMSUPPORT_TITLE

    Continuing with the previous example, when you run Databridge Span, it might try to process an audit file with update level 51. If so, Databridge automatically tries to read DESCRIPTION/BANKDB/51 or 51/DESCRIPTION/BANKDB and tries to link to DMSUPPORT/BANKDB/51 or 51/

    DMSUPPORT/BANKDB to determine how to process that audit file. When Databridge finishes processing audit files with update level 51, it searches for a DESCRIPTION file and DMSUPPORT file with update level 52. 3. Process the Databridge Span output files as you usually do. For example, you may transfer them to the client system. This prevents from having data (if record sizes are equal) or an /OLDATTS node appended to the filenames of your old output (if record sizes are not equal) the next time you run Databridge Span.

  3. Prepare the client system to process files corresponding to the new format for the reorganized data sets. The changes you make will depend on how the client is set up at your site.

  4. In the Databridge Span parameter file, identify the reorganized data sets which will now have a mode of 3, and do the following:

    1. Change the mode from 3 (indicating reorganization) to 2 (indicating “ready to update”).
    2. Change the client format level to match the DMSII format level.

  5. Run Databridge Span as usual.

    The reorganized records will appear in the Databridge Span output files.

Preparing for a DMSII Rollback

You can prepare for possible DMSII rollbacks by backing up Databridge Span parameter files after each replication run. If you typically let Databridge Span append data to existing data files from previous runs, you will also need to back up the data files at the end of each run such that they can be matched with any particular parameter file backup. This allows you to easily reposition the Databridge Span parameter file to a commit point prior to the restore point on the primary database.

If you anticipate having to roll back up to three days of transactions from your database, save backup copies of Span Accessory parameter files for the last three days that you ran it. Databridge Span stores audit location information in its parameter file and the information is updated each time you run it.

Consider saving the parameter files in one of the following ways:

  • If you run Span several times a day:

    DATA/SPAN/databasename/CONTROL/001 DATA/SPAN/databasename/CONTROL/002 DATA/SPAN/databasename/CONTROL/003

  • If you run Span once a day:

    DATA/SPAN/databasename/CONTROL/FEBRUARY4 DATA/SPAN/databasename/CONTROL/FEBRUARY5 DATA/SPAN/databasename/CONTROL/FEBRUARY6

Recover from a DMSII Rollback

Use the following procedure to recover from a DMSII rollback in Databridge Span. This procedure requires that you routinely back up your Databridge Span parameter file. See Preparing for a DMSII Rollback for more information. If you don't have these files, use the procedure in the Manual Recovery from a Rollback section.

To recover from a DMSII rollback

  1. Read the DMSII rollback report to determine the audit location of the rollback point. The report will indicate the AFN (audit file number) and ABSN (audit block serial number) of the rollback point, or earlier.

    Alternatively, if you run Databridge Span before reloading an older parameter file, DBEngine will detect an audit location mismatch and try to find the rollback point in the audit trail. If it is successful, Databridge Span will receive the result code 0120 Databridge Engine: Database rolled back to AFN=afn ABSN=absn Seg=seg Inx=inx timestamp

  2. Restore the Databridge Span parameter file that corresponds to the rollback point, or earlier.

  3. Remove any Databridge Span output files that were created after the rollback point.

  4. If Databridge Span appends updates to data files created by previous replication runs, you must copy the data files from the backup you made matching the parameter file you loaded in step 2.

  5. Run Databridge Span as usual.

    If you get an error similar to either of the following, an audit discontinuity has occurred. See the next procedure, Manual Recovery from a Rollback.

    Databridge Engine: >> [0033] tablename: Audit location mismatch,
    subtype = value is wrong. Check for DMS rollback <<
    Databridge Engine: >> [0092] Expected ABSN=nnnn in AUDITnnn at segment
    nnnn but found ABSN=mmmm <<

Manual Recovery from a Rollback

Use this procedure to manually recover the Databridge Span parameter and output files after a DMSII rollback occurs. This procedure is appropriate for situations where a copy of the Databridge Span parameter file prior to the rollback point is unavailable. Databridge cannot continue replication until the audit locations in the parameter file are manually corrected using the following instructions.

To manually recover from a rollback

  1. Run DBInfo in Interactive Mode.

  2. When prompted, enter the AFN and ABSN of the rollback point and record the information that appears. For example:

    Quiet point found on January 30, 2010 @ 09:12:17 at audit location AFN = 18 ABSN = 17090 SEG = 9 INX = 10

    If Databridge Span sometimes appends updates to data files created by previous replication runs, you must use an AFN and ABSN corresponding to the last time the data files were created from scratch prior to the rollback point. For example, if the rollback point is AFN 18 and ABSN 17090 but the last time the output files were created from scratch was at AFN 17 and ABSN 15885, you need to enter AFN 17 and ABSN 15885 in the Database Info utility.

  3. Get the Databridge Span parameter file.

  4. In the replication status information, enter the values from the DBInfo interactive report for each data set:

    Caution

    Take precautions to enter the information from the DBInfo interactive report correctly. If the numbers aren't entered correctly, valid updates may be skipped. For example, if the AFN is 100, make sure that you enter 100 and not 102. Entering 102 would prevent you from getting updates from audit files 100 and 101.

    • From the Info interactive report, enter the AFN value for File Nbr.
    • From the Info interactive report, enter the ABSN value for Aud Block SerialNbr.
    • From the Info interactive report, enter the SEG value for Segment Number.
    • From the Info interactive report, enter the INX value for Word Index.
    • Change the date and time values to all zeros. (If you omit this, the Span Accessory will fail with an invalid timestamp error or 0033, which indicates a corrupt audit file because of the invalid timestamp.)
    • Change the Mode to 2 if it is not already 2. (If you know that the value was something else, use that value; in most cases, however, the value will be 2. A value of 2 indicates that the data set is ready to be updated.)

    An example of the pertinent columns in the replication status information follows.

    %Data Rec File Aud Block Segment Word Date Time Mo- Format-Lvl %-set Type Nbr SerialNbr Number Index YYYYMMDDhhmmss de DMS Client %---- --- ---- --------- ------- ----- -------------- - ---- ---- % . % . % . %00003 000 0018 0000017090 0000009 00010 0000000000000 2 00000 00000

  5. When you have finished making the changes to each data set, save the Span Accessory parameter file.

  6. Remove all of the current Databridge Span output files to prevent the new updates from appending on to the current (yet now obsolete) files.

  7. Run Databridge Span as usual.

    Caution

    If the entered audit location does not exactly match the secondary database, or if you do not know the exact state of the secondary database, there is a possibility of record duplication or loss.