TYPE/PAGE=SAVE on SSH doesn't erase bits of text when paging through a file

[BenAArmstrong]

When I connect from a PC (running Linux or Windows) to one of our local VMS systems and then connect from there to a remote VMS site via ssh, the display becomes garbled when performing certain operations.

For example, if I TYPE/PAGE=SAVE a file that has a mix of longer and shorter lines, after two or three pages some of the longer lines of text from previous pages remain unerased on the screen. This makes it quite difficult to read the files, especially as the effects of the corruption are cumulative -- the more I page through the file, the more bits of unerased lines remain on the screen.

This problem does not occur if I connect to the remote site with telnet instead.

I have so far reproduced the problem using either TCPIP V5.6 - ECO 5 on OpenVMS/Alpha V8.3 (let's call this "local") or TCPIP V5.7 - ECO 2 on OpenVMS/Itanium V8.4 (let's call this "remote"). It doesn't matter which system I use as the client or server, the problem is reproducible in all four permutations (local -> remote, local -> local, remote -> remote, remote -> local).

I've tried this using three ssh clients from our PC workstations: OpenSSH, PuTTY and Secure CRT. When used to directly connect to a remote VMS system, none of these clients exhibits any problems when paging through text files as described above. Also, it doesn't matter which of the three clients is used to initially connect to the local VMS system, after SSHing from there to remote VMS system, TYPE/PAGE=SAVE always has the problem described above. So I'm confident I can rule out the PC ssh client as being the problem.

Is this a known problem? If so, is there a solution?

Thanks,

Ben

[John Gillings]

Ben,

  I connect to numerous OpenVMS systems via SSH using PuTTY and I can't say I've ever noticed anything like you describe. I've just tried TYPE/PAGE=SAVE with no issues.

  Some things to check... Make sure your terminal settings are correct, especially the height, width and device type.  I generally use VT400 function keys and keypad. SHOW TERMINAL says device type is VT102 (set with the SET_TERM_INQUIRE utility from the freeware).

  If that doesn't help, please post a sample file with exact sequence of events to reproduce the symptom. 

[Volker Halle]

Ben,

if I understand your description correctly, you're only seeing this problem with a SSH session between 2 OpenVMS systems. Please do a SHOW TERMINAL on your 'local' system, before you establish the SSH session and then another SHOW TERMINAL on the 'remote' OpenVMS system, after you've established the SSH session.

Any differences ?

Volker.

[Volker Halle]

Ben,

I tested this with OpenVMS V8.3 and TCPIP V5.6 ECO 5 running on PersonalAlpha. I logged in to the node with PowerTerm (TELNET) and then did a SSH local-node-name and then TYPE/PAGE=SAVE SYS$STARTUP:TCPIP$STARTUP.COM - nothing unusual

These is a SET TERM/INQUIRE in LOGIN.COM.

SYLOGIN.COM - by default - does not issue SET TERM/INQ on TNA and FTA devices !

Volker.

[BenAArmstrong]

Terminal: _FTA68:     Device_Type: VT100         Owner: BG_01
                                              Username: BG

   Input:    9600     LFfill:  0      Width: 142      Parity: None
   Output:   9600     CRfill:  0      Page:   44

Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   Hostsync           TTsync             Lowercase          Tab
   Wrap               Scope              No Remote          Eightbit
   Broadcast          No Readsync        Form               Fulldup
   No Modem           No Local_echo      No Autobaud        No Hangup
   No Brdcstmbx       No DMA             Altypeahd          Set_speed
   No Commsync        Line Editing       Insert editing     No Fallback
   Dialup             Secure server      Disconnect         No Pasthru
   No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port
   Numeric Keypad     ANSI_CRT           No Regis           No Block_mode
   Advanced_video     Edit_mode          DEC_CRT            No DEC_CRT2
   No DEC_CRT3        No DEC_CRT4        No DEC_CRT5        No Ansi_Color
   VMS Style Input    <CTRL-H> Backspace

There is no difference in the SHOW TERM output between 'local' and 'remote'. They both resemble the above.

Ben

[BenAArmstrong]

I misreported the versions exhibiting the problem. In fact, I cannot reproduce the problem when the server is this system:

  HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 1
  on an HP rx2600  (1.50GHz/6.0MB) running OpenVMS V8.3-1H1 

 Oddly, the problem recurs again on this system:

  HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2
  on an HP rx2600  (1.50GHz/6.0MB) running OpenVMS V8.4

I have edited the original post to indicate this second system as my second failing case.

So either it regresses in this version or is not related to TCPIP stack & VMS version at all, but some other factor I'm missing.

Ben

[BenAArmstrong]

I retested using your test file and observed that when the window size is small (80x25) there are no problems. When the window size is large (142x44) problems start to occur on the second page:

$     if (startup_p1 .eqs. "INST") .or. (startup_p1 .eqs. "UPGRADE")
$     then
$         tcpip$startup_fail == "TCPIP-E-UNSUPPORTED, ''startup_p1' boot not suppPIP-I-INFO, n  goto error_exit
$     endif

 which should have looked like this instead:

$     if (startup_p1 .eqs. "INST") .or. (startup_p1 .eqs. "UPGRADE")
$     then
$         tcpip$startup_fail == "TCPIP-E-UNSUPPORTED, ''startup_p1' boot not supported"
$         goto error_exit
$     endif

[BenAArmstrong]

And yes, we have SET TERM/INQ in our own LOGIN.COM too. We are aware of that limitation of the default system-wide one.

[Brian Reiter]

Ben,

is the remote system connected via a fairly slow netowrk link? I've often seen the OpenVMS SSH client miss characters or otherwise screw up its output over slow slings (in our case ADSL at about 64K). I've never seen it (as far as I can tell) on machines connected on our LAN.

I know its not a great deal of help!

cheers

Brian

[BenAArmstrong]

No. The problem is reproducible across a broad range of connection speeds: gigabit, 100Mbit and distant remote sites across networks of varying speeds.

Ben

[Volker Halle]

Ben,

yes - I can reproduce this, although not 100% reliably, a couple of retries may be needed:

I login with putty (TELNET) to a PersonalAlpha running OpenVMS Alpha V8.3 TCPIP V5.6 ECO 5. Terminal window size set to 142x44, then SET TERM/INQ. Then SSH to the same node.

$ TYPE/PAGE SYS$STARTUP:TCPIP$STARTUP.COM

press <return> to advance to 2nd page of file

press <page up>

press <page down>

Then I sometimes see what you seem to be seeing. See attached screen shot.

CTRL-W correctly repaints the screen.

Also reproduced when logging in with PowerTerm instead of Putty.

Time to log a call against TCPIP SSH ? Looks like some data might be getting lost via the SSH connection.

Volker.

[BenAArmstrong]

HP has confirmed the bug and it has been forwarded to engineering as case# 4631997916. Thanks for helping to test.