Possibly what is meant by Lee's statement is that any time you make a
capacity change on an Image Master, physical placement of entries changes
based on hashing, secondaries, migrating secondaries(takes long time on
large masters).  Since Image Logging is dependent on physical entry number
only, any physical movement of entries causes an Image 'Log logid,Restart'
to be inapplicable since DBRECOV depends on enrty number, not key values,
etc.  Certain database tools will require you to stop logging if you make
master capacity changes, but will not require you to stop logging on an
detail since the cap change(no repacking)does nothing more than add space at
the end of the dataset(for cap increase and decreases as long as you don't
collapse smaller than the high water mark).
Tom (Logging is fine, DBRECOV is a pain) Stelter
 ----------
>From: owner-hp3000-l
>To: Multiple recipients of list HP3000-L
>Subject: Re: Re[2]: DB Capacity Management
>Date: Wednesday, March 13, 1996 1:21PM
>
>On March 8, 1996, Lee Gunter wrote:
>
>>Agreed!  User logging also complicates database capacity management due
>>to the need to refresh logging cycles afterward - and on large
>>databases, those changes can take hours!
>
>As far as I know, data base capacity changes should NOT necessitate the
>refreshing of logging cycles - with the following caveats:
>
>To effect capacity changes, you must firstdisable logging. Once the changes
>have been completed, logging can be re-enabled. The resulting warning
>message can be ignored, subject to the point following.
>
>In the event of subsequent data base recovery with the interrupted log file
>(disabled, then re-enabled) it is possible that transactions could fail to
>be recovered if, for example, a dbput was issued for a full dataset
>(remember, in real time, we had, say, increased the capacity of the
>dataset). No big deal. Simply start the recovery process over again - this
>time performing appropriate capacity changes prior to recovering the log
file.
>
>I do understand that dataset re-packs DO require the refreshing of logging
>cycles - but not capacity changes.
>
>So, I don't understand why user logging should complicate the capacity
>management issue - apart from the caveats indicated.
>
>Unless, of course, my initial assumptions are incorrect.
>