Dumb terminal screenlength problem

[Edward L. Hepler]

zeke at sunfun.eta.com (Robert K. Scott) writes:
> We have a curious problem with TELNET access to a SUN 3/280 running Sun/OS
> ... The problem for these users is
> strange: sometimes their session thinks that they have more than 24 lines
> per screen, almost as if it thinks that they have a large Suntools window.
> ...

I found this same problem. I first attributed it to the Sun DNI product
since our users were trying to "set host" from some Vaxes here.  After a
couple of experiments, I found that I could also get this problem to occur
between Suns by using telnet and a "smaller than default sunwindow" from
the "calling" machine.  Rlogin works because it seems to pass window size
information with the login request.  I submitted this as a bug to Sun
(Service Order #215803) a couple of months ago and have yet to get a
reasonable response from them.  I had a lot of trouble even getting them
to try the experiment I told them about to convince them that the problem
existed. (They simply thought that I had set the TERM env. var. wrong,
etc.)

My E-mail report to them (as they requested) is attached at the end of
this message.

I ended up finding a temporary solution....  It seems that the default
term setting when logging into a Sun is a sunwindow.  Once that has been
set, doing setenv's set's and tset's, etc.. don't seem to phase it..  We
now default to setting the term type to vt100 in the .login file.  It
seems that when this is done, you can later change to sun, if desired,
without problem.  A typical .login looks like:

set path=(. ---YOUR PATH INFO---)
if("`tty`" == "/dev/console")then
        echo -n "Suntools? "
        set a = $<
        if($a == "y")then
                exec /usr/bin/suntools -8bit_color_only -toggle_enable
        endif
set term=vt100
setenv TERM vt100
tset
endif

I also have users run a script after logging in which (I guess I'm
paranoid) reinforces all of this.  It is alias'd as follows:

alias vt100 source /usr/local/lib/vt100_setup

where vt100_setup looks like:

set term=vt100
set noglob
set t=(`tset -S vt100`)
setenv TERM $t[1]
setenv TERMCAP "$t[2]"
unset t
unset noglob
alias vi vi -w24

I hope this helps.

Ed Hepler
GE, Valley Forge, Pa.

elh at vu-vlsi or ...vu-vlsi!mercury!elh

Bug report Email to Sun (to pravin at sun.com)...

RE: Service Order #215803

Machine type: Sun 4/110
Operating System: Sun OS 4.0
Other: DNI 6.0, TE100 6.0

Problem #1:

Symptom:
        It is not possible to edit using vi when logged in via
        set host from a VAX running VMS with a vt100 terminal. 
Summary: 
        When logging in from another system, it is not possible to 
        get the remote system to recognize that the terminal is not 
        a Sun window. 

Detailed Description: 
    Example 1: (Actual working arrangement.)
        Log in, using a VT100, from a VAX running VMS to a Sun by 
        doing a "set host" command.  Observe that the environment
        variable TERM is set to "sun".  Do a "setenv TERM vt100" and 
        "tset" and observe via printenv that TERM has indeed been 
        set.  Now perform a "more" of a file or edit a file using "vi". 
        Observe that more than 24 lines (the size of a vt100) are  
        displayed, and if "vi" was invoked, it is not possible to  
        edit the file. 

    Example 2: (To isolate to only Sun environment.) 
        Open a vt100 window on the Sun using te100tool.  From that 
        window log into another Sun using "telnet".  Set the TERM
        environment variable on the remote Sun to vt100 as in  
        example 1.  Perform a "more" of a file or edit a file with 
        "vi".  Observe that more than 24 lines are displayed as above.

    Note that if Example 2 is run with "rlogin" instead of "telnet",
    everything works OK.  It seems that rlogin passes the window
    parameters to the remote machine...

Problem #2:

Symptom:
        When using "dnilogin" to log into a remote VAX running VMS,
        terminal characteristic information is not passed properly
        to the VAX. 
Summary: 
        The dni software doesn't seem to pass the escape seqences 
        with terminal type and terminal parameter information back 
        to a VAX. 

Detailed Description: 
        Open a te100tool window on a Sun.  From that window, do 
        a dnilogin to a VAX running VMS.  (Our systems query the terminal 
        for its type during the login sequence.  If the terminal does 
        not respond correctly, the system prints a "Terminal type?:"
        query to the user.)  Respond with "vt100". 
        Once logged in, try doing a "sho term". 
        This should cause the VAX to do a parameter query to the 
        terminal (te100tool).  The correct parameters are not shown 
        (In fact the terminal type is shown as unknown). 

        This now causes one to suspect either the te100tool as not 
        responding correctly to the inquiries or the dni software as 
        not passing the responses back correctly.   

        To isolate the two, I did the following:

        I repeated the above example, but substituted the dnilogin to
        the VAX with a login to the VAX using kermit over an RS232
        line.  This time the te100tool responded correctly and the
        VAX did not have to prompt the user.  The "sho term" command
        also worked correctly.

Problem #3: (I have previously reported this to our local Sun office
        but did not mention it to you on the phone...)

Symptom:
        The dni software generates large 'trace looking' files in
        the /tmp directory.

Summary:
        Any set host from a remote VAX, and possibly copies from a
        remote VAX, produce what looks to be some sort of debugging
        trace file in the /tmp directory of the Sun which is the
        target of the command.

Detailed Description:
        As noted above, files named ctermsrv.XXX where XXX appears
        to be a PID appear in the /tmp directory of a Sun which has
        been logged into via a set host from a VAX.  It also appears
        that the files might appear when a copy to the Sun from a 
        remote machine is performed.The files are not automatically 
        removed, and in one case became as large as 4 Mbytes in one day.
        This quickly fills the root file system.....

Thanks,

Dr. Edward L. Hepler
GE Aerospace Systems Division
(215)-354-1775
elh at vu-vlsi      <-- This is preferred, as I can send or receive from here.
  -or-
elh at scovcb.ge.com    <--I can only receive mail here.