Skip to content

Tracking Updates to the DMSII Database

This chapter covers the tracking of updates to the DMSII database by the Databridge Flat File Client. The Flat File Client tracks updates to a data set (or a table mapped from a data set) by writing them to a flat file that contains some meta-data columns that identify things like the update type. This is very similar to the concept of history tables that the relational database clients support. In addition, it explains how to deal with DMSII reorganizations.

Creating the Update Flat Files

The system tracks DMSII updates by adding a record that contains the DMSII record data to the corresponding flat file with some meta-data columns added. Updates that involve the addition, deletion, or modification of a record are represented by a column that specifies the update type and the actual record data. The Flat File Client offers two choices for this column, mainly the numeric update_type column or the single character change_code column that the DBSPAN accessory uses. See the table in Defining a Data Source of this manual for details on these columns.

Extracts, fixups and updates can be written to the same set of files (one per table) or to a different set of files (one set for extracts, one for fixups, and one for updates). The directories where these files reside are defined by the extracts_dir, fixups_dir and updates_dir parameters in the [PCSpan] section of the Client Configuration Files. They are described in Client Configuration Files in the Appendix of this manual. If using a single set of files, you will likely want to include the mode column in the files.

You can save updates in the Databridge Flat File Client data files by executing the process command each time you want to process the updates, or you can schedule a process command. See Scheduling Updates in Chapter 4 of the Client Administrator's Guide for details on scheduling.

Anomalies That Can Occur In Updates

When the Databridge Flat File Client updates the data files, the following anomalies can occur:
Last quiet point (QPT) in an audit file When processing an update transaction group since the last quiet point, DBEngine or DBEnterprise does the following when it reaches the end of the last available audit file:
  • Aborts the current transaction group so that the updates are rolled back. These are not duplicate updates, but updates that could not be committed. These updates will be reapplied the next time you run a process command.
  • Sends the Databridge Client a status indicating that the transaction group was rolled back. Upon receiving this status, the Databridge Client does not display any messages. In this case the updates in the transaction group are not appended to the data files.
Host application rolls back changes. See Rollbacks for more information. If a host application encounters an error condition while updating the DMSII database, it rolls back all of the changes it made. In this case, DBEngine aborts the updates when it finds the aborted transaction indication in the audit file. DBEngine handles the situation in one of two ways based on the setting of the Engine control file parameter CONVERT REVERSALS TO UPDATES:
  1. If CONVERT REVERSALS TO UPDATES is FALSE (the default setting), DBEngine sends an abort transaction status to the Databridge Client and then reprocesses the transaction group, excluding any updates by the program(s) that rolled back its updates. In this case, no data in the aborted transaction is written to the data files.
  2. If CONVERT REVERSALS TO UPDATES is TRUE, DBEngine will continue to process the audit file, converting the items marked as reversals to normal updates, in a manner similar to the method employed by DMSII. (DMSII aborts transactions by reversing the updates previously done. Thus an ADD will be reversed to a DELETE, a DELETE reversed to ADD, MODIFY to a MODIFY using the Before Image). All updates, including those that were aborted and their reversals, are written to the data files.

In order to handle these situations, the Flat File Client uses temporary files to hold the updates in a transaction group. Upon getting a COMMIT from the Databridge Engine (we use this term to refer to both DBServer on the MCP and Databridge Enterprise Server), it appends the updates for all the tables that were updated to the corresponding data files. In the case of getting an ABORT from the Databridge Engine, it does not update the data files. In both cases, the temporary files are invalidated so that they get overwritten when the Client gets the next group of updates.