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