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! :-)
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.
0x15 is EBCDIC "newline".
Even prior to USS, certain EBCDIC systems used newline (meaning 0x15)
where record boundaries were unavailable or not effective.
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!
ASCII has a "newline" at 0x85. (aka NEL) Historically ASCII was a 7-bit
animal, so there is no 0x85 (or "was"), so Unix used linefeed as its
end-of-line marker, called it "newline", and made its contribution to
the Bad History.
Precedent:
EBCDIC systems use 0x15 to indicate end-of-line.
ASCII systems use 0x0A to indicate end-of-line.
(I hear the voice of David Warner as the MCP. Time to start quoting old
movies?)
>Once the result of the EBCDIC (or not) check is known, one can apply
>locale and "convert" appropriately. i.e., beyond the cramped walls of
>8-bit space.
But one must somehow know locale to differentiate among ISO-8859-x
and UTF-8 and the far greater number of EBCDIC CCSIDs.
True dat.
"Oh, an African swallow, may-be."
And if we're going to handle code pages or CCSIDs or what not then we're
going to have musical translate tables. Tropical zone? Temperate zone?
This sucks.
"Just not a European swallow, that's all I'm talkin about."
Problem with translate tables is they're not migratory.
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
