Ref: Your note of Thu, 19 Oct 2017 11:18:43 -0600 On Linux, HLASM looks at the first record of a file and if it contains an ASCII space, asterisk or digit 0-9 (all of which are outside the EBCDIC printable range) it assumes the file is ASCII and turns on translation from 819 to 037.
We are already aware of a requirement to be able to translate SYSPRINT to ASCII for Linux. I'm not sure about translating to a general codepage, as I would have thought that one would normally view the listing using the same code page as the source. Paul Gilmartin writes: > I think it would be best for HLASM to operate with a consistent internal > CP regardless of the input CP(s). "DC C'['" should generate the same > binary object regardless whether the input CP is 819, 1047, 500, or 037. That seems a bit backwards. HLASM reads files containing EBCDIC codes which it normally regurgitates faithfully, unchanged, in character constants, without any idea what symbols they represent. The same code may appear as different characters on different terminals or printers, especially when it is supposed to represent a square bracket! In order to translate that code reliably to a representation of the same character in another code page, it needs to know the input code page. You can of course use the TRANSLATE option with a user-defined table to translate character strings in the object code to a different EBCDIC variant if necessary. Jonathan Scott HLASM team, IBM Hursley, UK
