🚀 go-pugleaf

On Sat, 23 Sep 2006 10:08:57 -0600, Paul Gilmartin wrote:
>I see a need for something akin to a PRAGMA identifying the
>source code page, as IBM does for other languages:
>
>    head -4 /usr/include/sys/types.h /dev/null
>    ==> /usr/include/sys/types.h <==
>                       ??=ifndef __types
>                       ??=ifdef __COMPILER_VER__
>                         ??=pragma filetag("IBM-1047")
>                       ??=endif

What is wrong with *PROCESS CODEPAGE(1047) ?

>Of course this needs to have the scope of the copybook member
>so that nested COPYs can possess different code pages.

Yes, *PROCESS does not work in a copy member.

>Of course this would also benefit the suppliers of cross
>assemblers on ASCII platforms in that they would have
>guidance for the correct interpretation of "c'$'"

I don't see any need for guidance and I don't see any difference between CA
self-defining terms and CA operands on a DC statement.

If the source file is EBCDIC then C'$' only contains a dollar sign if that
is what your terminal code page displays for X'5B'.  It could just as
likely appear to be the British Pound symbol or any of a number of other
characters.  The assembler just accepts value within the apostrophes
without any conversion.

If you are using C'$' for a member name then as long as the character in
apostrophes is X'5B', this usage is correct.  It will display differently
on different terminals and you can argue that the programmer should have
explicitly coded X'5B', but the code is unambiguous.

If you meant to use a dollar sign because you are formatting a currency
field then unless you know the code page that will be used to display the
field you shouldn't code C'$'.  Culturally correct currency formatting is
probably best done in a language that explicitly provides support anyway.

If the source file is EBCDIC, then CA'$' is equally unambiguous if the
assembler can be told which ASCII code page is to be used.  The assembler
just converts whatever code point is within the apostrophes to ASCII using
the EBCDIC and ASCII code pages.  The Tachyon z/Assembler extends the
CODEPAGE option to be:
CODEPAGE(ebcdic-cp,ascii-cp) and then builds the translation table from the
pair of code pages.  HLASM doesn't have a way to set the ASCII code page.
Instead it has a translation table that is insensitive to the CODEPAGE
setting.  The ambiguity exists because HLASM is missing important
information.

If the source file is ASCII, then C'$' and CE'$' have the same issues as
CA'$' does if the source file is EBCDIC.  The assembler needs to know both
the EBCDIC and ASCII code pages so it can perform a meaningful conversion.
This isn't a problem for HLASM except on z/Linux.

David Bond - Tachyon Software LLC - http://www.tachyonsoft.com