William J. Kammerer was nice enough to point out the error in my analysis. The actual mistake made was that I looked misinterpreted the EBCDIC code as decimal 60 instead of hex 60. The dash "-" does in fact correctly map correctly between character sets.
But, like the election, the story goes on. I use the following EBDCID table
http://www.natural-innovations.com/boo/asciiebcdic.html
along with the tables referenced by William to determine the set of characters with interpretive mapping or no mapping at all. I was surprised to see that the set of invalid characters included:
INVALID CHARACTERS
ASCII EBCDIC
~ Tilde a1
\ Reverse Slant e0
| Vertical Line 6a
{ Opening Brace c0
} Closing Brace d0
` Grave Accent 79
^ Circumflex, Caret 5f � Logical NOT
[ Opening Bracket 4a � Cent Sign
] Closing Bracket 5a ! Exclamation Point
! Exclamation Point 4f | Logical OR
Look, our old friends tilde and pipe! How could this be? I have been using tilde as my segment terminator with the partner in question for some time now.
To go right to the horse's mouth:
http://giswww.pok.ibm.com/gpg/ggv2ad45.html#TBLBADCHR
"The problems arise because there are many different "code pages" for EBCDIC host-connected display terminals. These different code pages (implemented in the 317x and 327x control units) map a number of displayed characters to different EBCDIC hexadecimal byte values (and vice-versa)."
Indeed, the EBCDIC code table on the web, where 0xA1 has no mapping, is slightly different than the EBCDIC table on the System 370 quick reference card, where 0xA1 is, in fact, a tilde.
So in the final analysis, the entire foundation is a bit shaky. What I ended up doing was taking 10 PO batches that were known to be successful and wrote a quick script to extract the set of unique characters used in those transactions.
In the second point, I was thinking of an SAC segment where the charge is indicated as in SAC_05, with SAC_01 as the allowance or charge indicator. If you have 70 trading partners, you want to standardize how people use this segment. In the case that I'm thinking of, we had partners uniformly express the amount as an absolute value and the allowance or charge indicator was effectively interpreted as the sign.
Anthony
> -----Original Message-----
> From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 09, 2000 8:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ASCII - EBCDIC conversion issue solved! Or Not Quite....
>
>
> Anthony Beecher wrote that "-" in ASCII maps to DC4 (device control 4)
> in EBCDIC(!!) using the EBCDIC to ASCII conversion charts I
> pointed out
> residing at the University of Illinois in their Character Codes Quick
> Reference at http://www.uiuc.edu/ccso/pubs/all/qr/QR_0.8.html.
>
> Dear Anthony:
>
> Whoa!!! Hold on, big fella. Let's do a sanity check here. In any just
> and decent world, an ordinary dash (-) in ASCII should map to the same
> graphic in EBCDIC. I think you were using the wrong table.
>
> The dash in ASCII is 0x2D, as shown in Table 4: 7-bit ASCII
> Definitions.
> Using Table 2b -- 8-bit ASCII --> EBCDIC, you see that 0x2D
> maps to 0x60
> in EBCDIC, which Table 3: EBCDIC Definitions shows to be the dash, as
> expected.
>
> Further, you added "No wonder X12 likes to express money as
> an absolute
> value with a separate sign indicator. If you try to send a negative
> number from ASCII to EBCDIC, you won't get the sign character through
> conversion." Actually, X12 numeric elements do include the
> minus sign,
> or dash, for negative numbers. Maybe you're thinking of the
> COBOL SIGN
> SEPARATE thingy.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Memorial Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "Commerce for a New World"
>
> ==============================================================
> =========
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
