On 30 November 2010 22:57, Mike Schwab <mike.a.sch...@gmail.com> wrote:
> Here is an idea to bounce around. z/OS Unix System Services does a > lot of work converting ASCII to EBCDIC and back. I'm puzzled by this. What is all this conversion work that takes to much time and effort? To the extent that character coding is relevant, z/OS UNIX operates in EBCDIC, and it is typically only some external interfaces that require character translation. And that is often enough, e.g. in the case of TN3270, done at the client end on the desktop. To be sure there are some ugly cases, such as various sorts of archives containing a mix of binary and character data, but I don't see that there is a lot of expensive or conceptually difficult character conversion going on. > z/Linux works all in > ASCII. Why not get 4 new instructions that work with PD<=> ASCII like > the PD <=> EBCDIC instructions PACK, UNPK, ED, EDMK, but with an A > suffix to denote ASCII character. Conversion from Packed to binary > would be the same. Assembler would get new instructions. z/OS would > need to know if a file was ASCII for proper translation when printing > it. It's all there. > Shoot, do we want to limit this to just ASCII? Could we do some sort > of Unicode translation? Some of that is there too. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
