In a recent note, "Hunkeler Peter (KIUK 3)" said:
> Date: Wed, 31 Jan 2007 11:01:42 +0100
>
> I've not played with code pages and assembler so far, so
> I may be missing HLASM options.
>
If there is such an option for HLASM, an assembler program
would need to be recompiled for each locale; no portable
load modules. Undesirable.
> The assembler doesn't care for a locale, does it? So the
> backslash on the CLI will not be changed during execution,
> irrespective of any locale that may have been set in the LE
> (assuming this is LE enabled assembler code).
>
> BPX1RED does not translate what it reads (except in the
> context of autoconvert), does it? So, changing the locale
> does not have any influence in what you get in your buffer.
>
So, how does the PARM='ENVAR("LC_ALL=De_DE.IBM-273")/sh'
you suggested work? Does it cause the shell to translate
all character data to a standard code page when performing
any test? Performance? Well, it's only an interpreter anyway.
You wrote, "AOPBATCH's shell". Does AOPBATCH have its own
version of shell, or does it use /bin/sh? What programs other
than sh are ENVAR()-savvy.
As for Jan M's caution about multiple Unicode representations,
UTF-8 has wide support; it's highly compatible with applications
that have metacharacters in only the USASCII subset; it's
indifferent to endianness; it can be further encoded with Q-P
for 7-bit hygiene. I can only regret that UTF-8 (not EBCDIC
UTF-8!) was not made the base encoding for Unix System Services.
Does iconv support UTF-8? Does PARM=ENVAR() support UTF-8?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
