Tracy writes:
> I found that a set of NM KSAM files that were in
> the middle of a posting got only so far, but at
> least it was a clean cut off between the file that
> was posted last and the next one that was about
> to be posted before the crash. i.e.:
>
> FILE    POSTED
>         CLEAN?
> A       Yes
> B       Yes
> C       Yes
> D       Yes
> E       Yes
> (crash)
> F       No
> G       No
> H       No
> I       No
> K       No

But it's possible that the intrinsic calls to update F and possibly G, H,
etc. could have completed such that if the program that was doing the
updates printed out a sequence of messages they could have looked like:

Updated A ok.
Updated B ok.
Updated C ok.
Updated D ok.
Updated E ok.
Updated F ok.
Updated G ok.
<system crashes at this point>

but after coming backup up you would find that only updates to A through E
had actually survived the crash.  XM guarantees that, for entities "attached"
to it, if an update done at time X survives then all updates done at times
before X will also survive, and that all individual changes done as part of
a "transaction" (say putting to a detail set and updating the associated
master sets) are either all applied or none of them are applied.  Normally
an application programmer doesn't have the ability to create her own XM
transactions that span more than one update.  The exception to this is the
Image DBX transaction facility which allows multiple Image API calls to be
wrapped within a single transaction thus guaranteeing that either none of
the changes gets made or all or the changes get made.

XM works by being in no hurry to actually post changes that you make to the
actual files involved.  Instead it appends information to a "log file" that
indicates what changes have been made.  So that rather than having to post
updates constantly all over the disk, it simply has to "occasionally" post
the log file to disk, and when the system comes back up after failing, it
reads the log file and reapplies all the complete transactions that it
finds.

But for performance reasons, the XM log is not flushed to disk after every
transaction but only "occasionally".  In practice, I believe the maximum
delay is a timeout of something like 1/5 of a second these days, but that's
still long enough for your program to "think" it has completed updates
which in fact will be lost if the system fails at that point.

Besides the timeout there are, I believe, a number of other conditions
which will result in flushing the log buffers to disk thus ensuring that
all transactions completed to that point will survive (such as the log
buffers filling up etc.) and it's possible that some APIs may explicitly
invoke a flushing of the log buffers to disk, in which case the permanent
committing of the updates would be synchronous with the execution of the
program.

For example, for single database DBX transactions, DBXEND has two modes.
Mode 1 commits the transaction normally (possibly resulting in a delay
before the log buffers are written to disk) but Mode 2 commits the
transaction *and* forces a flush of the XM log buffers to disk, so that
after a DBXEND Mode 2, you can be sure that when the intrinsic call
returns, your updates will survive a system abort that occurs from that
point forward.  For best *performance* though you should probably avoid
DBXEND Mode 2, since it could add significant I/O overhead above letting
the system manage the log file posting on its own, and could have a
performance impact for all other XM users on that volume set.

For non-Image files that are attached to XM (NM KSAM etc.) I suspect that
one of the standard FCONTROLs (2 probably) will have the same result.

Of course I don't claim to be an XM guru, so Paul (who wrote most of it)
or someone else will likely jump in and correct me where I'm wrong.

G.