Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.os.vms
Subject: Re: Odd subprocess behaviour
Message-ID: <245@wsccs.UUCP>
Date: 2 Mar 88 06:05:08 GMT
References: <2746@enea.se> <3197@okstate.UUCP>
Lines: 50
Summary: Terminal servers, too.

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