SPAWN and an Associated Mailbox?

LIB$SPAWN and associated mailbox

To a particular existing program of some vintage I have added a call to a
routine that in turn calls LIB$SPAWN. This results in the failure status
%X388F2. {HELP/MESS on that has a fairly useless User Action. It assumes that
it is a SPAWN command, and not
a call to LIB$SPAWN.} VMS is V7.3-1

Fixing this from an application point of view would seem to result in non-ideal
modularity and/or elegance.

But let's forget about elegance, does VMS provide sufficient interface (e.g.
$QIOW to the terminal driver) for a routine that wants to call LIB$SPAWN to
find out the name of the associated mailbox, unassociate it, do the spawn, and
then reassociate the or
iginal mailbox???

In my application the routine that calls LIB$SPAWN always waits for the process
to complete and the temporary interruption to whatever might wish to be
written to the original associated mailbox can be tolerated (but I'm not sure
what DCL might do with un
expected messages in its mailbox).

Does the Wizard have any better ideas to fix my application given that SPAWN is
today the way it is??? The other routine (i.e. the one that is already using
an associated mailbox) does not appear to offer sufficient interface for me to
unassociate and res
tore around the call to LIB$SPAWN. I believe that the other routine is doing
broadcast trapping. For the record I have read 5887. My application is not
using SMG.

Calling SYS$CREPRC to create a subprocess is relatively impractical because the
subprocess needs access to logical names, not to mention the minor hassle of
passing the command to the subprocess.

Does the Wizard consider this to be a problem in the implementation of SPAWN???

Does the Wizard have any blue-sky ideas to share for how to change SPAWN to
avoid this problem???

Retrofitting capabilities into an older application is not without
its difficulties.  Obviously.

The user process is apparently utilizing a terminal that has an
associated mailbox -- SMG is not the only application that uses
the mailbox, most any application performing broadcast trapping
or asynchronous terminal processing will utilize one.  (For some
additional details, please see the I/O User's Reference Manual.)

The associated mailbox information is available via calls to $getdvi.

The OpenVMS Wizard would also look at utilizing a detached process,
and sharing the necessary logical names with it directly (using a
shared table, or by passing over the contextual information through
the communications link) or indirectly (using file storage or such).

As for discussions of this particular (mis)feature of OpenVMS, the
current use of mailboxes is rather constraining and the OpenVMS
Wizard might well choose a wholely different approach and solution
should this area of OpenVMS be re-architected.  The current
capabilities would obviously have to be maintained.

As for the specific error:

$ x = f$message(%X388F2)
$ show symbol x

X = "%CLI-E-TRMMBX, terminal has associated mailbox - terminate image and
then SPAWN"

Within the (undocumented) sys$cli system service interface, the DCL
command SPAWN and the OpenVMS RTL call lib$spawn both use identical
underpinnings.