Topic drift ... I was referring to binary fields in application data files, and I don't *think* UTF-16 endianness addresses this. (Correct me if I am wrong!) It just addresses the endianness of the UTF-16 "binary halfword" character format.
Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, November 2, 2017 3:04 PM To: [email protected] Subject: Re: ASCII self-defining constants On 2017-11-02, at 15:38:43, Charles Mills wrote: > 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. > UTF-16 addresses this with the BOM. I suppose. > -----Original Message----- > From: Of Dave Rivers > Sent: Thursday, November 2, 2017 2:10 PM > > 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. > Why would any sane programmer (assuming such exist) put binary data in compiler (assembler source)!? > Even for HLASM input. we have this very problem in our cross-assembler. > I suspect the DASM programmer with anything like CP819 on a desktop who codes either "DC CA'['" or "DC X'5B'" gets the same result for each. And I consider neither to be "binary", and I expect neither DASM, nor HLASM, to exempt the characters in the coded hex constant from input translation. "All or nothing." CP1047 is the outlier here. -- gil
