Conference jamin::pathworks32

I've sent your note to Ericom. Since I don't have access to a 
DIGITAL UNIX system right now, I've connected to something
that calls itself:

    DEC OSF/1 V3.0 (Rev. 347); Thu Dec 21 11:51:30 MET 1995

and did not get that error. The variable term still says uknown, though.
Don't know if this helps...

Slobodan

PowerTerm sends a terminal ID according to the terminal ID in the 
General tab of the Terminal Setup dialog box.

    If it is VT320 (default) it will send vt320.
    If it is VT420 it will send vt420, etc.

By the way, the change from VT420 to VT320 as the default ID was made 
in PowerTerm since some apps (like SEDT on VMS), that worked fine with 
VT320, broke.

>    never seen before; VTstar (VT320e), Windows Telnet (in VT100 mode),
>    KEAterm, and various free- and shareware Telnet programs like QVTnet
>    and UWterm all work without a problem. 

Do you know what ID are these sending?

Does the VT320 emulator work when you connect to the same system? 
It sends VT320 as the ID. If it works, then PowerTerm has a problem...

Try PowerTerm with VT100 as the ID.

Regards,
Slobodan

Tried it on

    Digital UNIX V4.0 (Rev. 386); Thu Sep 26 16:40:27 MET DST 1996

and did not get that error. The variable term still says uknown.

Slobodan

    >does vt320 work...
    
    It never has before.  See discussions in the other PW client notesfiles
    -- the vt320 engineers and the PW Telnet driver engineers have in the
    past just pointed fingers at each other when the question of "who
    should send the terminal id" came up, leaving end users hanging in
    limbo.
    
    As for PowerTerm, it sends "VT320" by default but DIGITAL UNIX has no
    "VT320" entry in /etc/termcap -- it has "vt320", "vt320-am", and
    "Digital VT320" but no "VT320".
    
    PLEASE either make the terminal ID lower case or add both upper&lower
    selections.
    
    Possible workaround (that I thought would work but dosn't on my 3.2C
    system - is there now something called terminfo that's used rather than
    termcap?): edit /etc/termcap, and change one line from
    
    de|vt320|vt320-am|Digital VT320:\
    	to
    de|vt320|vt320-am|Digital VT320|VT320:\
    
    (exact case and don't forget that last colon)
    
    
    Of course, now we just need to get the arrow keys working in emacs and
    vi ;-)
    
    -Steven
    

Steven, thanks for clarifying this. I can confirm it. I've just tried 
VT320 on those OSF/1 and DU nodes, and the term (TERM on DU)
variable stayed unknown. 

>    -- the vt320 engineers and the PW Telnet driver engineers have in the
>    past just pointed fingers at each other when the question of "who
>    should send the terminal id" came up, leaving end users hanging in
>    limbo.
>    
>    As for PowerTerm, it sends "VT320" by default but DIGITAL UNIX has no
>    "VT320" entry in /etc/termcap -- it has "vt320", "vt320-am", and
>    "Digital VT320" but no "VT320".
>    
>    PLEASE either make the terminal ID lower case or add both upper&lower
>    selections.

I wasn't aware of this (stayed away from Unix all these years and its
idiotic case sensitivity in areas where it does not matter). I'll
ask Ericom to add "vt320" (and probably all the others, sigh) to the 
list.

All DIGITAL's documentation, SHOW TERMINAL, etc., always had "VTxxx"
in capitals, I've never seen this in lower case.

So, KEA, VTstar, and all the others are actually sending "vt320"? Where
they just lucky, or did they modify their code after trying our Unixes?
I hexdumped KEA and found only "VT320", so they must be doing something
special, maybe trying both upper and lower...

Regards,
Slobodan

    before asking them for the change, get someone from DU engineering or
    support to confirm that's what's really required and will work -- like
    I said, the workaround wasn't working for me when I tried it, but I
    didn't really have the cycles at that point to do extensive testing.

    re: workaround.
    
    Steven,
    
    I tried this too, under 3.2C, and it didn't work for me. I also
    took a look at the terminfo file on 4.0, and tried adding it there,
    still no luck.
    
    Simon

Just tired it with PowerTerm Interconnect (DEMO) version. It talks
directly to telnet. The term variable says vt320. It works fine. 

Both VT320 and PowerTerm 525 use DECTAL.DLL, and it does not work.

Too bad, we almost had the Unix folks this time!

Slobodan

    so PT uses DECTAL which follows PW's tradition of... well, I'll be nice
    and just leave it with "...of ignoring user's needs."  :-(
    
    Have you filed a QAR or shall I?
    
    -Steven                                              
    

>    <<< Note 110.8 by JOBIM::VUJNOVIC "I�t�r��t���l�z�t��L���l�z�t��" >>>
>                       -< DECTAL actually sends the ID! >-
>
>Just tired it with PowerTerm Interconnect (DEMO) version. It talks
>directly to telnet. The term variable says vt320. It works fine. 
>
>Both VT320 and PowerTerm 525 use DECTAL.DLL, and it does not work.
    
    Ah, so that's it! Thanks!
    

Steven,					5-Feb-1997 10:46:37

Please QAR it (against TRMNLAXS). I won't be here much longer to
follow up on this.

Slobodan

 And the QAR's answer was...
 
    Thank you for the information.  Because there is a work around
    I'm lowering this to Medium priority.  And because we won't be
    able to address this until our next release I'm deferring it.
    
    We will address this later and, when we get a solution, may
    include you in verifying it.
    

    We are trying to  ship this product.  You have a workaround
    and it is now release noted.  You said it's been this way
    forever and you want it changed.  This is not the time to
    make this change, just as we're about to ship.  This should
    not hold up shipping version 7.

    I wanted to set it to a LOW priority because  you only have
    to put a TERM=vt320 in your startup file or a "setenv" cmd.

    Now, the problem is, as best as I can tell, that when TELNET
    makes the connect, as part of the handshaking, the client
    passes it's terminal type.

    After the type is set on the host (server) it can be changed/
    overridden with the setenv command.  What TELNET passes is
    a default.

    Right not TELNET passes "unknown" as the terminal type.  Somehow
    it needs to find out what type of terminal is using it.  The 
    question is, "What's the best way?"

    1. It could query the terminal by sending up a control sequence
    and listening for a response and map that to a string like "vt320".
    This is very messy and problematic.

    2. We could default to something besides "unknown" like "vt100".
    I believe this is what cterm does (VT100 actually).

    3. There is a PWTELNT call called TelnetSetTerminalType.
    DECTAL does support it.  There are  many emulators out there
    that would have to be changed.

    4. We could place a default value in a file like PWTCP.INI and
    read it from there.

    5. We could put an entry into the PATHWORKS\Config registry area
    with the SETUP program and use that.

    I'm tending to go with solution #5, but it involves changing SETUP
    and SETUP should not be changed *AT THIS TIME* for so small a problem.
    
    If this problem were brought up a 6 weeks ago my response would be 
    different.

    Does anyone have any other solutions?  Does anyone have an opinions
    on which solution we should go with?

    Tom

    How many emulators will use our DLL's?  Option 3 sounds best to me,
    just have PTW and VT320 set it (I'm assuming it's a call that allows
    the TE to set the type that PWTELNET then passes along to the remote
    host).  That would allow the user to set it via the TE's native
    options.   If there are other TE's that use PWTELNET, what do they do
    now?  If the're in the same boat that VT320/PTW are, they would have
    the option of using this call, if not then they're doing something else
    that perhaps #3 wouldn't break.
    
    re: your 1st couple of paragraphs...
    
    I am truely sorry if -.2 was snippy, I just meant to provide an
    accurate update to this Note stream.
    
    -Steven

>    How many emulators will use our DLL's?  Option 3 sounds best to me,

    Now that you mention it, that sounds like the best option.

    It means a fairly small change in vt320 and likely a small change
    in PowerTerm.

    The Reflections people are working on a new version that goes
    through DECTAL and I just alerted them to this issue.

    Alas, our TE changes won't make it out for this release.

    Tom

    I see in the QAR that the problem is fixed in 4.00.38, not yet
    available - that's understandable so far.  Then, a month later, there's
    a note saying that the QAR's being deferred until after 7.0A -- can
    anyone explain that?