Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Showing results for 
Search instead for 
Did you mean: 

Telnet Vs Reflection

Praveen Bezawada
Respected Contributor

Telnet Vs Reflection

When I invoke sqlplus on X terminal ( reflection)and add some swedish character, say '?', it is stored in-correctly ( the ascii of the stored character is wrong)
Whereas from a telnet session it is stored properly.
On reflection, I tried both with LANG set to sv_SE.iso88591 and DEFAULT. When LANG is set to sv_SE.iso88591 and istrip set to cs8 and parity turned off, I am able to display '?' on the command prompt and also at sqlplus prompt. But the character getting stored in database is not '?'.
What could be the problem
Thanks in advance
Honored Contributor

Re: Telnet Vs Reflection

what does the output of locale return?

It works for me (tm)
Praveen Bezawada
Respected Contributor

Re: Telnet Vs Reflection

locale return

sv_SE.iso8859p1 for all parameters
Honored Contributor

Re: Telnet Vs Reflection

Hello Praveen,

it is NOT about locales but about your key
encoding: HP "loves" the HP ROMAN8 encoding,
vs. ISO-8859-1 as done by others...
Just try something like "od -cx" and enter
some of your accented characters, look for
their codenumbers and check what they should
be... :-(

You max use "xmodmap" to re-map single keys,
or look into "/sbin/bcheckrc" (strange place,
I know), where the actual encoding of your
graphics keyboard is done from.

Kenneth Platz
Esteemed Contributor

Re: Telnet Vs Reflection


I believe the problem you are seeing has arisen because the default font encoding for HP-UX systems is the HP-Roman8 encoding, not the ISO8859-1 encoding. These two encodings are both extensions of the ASCII character set, so you would not notice any differences in most situations, but if you are trying to access the upper 128 (ie, extended) characters you will notice a vast difference between roman8 and ISO8859-1. The solution to this problem is to start up a terminal window using ISO8859-1 fonts.

You might want to try starting a new dtterm (instead of hpterm or xterm) window with the following command:

# LANG=sv_SE.iso88591 dtterm

The reason for using dtterm instead of xterm or hpterm is that dtterm is X11R6-based, and as such when it is started with the LANG variable set, it will attempt to find a font that matches up with the appropriate character set of that locale.

I hope this helps.
I think, therefore I am... I think!