>        Subject:
>               IMAGE Logging Cycle Resetting
>        Date:
>               Sat, 27 Apr 1996 10:39:07 -0400
>        From:
>               Gilles Schipper <[log in to unmask]>
>        Newsgroups:
>               comp.sys.hp.mpe
>
>
>Ron Seybold, in the 3000 NewsWire Online Extra, April issue update, writes:
>
>snip....
>>Finally, Dennis Heidner, one of the authors of the "IMAGE Handbook," sent
>>us this note on our April net.digest column.
>>
>>"In the April 1996 net.digest column, "IMAGE Logging: When to Reset", you
>>stated that "The consensus was that database capacity changes should NOT
>>necessitate the refreshing of logging cycles."
>>
>>WRONG! Unless significant changes have been made to TurboIMAGE (or
>>TurboIMAGE/XL)  in the last year or so... the primary key is not logged
>>UNLESS the key itself  is changed.   TurboIMAGE records the dataset number,
>>the dataset record number (not key value) and the before and after values
>>that were changed.
>>
 
 Gilles is right.  Image logging of master sets _always_ logs the search
item value along with data, whether DBUPDATE, DBPUT, OR DBDELETE.
 
 Why?  Because migrating secondaries within the master could change record
numbers and record numbers as keys to masters are not a good idea unless you
like randomness in your recoveries.
 
>>For detail datasets, it is possible to have multiple entries with the same
>>primary key.  Thus knowing only the key value is insufficient for
>>re-applying the transaction.  The original dataset record number must be
>>available and valid.
>>
 
I'm assuming you mean path and you can have multiple entries in a chain.
Yes, this is true.  This is not an RDBMS unique key here.
 
The _only_ unique key in an Image detail set is the record number.
Otherwise, the next best guess as to original order is path value +
chronological entry count "offset", but not always guaranteed if a
suppressed DBDELETE sneaks in there.
 
>>For manual datasets it is important to remember that you can design a
>>database which has additional non-key data fields as part of a manual
>>master dataset record.  A capacity change will force the re-sequencing of
>>the data entries.   Thus changing the capacity on manual master dataset
>>would be fatal for many applications, should you later attempt to recover
>>based on your recommendations.
>>
 
Both Automatic and Manual masters work the same way - as keys go.  Automatic
sets are not logged because they are automatic!
 
>>The most important tip to remember is that those warning messages are being
>>displayed for a reason. If you ignore them, you may later pay a much higher
>>price (lost time), then if you had just stored the database and started a
>>new cycle."
>
 
Image logging has "idiot proof" procedures if you use them.  The feature you
want to preserve is the backup time stamp on roll forward recovery.  Sure,
DBRECOV lets you disable just about every integrity check known to man, but
I don't like flying by the seat of my pants in a critical time dependent
recovery operation.
 
Some people are turned on by the thrill of stressful critical situations
where they slay data recovery like a knight to a dragon or like mountain
climbing.  Not for me.  I say to an operator:  "Stream job a, b, c"  and I
go back to sleep!
----------------------------------------------------------------
Eric J. Schubert                    Senior Data Base Analyst
Office of Information Technologies  Univ of Notre Dame, IN USA
(219) 631-7306                      http://www.nd.edu/~eschuber