I've seen six broken chains(different systems all on 6.0) in the past twelve
months.


"Gavin Scott" <[log in to unmask]> wrote in message
news:9kfbe90j4n@enews2.newsguy.com...
> > A programmer asked me if doing an ABORTJOB on a program will
> > cause a broken chain in an Image database.
>
> It's amazing how much superstition exists surrounding this kind of stuff,
> and how many unnecessary rituals and sacrifices are performed daily to
> appease the mythical pantheon of data integrity gods.
>
> "Real" broken chains are (supposed to be) *impossible* to achieve with
Image
> on MPE/iX, no matter what application programs do, or how they are
aborted,
> or how many times the system crashes!
>
> The Transaction Manager (XM) provides absolute protection against internal
> database inconsistencies, as long as there are no bugs in the system and
as
> long as the hardware is not corrupting data.  No action or configuration
is
> required on the part of the user.
>
> Logical inconsistencies (order detail without an associated order header
> record for example) can easily be created by aborting an application
that's
> in the middle of performing a database update that spans multiple records.
> Of course Image doesn't care whether your data is logically correct or
not,
> that's the job of application programmers.
>
> Using DBBEGIN/DBEND will have no affect on logical integrity whatsoever,
> unless you actually run DBRECOV to roll forward or roll back the database
to
> a consistent point *every time* you abort a program or suffer any other
> failure.
>
> By using the DBXBEGIN/DBXEND "XM style" transactions, you can extend
Image's
> guarantee of physical integrity to the logical integrity of your database.
> The system will ensure that no matter what happens, either all changes
> inside a DBX transaction will be applied, or none of them will be.  Of
> course it's still possible to use this feature incorrectly (locking
> strategies are non-trivial as you need to lock the data that you *read* as
> well as that which you intend to write in many cases).
>
> MPE/V introduced a feature called Intrinsic Level Recovery (ILR) which
could
> (and still can be) enabled for a database.  This was sort of a mini-XM
which
> forced updates to disk each time an Intrinsic call completed in order to
> ensure structural integrity of the database in the face of system
failures.
>
> I believe that on MPE/iX, enabling ILR for a database does something
really
> nasty like forcing an XM post after every update intrinsic call, which is
a
> serious performance problem.  ILR is no longer required on MPE/iX as XM
will
> ensure integrity without it.  With ILR you might be guaranteed that every
> committed transaction will survive a system abort, whereas without it XM
> might end up having to rollback the last fraction of a second's worth of
> transactions.  For almost any application this difference is negligible.
Do
> not turn ILR on!
>
> There are more complexities if your application performs transactions that
> affect multiple databases or databases and non-database files.  It's
> possible to do multi-database Image transactions, but only if the
databases
> reside on the same volume-set I believe.
>
> G.
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

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