On Tue, Nov 30, 2010 at 7:01 PM, Wayne Bickerdike <wayn...@gmail.com> wrote:
> 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

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

Reply via email to