Bryan O'Halloran <[log in to unmask]> wrote:
 
>I need to institute Dynamic Rollback Recovery for my databases because it
is
>taking me two hours to recover from a System Abort and I need to shorten
the
>time dramatically.  I will set out the steps which cause this long lag in
>another message.
>
I retrofitted a 70 user application with Dynamic Rollback a few years ago
(on MPE/XL 3.0).
>
>I have not yet enabled my databases for DBX... stuff because of statements
like
>the following
>
>"If your dynamic transaction is very long causing XM to reach its limit of
the
>log buffer space allowed per process, it will become a stalled transaction,
>and you cannot continue any further.  The stalled transaction will be
rolled
>back and the process is terminated."
 
If I remember correctly "long" is something like an hour -- also, this might
have changed since the Transaction Manager was revised in MPE/iX 4.0.  There
also is or used to be) a constraint on the *size* of the transaction -- I
forget exactly what the constraint was (1MB or 4 MB come to mind) this too
might have changes with iX 4.0.
>
>Can someone with experience of a medium size HP3k (300 to 400 users) advise
if
>dynamic rollback recovery will work in practice or should I continue being
>ultra cautious.
 
Yes, it does work.  It seems to me that you'll have to call DBXEND with
mode=2 to force the write to disc; otherwise your recovery time probably
won't be shortened after a system abort -- after all, when the system is
coming up XM recovery will still have to rollback all of the uncommitted
transactions in addition to posting everything to disc that was in the XM
log files.
 
>What other bits of the equation have I left out of the question.
 
On the application I retrofitted I had code for situation in which 5
databases, a KSAM file, and a flat file were involved in the dynamic
transaction -- if you want some more pointers or guidelines, please let me
know.
 
Good Luck.
 
 -- Evan