Tracy replies:
> To carry out Gavin's example further, if NM KSAM files A and B are
> updated, then it crashes before the application updates NM KSAM file C.
> You'll WILL have an inconsistent set of files (no matter whether they
> are on the same Volume Set or not.)

Not necessarily.  It's quite possible that *none* of the updates done
above will be committed, so you could find that A, B, and C are all in
their "pre transaction" state, and that there is no evidence whatsoever
that any part of the logical transaction ever happened.

> However these independent NM KSAM files will be good in and of themselves
> since they won't corrupt.

Assuming of course that XM works right, there are no hardware failures, etc.,
the NM KSAM files should always remain "physically" intact and internally
"logically" consistent (i.e. the key data matches the data data, etc.) if
not necessarily logically consistent with respect to other files and
databases.

The NM KSAM files used to implement the B-Tree retrieval feature in Image
are a special case as they are updated within the same low-level XM
transaction as the rest of the files making up the Image database, and so
they always get committed together with the rest of the database changes.

G.