IBM 360 ASCII mode

[Darrel VanBuer]

I still have 360 Principles, so I can answer the issue of ASCII codes and
relevant decimal instructions.
The differences are confined to the choice of zone and sign nibbles when
generating results of decimal arithmetic, UNPK, EDIT and EDMK.  Since PACK
ignores zones, and all six (16-10) possible sign nibbles are accepted in
such a way that ASCII and EBCDIC  signs are compatible, the format is not
important as inputs.
There was a question about certain special pattern characters in EDIT (hex
20, 21 22) looking like ASCII printables (blank ! ").  There turns out not
to be a conflict, because the code used is USASCII-8, not USASCII.
The standard bit numbering in USASCII is (msb to lsb) 7654321.  It is
embedded in USASCII-8 by replicating bit 7 in the pattern 76754321.
As a result, 20-22 are NOT USASCII characters [blank ! " are hex 40, 41, 42],
so there is no conflict between.
A side effect of this rather funny embedding is that the printable
characters are not contiguous in USASCII-8 (but contiguous in blocks of 32),
and the gaps are not of uniform size (two are 32, one is 64).

Still another ideosyncracy of the IBM communications controller requires
virtually ALL characters in/out of the machine to be run thru a translation
table.  The serial interfaces on 360/370 equipment transmit MOST SIGNIFICANT
BIT first, so even an ASCII-7 string in memory has to be translated to
reverse the bits to match the LSB first that everyone uses (and parity is
appended by this translation as well!).

Your should see the condensed table of the correspondence between EBCDIC and
hollerith punches!
-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER at USC-ECL.ARPA