ANYTHING is possible of course, but this is not what happens
based on my experience with crashes on a totally NM KSAM application,
it had typically a dozen NM KSAM files opened for R/W at the
same time.

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

> -----Original Message-----
>
> 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.
>