Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucbvax!VB.CC.CMU.EDU!R022DB3L
From: R022DB3L@VB.CC.CMU.EDU (Mithrandir)
Newsgroups: comp.os.vms
Subject: Completion Status in LIB$SPAWN
Message-ID: <8710011304.AA13458@ucbvax.Berkeley.EDU>
Date: Wed, 30-Sep-87 14:49:18 EDT
Article-I.D.: ucbvax.8710011304.AA13458
Posted: Wed Sep 30 14:49:18 1987
Date-Received: Mon, 5-Oct-87 02:37:42 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 36

I'm encountering strange returns when using the completion status field of
the RTL routine LIB$SPAWN to check the exit status of an image I'm spawning.

Basically, I use LIB$SPAWN to invoke EMACS (the standard text editor here)
in order to edit a temporary file.  I check the return code for the spawn
call to see if that worked, and if it checks out, I then check the return
information in the completion status field to see if the EMACS image 
encountered any problems.  From reading my friendly orange manuals, I was
lead to believe that the completion status code is simply the standard VMS
exit code for the image (or whatever you are doing in the spawn).

In general this causes no problems, and I get a nice return of SS$_NORMAL
from both lib$spawn and the status field.  However, if I pause EMACS (a
function to leave the emacs process in place and return to the parent
process), the spawn succeeds, but the condition status code returns a
value of 2146620316 (7FF2D39C hex).  This seems much higher than any normal
return codes I've seen in the past, and as it's even should indicate an
error, although none occured.

My question is not so much EMACS specific as it is just on the general
use of the completion field - can I assume it to be a standard VMS return
code?  Where would I be getting such an extremely large number on an
apparently successful call?  And if anyone is familiar with EMACS (this
being the Unipress version), has anyone else ever encountered this?

Right now I'm eliminating the completion status check because it is incorrectly
identifying an error where none exists - but I don't want to leave it out in
the final version, because then all I'd be checking is the spawn result, and
not the result of the actual operation being performed in the sub-process.

Any comments, suggestions, etc.. would be much appreciated.


-- David Bolen				Arpanet:  R022DB3L@VB.CC.CMU.EDU
   Carnegie-Mellon University		Bitnet :  R022DB3L@CMCCVB
   Pittsburgh, PA  15213