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
