On 2014-01-14 11:32, John Ehrman wrote:
>
> * The mapping of EBCDIC source characters to other forms is limited in
> scope (as many have noted).  This was intended.
>
Did that intent include not translating all of CP 037 to all of CP 819?
What was the motivation?

> * HLASM was not designed to accept ASCII source programs.  (On zLinux,
> however, a brief test is done on the first record to determine whether or
> not to translate the file to EBCDIC as it's read for processing.)
>
CP 819 -> CP 037, I hope.  Or should it be CP 1047 for compatibility
with Unix System services?

> * A CA-type constant simply translates standard EBCDIC source characters
> (code page 037) to generate ASCII object bytes (code page 819, I believe).
>
That is what the RM on z/OS 2.1 InfoCenter claims.

> * The TRANSLATE option lets you specify a translate table to be used for
> mapping EBCDIC source bytes to a different object encoding; the default
> table is 037-to-819 (I believe).  Several typical translate tables are
> provided for common (extended) EBCDIC code pages, but you can write your
> own translate table as described in the Programmer's Guide.
>
Is it possible for me to inspect the default translate table?  How?

> If you would like HLASM to accept and/or generate a wider variety of
> character sets, submit a "Request For Enhancement" through the HLASM web
> site, or with the help of your friendly local IBM representatives.
>
Given that the z/OS 2.1 clearly states 037 and 819, but not the entire
CP 037 is correctly translated to 819, this feels more like PMR than
RFE.  When we get 2.1 to test.  Which seems a long way off.  For
business reasons.

Thanks,
gil

Reply via email to