|
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/
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.