Program Requirements

Intact D/R requires the following intrinsics on every system associated with the application.

DBBEGIN and DBEND

In order to use the DBBEGIN rollback mode, any program which uses an Intact Dynamic Rollback-enabled database must use DBBEGIN and DBEND to surround logical transactions. (A transaction is defined as a sequence of one or more modifications to a database that change it from one constant state to another.)

NOTE If you use a fourth-generation language (4GL) or a third-party application to create and modify your databases, ask the vendor whether DBBEGIN, DBEND and DBLOCKING are included in their products.

For information about DBBEGIN, see "Rollback to DBBEGIN".

DBOPEN and DBCLOSE

At the termination of any program, TurboIMAGE will automatically close any databases opened by the program. If the job is enabled to rollback to DBOPEN and the program does not close the database, your transactions will be lost when the rollback occurs. Therefore, DBCLOSE must also be included in the program.

NOTE If you use a fourth-generation language (4GL) or a third-party application to create and modify your databases, ask the vendor whether DBCLOSE is used in the normal cleanup procedure.

DBLOCK and DBUNLOCK

Hewlett-Packard recommends the use of locking in TurboIMAGE applications. Locking applies a logical lock to one database or to one or more datasets or data entries, to prevent more than one user from modifying the same data. The lock is applied and released with the DBLOCK and DBUNLOCK intrinsics. Intact Dynamic Rollback can insure validity in your database after a rollback only if locking is performed.

Locking must be applied in either of the following two sequences:

Sequence 1	Sequence 2
DBBEGIN	DBLOCK
DBLOCK	DBBEGIN
_	_
_	_
_	_
DBEND	DBEND
DBUNLOCK	DBUNLOCK

Either the DBBEGIN or the DBLOCK intrinsic can be called first. However, DBEND must be called before DBUNLOCK, because of the relatively short time span between the two intrinsics. For instance, if the DBUNLOCK is performed first, there is a chance that the data item just modified can be changed again before the DBEND intrinsic can be implemented. This instance should prevent Intact Dynamic Rollback from completing a rollback.

Consider the following situation. Two data entry clerks are modifying the same database. Both are updating the database and are running the same program. If locking is applied, the following will occur:

Data Entry Clerk 1	Data Entry Clerk 2
DBLOCK	_
DBBEGIN	_
Update qty-on-hand	_
Update qty-in-warehouse	_
DBEND	_
DBUNLOCK	_
_	DBLOCK
_	DBBEGIN
_	Update qty-on-hand
_	Update qty-in-warehouse
_	DBUNLOCK
_	DBEND

The second data entry clerk updates the database after the modifications by the first user are complete and the database is unlocked. When locking is used properly, as in this example situation, each logical transaction is applied to the database separately and each is completed before any other transaction can begin. If an abort occurs part way through the first transaction, rollout of that partial transaction will occur before the second transaction begins.

If locking is not applied, the following might occur:

Data Entry Clerk 1	Data Entry Clerk 2
DBLOCK	_
DBBEGIN	_
Update qty-on-hand 550->200	DBBEGIN
Update qty-in-warehouse	Update qty-on-hand 200->155
_	_
PROGRAM ABORT!!	_
_	DBEND

The program aborted after Data Entry Clerk 2 updated the qty-on-hand field. When Intact Dynamic Rollback attempts to roll out the transactions from Data Entry Clerk 1, it expects to see “200” in the qty-on-hand field, but it finds “155” instead. This discrepancy will cause Intact Dynamic Rollback to stop the rollout process and display the message, “Record Modified,” indicating the database is not locked or it is locked incorrectly.

Logging

Logging is a standard HP 3000 procedure recommended by Hewlett-Packard to allow recovery of a database after a system failure. If logging is not used, the methods of recovery are limited. Intact Dynamic Rollback checks the information collected in the log file as part of the database recovery process, therefore, logging must be enabled for each database maintained by the Intact Dynamic Rollback program.

For complete information on logging, refer to the following manuals:

TurboIMAGE Manual

MPE System Manager/System Supervisor Manual

Console Operator’s Guide

MPE Commands Reference Manual

MPE Intrinsics Reference Manual

Log Files

TurboIMAGE can create chains of log files and span one transaction across multiple log files. Intact Dynamic Rollback requires the log file which contains the beginning of the transaction to remain on disc until the transaction is complete.

Logical Transactions

Intact Dynamic Rollback does not have a built-in mechanism to recognize a super transaction (a logical transaction which spans multiple databases). However, Intact Dynamic Rollback can rollback a super transaction when the following structure is used.

DBBEGIN					(dbase 1)
	DBBEGIN				(dbase 2)
		DBBEGIN			(dbase 3)
			....
			transaction 1
			transaction2
			....
			transaction n
		DBEND			(dbase 3)
	DBEND				(dbase 2)
DBEND					(dbase 1)

If no other tasks are given to the application program between consecutive DBBEGIN and DBEND calls, a program abort between the first and last DBBEGIN or DBEND is nearly non- existent. A program abort that occurs somewhere within the innermost DBBEGIN/DBEND loop will cause Intact Dynamic Rollback to do the rollout, thereby preserving the logical correctness of the databases. Intact Dynamic Rollback’s DBBEGIN rollout mode requires that all databases in the super transaction must be enabled with proper locking in place (see "DBLOCK and DBUNLOCK").