On Thu, 20 Oct 2016 13:17:07 -0400, Rick Troth wrote: >On 10/14/16 18:50, Paul Gilmartin wrote: >> CMS Pipelines (perhaps other CMS utilities) use 0x25 instead of 0x15. >> There's some very Bad History behind all this. > >So you're saying even Hartmann makes mistakes? Shock! :-) > Rather, I'd call him a "pedantic stickler[] for doco".
>0x25 is EBCDIC "linefeed". >Sadly, that's printable if misinterpreted as ASCII. The value of 0x15 >and 0x0A is they're both non-printable in both worlds. > Many ASCII editors (and, I believe, Info-Zip) make decisions on statistics. Any UTF-8 file is valid ISO8859-1. Most ISO8859-1 files are not valid UTF-8. Files containing no characters >=0x80 are probably ASCII, etc. >0x0A is referred to as newline in Unix land, but is officially >"linefeed", so would map to EBCDIC 0x25. Certain pedantic sticklers for >doco (against the grain of actual /usage/) ... cough ... IBM ... cough >... would insist on translating EBCDIC 0x25 to/from ASCII 0x0A. Bad >History indeed! > The burden of that Bad History impelled IBM to transgress its own specs when implementing iconv. Linux iconv insists ... I might less rather call the developers "pedantic sticklers" than merely naive adherents to the doco. IBM could alleviate this by defining a code page, call it 1047x, with LF at 0x15 and NL at 0x25. But pedantic sticklers of another ilk declare, "Curst be that moves my [control characters]." And IBM could have evaded all this and many other conflicts if IBM had chosen to make OpenEdition ASCII-based instead of EBCDIC. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
