> OK, maybe I'm a bit confused -- I was under the impression 
> this "record" in
> the message file was one ADDED by the system after a restart. 
>  In other
> words, the record with the "crash flag" didn't contain data

Nope.

> In that case, replace "delete this error record" in what I said above
> with "process the record with the crash flag" and I think 
> we're all on the same track.

Yup.

The simplest rule would be something like: completely ignore CCL/151
unless you know that you need to do something specific with the
information.

Personally, I'd like to see it implemented the way Gavin mentioned:
don't tell me about FSERR151-causing events unless I specifically
indicate that I want them, by asking for the writer info for the
messages.

> OTOH: if a "logical transaction" spans more than one message in the
> file, "deleting" (by simply ignoring) this record may be the 
> appropriate
> action -- in other words, if the record with the crash-flag 
> is NOT the end
> of a logical transaction, it really shouldn't be processed 
> (presumably, the
> next record in the message file will be the start of a new "logical"
> transaction)

If a "logical transaction" spans more than one message, I'd suggest that
message files are not the mechanism that should be used, for reasons
listed in an earlier message. Expecting to use message files to maintain
logical integrity of some activity is unrealistic, and will sooner or
later result in an unpleasant surprise.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *