From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 25-MAY-1989 04:33 To: MRGATE::"ARISIA::EVERHART" Subj: Re: Making processes persist? Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed, 24 MAY 89 12:08:04 PDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Wed, 24 May 89 12:00:39 PDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA14961; Wed, 24 May 89 11:47:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 89 17:59:22 GMT From: bsu-cs!cfchiesa@iuvax.cs.indiana.edu (Christopher Chiesa) Organization: CS Dept, Ball St U, Muncie, IN, USA Subject: Re: Making processes persist? Message-Id: <7416@bsu-cs.bsu.edu> References: <8905231659.AA26834@ucbvax.Berkeley.EDU> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com In article <8905231659.AA26834@ucbvax.Berkeley.EDU>, MBASS@UONEURO.UOREGON.EDU (Michael Bass) writes: > How can I get a VMS process to continue executing after the modem line > is hung up? > > I have a program that exchanges data with a pc over phone lines and then > must do some manipulation on the data. The problem is the pc hangs up > right after exchanging the data. The VAX then kills the process so > nothing after the data exchange is ever executed. > > I've thought of creating a detached process, but I'm not sure if the > detached process will still be able to communicate with the process (to > exchange the data). And then how would I keep the connected process > from interpreting the data? Some things I can think of, which may or may not work depending on system hardware setup, your particular privilege level, etc. etc. (If you have sufficient privs to create detached processes, though, you probably can do the rest of the required tricks...) 1) Submit the program as a batch job, preceding the actual RUN command with appropriate ALLOCATE, DEFINE/USER SYS$INPUT and DEFINE/USER SYS$OUTPUT statements to tell that batch job to STILL USE YOUR TERMINAL (specified by physical name) for I/O. Submit this job with a delta-time /HOLD value of long enough for you to issue a SET PROC/SUSPEND command in your main interactive process, pop out to PC "local mode," and start the PC side of the connection. Result: the Batch job talks to the terminal line and the PC and gets the data, while your main process is suspended and NOT looking at the terminal line for input or output data; after the transfer, the PC hangs up, the interac- tive process disconnects, and the batch program proceeds on its merry way. (Note that the DEFINE/USER version of DEFINE, in that batch job, also neatly causes SYS$INPUT et al to revert to the batch.LOG file etc. after running the data-grab program; this is more of an advantage, of course, if the data-grab and data-processing program are NOT the SAME.) Requirements: You need some kind of priv (PHY_IO maybe?) to ALLOCATE the terminal line from that batch job, and the batch job MUST allocate the terminal in order to DEFINE SYS$..etc. to it. Possible problems: SET PROC/SUSPEND may not be sufficient to keep the inter- active process' nose out of the proceedings: data MAY all pile up in the typeahead buffer. I'm hoping that the ALLOCATE etc. from the batch job will SUPERSEDE this; I know it works for OUTPUT, but I don't know about input. 2) Do the same as the above, with a Detached process instead of a Batch job. 3) Set the terminal you're using to /PERM/NOHANGUP. When the PC hangs up, your process WON'T be killed. You then dial back in to the SAME TERMINAL (beware, if you can't guarantee you'll GET the same terminal, DON'T DO THIS as it compromises security!) and continue where you left off, just as though nothing had happened. I've done this, and it works, although it's not the safest thing in the world for security reasons. (You also want to make sure that the host MODEM still hangs up, else you won't be able to dial in. I think the default behavior is appropriate for what you want to do, though, so don't change anything unless you see it failing.) 4) Separate the data-grab and data-processing portions of the program; this is of course only possible if it is something YOU wrote -- OR if you're good at hacking executable binaries, UGH! :-( *I* wouldn't want to try it. 5) Figure out some way to keep the PC from hanging up! Gimmick your home modem (jumper something over to the DTR line on the computer-to-modem cable) so that when the PC drops DTR, the modem stays connected. Or look for some software setting that you've overlooked; if you're using a commercial package, this sounds like your best bet, as they'd have to be insane to provide programs that don't work together (assuming the home program and host program come from the same place and are MEANT to work together?). ---- I hope some of this proves helpful; this sounds a lot like what happened to ME when I wanted to run Kermit file transfers from the Batch queue! I had to do a variant of suggestion #1 above, myself. Good luck, Chris Chiesa -- UUCP: !{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP