SPAWN and an Associated Mailbox?

The Question is:

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

The Answer is :

 
  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.