Yep. Unless you want to make this requirement muy complicated you have to say "all or nothing -- take it or leave it" I used to be in the mainframe-PC file transfer software business. "Transform" is a whole product/problem area of its own. If you are going to be cognizant of binary fields, then the next subject to come up is endian-ness.
Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Dave Rivers Sent: Thursday, November 2, 2017 2:10 PM To: [email protected] Subject: Re: ASCII self-defining constants 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 >
