STRASSER@RSBS0.anu.OZ.AU (Mike Strasser) (02/08/88)
I have noticed two odd piecess of behaviour in handling subprocesses,
which I think shouldn't happen. Both happen under VMS 4.6, on both an
11/750 and a 8700 (it *should* be consistent!).
Firstly, if you create a subprocess and attach to it, then re-attach to
the parent process, then spawn a second subprocess and attach to it, THEN
kill the first subprocess with a STOP command from t'other (still with
me?), VMS can't decide which of the remaining two processes (parent and
2nd child) is attached to the terminal! You get a mixture of prompts, and
it isn't clear where the things you type go.
Why would I be doing this? Well, I often run a program in my login process,
then spawn a child to do a few other things. One program I use keeps that
child intact even after it exits (all right, I wrote it that way deliberately)
so in a later run of the program (which I use frequently) I can jump into
the same child process (which is given a particular name by the program).
This saves time with creating and killing processes (fast on the 8700 with
< 30-odd users, and always slow on the 750). I have a subprocess quota of
2 on both machines, and a couple of times I've been in another child
process created by a different program and I've wanted to kill the first so
I could create another for something else. Simple, really! Anyway, my
point is that VMS shouldn't be behaving this way. Anyone else seen this?
My second observation is that whenever you leave a child process (logout or
attach), that last command line (logout or attach...) is put
on the top of the command stack of the parent process if it's running a
program, but not at DCL level. Anyone explain why this should be so? To
give an example, this happens from TPU.
Mike Strasser
Research School of Biological Sciences
The Australian National University
Canberra, Australia
ACSnet, CSnet strasser@rsbs0.anu.oz
INTERNET strasser%rsbs0.anu.oz@uunet.uu.net
UUCP {uunet,hplabs,ubc-vision,nttlab,mcvax,ukc}!munnari
!rsbs0.anu.oz!strasserLEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (02/11/88)
...[I]f you create a subprocess and attach to it, then re-attach to the parent process, then spawn a second subprocess and attach to it, THEN kill the first subprocess with a STOP command from t'other (still with me?), VMS can't decide which of the remaining two processes (parent and 2nd child) is attached to the terminal! You get a mixture of prompts, and it isn't clear where the things you type go. ... Same thing happens on VMS V4.5. It's actually not hard to see why this is happening, given the mechanisms DCL uses to implement SPAWN and ATTACH (which are too involved to go into here); but it certainly isn't what you'd WANT to have happening. Submit an SPR! In the meantime, the easiest work-around I can think of is: Rather than doing a STOP for subprocess X, ATTACH to it and type LOGOUT. Unfortunately, this will put you back in the process that created X, rather than the one you just ATTACHed from (for exactly the same reason that STOP will make the two processes fight for the terminal), but another ATTACH should get you where you want to be. My second observation is that whenever you leave a child process (logout or attach), that last command line (logout or attach...) is put on the top of the command stack of the parent process if it's running a program, but not at DCL level. Anyone explain why this should be so? To give an example, this happens from TPU. Actually, the last command line is ALWAYS on the "command stack" FOR THE TERMINAL DRIVER. It's just that DCL (and many other programs, like MAIL) maintain their own recall stacks, and hence the command saved by the driver is never visible to you. (The terminal driver only saves one line; DCL and programs save more, typically 20. The easiest way for a program to get multiple command lines saved is to use SMG$READ_COMPOSED_LINE to get its input.) -- Jerry
sommar@enea.se (Erland Sommarskog) (02/20/88)
Jerry Leichter writes: > ...[I]f you create a subprocess and attach to it, then re-attach to > the parent process, then spawn a second subprocess and attach to it, > THEN kill the first subprocess with a STOP command from t'other (still > with me?), VMS can't decide which of the remaining two processes > (parent and 2nd child) is attached to the terminal! You get a mixture > of prompts, and it isn't clear where the things you type go. > ... > >Same thing happens on VMS V4.5. It's actually not hard to see why this is >happening, given the mechanisms DCL uses to implement SPAWN and ATTACH (which >are too involved to go into here); but it certainly isn't what you'd WANT to >have happening. Submit an SPR! In the meantime, the easiest work-around I To add some more on this. I have been exposed to something similar: Main process: Communication with target computer. Sub-proc 1: TPU Sub-proc of Sub-proc 2: DCL Mostly I switched between TPU looking up line numbers in compilation listsings and the main process sending commands to my target machine. Sometimes I needed some other utility and created the DCL process, but since it was rarely used, the watch dog killed it. And now: chaos. One key- stroke in TPU, next in the comm.program. Total confusion. This happened to me more than one time. I never studied it closely enough to tell whether it mattered if I went from DCL to TPU to the main process, or went there directly. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP Io, chi parlo di niente, lo faccio soltanto in paura di silenzio
gregg@a.cs.okstate.edu (Gregg Wonderly) (02/22/88)
in article <2746@enea.se>, sommar@enea.se (Erland Sommarskog) says: > > Jerry Leichter writes: >> ...[I]f you create a subprocess and attach to it, then re-attach to >> the parent process, then spawn a second subprocess and attach to it, >> THEN kill the first subprocess with a STOP command from t'other (still >> with me?), VMS can't decide which of the remaining two processes >> (parent and 2nd child) is attached to the terminal! You get a mixture >> of prompts, and it isn't clear where the things you type go. >> ... Another not so nice behavior happens when you logon to a terminal set /NOMODEM, and then spawn a subprocess (a kept editor is an example). Attach back to the parent process from the subprocess, and DISCONNECT. Later, you logon to a terminal set /MODEM, and ATTACH to the subprocess. BINGO, DTR gets dropped, and you are DISCONNECTED. Log back on, and as soon as you CONNECT to the DISCONNECTED process, again, you are DISCONNECTED. Now you logon one more time, and all is well. The subprocess starts up, and you do whatever. Then you try to attach back to the parent. BINGO you are DISCONNECTED again. Log back on and CONNECT to the DISCONNECT'd process, and all is well. This is less than optimal, no? ----- Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers}!okstate!gregg Internet: gregg@A.CS.OKSTATE.EDU
cfchiesa@bsu-cs.UUCP (Sir Xetwnk) (02/25/88)
Here's another baddie.
I did the following the other day with the following results:
1) Enter an LSE session in my main process.
2) SPAWN a subprocess to do whatever it was I wanted to do....
3) ATTACH back to the parent process, leaving the subprocess out there.
4) Successfully ATTACH back and forth from LSE-in-parent-process to
DCL-in-subprocess, several times.
5) Terminate LSE session with EXIT command, leaving subprocess out there.
6) Successfully attach back and forth from DCL-in-parent-process to
DCL-in-subprocess, several times.
7) Issue LO (or EOJ) command from DCL-in-subprocess, with intent to have
it die and leave me back in the parent process.
Instead, it killed the Subprocess and "hung" the parent. It sat there
in HIB state (I logged on again and did a SHO PROC/CONT) and nothing I
could do (tried my li' SYS$WAKE utility, to no avail) affected it in the
least. I finally had to do a STOP/ID from the second login, to remove
the original nogoodnik from the system.
Any thoughts on what the $&%$&'@&!! happened? What a pain in the ... neck!
Chris Chiesa, Senior, CS Dept., Ball State Univrsity, Muncie, IN
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><>
<> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa <>
<> cfchiesa@bsu-cs.UUCP <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>terry@wsccs.UUCP (terry) (03/02/88)
In article <3197@okstate.UUCP>, gregg@a.cs.okstate.edu (Gregg Wonderly) writes: > in article <2746@enea.se>, sommar@enea.se (Erland Sommarskog) says: > Another not so nice behavior happens when you logon to a terminal set /NOMODEM > and then spawn a subprocess (a kept editor is an example). Attach back to the > parent process from the subprocess, and DISCONNECT. Later, you logon to a > terminal set /MODEM, and ATTACH to the subprocess. BINGO, DTR gets dropped, > and you are DISCONNECTED. Log back on, and as soon as you CONNECT to the > DISCONNECTED process, again, you are DISCONNECTED. Now you logon one more > time, and all is well. The subprocess starts up, and you do whatever. Then > you try to attach back to the parent. BINGO you are DISCONNECTED again. > Log back > on and CONNECT to the DISCONNECT'd process, and all is well. This > is less than optimal, no? I have run into a similar problem with Decserver 200's. I think it's supposed to. I'd set /NOMODEM, then /MODEM and poof! I'd get a 'Local>' prompt... disconnected process (of course, if the terminal was set /NODISC, I was logged out, not just disconnected!). The whole fiasco was a result of a problem with using the C signal function across a $WAITEFLOR. The alarm() signal is incompatable... but that's another story. The gist of this was that it disappeared in 4.7; That isn't bad, but I think it is an introduced bug, not a fix. There seem to be a number of other problems with attaching to a detached process via modems in all versions of VMS. For instance, if you call in, log in, disconnect, call back in, connect to it, VMS forgets you were on a modem. You hang up, and remain connected. Etc. And just try to restrict usage of certain programs/priveledges/devices/networks to non-modem users only! A nasty side effect to the 4.7 "fix" is that when you are attaching to a modem via and LTA: device, you can have to wait upwards of 30 seconds for a DTR cycle. This means that every time you drop DTR, you risk losing the modem to another user calling in, and getting in via a LAT-generated LTA: which is *not* the one you snarfed. This is _very_bad_ when you are dropping the DTR to hang up some modems, which can only be hung up that way. There is a workaround, using LAT QIO$ calls, but they are not compatable with the standard calls you use, and in addition, you have to *KNOW* you are talking to a LAT in the first place, something that is not always easy for an average dwiddly (read 'unpriveledged user') to do. If you install your program with priveledges, then everything you do, you have to prevent the user from abusing them unless he already has them, in which case it's OK to abuse them. The alternative to that is another program that _does_ have the required priveledge to do what needs to be done. I know this is in keeping with DEC's apparently unspoken axiom of "if you can require another program, do so", but it tic's me off. | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |