The problem - I think - is mixed text/binary data in the single file. You want the text translated, and not the binary; so translation at the file level isn’t always the right answer.
Even for HLASM input… we have this very problem in our cross-assembler. Consider REPRO cards... - Dave Rivers - > On Nov 2, 2017, at 5:05 PM, Charles Mills <[email protected]> wrote: > >> But perhaps the proper RFE would be for DfSMS to extend the applicability > of the CCSID parameter of the DD statement > > Far be it from me to tell another company how to design their products -- I > have enough trouble with my own -- but it would just seem like an almost > no-brainer enhancement to z/OS to have the ability to run every xSAM file > I/O through Unicode Services -- to externalize character set conversion -- > kind of like pervasive encryption, to have pervasive translation. > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Paul Gilmartin > Sent: Thursday, November 2, 2017 2:00 PM > To: [email protected] > Subject: Re: ASCII self-defining constants > > On 2017-11-02, at 13:28:08, Jonathan Scott wrote: >> >>> "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. >> > It seems only reasonable to me that a programmer accustomed to using CP1047 > who codes "DC CA'['" would expect the generated value to be X'5B', not > X'DD', even as if the input were CP819. Translation on input accomplishes > this for CP819. Why not for CP 1047? > > But perhaps the proper RFE would be for DfSMS to extend the applicability of > the CCSID parameter of the DD statement to all data set types rather than > continuing to restrict it (WHY?) to ISO/ANSI Version 4 tapes. > > -- gil >
