Thanks to Gilles, Chris, Denys, Eric, etc. for enlightening me to my
misunderstanding of Image Logging.  Learning can be fun(and humbling at the
same time).
 ----------
>From: owner-hp3000-l
>To: Multiple recipients of list HP3000-L
>Subject: Re: (no subject given)
>Date: Thursday, March 14, 1996 8:33PM
>
>>Message-ID: <[log in to unmask]>
>>Date: Wed, 13 Mar 1996 18:17:37 -0500
>>Reply-To: [log in to unmask]
>>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>>From: Denys Beauchemin <[log in to unmask]>
>>
>>The mists of time are parting a little.  I believe that DBRECOV uses the
>>address
>
>Yes, the record number of the detail set is logged for DBUPDATE.  No path
>information appears in the log record.  A full record list appears for
DBPUT
>and DBDELETE but the record number is still logged for each.
>
>> for detail entry work, and uses the key value (hashing and all that)
>>for masters.
>
>Yes.  No record number for masters - the primary key is used.
>
>> This is why a logging cycle would be unaffected by a cap change
>>(expand only for details) but would be totally tumbled after a (detpack,
>>reorg) of a detail dataset.
>
>Yes, right again.  Changing order is a big no no.
>
>> The key value is unique for master entries,
>
>Since masters are hashed, physical order is not important - only the key
>value.
>
>> and
>>the record number is unique for detail entries.
>>
>Right again.  Image keeps a backward chain pointer of deleted entries.  The
>last deleted record entry in a detail set is the first DBPUT entry.  If
>you somehow mess with this order, like a detpack (or the noaborts option of
>DBRECOV), events after this point can't move forward unless you duplicate
the
>detpack exactly at the same point during a recovery (or create a deleted
>record table).  I think we just went beyond reason to theory.
>
>>The log record layout in appendix E of the IMAGE manual shows the dataset
>>type being recorded as well as the record number.  In addition, for
masters
>>only, the offset to the key value is recorded as well.  It also seems that
>>the key value is recorded also.
>>
>Right again.
>
>>It is interesting to note that, if I am correct, DBRECOV has been using
for
>>years, the key value for master dataset access and the record number for
>>detail dataset access.  If this is the case,
>
>Yes it is.  I wrote a logfile list utility long ago and still use it today.
>I'm _very_ familar with Image log records - been doing it since 1982.  In
>fact, take a look at the "noaborts" option of DBRECOV.  DBRECOV actually
must
>maintain a _table_ of deleted detail records and perform a translation
around
>_suppressed_ aborted transactions.  These things get pretty goofy.
>
>> why, oh why, can't we get HP to
>>see that it is the same thing which is needed to enable MS Access
attachments
>
>Maybe no one knows Image logging and how DBRECOV works?  Take a poll and
see
>how many sites do logging.  I think I counted them on one hand last time I
>polled.  I have a utility that mirrors our 17 Image log files to an unused
>tape drive (multiplexes them as single blocks of data to tape) in real
time.
>We can recover up-to-the-minute online transtions from tape if our disks go
>belly up (which has happened even with RAID).  It is a simple system and is
>darn cheap for the protection we get from it!  The down side is you must do
a
>roll-forward recovery after your reload.  But hey, you are restoring your
>system anyway - it only takes a few extra minutes to recover your lost
>transactions from tape.
>
>Anyone interested in this logfile tape mirror program,  I can send article.
>
>Otherwise, Denys.  You are right on.
>
>
>----------------------------------------------------------------
>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
>