There are just so many layers of ambiguity now in any event. "How it displays" needs to be taken in the context that most (almost all) terminals are now 3270 emulators running on boxes where ASCII or some form of Unicode is the native character set. Most printers no longer process EBCDIC directly. Almost every display shows some glyph that the hardware and software uses to represent some ASCII or Unicode character that something has mapped from the EBCDIC.
Any reliance on the visible glyph as an unambiguous indication of the underlying bit pattern is going to be fraught. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jonathan Scott Sent: Monday, February 13, 2023 8:36 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM code page support enhancements Ref: Your note of Mon, 13 Feb 2023 09:23:37 -0700 gil writes: > Wouldn't that limitation have applied to EBCDIC terms contains characters > outside the invariant EBCDIC character set? such as: > CLI L,C'[' or: > DC C'[' > where it is not possible to determine the binary value from the written or > printed form? Yes, it is true that would not determine the binary value, but it would still display unchanged on a terminal in the same code page as the source. In contrast, an ASCII or Unicode converted character will not necessarily represent the same symbol unless the conversion takes into account the original EBCDIC code page. So to be more accurate, the problem was that the binary code for an ASCII or Unicode character does not necessarily give the same symbol as was coded in the EBCDIC source. > Can the macro author PUSH the CCSID on entry and POP it on exit in order to > control the CCSID non-disruptively? The CCSIDs for DC constants can be changed with ACONTROL, and ACONTROL settings can be saved and restored with PUSH and POP. However, I find it hard to imagine a meaningful use of this capability within a macro. The CCSIDs for self-defining terms and literals cannot be changed within an assembly, as these may be evaluated multiple times at different points regardless of the location at which they appear in the original source. > > ... All source files and listings are > > assumed to be in the local EBCDIC code page as specified on the > > EBCDIC option or assumed by default. > > Is this default affected by the CCSID tagging of z/OS UNIX source files? HLASM is unaware of any such tagging. As previously mentioned, you should refer to the APAR page on the support site and the additional documentation page which it references for full details. https://www.ibm.com/support/pages/apar/PH50915 Jonathan Scott, HLASM IBM Hursley, UK
