T_WADE%ccvax.ucd.ie@CUNYVM.CUNY.EDU ("Tom Wade, Systems") (06/15/88)
If you have a terminal line connected to another machine which you only use for VAX originated traffic (e.g. outgoing Kermit calls) then you can disable the line for incoming login attempts by SET TERMINAL/NOTYPEAHEAD (this prevents chattering whereby each node fires "Login Please" and "Authorization failure" messages at each other). This however will impact on your Kermit. A better method is to set the line $ Set Terminal TXB3 /secure /permanent This means that a break signal is required to initiate a login on that line, anything else is ignored. Of course, this won't work if the connected machine sends a break at any time your Kermit is running (a break causes any process with a channel open to the line to be terminated and the loginout process to start). Outgoing break signals from your Kermit are all right. I use the above for a connection to our telex interface to prevent chattering when the telex driver is not running. ------------------------------------------------------------------------- Tom Wade Heanet: T-Wade@ccvax.ucd.ie Systems Programmer Ean: t-wade@ccvax.ucd.irl Computer Center PSI: PSI%+27243154000712::T-WADE University College Belfield Telex: (0500) 91196 UCD EI Dublin 4. Uucp: t-wade%ccvax.ucd.ie@tcdcs.uucp Ireland Bitnet: twade@irlearn.bitnet Voice: +353-1-693244 Ext 2456 ICBMnet: 53 18 20 N; 06 13 38 W; 25m ------------------------------------------------------------------------- "The generation of random numbers is far too important to be left to chance"
dahls%vax.elab.unit.uninett@TOR.NTA.NO (Joern Yngve Dahl-Stamnes) (06/29/88)
There is an udocumented qualifier which we have used fix the problem: $ set terminal/permanent/nointeractive tta1: It seems to work. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ! The University of Trondheim ! Joern Yngve Dahl-Stamnes ! ! The Norwegian Institute of Technology ! System Manager ! ! Division of Physical Electronics ! ! ! N 7034 Trondheim, Norway ! ! !---------------------------------------+---------------------------! ! dahls%vax.elab.unit.uninett@tor.nta.no ! !------->>>>>>>> "t'nia stnatsnoc ,t'now selbairaV" <<<<<<<<------! +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
IMHW400@INDYVAX.BITNET (07/06/88)
>From: Joern Yngve Dahl-Stamnes <dahls%vax.elab.unit.uninett@TOR.NTA.NO> >There is an udocumented qualifier which we have used fix the problem: > > $ set terminal/permanent/nointeractive tta1: > >It seems to work. That's strange. When I do it, the terminal changes from INTERACTIVE to PASSALL but still prompts for login. I don't know what /NOINTERACTIVE (=/PASSALL, both undocumented) does, but one thing it doesn't do is suppress job creation. I wonder why it worked for you? I guess we need another terminal characteristics bit which means, specifically, "do not automatically run LOGINOUT from this port!!!". Every workaround I've seen causes some other kind of change in the port's behavior. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mark H. Wood IMHW400@INDYVAX.BITNET (317)274-0749 III U U PPPP U U III Indiana University - Purdue University at Indianapolis I U U P P U U I 799 West Michigan Street, ET 1023 I U U PPPP U U I Indianapolis, IN 46202 USA I U U P U U I [@disclaimer@] III UUU P UUU III
dragon@NSCVAX.PRINCETON.EDU (07/09/88)
Try setting the terminal /PERMANENT /NOTYPE_AHEAD. This will disable logins at that terminal until it is set /TYPE_AHEAD again.
EVERHART%ARISIA.DECnet@GE-CRD.ARPA (08/03/88)
*flame on* After many messages about how to prevent VMS terminals from getting Username: prompts, I wonder HOW LONG it will take DEC to add a /SLAVE switch to the terminal characteristics. This has been in the RSX11M and RSX11M+ products for years. Setting a terminal /slave changes NONE of its' characteristics, but prevents logins on that terminal. Therefore, typeahead works, flow control is normal, and whether the terminal is available for interactive use is decoupled from all the other weird characteristics available for controlling behavior. Setting a terminal slaved requires privilege, but would make a great deal of sense in a VMS environment. How about it, VMS Engineering??? *flame off* Glenn Everhart Everhart%Arisia.decnet@ge-crd.arpa Everhart@arisia.ge.com (uucp zone)
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (08/05/88)
> *flame on* > After many messages about how to prevent VMS terminals from getting > Username: prompts, I wonder HOW LONG it will take DEC to add a /SLAVE > switch to the terminal characteristics. I'll admit, the setting you describe does sound like it has its uses. Like keeping users from logging in on your letter-quality printer just because the manufacturer made the mistake of putting a keyboard on it. But still, one thing you haven't described is what this terminal is slaved TO. > This has been in the RSX11M and RSX11M+ products for years. Setting a > terminal /slave changes NONE of its' characteristics, but prevents > logins on that terminal. Therefore, typeahead works, flow control is > normal, and whether the terminal is available for interactive use is > decoupled from all the other weird characteristics available for > controlling behavior. Sounds a lot like what happens when I do something like: $ ALLOCATE TTE0 Setting the terminal /TYPEAHEAD/PERM affects only the terminal's type-ahead buffer (and therefore it's ability to start a job. If you're description of /SLAVE is correct, then I prefer /NOTYPEAHEAD. With the /NOTYPEAHEAD setting, the terminal port just ignores whatever's being sent to it. With the /SLAVE, eventually, the typeahead buffer's going to fill up on you anyway. At that point, depending on the other terminal characteristics, the port is going to do one of three things: 1) Start sending XOFFs (if it's set /HOSTSYNC, and therfore presumably is talking to another machine which is equipped to deal reasonably with flow control) back at whatever's filled up its buffer. If the thing that's filled up the terminal's type-ahead buffer has a big buffer of its own, then once you unblock the terminal line, you could be looking at close to a minute or more of the NIU or whatever unburdening itself. 2) Start sending BELs (if it's set /NOHOSTSYNC and therefore is presumably dealing with a human who is more likely to notice that his terminal's yelling at him than if it just stops echoing for a few moments; of course, if its another machine it's sending these control-G's at, all bets are off as to what happens; or the terminal port can 3) Start ignoring the incoming data, just like a terminal set /NOTYPEAHEAD. Then, of course, there's the question of just who/what the /SLAVED terminal is /SLAVED to. I'd say that an allocated terminal is pretty well slaved to the process it's allocated to. If it's simply a question of whoever wants to have an auxilliary terminal for his process, then /NOTYPEAHEAD/PERMANENT seems pretty close to what you've described /SLAVE to be. It's just that whoever wants to use the terminal has to remember to set it /TYPEAHEAD after they've allocated it either explicitly or implicitly through opening a channel to it. > Setting a terminal slaved requires privilege, but would make a great > deal of sense in a VMS environment. So does allocating a terminal, unless it's been set up with world read access. Please let me know how the following differs in any meaningful way from setting a terminal /SLAVED: At boot time, the terminal is set /NOTYPEAHEAD/PERMANENT, and then either made world-readable or given an ACL that grants read access to certain parties. The terminal will be unresponsive untiil somebody allocates it and sets it /TYPEAHEAD. At this point, they can do just about anything they want to with the terminal, as long as they keep it allocated or keep a channel open to it. As soon as the terminal's free again (unallocated, and no open channels), it returns to its /NOTYPEAHEAD state. > How about it, VMS Engineering??? > *flame off*
gkn@M5.SDSC.EDU (Gerard K. Newman) (08/06/88)
From: EVERHART%ARISIA.decnet@GE-CRD.ARPA Subject: Preventing chattering terminal lines Date: 3 Aug 88 10:54 EST *flame on* After many messages about how to prevent VMS terminals from getting Username: prompts, I wonder HOW LONG it will take DEC to add a /SLAVE switch to the terminal characteristics. This has been in the RSX11M and RSX11M+ products for years. Setting a terminal /slave changes NONE of its' characteristics, but prevents logins on that terminal. Therefore, typeahead works, flow control is normal, and whether the terminal is available for interactive use is decoupled from all the other weird characteristics available for controlling behavior. Setting a terminal slaved requires privilege, but would make a great deal of sense in a VMS environment. How about it, VMS Engineering??? *flame off* Glenn Everhart Quoted (w/o permission) from the V4.7 $UCBDEF macro: $EQU UCB$M_TT_NOLOGINS 32768 However, it doesn't appear that the routine UNSOL in TTYSUB pays any attention to it, and neither does UNSOLICITED_INPUT in the JOBCTL module UNSOLICIT. Close, I suppose. gkn ---------------------------------------- Internet: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) MFEnet: GKN@SDS USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138-5608 Phone: 619.534.5076