strange characters when going into SAM through SSH2 ver. 3.1

[Kathy McGohan_1]

When using Secure Shell ver. 3.1, SAM shows "q's" at the top of menu and "x's" on the sides instead of lines. How do I get SAM's menu to look normal?
When I do a straight telnet into our server, there is no problem with SAM, it's only when using SSH2.

[Steven Gillard_2]

Is your TERM environment variable set correctly?

Regards,
Steve

[Kathy McGohan_1]

I've tried several term types, vt100, vt220, and xterm.

[Steve Steel]

Hi


try a dtterm with this set


-tn term_name
Specify a name to which dtterm sets the TERM environment variable. The default is dtterm. The term_name argument specifies the terminal name used by dtterm.


Steve Steel

[Bill Hassell]

With hundreds of terminals and emulators available, it's important to recognize that character-mode applications must be informed of the terminal you are using. Now this can (unreliably) happen through the actual telnet handshake. For Unix-to-Unix systems, the TERM value can be propagated to the server during the telnet handshake. This however assumes that TERM on the client was set and that it was set to a meaningful value for HP-UX.

For PCs, all bets are off since this is a hidden or non-existent feature. So, to insure that TERM is set correctly, make sure that the TERM test in /etc/profile (and /etc/csh.login) is eliminated:

if [ "$TERM" = "" -o "$TERM" = "unknown" -o "$TERM" = "dialup" ....

The problem is that this test will allow incorrect settings to continue through the login process. The best way to handle this is to always test the terminal type (using ttytype) whether it was set prior to startunbg the shell or not. The setup in /etc/profile would be:

eval $(/usr/bin/ttytype -s)

Execution of this line will test all the popular terminal models and select the best match, followed by the shell command to set TERM, LINES, COLUMNS and ERASE. This should eliminate problems with mismatched terminals (or emulators).

[Mark Fenton]

Kathy,

The issue you are seeing, as Bill points out, is one of your terminal emulator improperly interpreting the characters that SAM is trying to draw on your screen. This can arise from several sources, even from the Font your emulator is using. ((I discovered a couple of ways to get this sort of behavior using Hummingbird's Host Explorer))

A couple of questions for you:

1) Are you using the same terminal emulator program for telnet as for ssh? -- if so, what are the differences in the emulation settings between the two.

2) If your ssh terminal emulator is a different program than the telnet emulator, take a look at the help pages for terminal settings to see if it offers any clues. Also, try a couple of different fonts to see if that makes any difference.

I would note that just because the appearance of the window is a little funky, it doesn't change the fact that SAM still works normally, just with ugly looking borders.....

[Kathy McGohan_1]

I did all that Bill said, but it still did not work. Mark, yes I am using the same terminal emulator program for telnet as for ssh, and you are right, SAM still works but it does not look as nice.

I received an email from a someone at ssh and he said "To clear up the SAM problems you could try alternative codepages. In HP_UX 10 (and 11) the default codepage was changed from 819 to 1051
(ROMAN8). You could try changing the codepage back to 819 (or something different) and see if your problem is solved".

Because I do not know anything about codepage, I have not tried what the ssh tech said. Do any of you know what he is talking about