On 2017-10-18, at 19:02:15, Tony Harminc wrote: > > I think allowing the user to specify both the inbound and (one or > more) outbound code pages, and passing those to Unicode Conversion > Services would be the the Right Thing To Do. I'm not sure to what > extent such conversion is supported on non z/OS platforms (VM, VSE, > zLinux?), but the notion of externalizing it to the experts, and > effectively putting it under user control because the user can supply > their own tables if they want, is good. > I believe HLASM is supported under Linux, so I suspect that SYSIN is translated. An additional translation for SYSPRINT might be valuable For example, SYSIN=1047; SYSPRINT=037 (Because that's what the printers are.) What CP is SYS1.MACLIB (does it matter?) It might be valuable to allow macros to have different code pages from SYSIN and each other; a pragma with file scope indicating the CP of that file. (Doesn't similar exist for C/C++?)
I think it would be best for HLASM to operate with a consistent internal CP regardless of the input CP(s). "DC C'['" should generate the same binary object regardless whether the input CP is 819, 1047, 500, or 037. > ... Is there currently a > fundamental constraint that limits the output to the same character > size as the input? For example, if I specify the input is CP 1047, and > the output is CP 1208 (= UTF-8), could a constant CA'€' correctly turn > into X'20AC'? (I'm assuming for the example that it's the CA constant > type that's subject to this translation.) In other words, internally > does the code assume that a 1-byte string must generate a 1-byte > value? > Oh, heck! Ask for the Moon! > Another Right Thing would be to allow these options (or at least the > "output" one(s)) to be changed on the fly with a *PROCESS (or > whatever) statement. > Again, with file scope for SYSLIB members. > I realize you don't want to be adding a zillion options, but perhaps > one to flag (or not) conversion failures or probable "surprises" would > be wise. -- gil
