B. writes:
> Gavin writes:
>
> > As I recall, message files (now in Native Mode since ~5.0)
> >do not support being attached to the transaction manager (an unfortunate
> >oversight as this ought to have made them virtually failure proof).
>
> Applications that use FCONTROL 6 to force data out to disc get the same
> benefit without the cost of having _every_ message file attached to the
> XM.

I assume that if message files supported XM attachment, that this would
be optional, just as it is for most other file types.  A message file
that is being used purely as a pipe between two processes is a completely
different usage than one which requires persistence of its content.  One
of the problems that comes with any discussion of message files is that
they can be used in a variety of ways, but few people are aware of all
of the different "modes" they can be used in and so make incorrect
assumptions about their value.  HP has been especially guilty of this, as
witnessed by the length of time it took to get the message file code
moved to Native Mode.  The view was generally that message files were
only useful as a process to process "pipe", for which better alternatives
were available, so there was no need for the expense of an NM
implementation.  Here's everything I can think of offhand that you can
do with a message file (anyone think of any others?):

1) Simple process to process "pipe".  Either explicitly by two processes
opening up a message file and using the Intrinsic API with all of its
message file specific features, or simply by redirecting $STDLIST from
one program into the "input side" of the message file and $STDIN for
another program to the "output side" of the message file.

2) Queue files with persistence.

3) One to many, many to many, and many to one multiplexing.  Any number
of readers and any number of writers can share a message file
simultaneously.  There are special features (SEMI exclusive access, etc.)
related to this.

4) As a control interface for background server processes.  A job that
uses NOWAIT I/O to serve a bunch of serial ports or network connections
will often have a message file that it waits on as well for communication
with a control or console program.  Servers which require some polling
activity will often use timed reads on the message file as the wakeup
mechanism.

5) Process termination trigger.  You can use a message file to guarantee
that a process will get notified when another process terminates, no
matter how that process terminates (normally, or any kind of abort).
By having the watchee process open a message file for write access, a
watcher process can enable the reading of "Writer IDs" on the message
file and get woken up by MPE when the watchee terminates due to the
"close record" that MPE writes to the message file when the watchee
closes the file (or terminates for some reason).

6) Interrupt file.  Message files support "soft interrupts" which work
sort of like a Control-Y break.  You can provide a service routine to
be called in your process whenever data arrives in your message file,
regardless of what the program is doing at the time.

Message files provide many of the features of pipes, signals, and
sockets, and do so in a way which is compatible back to about 1981.
Some of the more advanced uses of message files still have no good
replacement, and are way beyond anything found on UNIX.

You can tell I like message files :-)

Circular files, now *there's* a useless feature.

G.