🚀 go-pugleaf

My USD$0.02 worth: It seems to me that there is no practical difference
between these two code snippets with respect to what ASCII character the
Assembler is required to translate from and to:

        MVI  FIELD,CA'A'
And
        MVC  FIELD,ASCII_A
        ...
FIELD   DC   CL1
ASCII_A DC   CA'A'

In both cases HLASM has to choose (or be told) what code page(s) to use when
determining the actual code point for "CA'A'" or "CA'$'" or any other
possible character.

I highly doubt there is a lot of HLASM code out there yet that even uses the
CA type yet, so the impact on existing code should be very minimal.  So long
as the existing default code pages stay the same, most code should be
completely unaffected.

A new CODEPAGE option (or, since that option name is already taken, perhaps
two options, INCDPG and OUTCDPG, or one new one, CPXLATE [code page
translate]) could specify the input and output code pages the programmer
wants HLASM to use.

I can, of course, see potential problems in large organizations where things
like codepage specifications are done by fiat and no one is told what pages
were used when your TN3270 emulator and z/OS were set up, or where the z/OS
setup was done by different individual teams and TSO is not the same as CICS
is not the same as IMS/DC, etc., or where multiple geographic mainframe
locations in one organization each have different codepage standards.  Some
programmer confusion is likely in those scenarios, I admit.

Those are small prices to pay, IMHO.  And they all can be alleviated by very
aggressive highlighting of the new option when it is implemented -- notices
to all large customers (applications departments as well as systems), new
warning messages output when CA is used (removable by specifying the new
codepage option, whatever its name), SHARE/WAVV/etc. user group sessions,
announcement on IBM-MAIN and all other IBM mailing lists (several times over
the course of the introductory 12 months), etc.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ehrman@vnet.ibm.com] 
Sent: Friday, September 22, 2006 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: new type of CA for ascii strings

The easy explanation is that HLASM doesn't support CA terms.

Character self-defining terms are complex. When the assemblers
assumed only code page 037 for input, C'$' meant X'5B'. But we
now have dozens of EBCDIC code pages containing the $ character,
C'$' can have values X'5B' (the HLASM default), X'67', and X'4A'
just among the set of code pages HLASM supports for Unicode
translation.

Many EBCDIC code pages are now used to prepare input for HLASM.
A statement with the term C'$' could contain any of the code
points just mentioned; each has a different ASCII translation.

A possible solution would be to make *all* character terms and
constants subject to translation, but the impact on existing
applications is very difficult to determine.

Your thoughts and suggestions are welcomed.

John Ehrman
    (------------------ Referenced Note Follows --------------------)
Date:         Fri, 22 Sep 2006 15:33:43 +0200
From: Martin <martin@pi-sysprog.de>

To: those that teach HLASM

how do you "sell"/"explain" this to your students?

It is totaly okay to use

     MVI  FIELD,C'A'

to move the EBCDIC constant A to a field

but it is not okay to use

     MVI  FIELD,CA'A'

to move the ASCII constant A to a field.

ASCII is certainly not UNICODE-16.

_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.