DBBEGIN and DBEND define the logical start and end of a transaction
that may span multiple datasets. When using a transaction log file to
recover a database (last good backup + log file=good database up to
point prior to failure) the recovery program will not apply incomplete
transactions - those with a DBBEGIN but no DBEND, unless you choose the
option to force the transactions anyway. By applying only complete
transaction sets (DBBEGIN/END paired correctly) you assure a logically
consistent database.

If your programs include DBBEGIN/DBEND but you have not enabled logging
there is no affect to system operation other than possibly a machine
cycle or two while Image checks the root buffer flag to verify if
logging is enabled. However, even if you have not enabled logging, if
your program calls DBEND without having called the corresponding
DBBEGIN first, you will get an Image error code returned.

If your programs do not use DBBEGIN/DBEND the recovery utility will
take as a complete logical transaction the range of transactions
bracketed by DBOPEN/DBCLOSE.

The above applies to recovery using logging in general. ILR (Intrinsic
Level Recovery) has some more details that I'm sure others can fill in
if others on the list are interested or wish to get "more granular."
It's now early Monday morning so I'll leave it to others.

Since 1985 all user-interactive programs I've written have
DBBEGIN/DBEND pairs. Batch updates generaly not as in most cases the
batch update is considered a complete logical transaction and the
recovery process would be restoring the database, correcting the data
to be loaded/processed and then running the batch job again. In some
instances erasing a dataset is sufficient to restore the prior state
and run the batch job after input data correction.

HTH (hope this helps).

> At 06:25 26-04-03 -0400, Simpkins, Terry wrote:
>
> > DBBEGIN & DBEND intrinsics ... to define the "logical" transactions.
>
> Very good point. Without DB(X)BEGIN and DB(X)END the logfile will not
> be able to recover logically consistent transactions (i.e. re-apply
> completed transactions and drop incomplete ones). It will nly "replay"
> the recorded sequence of "atomic" image intrinsic calls like DBPUT or
> DBUPDATE or DBDELETE, as far as I understand.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *