|
HP OpenVMS Systemsask the wizard |
|
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.
|