Conference vaxaxp::vmsnotes

109.0. "Partial Output from CTRL-T, Control/T, CTRL^T on consol" by COMICS::SUMNERC (OpenVMS Counter Intelligence) Wed Jan 29 1997 12:05

    Hi,
    
    I'm still having problems with the issue I raised in vmsnotes_V12, note
    1247.14.
    
    I've tried this with all the drivers mentioned in 1247.*
    
    Does anyone have any more ideas ? or should I IPMT this ?  
    
    Thanks in advance for any help.
    
    
    Chris Sumner
    Server Management Support, UK. 7833 3667
    Here follows my original note:
            Partial Output from CTRL-T, Control/T, CTRL^T on console
            ========================================================
    
    Hi,
    
    I have a customer who is witnessing a problem with CTRL-T.  I have
    managed to
    reproduce this on a DEC 3000 Model 500, hardware model type 1033,
    running
    OpenVMS V6.1.  (My customer is on a DEC 1000 running OpenVMS V6.2).
    
    While running a command procedure from the OPA0: console we are seeing
    strange
    results from a CTRL-T.  The output from a CTRL-T is only partial.
    
    HADDE
    HADDE
    HADDES::SUMNE
    HADDES::SUM
    HADDES::_TNA2: 14:12:34   (DCL)   CPU=
    HADDES::_TNA2: 14:12:34   (DCL)   CPU=00:00:03.97 PF=724 IO=4742 MEM
    HADDE
    HADDES::SUM
    HADDES::S
    HADDES::_TNA2: 14:12:34   (DCL)   CPU=00:00:03.97 PF=724 IO=4742 MEM=62
    HADDE
    HADDE
    HADDES::SUMNE
    HADDES::SUM
    HADDES::_TNA2: 14:12:34   (DCL)   CPU=
    HADDES::_TNA2: 14:12:34   (DCL)   CPU=00:00:03.97 PF=724 IO=4742 MEM
    HADDE
    HADDES::SUM
    
    
    Occasionally a full CTRL-T message will get through.
    
    Issuing a REPLY mesage to OPA0: breaks through and displays with no
    problems.
    
    The following command procedure will demonstrate this behaviour.
    $ write sys$output "Ctrl-T Test For Log 16101"
    $ WAIT_TIME = "WAIT 00:00:00.01"
    $ show process
    $ loop:
    $ WAIT_TIME
    $ logical = f$trnlmn("CJS_TEST")
    $ IF logical .EQS. ""
    $ THEN
    $  define/user sys$output nl:
    $  show process sumnerc
    $  running_status = $status
    $  IF (running_status .AND. 1) .NE. 1
    $  THEN
    $ !  write sys$output "FAIL"
    $  ELSE
    $       GOTO loop
    $  ENDIF
    $ ENDIF
    $ exit
    
    
    The line "$ define/user sys$output nl:"  seems to enhance the problem.
    Taking/commenting it out ensures that the majority of CTRL-T's are
    broadcast in
    full.
    
    The terminal is set at 9600, XOFF, 8 Bits No Parity, 1 stop Bit.
    

    So you're running a command file that does a continuous SHOW SYSTEM
    on OPA0, and your ctrl-t's won't get through? Does that sum up the problem?
    
    

    Some of the ctrl-t's get through. For the others, the output is
    partial.  
    
    Yep, that sums up the problem.  Could this be due to the frequency at
    which OPA operates ?  I don't know, but my customer would like an
    explanation as his customer wants to know.
    
    Thanks in advance.
    
    Chris

    
    There were some fixes in the way that interrupts were handled on the
    COM1 port (aka OPA0) in post-6.2 versions. I've been trying to
    reproduce this on a new platform running 7.1 and can't. Can you
    try 6.2-1h3 on the 1000? The fix is in that version.
    Sue
    

    Hi Sue,
    
    I've tried this on a V7.0 DEC 3000 Model 500, hardware model type 1033.
    Are you saying that, on a 1000 running 6.2-1H3, you can't reproduce
    this ?
    
    Thanks,
    
    Chris

    Chris
    
    	remember that 6.2-1H3 has stuff in that V7.0 didn't get.
    
    FWIW I can't reproduce this with VAX OpenVMS 7.1.
    
    /a

    OK, 
    
    We'll try 7.1 as soon as we can set the system up.
    
    Thanks,
    
    Chris

    .5:
    I was able to reproduce it with 7.1 on an unannounced platform.
    I'm still trying to see if a recent fix can fix this.
    Sue