Tracy wrote:
> What will happen is that some NM KSAM files will get posted
> to and some others will not, depending where the application
> was at the nanosecond of the crash.  It becomes similar to
> the old problem of rollback or rollforward recovery for Image.
> But the NM KSAM files will not be corrupted in themselves,
> but may be out of sync with other ones that have a common
> link or field as defined by the application.

Since NM KSAM files are attached to the Transaction Manager,
all modifications to NM KSAM files (on the same volume set!) will
be committed in the order the updates were performed.  So if you
write to NM KSAM file A then NM KSAM file B, then the system fails,
you can be assured that if the update to B survives then the update
to A must also have survived.

The same thing applies to updates done to Image databases on the same
volume set, i.e. that updates to them will be serialized with respect
to each other and to other Image databases and NM KSAM files (and any
other entities attached to XM) on THAT SAME VOLUME SET.

This makes it possible to build your own robust transaction processing
applications and implement your own two-phased commit logic, etc.

If, however, you have part of your data involved in a "transaction" on
one volume set, and other data involved in the same transaction on a
different volume set, and the machine fails, then there is NO GUARANTEE
WHATSOEVER about what order the updates may be committed in.  So you
don't want to put logically related databases on different volume sets
because it can introduce logical inconsistencies into your data (after
a system abort) which were not possible when all the data was on the
same volume set.

G.