Lund Performance Solutions

Rollback Modes

Intact Dynamic Rollback Modes

There are three major rollback modes:
  • DBOPEN Mode (rollback to a DBOPEN)
  • DBBEGIN Mode (rollback to a DBBEGIN)
  • DBLOCK Mode (rollback to a DBBEGIN with soft locking)
  • The rollback mode for any database can be changed quickly and easily. A database does not have to use one mode of rollback permanently. For example, a job that modifies a particular database nightly is set to rollback to DBOPEN. In the morning, the database rollback mode can be changed to DBBEGIN to allow interactive use of the database during the day.The rollback mode can also be changed within the job stream.

    Rollback to DBOPEN

    DBOPEN is the broadest type of rollback. When a database is enabled to rollback to DBOPEN, all transactions after DBOPEN will be rolled out if a program abort occurs. This mode is particularly useful in testing a new program or in preparing test data for a new database.

    A rollback to a DBOPEN requires a database lock. This rollback mode is recommended when the database is modified by a single job. Rollback to DBOPEN can also be used when a database is modified by two (or more) jobs.

    For example, if Program 1 updates only Dataset 1, and Program 2 updates only Dataset 2 and the datasets are not related, then the two jobs may run at the same time. If Program 1 aborts, Intact Dynamic Rollback will wait until Program 2 releases its database level lock before rolling out any transactions, because Intact Dynamic Rollback requires the database level lock.

    In the second diagram the same programs update their respective datasets, however, the updates Program 1 applies to Dataset 1 are based on information the program reads from Dataset 2. If Program 2 aborts, Intact Dynamic Rollback must wait for a database level lock before rolling out the Program 2 transaction. Any changes Program 1 made (and continues to make) may be based on information that is going to be rolled out.

    To guarantee successful rollback, do the following:
  • Ensure the program that updates the database is the only modifier of that database. Other programs may access the database in read-only mode, however, if the program doing the updates aborts, the information read by the second program may be invalid.
  • Set up locking for the entire database to ensure no other modifiers inadvertently modify the same fields. If a rollback is necessary, Intact Dynamic Rollback will attempt to obtain a lock on the database and it will wait until it obtains the lock before restoring the database to its original state.
  • Typical Uses of Rollback to DBOPEN

    Restarting Jobs
    Suppose that you have a job which runs once a week at night to update the mailing database. Changes are entered into an ASCII file throughout the day and a job stream updates the database at midnight. At 12:07 AM the program updating the database aborts.

    Intact Dynamic Rollback can be set to roll back to the DBOPEN at the beginning of the job stream, so when the program aborts, any changes made to the database will be rolled back to the beginning of the job and the database administrator will be alerted. After the program error is resolved, the job can be started again without having to perform a DBRESTORE of the database.
    Testing Programs
    Suppose that you create an application program that uses a data file to update a database, and you plan to put the program into production in three weeks. To test the program, you also create a test database.

    A TERMINATE or QUIT intrinsic can be placed near the end of the program before the DBCLOSE intrinsic. When the TERMINATE or QUIT point is reached, the program will stop and Intact Dynamic Rollback will rollout all of the test data added to the database. You would not have to erase the test database.

    This use of Intact Dynamic Rollback enables a good test run for the database and for the program. However, this would not be practical if the amount of test data is so great that the rollout takes considerably longer than erasing the test entries from the database.
    Testing on a Live Database
    You can also test data on a live database. Make sure that the TERMINATE or QUIT in the program precedes the DBCLOSE of the database, then run the program that modifies the live database with the test data. (This program must be the only modifier of the database at that time, or Intact Dynamic Rollback cannot guarantee the success of the rollout.) The test data will be rolled out of the database at QUIT, or at any abort previous to that point.

    Rollback to DBBEGIN

    In the DBBEGIN rollback mode, Intact Dynamic Rollback will roll out any activity following a DBBEGIN for which there is no DBEND.

    Hewlett-Packard recommends that programs accessing a database use DBBEGIN and DBEND modes to surround logical transactions. Most programs place DBBEGIN’s and DBEND’s around a single transaction or a group of related transactions.

    For example, to fill an order of 1000 magnetic tapes, you would want to check the quantity of tapes in inventory. Assuming there are 500 magnetic tapes available in stock, you would use all 500 (leaving none) and backorder 500 from the supplier to complete the order. The database is modified three times in this logical transaction.
  • DBPUT is used to add the order to the Orders dataset.
  • DBUPDATE is used to update the quantity of tapes in stock.
  • DBUPDATE is used again to update the quantity of tapes backordered.
  • If an abort occurred between steps 1 and 2, the order placed would not affect the inventory dataset or the backorder dataset. The incomplete transaction would result in incorrect information that could propagate throughout the system.

    This series of updates to the database should be preceded by a DBBEGIN and followed by a DBEND. Locking must also be used to prevent others from logically corrupting the database. The recommended sequence of commands is:
    DBPUT to Orders dataset
    DBUPDATE to Quantity in Stock dataset
    DBUPDATE to Quantity in Warehouse dataset

    Typical Uses of Rollback to DBBEGIN

    Simultaneous Interactive Data Entry
    Rollback to a DBBEGIN is useful in a multi-user environment where many modifications can be made to a database as part of a daily routine. Only the transaction that is in progress at the time of the abort will be rolled out of the database. This will keep the database logically intact and ready for immediate access.
    Interactive Database Updates
    The first step in a job stream that updates a database interactively is to enable rollback to DBBEGIN. If this job enters an endless loop, Intact Dynamic Rollback will rollback any intrinsics after the last DBBEGIN.

    Rollback to DBLOCK

    The DBLOCK rollback mode is a different type of rollback than DBBEGIN. It is of primary concern to people that use “soft locking” in their programs.
    Rollback to DBBEGIN with Soft Locking
    Soft locking is the programmatic locking of multiple datasets within a database without locking the entire database. This is accomplished through means other than TurboIMAGE locking.

    NOTE TurboIMAGE does not allow the locking of multiple datasets without multiple RIN capability for locking the entire database.

    In the normal DBBEGIN rollback mode, Intact Dynamic Rollback expects changes to only one dataset between the DBBEGIN and DBEND intrinsics. A dataset-level lock must be obtainable by Intact Dynamic Rollback for each of the datasets in the BEGIN-END sequence. If, for any reason, a lock cannot be obtained on one of the datasets, the Intact Dynamic Rollback rollout will stop and an error message will display.

    The following is an example of an abort situation:

    Program Steps
    Actual Log File Contents
    Update Bulletin Board to obtain three locks
    Lock Dataset 1
    Unlock Dataset 1
    Lock Dataset 2
    Unlock Dataset 2
    Lock Dataset 3

    In the abort situation just described, Intact Dynamic Rollback will do the following:
  • Rollout both the Delete and Add steps for the third dataset, Dataset 3.
  • Find the modification to Dataset 2.
  • Release any locks it currently holds and attempt to lock Dataset 2.
  • Rollout the modifications to Dataset 2 (once the lock is in place).
  • Find the modification to Dataset 1.
  • Release the lock on Dataset 2 and lock Dataset 1.
  • Rollout the modifications to Dataset 1.
  • Find DBBEGIN.
  • Release the lock on Dataset 1.
  • If soft locking is not done properly, a “lock-up” can occur. This happens when one process is waiting for a lock held by another process which, in turn, is waiting for a lock held by the first process. Because Intact Dynamic Rollback waits for an unconditional lock, it will wait until the dataset is unlocked by the other process. This situation can be resolved by initiating a system restart.

    NOTE It is important that all processes updating a particular database use the same soft locking procedure.

    Lund Performance Solutions
    Voice: (541) 812-7600
    Fax: (541) 81207611