Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Preventing chattering terminal lines
Message-ID: <880805031618.76d@CitHex.Caltech.Edu>
Date: 5 Aug 88 11:23:52 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 67


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