Ref: Your note of Thu, 2 Nov 2017 12:20:44 -0600 > I would suggest, as a manageable development item, that HLASM continue > to operate in CP 037 internally, but should support input translation > from 500, 1047, 819, ... to 037, provided that a bijective translation > is available, even as on Linux it translates input from 819 to 037.
HLASM has no awareness of the EBCDIC code page except in the context of ASCII or Unicode translation. The syntactic characters are all within the common EBCDIC subset, and any other characters are treated by HLASM as byte values which are copied unchanged to the output unless a translation option is used. The purpose of an input code page option would therefore be to enable reliable translation to ASCII or Unicode. There is already a CODEPAGE option but it is limited to a few code pages and only affects Unicode, not ASCII translation. If we simply said that CODEPAGE will in future affect ASCII translation as well as Unicode that would be logical but potentially incompatible, so we have to be careful. > This should have file granularity so that if a 1047 member COPYs a > 037 member, that member should be treated as 037, but processing reverts > to 1047 when control returns to the parent. I think that's a fairly obscure requirement, given that the common EBCDIC subset is unaffected by such distinctions. If there is an option to set the input code page, it would probably be fairly easy to add it to the options which can be pushed, popped and changed using ACONTROL. > "DC C'['" should produce the same binary output regardless of input > code page. The symbol displayed for a given byte value depends on the code page of the terminal or printer being used to view it, so the interpretation of the byte value as a specific symbol already depends on the code page. Anyway, I think we understand the requirements for improved code page support, but that will require quite a bit of design and planning. In contrast, we all knew what we wanted for today's enhancement, which was for type CA (also CE and CU) to work for terms in expressions as well as for DC constants, and I'm glad we were able to get that done quickly. Jonathan Scott HLASM, IBM Hursley, UK
