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

Reply via email to