[comp.os.vms] Preventing chattering terminal lines

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