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