On Tue, 21 Dec 2021 14:57:35 -0500, Phil Smith III wrote:
>Remember that things like awk and sed and Python may have assumptions about
>character order that can bite in nasty ways. Not a reason to eschew them,
>but a source of surprises, especially if testing is superficial (i.e., it
>may "work" but then do the wrong thing in real-world cases).
>
The character types and character ranges ("A-Z") may help. Or aggravate.
There's a strong argument here for compiling such utilities in Enhanced ASCII
mode and relying on I/O autoconversion.
I've long noticed that while LC_COLLATE="en_CA" yields plausible results,
LC_COLLATE="en_US" behaves more like "C". I once went to SR on this,
but I used Linux behavior as a reference. "Rejected. Linux is ASCII; MVS
is EBCDIC. Now, the misbehavior is probably grandfathered in for
"compatibility".
>Making System/360 100% ASCII instead of the "It can do ASCII PSW bit that
>nobody ever used" is definitely on my time-machine task list.
>
<https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-BIT.HTM>
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN