On Tue, Nov 30, 2010 at 7:01 PM, Wayne Bickerdike <wayn...@gmail.com> wrote: <deleted> > My same source related the tale of a person in same bank who received > an EBCDIC file, opened it in Windows and saved it back as ASCII. The > file was duly transferred for processing on the mainframe. Most of the > packed data was garbaged ...... > > Oh my, dumb and dumber....
Here is an idea to bounce around. z/OS Unix System Services does a lot of work converting ASCII to EBCDIC and back. 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. Shoot, do we want to limit this to just ASCII? Could we do some sort of Unicode translation? Have GPR2 point to a memory area that indicates how many bytes per digit, then the 10 characters for 0-9? EDMK would overlay this address anyway, so ok for input. Would we want the number of digits? I.E. 10 for decimal, 8 for octal, 16 for hexadecimal (good for dumps!), up to 36 to encode numbers into a character string in some way (a basic encoding technique). Would Oriental languages want more than 255 numbers? Save the UNICODE value in the owner field, or a new field in the VTOC? 2 number of Bytes per digit, 2 number of digits, Digit 0, Digit 1, Digit 2, ..., Digit N. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- 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
