On Mon, Aug 1, 2016 at 2:08 PM, Eric Covener <[email protected]> wrote:
> The mainframe guys say it's an unfortunate but intentional > working-as-designed fudge of the iconv results to make the preferred > line separator (0x15)map to/from 0x0A. Seems like safest would be to > not use a table for conversion but instead go through the same iconv > that we're using to convert the data? We have a few choices, but the bottom line is that we treat /r/n as 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping. Choice 1; map both 0x15 and 0x37 to ASCII 0x0d, which grows the number of ascii equivalents by one. Both would be treated at CTRL. Choice 2; invert our current mapping, ASCII NL to EBCDIC LF and visa-versa. That would leave 0x37 'unguarded' and allowed as opaque text chars. Choice 3; treat the entire C1 codeplane on EBCDIC as CTRLs, and ignore some 32 'opaque bytes' as unsupportable. Thoughts?
