| Re: Blank 80-column punch cards up for grabs [message #408076 is a reply to message #408075] |
Sat, 08 May 2021 19:57   |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 8 May 2021 16:00:57 -0700 (PDT)
Quadibloc <jsavard@ecn.ab.ca> wrote:
> This, of course, is after the 1984 Macintosh, let alone the 1981 IBM PC.
> And ISO 8859-1 is the first standardized 8-bit code that can deservedly
> be called "8-bit ASCII".
But at the same time as ISO-8859-1 there were also ISO-8869-2
(Latin 2), ISO-8859-6 (Latin/Arabic) and ISO-8859-7 (Latin/Greek) with a
whole bunch of others added in the following year and more later with
ISO-8859-15 being the latest (ISO-8859-1 tweaked for the Euro). Some of them
were standardised by ECMA a little earlier than ISO.
There has *NEVER* been a single 8 bit ASCII, there has always been
a mess of incompatible and mostly incomplete code pages.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408079 is a reply to message #408076] |
Sat, 08 May 2021 22:03 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, May 8, 2021 at 6:00:09 PM UTC-6, Ahem A Rivet's Shot wrote:
> On Sat, 8 May 2021 16:00:57 -0700 (PDT)
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>> This, of course, is after the 1984 Macintosh, let alone the 1981 IBM PC.
>> And ISO 8859-1 is the first standardized 8-bit code that can deservedly
>> be called "8-bit ASCII".
> But at the same time as ISO-8859-1 there were also ISO-8869-2
> (Latin 2), ISO-8859-6 (Latin/Arabic) and ISO-8859-7 (Latin/Greek) with a
> whole bunch of others added in the following year and more later with
> ISO-8859-15 being the latest (ISO-8859-1 tweaked for the Euro). Some of them
> were standardised by ECMA a little earlier than ISO.
> There has *NEVER* been a single 8 bit ASCII, there has always been
> a mess of incompatible and mostly incomplete code pages.
Yes, that's true.
And there was only a single 7-bit ASCII for the time it took before furriners
got ahold of it and came up with ISO 646.
But ISO 8859-1 is also the first 256 characters of UNICODE now, and it was
the most widely used codepage in the ISO 8859 standard. So, while it may
not _fully_ deserve to be called "8-bit ASCII", it comes closer to that than
anything else.
John Savard
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408175 is a reply to message #407984] |
Fri, 07 May 2021 16:40 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> writes:
> Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes:
>> There was a time I could have written a program to punch a deck of
>> cards with every EBCDIC character and another program that would read
>> the deck in binary (Burroughs had a way of doing that) and then print
>> a table with all 256 characters and their corresponding punch codes
>> but it's too late now.
>
> ... while 709 was BCD for character, the equivalent of 360 TXT (output
> from assemblers & compilers) was "column binary" ... two six bit "bytes"
> in each card 12 row column ... so the 360 card read/punch equipment had
> "column binary" compatibility mode. Rewritting 1401 MPIO front-end for
> 360/30 ... I had to handle both BCD & "column binary" input & output.
> Column binary would map to two 360 bytes ... or 80 column card was 160
> (360) bytes.
>
> "green card" has 2540 CCWs ... green card IOS3270 that I redid in HTML
> shows (same) CCWs for 3525
> http://www.garlic.com/~lynn/gcard.html#23
> i.e. "data mode": 0-EBCDIC, 1-Card image
>
> I could read in EBCDIC and if I got "error" (i.e. invalid hole
> combination) reread in column binary.
>
> other trivia: biggest computer goof ever, from (IBM) father of ASCII (gone 404,
> but lives on at wayback machine)
> https://web.archive.org/web/20180513184025/http://www.bobbem er.com/P-BIT.HTM
> The culprit was T. Vincent Learson. The only thing for his defense is
> that he had no idea of what he had done. It was when he was an IBM Vice
> President, prior to tenure as Chairman of the Board, those lofty
> positions where you believe that, if you order it done, it actually will
> be done. I've mentioned this fiasco elsewhere.
>
> ...
>
> I mention this because it is a classic software mistake. IBM was going
> to announce the 360 in 1964 April as an ASCII machine, but their
> printers and punches were not ready to handle ASCII, and IBM just HAD to
> announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
> had a store of spendable money. They put in the P-bit. Set one way, it
> ran in EBCDIC. Set the other way, it ran in ASCII.
>
> ... snip ...
However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
ASCII into pairs of columns which alternated with undefined pairs of columns.
I'm glad they repurposed the P bit for the 370!
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408183 is a reply to message #408175] |
Thu, 13 May 2021 09:01 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, May 13, 2021 at 11:09:35 AM UTC+10, Rich Alderson wrote:
> Anne & Lynn Wheeler <ly...@garlic.com> writes:
>> Louis Krupp <lkr...@invalid.pssw.com.invalid> writes:
>>> There was a time I could have written a program to punch a deck of
>>> cards with every EBCDIC character and another program that would read
>>> the deck in binary (Burroughs had a way of doing that) and then print
>>> a table with all 256 characters and their corresponding punch codes
>>> but it's too late now.
>>
>> ... while 709 was BCD for character, the equivalent of 360 TXT (output
>> from assemblers & compilers) was "column binary" ... two six bit "bytes"
>> in each card 12 row column ... so the 360 card read/punch equipment had
>> "column binary" compatibility mode. Rewritting 1401 MPIO front-end for
>> 360/30 ... I had to handle both BCD & "column binary" input & output.
>> Column binary would map to two 360 bytes ... or 80 column card was 160
>> (360) bytes.
>>
>> "green card" has 2540 CCWs ... green card IOS3270 that I redid in HTML
>> shows (same) CCWs for 3525
>> http://www.garlic.com/~lynn/gcard.html#23
>> i.e. "data mode": 0-EBCDIC, 1-Card image
>>
>> I could read in EBCDIC and if I got "error" (i.e. invalid hole
>> combination) reread in column binary.
>>
>> other trivia: biggest computer goof ever, from (IBM) father of ASCII (gone 404,
>> but lives on at wayback machine)
>> https://web.archive.org/web/20180513184025/http://www.bobbem er.com/P-BIT.HTM
>> The culprit was T. Vincent Learson. The only thing for his defense is
>> that he had no idea of what he had done. It was when he was an IBM Vice
>> President, prior to tenure as Chairman of the Board, those lofty
>> positions where you believe that, if you order it done, it actually will
>> be done. I've mentioned this fiasco elsewhere.
>>
>> ...
>>
>> I mention this because it is a classic software mistake. IBM was going
>> to announce the 360 in 1964 April as an ASCII machine, but their
>> printers and punches were not ready to handle ASCII, and IBM just HAD to
>> announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
>> had a store of spendable money. They put in the P-bit. Set one way, it
>> ran in EBCDIC. Set the other way, it ran in ASCII.
> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
> ASCII into pairs of columns which alternated with undefined pairs of columns.
>
> I'm glad they repurposed the P bit for the 370!
..
It shouldn't have been a problem for the card reader,
which handles 4-zone code.
Printers could have been modified to produce the required glyphs.
The 029 key punch could have produced any code they wanted,
since that was new equipment.
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408191 is a reply to message #408183] |
Thu, 13 May 2021 17:07 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> wrote:
> On Thursday, May 13, 2021 at 11:09:35 AM UTC+10, Rich Alderson wrote:
>> Anne & Lynn Wheeler <ly...@garlic.com> writes:
>>> Louis Krupp <lkr...@invalid.pssw.com.invalid> writes:
>>>> There was a time I could have written a program to punch a deck of
>>>> cards with every EBCDIC character and another program that would read
>>>> the deck in binary (Burroughs had a way of doing that) and then print
>>>> a table with all 256 characters and their corresponding punch codes
>>>> but it's too late now.
>>>
>>> ... while 709 was BCD for character, the equivalent of 360 TXT (output
>>> from assemblers & compilers) was "column binary" ... two six bit "bytes"
>>> in each card 12 row column ... so the 360 card read/punch equipment had
>>> "column binary" compatibility mode. Rewritting 1401 MPIO front-end for
>>> 360/30 ... I had to handle both BCD & "column binary" input & output.
>>> Column binary would map to two 360 bytes ... or 80 column card was 160
>>> (360) bytes.
>>>
>>> "green card" has 2540 CCWs ... green card IOS3270 that I redid in HTML
>>> shows (same) CCWs for 3525
>>> http://www.garlic.com/~lynn/gcard.html#23
>>> i.e. "data mode": 0-EBCDIC, 1-Card image
>>>
>>> I could read in EBCDIC and if I got "error" (i.e. invalid hole
>>> combination) reread in column binary.
>>>
>>> other trivia: biggest computer goof ever, from (IBM) father of ASCII (gone 404,
>>> but lives on at wayback machine)
>>> https://web.archive.org/web/20180513184025/http://www.bobbem er.com/P-BIT.HTM
>>> The culprit was T. Vincent Learson. The only thing for his defense is
>>> that he had no idea of what he had done. It was when he was an IBM Vice
>>> President, prior to tenure as Chairman of the Board, those lofty
>>> positions where you believe that, if you order it done, it actually will
>>> be done. I've mentioned this fiasco elsewhere.
>>>
>>> ...
>>>
>>> I mention this because it is a classic software mistake. IBM was going
>>> to announce the 360 in 1964 April as an ASCII machine, but their
>>> printers and punches were not ready to handle ASCII, and IBM just HAD to
>>> announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
>>> had a store of spendable money. They put in the P-bit. Set one way, it
>>> ran in EBCDIC. Set the other way, it ran in ASCII.
>
>> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
>> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
>> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
>> ASCII into pairs of columns which alternated with undefined pairs of columns.
>>
>> I'm glad they repurposed the P bit for the 370!
> .
> It shouldn't have been a problem for the card reader,
> which handles 4-zone code.
> Printers could have been modified to produce the required glyphs.
> The 029 key punch could have produced any code they wanted,
> since that was new equipment.
>
Hardware wouldn’t have been as much of a problem as software. Changing
OS/360 to use ASCII would have been an absolute nightmare.
--
Pete
|
|
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408194 is a reply to message #408192] |
Thu, 13 May 2021 18:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Thu, 13 May 2021 14:07:01 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Hardware wouldn’t have been as much of a problem as software. Changing
>> OS/360 to use ASCII would have been an absolute nightmare.
>
> Isn't that called Z/OS ?
>
Not quite sure of the point you’re making. zOS has its Linux subsystem
(whatever they’re calling it now) which is ASCII, but base zOS is still all
EBCDIC. It is - or was, when I worked with it - annoying to deal with the
code differences. Otherwise, I was talking about when it was still OS/360
with all the embedded EBCDIC dependencies, which are mostly still there, at
a time when IBM made the choice of EBCDIC vs. ASCII.
--
Pete
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408195 is a reply to message #408192] |
Thu, 13 May 2021 18:52 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, May 13, 2021 at 4:00:07 PM UTC-6, Ahem A Rivet's Shot wrote:
> On Thu, 13 May 2021 14:07:01 -0700
> Peter Flass <peter...@yahoo.com> wrote:
>> Hardware wouldn’t have been as much of a problem as software. Changing
>> OS/360 to use ASCII would have been an absolute nightmare.
> Isn't that called Z/OS ?
It is _now_. It certainly wasn't back in '64.
It still wasn't called z/OS when it finally got delivered, some time after the
first 360s got delivered in 1965. The owners of the early 360 computers
had to make do with BOS, TOS, and DOS.
John Savard
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408196 is a reply to message #408175] |
Thu, 13 May 2021 18:55 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, May 12, 2021 at 7:09:35 PM UTC-6, Rich Alderson wrote:
> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
> ASCII into pairs of columns which alternated with undefined pairs of columns.
>
> I'm glad they repurposed the P bit for the 370!
It's certainly true that nobody ever used the option of running the 360
with IBM's take on ASCII. Which is why the bit was available when they needed
one bit to indicate extended control mode.
John Savard
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408200 is a reply to message #408194] |
Fri, 14 May 2021 01:55 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 13 May 2021 15:52:51 -0700
Peter Flass <peter_flass@yahoo.com> wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Thu, 13 May 2021 14:07:01 -0700
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> Hardware wouldn’t have been as much of a problem as software. Changing
>>> OS/360 to use ASCII would have been an absolute nightmare.
>>
>> Isn't that called Z/OS ?
>>
>
> Not quite sure of the point you’re making. zOS has its Linux subsystem
> (whatever they’re calling it now) which is ASCII, but base zOS is still
> all EBCDIC. It is - or was, when I worked with it - annoying to deal
> with the code differences. Otherwise, I was talking about when it was
> still OS/360 with all the embedded EBCDIC dependencies, which are mostly
> still there, at a time when IBM made the choice of EBCDIC vs. ASCII.
My understanding was that zOS had integrated both ASCII and Unicode
support in order to make the Linux subsystem possible. My point was that
IBM does backwards compatibility so OS-360 with ASCII would look like the
text support in zOS.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408203 is a reply to message #408194] |
Fri, 14 May 2021 05:30 |
|
|
Originally posted by: J. Clarke
On Thu, 13 May 2021 15:52:51 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Thu, 13 May 2021 14:07:01 -0700
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> Hardware wouldn’t have been as much of a problem as software. Changing
>>> OS/360 to use ASCII would have been an absolute nightmare.
>>
>> Isn't that called Z/OS ?
>>
>
> Not quite sure of the point you’re making. zOS has its Linux subsystem
> (whatever they’re calling it now) which is ASCII, but base zOS is still all
> EBCDIC. It is - or was, when I worked with it - annoying to deal with the
> code differences. Otherwise, I was talking about when it was still OS/360
> with all the embedded EBCDIC dependencies, which are mostly still there, at
> a time when IBM made the choice of EBCDIC vs. ASCII.
Don't conflate UNIX System Services with Linux. Both are available
under Z/OS but UNIX System Services is native and is normally EBCDIC.
Linux is Linux and doesn't really tie into Z/OS other than being able
to run on top of it.
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408206 is a reply to message #408200] |
Fri, 14 May 2021 07:11 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Friday, May 14, 2021 at 12:00:05 AM UTC-6, Ahem A Rivet's Shot wrote:
> My understanding was that zOS had integrated both ASCII and Unicode
> support in order to make the Linux subsystem possible. My point was that
> IBM does backwards compatibility so OS-360 with ASCII would look like the
> text support in zOS.
IBM does backwards compatibility, yes.
But OS/360 with ASCII would have used IBM's ASCII-8; the text support in
zOS does not, since running in 360 mode would limit the machine to only
the first 16 megabytes of memory.
And, indeed, running in 360 mode depends on the extended control bit being
off; the ASCII bit is the one specific exception IBM made to backwards
compatibility, which it could safely do because it was never used.
Not to mention that z/OS usually runs in 64-bit mode, not 390 mode which is
directly upwards compatible with the 370.
The current IBM mainframes have specific instructions for character handling
in UTF-8, so instead of using a mode bit so that the EDIT instruction converts
integers into ASCII form instead of EBCDIC form, they now use different instructions
for processing ASCII text.
John Savard
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408207 is a reply to message #408175] |
Fri, 14 May 2021 07:26 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, May 12, 2021 at 7:09:35 PM UTC-6, Rich Alderson wrote:
> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
> ASCII into pairs of columns which alternated with undefined pairs of columns.
For those who haven't seen the original IBM System/360 Principles of Operation,
I'll give a more detailed description of USASCII-8, which is what IBM called their
modified version of ASCII.
The control codes occupied the two columns 0x and 1x.
The first 32 printable characters, from space to ?, including the digits,
occupied the two columns 4x and 5x.
The upper-case letters were in columns Ax and Bx, and the lower-case
letters were in columns Ex and Fx.
IBM numbered the bits of a byte from the most significant bit as 0 to
the least significant bit as 7.
So if you take an ASCII character occupying bits 1 through 7, the USASCII-8
bit left the least significant five bits, bits 3 through 7, unchanged.
Bit 2 was moved to bit position 1.
Bit 1 was copied into both bit positions 0 and 2, so that the last 64 characters
of ASCII were both in the second half of the 256 character gamut, and also in
the second half of their respective 64-character blocks.
John Savard
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408208 is a reply to message #408207] |
Fri, 14 May 2021 07:50 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Friday, May 14, 2021 at 5:26:43 AM UTC-6, Quadibloc wrote:
> On Wednesday, May 12, 2021 at 7:09:35 PM UTC-6, Rich Alderson wrote:
>> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
>> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
>> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
>> ASCII into pairs of columns which alternated with undefined pairs of columns.
> For those who haven't seen the original IBM System/360 Principles of Operation,
> I'll give a more detailed description of USASCII-8, which is what IBM called their
> modified version of ASCII.
>
> The control codes occupied the two columns 0x and 1x.
> The first 32 printable characters, from space to ?, including the digits,
> occupied the two columns 4x and 5x.
> The upper-case letters were in columns Ax and Bx, and the lower-case
> letters were in columns Ex and Fx.
>
> IBM numbered the bits of a byte from the most significant bit as 0 to
> the least significant bit as 7.
>
> So if you take an ASCII character occupying bits 1 through 7, the USASCII-8
> bit left the least significant five bits, bits 3 through 7, unchanged.
>
> Bit 2 was moved to bit position 1.
> Bit 1 was copied into both bit positions 0 and 2, so that the last 64 characters
> of ASCII were both in the second half of the 256 character gamut, and also in
> the second half of their respective 64-character blocks.
As this verbal description may be hard to follow, I have now added
a chart of the infamous USASCII-8 to the bottom of my web page at
http://www.quadibloc.com/comp/cp02.htm
John Savard
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408216 is a reply to message #408207] |
Fri, 14 May 2021 15:01 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Wednesday, May 12, 2021 at 7:09:35 PM UTC-6, Rich Alderson wrote:
>
>> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
>> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
>> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
>> ASCII into pairs of columns which alternated with undefined pairs of columns.
>
> For those who haven't seen the original IBM System/360 Principles of Operation,
> I'll give a more detailed description of USASCII-8, which is what IBM called their
> modified version of ASCII.
>
> The control codes occupied the two columns 0x and 1x.
> The first 32 printable characters, from space to ?, including the digits,
> occupied the two columns 4x and 5x.
> The upper-case letters were in columns Ax and Bx, and the lower-case
> letters were in columns Ex and Fx.
>
> IBM numbered the bits of a byte from the most significant bit as 0 to
> the least significant bit as 7.
>
> So if you take an ASCII character occupying bits 1 through 7, the USASCII-8
> bit left the least significant five bits, bits 3 through 7, unchanged.
>
> Bit 2 was moved to bit position 1.
> Bit 1 was copied into both bit positions 0 and 2, so that the last 64 characters
> of ASCII were both in the second half of the 256 character gamut, and also in
> the second half of their respective 64-character blocks.
>
> John Savard
>
Gee, I wonder why no one used it? I think the ASCII bit also controlled the
interpretation of signs for PACK and UNPK
--
Pete
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408220 is a reply to message #408216] |
Fri, 14 May 2021 18:31 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Wednesday, May 12, 2021 at 7:09:35 PM UTC-6, Rich Alderson wrote:
>>
>>> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
>>> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
>>> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
>>> ASCII into pairs of columns which alternated with undefined pairs of columns.
>>
>> For those who haven't seen the original IBM System/360 Principles of Operation,
>> I'll give a more detailed description of USASCII-8, which is what IBM called their
>> modified version of ASCII.
>>
>> The control codes occupied the two columns 0x and 1x.
>> The first 32 printable characters, from space to ?, including the digits,
>> occupied the two columns 4x and 5x.
>> The upper-case letters were in columns Ax and Bx, and the lower-case
>> letters were in columns Ex and Fx.
>>
>> IBM numbered the bits of a byte from the most significant bit as 0 to
>> the least significant bit as 7.
>>
>> So if you take an ASCII character occupying bits 1 through 7, the USASCII-8
>> bit left the least significant five bits, bits 3 through 7, unchanged.
>>
>> Bit 2 was moved to bit position 1.
>> Bit 1 was copied into both bit positions 0 and 2, so that the last 64 characters
>> of ASCII were both in the second half of the 256 character gamut, and also in
>> the second half of their respective 64-character blocks.
>>
>> John Savard
>>
>
> Gee, I wonder why no one used it? I think the ASCII bit also controlled the
> interpretation of signs for PACK and UNPK
The Burroughs medium systems (B3500 and descendents) had an ASCII processor flag
(changed with the SMF (Set Mode Flag) instruction).
The flag controlled the value of the zone digit for arithmetic
on byte data (0x3 for ASCII, 0xf for EBCDIC). It had no other effect.
By the third generation machines the flag was a no-op and the zone digits were
always 0xf (EBCDIC).
The File Information Block (FIB) in the application had an ASCII flag
that would request translation (ASCII to EBCDIC inbound, vice versa outbound)
for I/O requests.
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #408225 is a reply to message #408220] |
Fri, 14 May 2021 19:15 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>> On Wednesday, May 12, 2021 at 7:09:35 PM UTC-6, Rich Alderson wrote:
>>>
>>>> However, IBM's 8-bit USASCII-8 was not a simple matter of adding a high order
>>>> bit to the defined 7-bit ASCII code. Instead, the addition bit was placed into
>>>> bit 5 (*five*!) of the 8-bit character, in an on/off pattern which put "7-bit"
>>>> ASCII into pairs of columns which alternated with undefined pairs of columns.
>>>
>>> For those who haven't seen the original IBM System/360 Principles of Operation,
>>> I'll give a more detailed description of USASCII-8, which is what IBM called their
>>> modified version of ASCII.
>>>
>>> The control codes occupied the two columns 0x and 1x.
>>> The first 32 printable characters, from space to ?, including the digits,
>>> occupied the two columns 4x and 5x.
>>> The upper-case letters were in columns Ax and Bx, and the lower-case
>>> letters were in columns Ex and Fx.
>>>
>>> IBM numbered the bits of a byte from the most significant bit as 0 to
>>> the least significant bit as 7.
>>>
>>> So if you take an ASCII character occupying bits 1 through 7, the USASCII-8
>>> bit left the least significant five bits, bits 3 through 7, unchanged.
>>>
>>> Bit 2 was moved to bit position 1.
>>> Bit 1 was copied into both bit positions 0 and 2, so that the last 64 characters
>>> of ASCII were both in the second half of the 256 character gamut, and also in
>>> the second half of their respective 64-character blocks.
>>>
>>> John Savard
>>>
>>
>> Gee, I wonder why no one used it? I think the ASCII bit also controlled the
>> interpretation of signs for PACK and UNPK
>
> The Burroughs medium systems (B3500 and descendents) had an ASCII processor flag
> (changed with the SMF (Set Mode Flag) instruction).
>
> The flag controlled the value of the zone digit for arithmetic
> on byte data (0x3 for ASCII, 0xf for EBCDIC). It had no other effect.
>
> By the third generation machines the flag was a no-op and the zone digits were
> always 0xf (EBCDIC).
>
> The File Information Block (FIB) in the application had an ASCII flag
> that would request translation (ASCII to EBCDIC inbound, vice versa outbound)
> for I/O requests.
>
Excellent idea.
--
Pete
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408227 is a reply to message #408225] |
Fri, 14 May 2021 22:22 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
>> The File Information Block (FIB) in the application had an ASCII flag
>> that would request translation (ASCII to EBCDIC inbound, vice versa outbound)
>> for I/O requests.
>
> Excellent idea.
OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
It was real ASCII, not the mutant version associated with the PSW bit.
I gather it was mainly used for government sites that mandated ASCII
to be interchanged with other kinds of computers. To tell it to do
ASCII translation, on your DD statement you could say LABEL=AL for
ANSI labels or DCB=OPTCD=Q just to translate without labeling the
tape.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408234 is a reply to message #408227] |
Sat, 15 May 2021 07:52 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Friday, May 14, 2021 at 8:22:09 PM UTC-6, John Levine wrote:
> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
Only 8 track tapes? I thought those were analogue tapes that you couldn't
even put in a computer, even if the cartridges for the Superbrain were in
plastic shells that made them look like 8-track tapes.
Perhaps you mean 9-track tapes?
John Savard
|
|
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408239 is a reply to message #408227] |
Sat, 15 May 2021 11:41 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> According to Peter Flass <peter_flass@yahoo.com>:
>>> The File Information Block (FIB) in the application had an ASCII flag
>>> that would request translation (ASCII to EBCDIC inbound, vice versa outbound)
>>> for I/O requests.
>>
>> Excellent idea.
>
> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
Surely, you meant 9-track, unless it was 3840 carts which are 18-track
(but those came way after OS/360).
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408241 is a reply to message #408234] |
Sat, 15 May 2021 13:16 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Quadibloc <jsavard@ecn.ab.ca>:
> On Friday, May 14, 2021 at 8:22:09 PM UTC-6, John Levine wrote:
>
>> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
>
> Only 8 track tapes? I thought those were analogue tapes that you couldn't
> even put in a computer, even if the cartridges for the Superbrain were in
> plastic shells that made them look like 8-track tapes.
>
> Perhaps you mean 9-track tapes?
Sigh. 8 bits plus parity, 800 bpi NRZI or 1600 bpi PE. You know what I mean.
There was also a way in your JCL to say to translate paper tape input from ASCII
but although paper tape readers were in the IBM catalog, I never knew anyone
who had one.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408244 is a reply to message #408227] |
Sat, 15 May 2021 16:25 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-05-15, John Levine <johnl@taugh.com> wrote:
> According to Peter Flass <peter_flass@yahoo.com>:
>
>>> The File Information Block (FIB) in the application had an ASCII flag
>>> that would request translation (ASCII to EBCDIC inbound, vice versa
>>> outbound) for I/O requests.
>>
>> Excellent idea.
>
> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
> It was real ASCII, not the mutant version associated with the PSW bit.
> I gather it was mainly used for government sites that mandated ASCII
> to be interchanged with other kinds of computers. To tell it to do
> ASCII translation, on your DD statement you could say LABEL=AL for
> ANSI labels or DCB=OPTCD=Q just to translate without labeling the
> tape.
ASCII stupid question, get a stupid ANSI.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408245 is a reply to message #408241] |
Sat, 15 May 2021 16:40 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> According to Quadibloc <jsavard@ecn.ab.ca>:
>> On Friday, May 14, 2021 at 8:22:09 PM UTC-6, John Levine wrote:
>>
>>> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
>>
>> Only 8 track tapes? I thought those were analogue tapes that you couldn't
>> even put in a computer, even if the cartridges for the Superbrain were in
>> plastic shells that made them look like 8-track tapes.
>>
>> Perhaps you mean 9-track tapes?
>
> Sigh. 8 bits plus parity, 800 bpi NRZI or 1600 bpi PE. You know what I mean.
>
> There was also a way in your JCL to say to translate paper tape input from ASCII
> but although paper tape readers were in the IBM catalog, I never knew anyone
> who had one.
>
From what I’ve seen they seem to be more of a European thing, although I
wouldn’t be surprised if publishers here used them, too.
--
Pete
|
|
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408248 is a reply to message #408245] |
Sat, 15 May 2021 18:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-05-15, Peter Flass <peter_flass@yahoo.com> wrote:
> John Levine <johnl@taugh.com> wrote:
>
>> According to Quadibloc <jsavard@ecn.ab.ca>:
>>
>>> On Friday, May 14, 2021 at 8:22:09 PM UTC-6, John Levine wrote:
>>>
>>>> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
>>>
>>> Only 8 track tapes? I thought those were analogue tapes that you couldn't
>>> even put in a computer, even if the cartridges for the Superbrain were in
>>> plastic shells that made them look like 8-track tapes.
>>>
>>> Perhaps you mean 9-track tapes?
>>
>> Sigh. 8 bits plus parity, 800 bpi NRZI or 1600 bpi PE.
>> You know what I mean.
>>
>> There was also a way in your JCL to say to translate paper tape input
>> from ASCII but although paper tape readers were in the IBM catalog, I
>> never knew anyone who had one.
>
> From what I’ve seen they seem to be more of a European thing, although
> I wouldn’t be surprised if publishers here used them, too.
The service bureau where I worked in the early '70s did a lot of paper
tape work. Many customers had adding machines with paper tape punches
attached; they'd add up their ledgers and have hard copy to send to us
for processing. The tapes were 8-track, mostly BCD, although we did
have at least one customer who sent us ASCII tapes. One application
was a listing of out-of-print books which was prepared on IBM Selectric
machines with a built-in punch. These machines punched what I later
found out was called "correspondence code". It took me a while to
figure it out and come up with a translation table for it, which I
realized with a shock was the raw tilt/rotate codes for the typeball.
I wrote a lot of custom IOCS.
Our paper tape reader was a Danish box, the Regnecentralen RC-2000.
It was originally designed as a peripheral for the GIER computer,
but some people at Univac cobbled together an interface to our
9300's multiplexer channel. This machine could read tape at 2000
frames per second. It had a compartment into which you'd place a
roll of paper tape, then feed the leader under a photocell read head.
The tape spewed out the side; we'd place a large bin next to it to
catch the tape (which we'd rewind with one of those hand-cranked
gadgets afterwards).
It was a pretty sophisticated unit; it contained a 256-byte buffer
which it would try to keep about half full by varying the speed
of the servo motor that drove the capstan. We didn't have many
applications that drove it to the speed of which it was capable;
most of our tapes contained records about 10 bytes long which were
listed on our (non-spooled) 600-lpm printer. I added a summary
option to one of our programs just so I could watch it really fly.
One application which did run it flat out was the above-mentioned
out-of-print books listing, which just took in data and wrote it
to disk. We had large rolls of tape which shot through the machine
at 200 inches per second - which, we discovered, built up enough
static electricity that when the inevitable spark jumped, it would
crash the computer. We finally managed to get the job to run to
completion after I hung a grounded chain of paper clips by the
reader where the tape would hit it on the way out, and even then
we had to place a boiling kettle in the machine room to get the
humidity up enough to help bleed off the charge.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408257 is a reply to message #408241] |
Sat, 15 May 2021 23:15 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, May 16, 2021 at 3:16:57 AM UTC+10, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
>> On Friday, May 14, 2021 at 8:22:09 PM UTC-6, John Levine wrote:
>>
>>> OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
>>
>> Only 8 track tapes? I thought those were analogue tapes that you couldn't
>> even put in a computer, even if the cartridges for the Superbrain were in
>> plastic shells that made them look like 8-track tapes.
>>
>> Perhaps you mean 9-track tapes?
> Sigh. 8 bits plus parity, 800 bpi NRZI or 1600 bpi PE. You know what I mean.
>
> There was also a way in your JCL to say to translate paper tape input from ASCII
> but although paper tape readers were in the IBM catalog, I never knew anyone
> who had one.
..
Our site had one.
The reader could read at 1,000 c/s, but if you added spoolers to it, the speed was --
wait for it -- 500 c/s.
Go figure.
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408258 is a reply to message #408248] |
Sat, 15 May 2021 23:29 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, May 16, 2021 at 8:28:16 AM UTC+10, Charlie Gibbs wrote:
> On 2021-05-15, Peter Flass <peter...@yahoo.com> wrote:
>
>> John Levine <jo...@taugh.com> wrote:
>>
>>> According to Quadibloc <jsa...@ecn.ab.ca>:
>>>
>>>> On Friday, May 14, 2021 at 8:22:09 PM UTC-6, John Levine wrote:
>>>>
>>>> > OS/360 added support for ASCII data with ANSI labels on 8-track tapes.
>>>>
>>>> Only 8 track tapes? I thought those were analogue tapes that you couldn't
>>>> even put in a computer, even if the cartridges for the Superbrain were in
>>>> plastic shells that made them look like 8-track tapes.
>>>>
>>>> Perhaps you mean 9-track tapes?
>>>
>>> Sigh. 8 bits plus parity, 800 bpi NRZI or 1600 bpi PE.
>>> You know what I mean.
>>>
>>> There was also a way in your JCL to say to translate paper tape input
>>> from ASCII but although paper tape readers were in the IBM catalog, I
>>> never knew anyone who had one.
>>
>> From what I’ve seen they seem to be more of a European thing, although
>> I wouldn’t be surprised if publishers here used them, too.
> The service bureau where I worked in the early '70s did a lot of paper
> tape work. Many customers had adding machines with paper tape punches
> attached; they'd add up their ledgers and have hard copy to send to us
> for processing. The tapes were 8-track, mostly BCD, although we did
> have at least one customer who sent us ASCII tapes. One application
> was a listing of out-of-print books which was prepared on IBM Selectric
> machines with a built-in punch. These machines punched what I later
> found out was called "correspondence code". It took me a while to
> figure it out and come up with a translation table for it, which I
> realized with a shock was the raw tilt/rotate codes for the typeball.
>
> I wrote a lot of custom IOCS.
>
> Our paper tape reader was a Danish box, the Regnecentralen RC-2000.
> It was originally designed as a peripheral for the GIER computer,
> but some people at Univac cobbled together an interface to our
> 9300's multiplexer channel. This machine could read tape at 2000
> frames per second. It had a compartment into which you'd place a
> roll of paper tape, then feed the leader under a photocell read head.
> The tape spewed out the side; we'd place a large bin next to it to
> catch the tape (which we'd rewind with one of those hand-cranked
> gadgets afterwards).
English Electric's paper tape reader (1,000 cps) for the KDF9
and their other computers had a removeable compartment.
The tape was passed into this directly after the read station.
The compartment was lifted off the reader, and an empty one
placed on the reader ready for the next job. Meanwhile, the tape
in the full container would be wound by hand, at leisure, into
a reel. No tangles. The tape could be stopped between characters.
..
> It was a pretty sophisticated unit; it contained a 256-byte buffer
> which it would try to keep about half full by varying the speed
> of the servo motor that drove the capstan. We didn't have many
> applications that drove it to the speed of which it was capable;
> most of our tapes contained records about 10 bytes long which were
> listed on our (non-spooled) 600-lpm printer. I added a summary
> option to one of our programs just so I could watch it really fly.
>
> One application which did run it flat out was the above-mentioned
> out-of-print books listing, which just took in data and wrote it
> to disk. We had large rolls of tape which shot through the machine
> at 200 inches per second - which, we discovered, built up enough
> static electricity that when the inevitable spark jumped, it would
> crash the computer. We finally managed to get the job to run to
> completion after I hung a grounded chain of paper clips by the
> reader where the tape would hit it on the way out, and even then
> we had to place a boiling kettle in the machine room to get the
> humidity up enough to help bleed off the charge.
|
|
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408267 is a reply to message #408241] |
Sun, 16 May 2021 11:42 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, May 15, 2021 at 11:16:57 AM UTC-6, John Levine wrote:
> Sigh. 8 bits plus parity, 800 bpi NRZI or 1600 bpi PE. You know what I mean.
Or 6250 bpi GCR.
I thought that's what you meant, but such tapes were, at the time, always
called "9-track tapes", in contrast to 7-track (never 6-track) tapes. The term
"8-track tape" means something else.
> There was also a way in your JCL to say to translate paper tape input from ASCII
> but although paper tape readers were in the IBM catalog, I never knew anyone
> who had one.
I remember that at the University of Alberta, paper tape could be read and punched by
the IBM System 360/67 used for campus computing. Whether it was by IBM paper
tape devices or by paper tape devices connected to the PDP-11 used as its front-end
communications processor (so as to support attaching more terminals than would be
economical directly) I don't know.
John Savard
|
|
|
|
| Re: half-ASCII, was Blank 80-column punch cards up for grabs [message #408273 is a reply to message #408263] |
Sun, 16 May 2021 20:49 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-05-16, Kerr-Mudd, John <admin@127.0.0.1> wrote:
> On Sat, 15 May 2021 22:56:45 +0100
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On 15 May 2021 20:25:08 GMT
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> ASCII stupid question, get a stupid ANSI.
>>
>> <applause>
>
> It's an oldie but goodie. (I think I've seen it in someones sig
> a long while back)
Yes, I stole it from somewhere. The other good one was in
Ted Nelson's _Computer Lib_:
ASCII and ye shall receive.
-- the computer industry
ASCII not, what your machine can do for you.
-- IBM
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
|
|
| Re: Blank 80-column punch cards up for grabs [message #413553 is a reply to message #413552] |
Sat, 12 March 2022 22:47 |
|
|
Originally posted by: Michael Trew
On 3/12/2022 20:51, Steve Peacock wrote:
> Charlie,
>
> Do you still have a box of 5081s?
>
> Steve
We used to have several ancient punch cards (used) laying around the
house. My grandmother brought them home from Westinghouse Engineering
in the 60's. They've slowly all disappeared, but a couple might still
be in use as bookmarks.
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
