RE: Vertical bar translation

Rob:

No good answer, just a bunch comments. I run into similar cases, once every 
year or two. Each time, I go through the laborious process of cross-referencing 
CCSIDs and/or code pages and/or character sets and probably EBCDIC, ASCII and 
decimal values as well. I've never been sure what the parts all actually mean. 
But I've created my mental maps with guidelines that seem to work much of the 
time in letting me track issues down.

I'm not writing any of this claiming any of it's correct. More hoping that 
someone who _knows_ something will jump in and make corrections or add 
refinements. Some day I'd really like to learn this and I suspect many feel the 
same.

First, what is a "character set"? I tend to think of them as applying mostly to 
the human/machine interface. The character set determines which character to 
display or print. This is very closely related to a font in that a font will 
specify how the exact shape of a character will be drawn. I'm not sure if a 
"character set" is ever actually used unless data is ready to be presented to a 
human. The character set, then, determines whether a particular bit pattern in 
your code page will be rendered as a vertical bar or as an upper-case, 
superscripted Q.

Next, why "code pages"? Since code pages seem to be tied to language groups, 
I've thought that code page translation has to do with machine logic. In 
particular, collating sequences or some such. Some bit patterns in some 
languages are assigned to special forms of letters -- a lower-case "o" with an 
umlaut for example. (Off the top of my head; I have no idea how that fits into 
any collating sequence in any language.) But the bit pattern for a simple "o" 
compared to an umlauted "o" should be sortable in a meaningful sense, and the 
sequence might differ from language to language.

Therefore, translation from one code page/character set to another must be 
defined so that collating continues to make sense as data travel between unlike 
systems. When code page/character sets go with data, the collating can be 
handled in predictable ways as long as there's universal agreement. Some 
languages might have umlaut-"o" all the time and need them sequenced right 
alongside regular "o"; others might have no significant use for them. 
Efficiency alone might be enough reason to micro-code differently for them.

For CCSIDs, these seem to be kind of combined code page and character set 
together in a single identifier. Code pages and character sets seem to be 
losing out world-wide to CCSIDs.

Okay, so you have a keyboard setting and/or display device setting that tells 
your computer something about the _meanings_ of the bit patterns that get sent 
when you strike a key (code page/character set). You also have a file with 
CCSID that says something about what translation should happen when data goes 
into/out of the file. At the other end, when another human looks at the data on 
maybe a printout, the bit patterns were sent to the printer which had settings 
about what valid characters it could render (code page/character set).

You mention a file as the intermediary that had CCSID 65535, i.e., no 
translation, no interpretation. I suspect that unless your input device had the 
exact settings as the output device, some characters will be misrepresented. 
This can be true even if you type on your keyboard, view the result on your 
display and then print the file on your personal printer plugged right into 
your PC. Since you often have no way to predict anything on the output side, 
you'll have to perform explicit conversion. CCSID 65535 will probably have to 
go. Specify an actual CCSID.

Now, hopefully, someone else will add some truly useful bits to this. I've 
exhausted my conjecture. Maybe we can even get a decent FAQ put together that 
describes all these in real-world terms.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   5. Vertical bar translation (rob@xxxxxxxxx)
>
>I have a file in a library.  The CCSID of this file, (from DSPFD) is 
>65535.
>I use the following command on this file:
>CPYTOSTMF  +
>                          FROMMBR('/qsys.lib/ediftpdta.lib/gxsftpun.f+
>                          ile/gxsftpun.mbr') +
>                          TOSTMF('/ediftpdta/edioutifs') +
>                          STMFOPT(*REPLACE) STMFCODPAG(*STMF) +
>                          ENDLINFMT(*CRLF)
>Then I use FTP in the standard ASCII method to move this file to another 
>platform.
>
>Problem:  Hex CA is a vertical bar.  On my keyboard it's the cap's mode of 
>the backslash just above the Enter key.
>If I ftp this down to my PC and use either Notepad or Wordpad it looks 
>great - a vertical bar.
>However if I use TYPE thefilename from DOS it looks like a superscripted 
>underlined capital Q.
>I don't know how to use these utilities to display the ascii code of the 
>data.

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


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455