>The key here is *physically corrupted*.  The logical structure is
>screwed up, not the physical structure.  E.g., you won't have "lost"
>track of an extent of a message file (or any other kind), even though
>the data *within* the extent might not have been completely posted.
 
To me, corrupted is corrupted. Program continues to run but breaks in
mysterious ways. Of course, no filesystem errors are returned to indicate
anything is wrong.
 
This should not happen. Whether it's physical, logical or illogical, MPE
should not allow such behavior.
 
Maybe MPE does do 'better checking than Unix'. However, we don't have these
kinds of silly problems with our Unix machines. Doesn't matter if MPE does
all the checking in the universe if it _just doesn't work_.
 
>> FIFO files do, but they are different from named pipes. However, Unix does
>> consistency checking on the filesystem so if something didn't get posted to
>> disk (or partially posted), you'd know about it.
>On the physical structure only, Unix doesn't (and couldn't) do
>checking of internal consistency (partially because there isn't any
>to speak of, for most files)
 
Of course! Because everything is a byte stream file (or block, but usually
only for device files -- which are generally not 'real' files). They _have_
no internal structure to check. Unlike MPE's record structure files which do
have a logical structure.
 
>I agree...I think HP could have, and should have, done the following:
>
>   - when a message file is opened, flag it as "needs cleaning".
>     Post the flag to disk.
>
>   - at system bootup (or, when the message file is first opened after
>     a system failure), if the "needs cleaning" flag is on,
>     the message file should be emptied and guaranteed to be "clean".
>
>This would have prevented the problems you, and others, encounter.
>
>Ok...why not add:
>
>   - message file should be intact, with data
 
I don't think data should be maintained at all in a message file after a
crash. For us, it would suffice to have the message file _guaranteed_ to be
in a known state, e.g. physically/logically correct, and empty.
 
-Dan
.----------------------------------------------.
|Dan Hollis -- Pharmacy Computer Services, Inc.|
[log in to unmask]      -     (503)476-3139|
`----------------------------------------------'