[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference jamin::pathworks32

Title:Digital PATHWORKS 32
Moderator:SPELNK::curless
Created:Fri Nov 01 1996
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:337
Total number of notes:1612

318.0. "intr key prints character in VT320" by ATZIS3::JETZINGER_J () Tue May 27 1997 10:52

    We have the following problem on Win95 clients which connect to
    an SCO OpenServer Network 3.0 system via VT320.
    
    When pressing the <Del>-key (= intr) in the VT320 session, 
    an "�" (o-grave) character is printed. This destroys the screen of the
    user program (Informix application).
    
    Server config.: SCO OpenServer Network 3.0
                    NET382 Enhanced TCP/IP driver
                    SMC/WD 8013 ethernet adapter
    Client config.: Win95 4.00.095a
                    Pathworks VT320 7.0.033
                    DE435 ethernet adapter
    
    The same happens with VT320 6.x, but not with 5.x on
    WfW systems.
    
    Is this a known problem, any solution available ?
    Thanks for any info,
    
    Josef Jetzinger
    [email protected]
T.RTitleUserPersonal
Name		DateLines
318.1bug in VT320 ?ATZIS3::JETZINGER_JWed May 28 1997 09:5620
    I posted this question also in the comp.unix.sxo.misc newsgroup
    and got the following reply there:
    
    >This is a bug in the terminal emulator.  It has, for example, been
    >fixed
    >in MS Kermit between version 3.13 and 3.14 (as a conscious change  - I
    >raised the bug report).  The version of KEATerm that we use does have
    >this problem, but older ones didn't.
    >
    >As I remember it, the problem arises because the the telnet sequence in
    >response to the interrupt is split between two IP packets.  Kermit 3.13
    >tried to treat each packet in isolation and therefore output the second
    >character of the telnet control sequence; Kermit 3.14 maintains the
    >relevant state between packets.
    
    Could someone verify that for VT320, please ?
    
    Thanks in advance,
    Josef
318.2waiting for an answerATZIS3::JETZINGER_JMon Jun 02 1997 03:298
    Is there anyone who can give an answer to this question ?
    
    It's really important for our customers.
    If there is no solution for this problem, we have to tell them to use 
    an other terminal emulator (e.g. WRQ Reflection does not have this problem).
                                         
    Thanks,
    Josef
318.3SPELNK::curlessMon Jun 02 1997 12:2810
Keep waiting, or file a IPMT.  This is not an offical report channel.  If you
must have an answer in a specific length of time, and there is no response
from your posted note.... then either

1) The engineer that needs to look at this problem doesn't read notes
2) The engineer that needs to look at the problem is busy
3) ,,, heap loads of others

Jeff
318.4Haven't see it hereJAMIN::MCCARRONMon Jun 02 1997 15:3719
    
    Josef,
    
    What transport are you using: LAT, CTERM, or TELNET?  Does it happen
    with all 3?  If not, which ones fail?
    
>>    When pressing the <Del>-key (= intr) in the VT320 session, 
>>    an "�" (o-grave) character is printed. This destroys the screen of the
>>    user program (Informix application).
    
    Does this mean you are pressing the <DELETE> and <MINUS> key or just
    the <DEL> key?
    
    We haven't seen this problem here so we need a little bit more info
    in order to reproduce it.
    
    thanks,
    
    bruce,
318.5transport is TELNETATZIS3::JETZINGER_JTue Jun 03 1997 04:0417
    >What transport are you using: LAT, CTERM, or TELNET?  Does it happen
    >    with all 3?  If not, which ones fail?
     
    We are only using TELNET to connect to SCO servers.
       
        
    >    Does this mean you are pressing the <DELETE> and <MINUS> key or
    >just the <DEL> key?
        
    It means that the <DELETE> key is pressed. But it's not the <DELETE>
    key which makes the problem, it's the interrupt function.
    When mapping interrupt to <CONTROL><C> (stty intr ^C), then this 
    keys (or any other combination) make the problem.
    
    Thanks for your help,
    Josef
318.6Haven't seen it yetJAMIN::MCCARRONThu Jun 05 1997 11:4611
    Josef,
    
    I tried to repriduce this in our lab but haven't been able to yet.
    I know next to nothing about UNIX, so I'm probably doin something
    wrong.  Could you list the steps taken in order get the problem to
    happen.  I can log in and get to the # prompt.  After that, I wasn't
    too sure of what I was doing.
    
    thanks,
    
    bruce,