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

Boy, I hope you aren't putting those words in *my* mouth ;-)

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

Without getting too far into the "broken record" mode: if the proper
functioning of an application requires that 
 1) Every message be processed (no lost messages)
 2) Each message be processed exactly once (no duplicates)

then message files are not a valid data-transfer mechanism; they can
(yes, I'll use the "n word") *never* satisfy the requirements.

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