RE: CPYTOSTMF character translation redux

David:

It isn't clear what you mean by "translated incorrectly". Do you mean the hex 
value is incorrect or that it displays incorrectly?

In particular, is the hex representation of the "$" (US dollar sign) correct 
when the file is viewed in hex? If it is, then I'd look at the character set 
being used by whatever device is doing the display.

There are two major pieces -- character set _AND_ code page. (I'm avoiding 
discussions on CCSIDs, etc., for now for simplicity and because I'm not an 
expert.) Code pages kind of tell how hex values should be mapped/translated 
from one code page to another; character sets essentially tell how particular 
hex values should look when they're displayed.

So, a French character set being used to display cope page 37 might have some 
characters different from an English character set being used to display the 
exact same data. (Example for illustration only, not necessarily accurate.) In 
some ways, this is similar to using a different font -- the "data" is exactly 
the same but the "information" changes. That is, "it depends on how you look at 
it".

This means that the character sets _AND_ code pages have to be compared at the 
point of entry _AND_ the point of output _AS WELL AS_ at any possible 
translation points in between such as from a CPY or FTP or...

Hope this sparks an idea and maybe corrections from others on concepts -- I 
wouldn't mind learning on this myself.

Tom Liotta

midrange-l-request@midrange.com wrote:

>   9. CPYTOSTMF character translation redux (David Gibbs)
>
>A bit more than a year ago I reported problems using the CPYTOSTMF command
>running on a machine in the UK
>(http://archive.midrange.com/midrange-l/200109/msg01241.html).
>
>Well, I'm back to investigating the problem ... and I've seen some odd
>behaviors, and I was wondering if anyone has ever seen this before.
>
>To summarize the situation ... I've got a CL program running on a V5R1
>system.  The CL program copies a source physical file member into a stream
>file.  It then invokes a Java program that reads the stream file and
>processes the records.  For some reason, when the source pf contains a
>dollar sign "$", it gets translated incorrectly.
>
>When we use STMFCODPAG(437), the $ gets translated into a single quote "'",
>if we use STMFCODPAG(*PCASCII), it gets translated into a cents symbol "=A2"
>(no jokes about the system making commentary on the financial situation) ...
>I don't know what the result would be if we used STMFCODPAG(*STDASCII), but
>I've requested that this test be run also.
>
>I absolutely didn't expect the incorrect translation when we used *PCASCII.
>The fact that a dollar sign is being translated into a cents sign makes me
>suspicious.
>
>Anyone know what might be causing this?  Is it possible that the standard
>translation table on the 400 was changed?  Anyone know how you can TELL if
>the standard translation tables were changed?

--
--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! 
http://channels.netscape.com/ns/browsers/download.jsp

Get your own FREE, personal Netscape Mail account today at 
http://webmail.netscape.com/