Steve after somebody:
> > error, then it means the program is doing the right thing
> > when dealing with message files: issuing a non-destructive
> > read, processing the record, then issuing a destructive
> > read to clear the record.

This can be good *if* the rest of your code is set up so that if the program
fails that the record isn't processed twice, and if you're trying to protect
against system failures then things get a lot more complex since you may
wait until after doing a DBPUT to delete the record from the message file
but after a system failure in the middle of this it's possible for neither
the DBPUT nor the message file record to be there after rebooting, since
unfortunately even NM message files can't be attached to the transaction
manager.


>
> I've seen this method advertised as the "right" way to handle message
> files a number of times over the years, and I've never bought it, for
> several reasons:
>  1) The usual reason for using message files is for speed: to quickly
> transmit some information from one activity to another. That's why
> message files are memory-resident and aren't flushed to disk. Doubling
> the reads (and throwing in otherwise-unnecessary FCONTROL calls) kind of
> kicks the speed boost in the face.
>  2) If the data being passed in the message file is so critical that you
> can't afford to lose a message in the event of a system crash (or your
> application fails so frequently that it's an issue), you might need to
> re-evaluate your use of message files (or get a better app that doesn't
> blow up so much). Critical, can't-lose-it data belongs somewhere safer,
> like in a database.
>  3) Double-reading breaks completely in any multiple-reader scenario.
> Unless the message is accessed exactly once by a destructive read, it is
> likely to be "processed" by any number of the readers--all but one of
> whom will then destructively read and throw away a valid, unprocessed
> message in the name of "clearing" the just-processed message.
>  4) Even with a single reader it is subject to duplicate processing in
> the event of a system or application failure: the app reads the message
> non-destructively, processes it, blows up, restarts, and processes the
> message again.
>
> The last issue is probably at least part of the reason for the FSERR 151
> in the first place: to notify the application that the message it just
> read--which is a PERFECTLY GOOD message--was the last message written
> before a processing break, and may need to be handled specially.
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

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