Discussion:
Blank 80-column punch cards up for grabs
(too old to reply)
Charlie Gibbs
2021-05-02 17:51:59 UTC
Permalink
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.

I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Ahem A Rivet's Shot
2021-05-02 20:14:15 UTC
Permalink
On 2 May 2021 17:51:59 GMT
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
Have you seen what they go for on eBay ? A typical example:

https://www.ebay.ie/itm/224223304294
--
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/
Peter Flass
2021-05-02 23:41:11 UTC
Permalink
Post by Ahem A Rivet's Shot
On 2 May 2021 17:51:59 GMT
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
https://www.ebay.ie/itm/224223304294
That’s insane. I think I have a small deck of 110 or so cards somewhere, at
that price that’s $900!
--
Pete
Charlie Gibbs
2021-05-03 03:49:44 UTC
Permalink
Post by Peter Flass
Post by Ahem A Rivet's Shot
On 2 May 2021 17:51:59 GMT
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
https://www.ebay.ie/itm/224223304294
That’s insane. I think I have a small deck of 110 or so cards somewhere,
at that price that’s $900!
And I could say that they're still in the original packaging. :-)
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Ahem A Rivet's Shot
2021-05-03 05:34:35 UTC
Permalink
On 3 May 2021 03:49:44 GMT
Post by Charlie Gibbs
Post by Peter Flass
Post by Ahem A Rivet's Shot
https://www.ebay.ie/itm/224223304294
That’s insane. I think I have a small deck of 110 or so cards somewhere,
at that price that’s $900!
Isn't it just - I found out when I thought I might pick up a few to
show folks, I changed my mind.
Post by Charlie Gibbs
And I could say that they're still in the original packaging. :-)
I haven't investigated but it wouldn't surprise me if they're like
stamps, worth more when used with some uses fetching a premium.
--
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/
Chris Bigos
2021-05-03 08:32:04 UTC
Permalink
Post by Peter Flass
Post by Ahem A Rivet's Shot
https://www.ebay.ie/itm/224223304294
That’s insane. I think I have a small deck of 110 or so cards somewhere, at
that price that’s $900!
--
Pete
Don't get too excited - that's just what they are asking. They actually sell for rather less (though still more than I would have thought).

https://www.ebay.com/sch/i.html?_from=R40&_nkw=IBM+punch+card&_sacat=0&rt=nc&LH_Sold=1&LH_Complete=1

I have unused boxes in various colours ('white', yellow, green, red, blue, orange) stacked away somewhere.
Scott Lurndal
2021-05-03 14:07:12 UTC
Permalink
Post by Ahem A Rivet's Shot
On 2 May 2021 17:51:59 GMT
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
https://www.ebay.ie/itm/224223304294
That’s insane. I think I have a small deck of 110 or so cards somewhere, at
that price that’s $900!
Although the asking price isn't necessarily the price that
someone is willing to pay....
bert
2021-05-03 08:28:32 UTC
Permalink
Post by Ahem A Rivet's Shot
On 2 May 2021 17:51:59 GMT
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
https://www.ebay.ie/itm/224223304294
Sorry, that asking price - like many more on eBay - is meaningless.
Because listings are free, eBay is flooded with ill-informed sellers
who are convinced that their item is of great value. An item's value
is better found among "Sold items" than among "Items for sale".
Andy Burns
2021-05-03 08:30:25 UTC
Permalink
Post by Ahem A Rivet's Shot
https://www.ebay.ie/itm/224223304294
The "sold" prices are slightly more sane than the "for sale" prices

<https://www.ebay.ie/sch/i.html?_nkw=ibm+punched+cards&LH_Sold=1>
Rich Alderson
2021-05-02 22:40:21 UTC
Permalink
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
Before 6 March 2020 I would have arranged for all of that to come to the museum
in Seattle, but with the final closure on 1 July 2020 there is no one there to
take you up on it.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Peter Flass
2021-05-02 23:41:13 UTC
Permalink
Post by Rich Alderson
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
Before 6 March 2020 I would have arranged for all of that to come to the museum
in Seattle, but with the final closure on 1 July 2020 there is no one there to
take you up on it.
BitsVers has had good luck reading old tapes, but I would imagine they’d
only be interested if it was something really worthwhile, and not just some
random programs or data files.
--
Pete
Charlie Gibbs
2021-05-03 03:49:44 UTC
Permalink
Post by Rich Alderson
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
While cleaning things out I came across an unopened case of good old
form 5081 (5 boxes at 2000 cards per box). I have a couple more boxes
of blank cards as well. Anyone in the Vancouver, B.C. area who is
interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
Before 6 March 2020 I would have arranged for all of that to come to the
museum in Seattle, but with the final closure on 1 July 2020 there is no
one there to take you up on it.
Damn, I snoozed again.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Andreas Kohlbach
2021-05-03 12:29:22 UTC
Permalink
Post by Charlie Gibbs
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
A 1/2-inch tape are punch cards?

In the German folklore usenet group <news:de.alt.folklore.computer> is by
chance (what are the odds! :-) a topic about how to rescue old punch
cards with the subject "Lochkarten lesen". Lochkarte is the German term
for punch cards (or is it punchED cards?), literally "hole card".

Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.

One problem not solved how to get some 1000 cards scanned
automatically. Scanning 1000 cards manually might otherwise take quite
some time.

The other problem was to know what format the data are, because punch
cards just produce data without declaring any meta-data. In the case of
the German news group the original poster said it was some kind of
spreadsheet, classifying bird, where they live (some kind of latitude and
longitude) and other things.

The thread later deviated into programming languages (FORTRAN) and other
things, and the problem wasn't solved yet.

If someone interested can read and understand German, I mentioned the
usenet group and subject above. I think the thread has well over 300
articles by now. If not, and any working solution to scan and read the
data comes up, I can then post it here.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Dan Espen
2021-05-03 14:11:45 UTC
Permalink
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I may not know asterisk, period, etc. from memory but numbers and
letters are no problem.
--
Dan Espen
Quadibloc
2021-05-06 07:26:51 UTC
Permalink
Post by Dan Espen
I may not know asterisk, period, etc. from memory but numbers and
letters are no problem.
It's true that &, -, and the digits... and / and the letters... are the
easiest.

I don't know the punctuation marks by heart either, but when you
mentioned the *period* and the *asterisk*, I realized that _those_
would be the easiest to remember of the punctuation marks, since
they're in the top row... I believe . is 12-8-3 and * is 11-8-3, with the
comma being 0-8-3.

12-8-2 would be the cent sign, and 11-8-2 the exclamation mark.

John Savard
Quadibloc
2021-05-06 07:30:17 UTC
Permalink
Post by Quadibloc
Post by Dan Espen
I may not know asterisk, period, etc. from memory but numbers and
letters are no problem.
It's true that &, -, and the digits... and / and the letters... are the
easiest.
I don't know the punctuation marks by heart either, but when you
mentioned the *period* and the *asterisk*, I realized that _those_
would be the easiest to remember of the punctuation marks, since
they're in the top row... I believe . is 12-8-3 and * is 11-8-3, with the
comma being 0-8-3.
12-8-2 would be the cent sign, and 11-8-2 the exclamation mark.
I went and looked it up; my memory was good, but not perfect.

11-8-3 is actually $, with 11-8-4 being the asterisk.

Of course, in other versions of the punched card code, 12 by
itself is + instead of &, and 12-8-2 (or 12-0) is ? instead of the
cent sign.

John Savard
Ahem A Rivet's Shot
2021-05-03 16:19:07 UTC
Permalink
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
--
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/
Dan Espen
2021-05-03 18:26:19 UTC
Permalink
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
--
Dan Espen
Ahem A Rivet's Shot
2021-05-03 18:42:16 UTC
Permalink
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
--
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/
Anne & Lynn Wheeler
2021-05-03 19:19:33 UTC
Permalink
Post by Ahem A Rivet's Shot
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
long ago and far away I had learned to read punch holes ... all ebcdic
combinations as well as alpha/numeric equivalence, but now lost in mists
of time. fan assembly output TXT deck looking for card with program
displacement and then (026) duplicate card ... multi-punching patch into
the duped card.

after two semester hr intro to fortran/computers ... got student job to
reimplement 1401 MPIO (tape<->unit record, i.e. unit record front end
for 709) in 360 assembler (360/30 temporary replaces 1401 on way to
upgrading 709/1401 to 360/67). univ. shutdown datacenter from 8am sat
until 8am mon and I could have the whole place to myself for 48hrs
straight (360/30 as my personal computer). I got to design & implement
my own monitor, device drivers, interrupt handlers, error recovery,
storage management, etc.

After a couple months, I had 2000 card assembler program ... with
conditional assembly ... 1) stand-alone (loaded with BPS loader) or 2)
run under os/360. stand-alone took 30mins to assemble (on 360/30)
... os/360 version took an hr to assemble; >5min per DCB macro (you
could see it hit the DCB macros by pattern in the front panel lights). I
could frequently do multi-punch patches much faster than re-assemble.
--
virtualization experience starting Jan1968, online at home since Mar1970
Anne & Lynn Wheeler
2021-05-03 23:38:12 UTC
Permalink
I did quick&dirty conversion of the (internal) "gcard ios3270" dated
1986, to html, that was started from gx20-1850-3 (1976) ... but doesn't
have the punch card information
http://www.garlic.com/~lynn/gcard.html

gx20-1703 (-7 & -9) pdf image at bitsavers
http://bitsavers.org/pdf/ibm/360/referenceCard/
also -9 at wayback machine in lots of formats
https://archive.org/details/bitsavers_ibm360refeystem360ReferenceData_662124

i still remember "12-2-9" since that is '02'x in column one of
output deck of assemblers and compilers ... followed by type. two decade
old alt.folklore.computers & bit.listserv.ibm-main posts about format
http://www.garlic.com/~lynn/2001.html#14
http://www.garlic.com/~lynn/2001.html#8
--
virtualization experience starting Jan1968, online at home since Mar1970
Anne & Lynn Wheeler
2021-05-05 03:45:07 UTC
Permalink
Post by Anne & Lynn Wheeler
after two semester hr intro to fortran/computers ... got student job to
reimplement 1401 MPIO (tape<->unit record, i.e. unit record front end
for 709) in 360 assembler (360/30 temporary replaces 1401 on way to
upgrading 709/1401 to 360/67). univ. shutdown datacenter from 8am sat
until 8am mon and I could have the whole place to myself for 48hrs
straight (360/30 as my personal computer). I got to design & implement
my own monitor, device drivers, interrupt handlers, error recovery,
storage management, etc.
one of the things I fairly quickly learned coming in 8am sat morning,
was to clean all the tape drives, and then take the 2540 printer/punch
apart and clean it ... clean 1403, etc.

the other issue was sometimes datacenter operations finished early
and when I came in at 8am, everything was dark and powered off. sometimes
trying to power on 360/30, it wouldn't come up. thru trial and error,
i learned to put all the control units into ce mode ... power them
on individual, power on the 360/30 and then take each controller out
of ce mode.

other drift; mit lincoln labs was 1st installation (after science
center) for installation of cp67 (univ. where i was responsible for
systems was next after lincoln labs). Lincoln labs had done their own
360 monitor with lots of functions (including unit record<->tape) as
LLMPS ... and made it available via SHARE program library
https://en.wikipedia.org/wiki/SHARE_(computing)

Most installations getting 360/67 for tss/360 just fell back to using it
as 360/65 with os/360. However both Stanford and Univ. of Michigan wrote
their own virtual memory operating systems (for 360/67). UM started off
by scaffolding MTS off the LLMPS monitor.

Some information about LLMPS
http://archive.michigan-terminal-system.org/discussions/anecdotes-comments-observations/8-1someinformationaboutllmps
Did anything of LLMPS remain as part of UMMPS?
http://archive.michigan-terminal-system.org/discussions/anecdotes-comments-observations/8didanythingofllmpsremainaspartofummps

other MTS refs:
http://archive.michigan-terminal-system.org/
http://archive.michigan-terminal-system.org/documentation
http://archive.michigan-terminal-system.org/myths
https://en.wikipedia.org/wiki/Michigan_Terminal_System
http://www.eecis.udel.edu/~mills/gallery/gallery7.html
http://www.eecis.udel.edu/~mills/gallery/gallery8.html
http://mtswiki.westwood-tech.com/mtswiki-index.php
--
virtualization experience starting Jan1968, online at home since Mar1970
Dan Espen
2021-05-03 20:36:52 UTC
Permalink
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
I didn't learn by using a hand punch. It was the first thing I had to
learn when I went to programming school. I remember very clearly, took
my first class, memorized the codes, went home had my wife drill me on
it.

Mostly the cards I dealt with were interpreted but sometimes you'd need
to patch an object deck and you'd be reading uninterpreted cards.

I remember once I was trying to find a problem and the character
printed on the card was correct but the punch was wrong.
--
Dan Espen
Charlie Gibbs
2021-05-03 23:18:31 UTC
Permalink
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
I can still do alphanumerics and a handful of special characters.
Plus oddballs like 12-0-1-8-9 (X'00').
Post by Dan Espen
Post by Ahem A Rivet's Shot
Post by Dan Espen
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
When we got a hand punch I attached a note to it:
"Programmers have priority on this punch!"
Post by Dan Espen
I didn't learn by using a hand punch. It was the first thing I had to
learn when I went to programming school. I remember very clearly, took
my first class, memorized the codes, went home had my wife drill me on
it.
Mostly the cards I dealt with were interpreted but sometimes you'd need
to patch an object deck and you'd be reading uninterpreted cards.
I remember once I was trying to find a problem and the character
printed on the card was correct but the punch was wrong.
When we converted a customer from a Univac 9300 (which didn't throw data
exceptions on invalid packed decimal digits) to a 90/30 (which did), we
had to track down a scary number of mispunched cards. Something I could
never understand is why the IBM 029 had the vertical bar as shift-Y,
right next to the numeral 1, which was shift-U. A slight overreach and
you got a typo which a quick scan of an interpreted card would miss.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Scott Lurndal
2021-05-04 00:01:20 UTC
Permalink
Post by Charlie Gibbs
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
I can still do alphanumerics and a handful of special characters.
Plus oddballs like 12-0-1-8-9 (X'00').
On the Burroughs systems, control cards were marked with an invalid
punch in column 1. Typically we'd use 1-2-3. The read I/O request
would return with an invalid punch result-descriptor and the OS would
treat the card as a control card and execute it. When printed, the
first column would be printed as ?.

?COMPILE FRED WITH BPL LIB MEM + 60
?DATA CARD
FRED:
BEGIN
STOP;
END.
?END
Peter Flass
2021-05-04 01:38:35 UTC
Permalink
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
I didn't learn by using a hand punch. It was the first thing I had to
learn when I went to programming school. I remember very clearly, took
my first class, memorized the codes, went home had my wife drill me on
it.
Mostly the cards I dealt with were interpreted but sometimes you'd need
to patch an object deck and you'd be reading uninterpreted cards.
I remember once I was trying to find a problem and the character
printed on the card was correct but the punch was wrong.
I remember one shop where the keypunch available to programmers was an 026
without the print feature.
--
Pete
Dan Espen
2021-05-04 02:27:53 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
I didn't learn by using a hand punch. It was the first thing I had to
learn when I went to programming school. I remember very clearly, took
my first class, memorized the codes, went home had my wife drill me on
it.
Mostly the cards I dealt with were interpreted but sometimes you'd need
to patch an object deck and you'd be reading uninterpreted cards.
I remember once I was trying to find a problem and the character
printed on the card was correct but the punch was wrong.
I remember one shop where the keypunch available to programmers was an 026
without the print feature.
That's just mean.
I remember being told to use the 519? (EAM equipment that could print a
maximum of 60 characters on a card, not aligned with the columns).
That was junk too.

Stuff like that would get me working weekends, nights.
--
Dan Espen
Robin Vowels
2021-05-04 03:05:12 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
I didn't learn by using a hand punch. It was the first thing I had to
learn when I went to programming school. I remember very clearly, took
my first class, memorized the codes, went home had my wife drill me on
it.
Mostly the cards I dealt with were interpreted but sometimes you'd need
to patch an object deck and you'd be reading uninterpreted cards.
I remember once I was trying to find a problem and the character
printed on the card was correct but the punch was wrong.
I remember one shop where the keypunch available to programmers was an 026
without the print feature.
That's just mean.
I remember being told to use the 519? (EAM equipment that could print a
maximum of 60 characters on a card, not aligned with the columns).
That was junk too.
.
We had to get up before midnight .....
.
In those days, some used a portable hand punch,
to punch binary of all 12 rows at once.
Charlie Gibbs
2021-05-04 17:49:18 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Mostly the cards I dealt with were interpreted but sometimes you'd need
to patch an object deck and you'd be reading uninterpreted cards.
I remember once I was trying to find a problem and the character
printed on the card was correct but the punch was wrong.
I remember one shop where the keypunch available to programmers was an 026
without the print feature.
When I was at university they were in the process of transitioning
from a 7044 to a 360/67. Since the card codes were different for the
two machines, there were two groups of keypunches in the student area.
The 7044 was being used less and less, so there were always lineups
for the 360-coded keypunches while the 7044 punches stood empty.
I quickly figured out that the correspondence between the keyboard
and the holes punched in the cards was the same for both punches,
so I disregarded the markings on the keycaps and touch-typed what
I needed on a 7044 punch rather than waiting for a 360 punch.
Special characters were printed wrong on the card, but that was
less of inconvenience than waiting in line for a punch. (Some
of the 7044 punches were 029s - for the 026s I got good at using
the multi-punch key to get the unsupported characters.)

The other way I managed to quickly get access to a keypunch was by
learning to clear a jammed unit. There was almost always one or
two units out of service. Not having a card saw, I would tear a
card in half lengthwise, feed it under the punch head, trip the
interlocks, and punch a bunch of stuff while moving the card
around. It worked a treat, and not only did I immediately get
a punch to use, but it was left available for others.

Since I quickly got into the use of program cards, another problem
was a malfunction in the unit that read the drum. This was usually
caused by people not bothering to raise the star wheels before
jamming the drum into position. I'd have to open the back and
retrieve the star wheels that had been knocked off, and set them
back into position before I could use the punch.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Robin Vowels
2021-05-04 02:56:57 UTC
Permalink
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
Ahem A Rivet's Shot
2021-05-04 06:23:57 UTC
Permalink
On Mon, 3 May 2021 19:56:57 -0700 (PDT)
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
Like I said, more than forty years ago I would have told you
instantly.
--
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/
Dan Espen
2021-05-04 11:18:25 UTC
Permalink
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
Beats me. Where is the "+" row on a card?
Last time I looked the rows were numbered 12, 11, 0 - 9.
--
Dan Espen
Scott Lurndal
2021-05-04 14:13:21 UTC
Permalink
Post by Dan Espen
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
Beats me. Where is the "+" row on a card?
Last time I looked the rows were numbered 12, 11, 0 - 9.
You are responding to Rod Speed, Dan. 'nuf said.
Dan Espen
2021-05-04 16:10:53 UTC
Permalink
Post by Scott Lurndal
Post by Dan Espen
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
Beats me. Where is the "+" row on a card?
Last time I looked the rows were numbered 12, 11, 0 - 9.
You are responding to Rod Speed, Dan. 'nuf said.
I'm guessing you're right, but this one seems a little off.
Probably meant 12 6 8 which would be EBCDIC +.
--
Dan Espen
Robin Vowels
2021-05-04 23:53:56 UTC
Permalink
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
.
Beats me. Where is the "+" row on a card?
.
It's the top row.
.
Last time I looked the rows were numbered 12, 11, 0 - 9.
.
Alternative numberings were Y-X-0...9
and + - 0...9
Dan Espen
2021-05-05 00:35:22 UTC
Permalink
Post by Robin Vowels
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
.
Beats me. Where is the "+" row on a card?
.
It's the top row.
.
Last time I looked the rows were numbered 12, 11, 0 - 9.
.
Alternative numberings were Y-X-0...9
and + - 0...9
Interesting, neither rings any bells.
--
Dan Espen
Charlie Gibbs
2021-05-04 17:49:18 UTC
Permalink
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
OK, what's +-6-8 ?
That depends. It sounds like you're using a BCD-encoded punch.
On an EBCDIC punch that would be &-6-8.

Or we could be ecumenical and call it 12-6-8.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Scott Lurndal
2021-05-04 17:56:54 UTC
Permalink
Post by Charlie Gibbs
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
OK, what's +-6-8 ?
That depends. It sounds like you're using a BCD-encoded punch.
On an EBCDIC punch that would be &-6-8.
Or we could be ecumenical and call it 12-6-8.
Although most charts list in descending order, so 12-8-6
would be canonical. (12-8-6 is EBCDIC plus (+)).
Robin Vowels
2021-05-05 00:00:43 UTC
Permalink
Post by Scott Lurndal
Post by Robin Vowels
Post by Ahem A Rivet's Shot
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
OK, what's +-6-8 ?
That depends. It sounds like you're using a BCD-encoded punch.
On an EBCDIC punch that would be &-6-8.
Or we could be ecumenical and call it 12-6-8.
Although most charts list in descending order, so 12-8-6
would be canonical. (12-8-6 is EBCDIC plus (+)).
.
In earlier systems, plus (+) was the Y-row (or 12-row),
and minus was the X-row (or 11-row).
These were convenient to punch with the manual keypunches,
using one finger for + - and all the digits.
Louis Krupp
2021-05-05 03:47:53 UTC
Permalink
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
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.

Louis
Kerr-Mudd, John
2021-05-05 10:31:16 UTC
Permalink
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined!
(fails to provide a link to a pdf from Bitsavers of a yellow card)
--
Bah, and indeed Humbug.
Scott Lurndal
2021-05-05 13:44:58 UTC
Permalink
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined!
(fails to provide a link to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded Decimal Interchange Code)
show a valid hollerith encoding for each of the 256 character positions.

e.g. 0x42 is 12-0-9-2
Kerr-Mudd, John
2021-05-05 14:25:26 UTC
Permalink
On Wed, 05 May 2021 13:44:58 GMT
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined!
(fails to provide a link to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded Decimal Interchange Code)
show a valid hollerith encoding for each of the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, for data, but EBCDIC didn't allocate all the funny characters like MS did to 8bit ASCII.
--
Bah, and indeed Humbug.
Niklas Karlsson
2021-05-05 17:05:45 UTC
Permalink
Post by Kerr-Mudd, John
On Wed, 05 May 2021 13:44:58 GMT
Post by Scott Lurndal
e.g. 0x42 is 12-0-9-2
Sure, for data, but EBCDIC didn't allocate all the funny characters like MS did to 8bit ASCII.
Wasn't 8-bit ASCII originally an IBMism, for the PC?

Niklas
--
"The best way to get something to compile on Linux is to find something
that was not developed by Linux developers." -- Graham Reed
J. Clarke
2021-05-05 19:15:40 UTC
Permalink
Post by Niklas Karlsson
Post by Kerr-Mudd, John
On Wed, 05 May 2021 13:44:58 GMT
Post by Scott Lurndal
e.g. 0x42 is 12-0-9-2
Sure, for data, but EBCDIC didn't allocate all the funny characters like MS did to 8bit ASCII.
Wasn't 8-bit ASCII originally an IBMism, for the PC?
The significance of the upper characters was not standardized. The
original IBM PC printer was made by Epson--you could buy the same
hardware under the Epson brand for less. However people who did that
were often dismayed to find that what was on screen on the PC did not
print properly on the Epson-brand printer because of the different
upper character set.
Ahem A Rivet's Shot
2021-05-05 20:04:22 UTC
Permalink
On Wed, 05 May 2021 15:15:40 -0400
Post by J. Clarke
The significance of the upper characters was not standardized.
Oh it was, just in a great many ways -IBM CP-nnn, Microsoft
Win-nnnn, ISO8859-* and probably a few more.
--
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/
Charlie Gibbs
2021-05-05 21:21:03 UTC
Permalink
Post by Ahem A Rivet's Shot
On Wed, 05 May 2021 15:15:40 -0400
Post by J. Clarke
The significance of the upper characters was not standardized.
Oh it was, just in a great many ways -IBM CP-nnn, Microsoft
Win-nnnn, ISO8859-* and probably a few more.
"The nice thing about standards is that there are so many to
choose from." -- various

But getting back to cards, the correspondence between holes
and bits in a byte was fortunately pretty well standardized.
At least for EBCDIC gear.

The Univac 9300, although an EBCDIC machine, used its own internal
mapping between holes and bits - EBCDIC has enough irregularities
that it would have taken too much expensive electronics to do the
translation. So Univac came up with "compressed code",
which worked like this:

Row
xxxx xxxx
|||| |||`-- 12
|||| ||`--- 11
|||| |`---- 0
|||| `----- 8
|```------- 1-7
`---------- 9

Punches in rows 1 through 7 correspond to the following bits:

Row Bits
1 011
2 101
3 001
4 010
5 100
6 111
7 110

(Don't ask me why it's not straight binary - maybe someone
figured that this would give a better distribution of holes.)

If there was more than one punch in rows 1 through 7, the
resulting patterns were ORed together. (Univac left out
validity checking, again to save hardware.)

It was standard to link the supplied translation tables with
your program to convert between EBCDIC and compressed code.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Scott Lurndal
2021-05-05 19:30:58 UTC
Permalink
Post by Niklas Karlsson
Post by Kerr-Mudd, John
On Wed, 05 May 2021 13:44:58 GMT
Post by Scott Lurndal
e.g. 0x42 is 12-0-9-2
Sure, for data, but EBCDIC didn't allocate all the funny characters like MS did to 8bit ASCII.
Wasn't 8-bit ASCII originally an IBMism, for the PC?
No, ANSI had an 8-bit ASCII spec in the mid 70's.
Niklas Karlsson
2021-05-06 11:40:03 UTC
Permalink
Post by Scott Lurndal
Post by Niklas Karlsson
Post by Kerr-Mudd, John
Sure, for data, but EBCDIC didn't allocate all the funny characters like MS did to 8bit ASCII.
Wasn't 8-bit ASCII originally an IBMism, for the PC?
No, ANSI had an 8-bit ASCII spec in the mid 70's.
Okay. Was that the same as used by the IBM PC? I remember it handling
funny letters like our åäö, well before standards like ISO 8859-1, let
alone Unicode.

Niklas
--
All isotopes of Pentium are intrinsically rather unstable: doomed
by their short half-lives to one day decay, emit two Bogons, and
revert to the vastly more-inert '286' ground-state.
-- Tanuki in asr
Quadibloc
2021-05-08 23:00:57 UTC
Permalink
Post by Niklas Karlsson
Post by Scott Lurndal
Post by Niklas Karlsson
Wasn't 8-bit ASCII originally an IBMism, for the PC?
No, ANSI had an 8-bit ASCII spec in the mid 70's.
Okay. Was that the same as used by the IBM PC? I remember it handling
funny letters like our åäö, well before standards like ISO 8859-1, let
alone Unicode.
What I remember is that the Commodore Amiga, when it came out,
used a preliminary version of ISO 8859-1, where the multiplication and
division signs weren't yet defined.

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".

However, the IBM PC - and, indeed, lots of other computers - defined
extra graphics characters to turn ASCII into an 8-bit code. Also,
the Lawrence Livermore Laboratories defined an 8-bit version of
ASCII for their terminals; there was even an article about it in Datamation.

Perhaps even more relevant, there was a Japanese standard which
defined 64 additional characters for an 8-bit version of ASCII so as to
allow the use of Japanese kana characters on computer systems.
Before ISO 8859-1, that's the only 8-bit 'ASCII that I know of that could
really have been called a standard.

The IBM PC's original 8-bit extended ASCII was IBM's own invention.

John Savard
Ahem A Rivet's Shot
2021-05-08 23:57:55 UTC
Permalink
On Sat, 8 May 2021 16:00:57 -0700 (PDT)
Post by Quadibloc
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/
Quadibloc
2021-05-09 02:03:13 UTC
Permalink
Post by Ahem A Rivet's Shot
On Sat, 8 May 2021 16:00:57 -0700 (PDT)
Post by Quadibloc
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
Lawrence Statton (NK1G)
2021-05-06 21:20:10 UTC
Permalink
Post by Scott Lurndal
Post by Niklas Karlsson
Post by Kerr-Mudd, John
On Wed, 05 May 2021 13:44:58 GMT
Post by Scott Lurndal
e.g. 0x42 is 12-0-9-2
Sure, for data, but EBCDIC didn't allocate all the funny characters
like MS did to 8bit ASCII.
Wasn't 8-bit ASCII originally an IBMism, for the PC?
No, ANSI had an 8-bit ASCII spec in the mid 70's.
I am skeptical of an uncited reference to an 8-bit extension to ASCII.

All of the pre-IBM-PC microcomputer vendors had their own idea of "what
to do with high-bit-set characters" with literally zero comatibility.

Many national standards bodies came up with things to do with
code-points 128-255, extending ASCII to support other languages.

Some DEC terminals came with an extended character set, whose name I
suddenly can't remember, whose code-points mostly became (via a couple
of intermediate standards bodies) ISO-8859-1.

For all the bitching and moaning and foot-dragging, given that TWIAVBP,
eight-bits are simply nowhere near enough for human languages. That UTF-8
magically squeezes Unicode's 21-bit characters into an octet-stream that
for a huge volume of text is indistinguishable from ASCII is a Very
Clever and Needful Hack.

echo '***@abaluon.abaom' | sed s/aba/c/g
Scott Lurndal
2021-05-06 21:56:08 UTC
Permalink
Post by Lawrence Statton (NK1G)
Post by Scott Lurndal
Post by Niklas Karlsson
Post by Kerr-Mudd, John
On Wed, 05 May 2021 13:44:58 GMT
Post by Scott Lurndal
e.g. 0x42 is 12-0-9-2
Sure, for data, but EBCDIC didn't allocate all the funny characters
like MS did to 8bit ASCII.
Wasn't 8-bit ASCII originally an IBMism, for the PC?
No, ANSI had an 8-bit ASCII spec in the mid 70's.
I am skeptical of an uncited reference to an 8-bit extension to ASCII.
Well, I have the paper standard out in the storage unit. I'll try to
locate it this weekend.
dave somename
2021-05-07 01:26:33 UTC
Permalink
Post by Lawrence Statton (NK1G)
Some DEC terminals came with an extended character set, whose name I
suddenly can't remember, whose code-points mostly became (via a couple
of intermediate standards bodies) ISO-8859-1.
DEC standard 169.
Dan Espen
2021-05-05 14:45:36 UTC
Permalink
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
--
Dan Espen
Charlie Gibbs
2021-05-05 16:00:39 UTC
Permalink
Post by Dan Espen
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
Even worse, some defined characters (e.g. vertical bar and exclamation
mark) suffered what could only be described as entropy.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Niklas Karlsson
2021-05-05 17:04:40 UTC
Permalink
Post by Charlie Gibbs
Post by Dan Espen
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
Even worse, some defined characters (e.g. vertical bar and exclamation
mark) suffered what could only be described as entropy.
Explain?

Niklas
--
Kids have it easy today. All they have to listen to is stories about
how back in the '70s we had to listen to stories about how bad it was
back in the '30s. --Keith Lynch
Charlie Gibbs
2021-05-05 20:34:59 UTC
Permalink
Post by Niklas Karlsson
Post by Charlie Gibbs
Post by Dan Espen
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
Even worse, some defined characters (e.g. vertical bar and exclamation
mark) suffered what could only be described as entropy.
Explain?
Hex 5A was the original exclamation mark in EBCDIC. Some of the
later Univac printers I worked with started mixing it up with the
vertical bar (hex 4F). There were probably other irregulatiries,
but that one was the worst.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Charlie Gibbs
2021-05-05 21:23:17 UTC
Permalink
Post by Charlie Gibbs
Hex 5A was the original exclamation mark in EBCDIC. Some of the
later Univac printers I worked with started mixing it up with the
vertical bar (hex 4F). There were probably other irregulatiries,
^^^^^^^^^^^^^^
Post by Charlie Gibbs
but that one was the worst.
Not to mention irregular spelling. :-)
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <***@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
Scott Lurndal
2021-05-05 16:08:38 UTC
Permalink
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
Dan Espen
2021-05-05 17:50:46 UTC
Permalink
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
--
Dan Espen
Scott Lurndal
2021-05-05 19:31:50 UTC
Permalink
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
That would have been an implementation choice by whoever developed
the Z/OS FTP utilities.
Dan Espen
2021-05-06 02:42:11 UTC
Permalink
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
That would have been an implementation choice by whoever developed
the Z/OS FTP utilities.
That's the point. They had a choice to make and they made a bad one.
They probably had a meeting. The worst decisions come out of meetings.
--
Dan Espen
Peter Flass
2021-05-06 20:43:01 UTC
Permalink
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
That would have been an implementation choice by whoever developed
the Z/OS FTP utilities.
That's the point. They had a choice to make and they made a bad one.
They probably had a meeting. The worst decisions come out of meetings.
From a brief glance at the doc, i think you nan specify the codepage used
to do the transfer.
--
Pete
Dan Espen
2021-05-06 22:07:55 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
That would have been an implementation choice by whoever developed
the Z/OS FTP utilities.
That's the point. They had a choice to make and they made a bad one.
They probably had a meeting. The worst decisions come out of meetings.
From a brief glance at the doc, i think you nan specify the codepage used
to do the transfer.
Yes, by specifying the code page, you get different translations.
I couldn't find any code page that preserved all the
characters I cared about. What bugged me is that all the code pages
would convert characters with no corresponding character to a null.
All IBM had to go is translate all the "unknown" characters to unique
values and then a user could fix them as desired.
--
Dan Espen
Peter Flass
2021-05-07 17:24:08 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
That would have been an implementation choice by whoever developed
the Z/OS FTP utilities.
That's the point. They had a choice to make and they made a bad one.
They probably had a meeting. The worst decisions come out of meetings.
From a brief glance at the doc, i think you nan specify the codepage used
to do the transfer.
Yes, by specifying the code page, you get different translations.
I couldn't find any code page that preserved all the
characters I cared about. What bugged me is that all the code pages
would convert characters with no corresponding character to a null.
All IBM had to go is translate all the "unknown" characters to unique
values and then a user could fix them as desired.
I couldn’t figure out whether you could use other than the IBM-supplied
code pages.
--
Pete
Dan Espen
2021-05-07 18:11:48 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Peter Flass
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
I know there's no universal translation but IMO there's no excuse for
FTP converting all the unknown characters to the same binary value
(nulls if I recall). It makes recovery on the receiving end impossible.
That would have been an implementation choice by whoever developed
the Z/OS FTP utilities.
That's the point. They had a choice to make and they made a bad one.
They probably had a meeting. The worst decisions come out of meetings.
From a brief glance at the doc, i think you nan specify the codepage used
to do the transfer.
Yes, by specifying the code page, you get different translations.
I couldn't find any code page that preserved all the
characters I cared about. What bugged me is that all the code pages
would convert characters with no corresponding character to a null.
All IBM had to go is translate all the "unknown" characters to unique
values and then a user could fix them as desired.
I couldn’t figure out whether you could use other than the IBM-supplied
code pages.
I don't exactly remember how I solved the problem.
My first thought was to create my own translate table.
I don't think that was allowed.

Okay now I remember, I had a bunch of panels with binary codes in them
because I ran out of plain characters for field delimiters. So in panels
you can declare the delimiter as 01 in the type line but then you put a
hex 01 in the panel definition. I had to change all the panels to use
things that weren't destroyed by FTP.
--
Dan Espen
Peter Flass
2021-05-05 22:46:29 UTC
Permalink
Post by Scott Lurndal
Post by Dan Espen
Post by Scott Lurndal
Post by Kerr-Mudd, John
On Tue, 4 May 2021 21:47:53 -0600
Post by Louis Krupp
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over
the scans, to one person (Christian C., liest Du hier mit? :-)
claiming to be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
. OK, what's +-6-8 ?
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.
Louis
WIWAL there weren't 256 characters defined! (fails to provide a link
to a pdf from Bitsavers of a yellow card)
My Burroughs yellow card (B2000/B3000/B4000 Extended Binary Coded
Decimal Interchange Code) show a valid hollerith encoding for each of
the 256 character positions.
e.g. 0x42 is 12-0-9-2
Sure, the IBM card is the same way, you can punch any of the 256 values.
But IBM didn't assign characters to all the positions. A big mistake in
my opinion. To this day, when you ftp data from a mainframe with
ebcdic-ascii translation, you're going to lose some data because IBM
didn't assign characters to all the positions and didn't have the
imagination to pick arbitrary, unique values.
The Burroughs and IBM EBCDIC mapping had some minor differences (mostly
in the control characters, but some graphics as well (e.g. the not symbol)),
so there isn't a universal EBCDIC <-> ASCII translation.
Plus all the national variants of EBCDIC. when I was writing code to
transfer data I used EBCDIC codepage 1040 and ASCII 8859 IIRC), which have
a one-one mapping.
--
Pete
Anne & Lynn Wheeler
2021-05-05 19:13:55 UTC
Permalink
Post by Dan Espen
Sure, the IBM card is the same way, you can punch any of the 256
values. But IBM didn't assign characters to all the positions. A big
mistake in my opinion. To this day, when you ftp data from a
mainframe with ebcdic-ascii translation, you're going to lose some
data because IBM didn't assign characters to all the positions and
didn't have the imagination to pick arbitrary, unique values.
trivia: CP67 as delivered to univ had terminal support for 1052 & 2741
... including being able to automagically doing terminal type on each
line/port (by using terminal controller "SAD" CCW to switch terminal
type line scanner type for the line and seeing what data worked and what
didn't). Univ. had some number of TTY33s ... so I had to add ASCII TTY
support, translate tables between ASCII<->EBCDIC and also extended the
automagic terminal type identification to TTY.

I then wanted to extend automagic terminal type to dial-up ... being
able to have single dialup number for all terminals ... single "hunt
group" dial-in number
https://en.wikipedia.org/wiki/Line_hunting

it almost worked ... except overlooked that IBM had taken short-cut in
the terminal controllers and while the terminal type line scanner could
be switched for every line, line speed was hard wired (tty line speed
different from 1052&2741). This was somewhat motivation for univ. to
start its own clone terminal controller project, build a channel
interface board for Interdata/3 programmed to emulate IBM terminal
controller ... with the addition it could do automagic terminal line
speed.

One of the first testing bugs was IBM channel had max. duration that
each controller could hold the channel (& memory bus). 360/67 had high
speed clock that updated storage location 80 every 13microseconds. If
clock went to update memory with timer tic and a previous timer tic
memory update was still pending, it would "red light" and the processor
stop. Channel interface board had to make sure it released the channel
interface (and memory bus) at least once every time tic interval.

The next was overlooked that IBM terminal controllers was doing
bit-reversed ascii ... leading bit went in the byte low order bit
position ... so every ascii character arriving in memory was bit
reversed pattern (and similarly on transmission) ... and IBM translate
tables had to handle the byte bit-reversed convention (note that IBM
"selectric" terminals didn't actually do EBCDIC ... they did tilt-rotate
code to select position on the selectric typeball, so had to do
EBCDIC<->tilt/rotate ... and account for the byte bit-reversed
convention).

I also had to somewhat arbritarily select mappings between EBCDIC
characters that weren't in ASCII ... especially for CMS line-editing
cent-sign. at-sign, "@" was "character-delete" , lower-case on far right
of keyboard; "line-delete" was cent-sign, upper case on the same key,
but no ascii equivalent. TTY had left&right bracket on same key at same
keyboard location ... so guess what I choose?

Interdata (later Perkin-Elmer) were selling the boxes as IBM clone
controller and four of us get written up as responsible for (some part
of) the IBM clone controller business.

When I was doing the TTY code ... I played some games with one byte
length values (even tho they were two byte fields). Later Van Vleck
https://www.multicians.org/thvv/
was supporting CP67/CMS system at the MIT Urban Systems lab (USL)
and he patched the max. ASCII line length to 1200(?), I think
for ascii plotter device done at Harvard ... which the one
byte stuff resulted in wrong length calculation which overran
the buffer and crashed CP/67 27times in single day.
https://www.multicians.org/thvv/360-67.html

trivia: IBM Science Center (& Multics/project mac) were in 545 tech sq,
USL was in tech square bldg on the opposite side of the quad ... and
Land's two story Polaroid bldg was on the street side between the two
bldgs (science center offices on the 4th flr overlooked Land's balcony
... one day we watched Land taking pictures of a model with the
unannounced SX-70).

other trivia: IBM later would have had to have two different
EBCDIC<->ASCII translate tables ... one for terminals with bit-reversed
ASCII (terminal controller) convention and another for straight ASCII.
--
virtualization experience starting Jan1968, online at home since Mar1970
Peter Flass
2021-05-05 22:46:30 UTC
Permalink
Post by Anne & Lynn Wheeler
The next was overlooked that IBM terminal controllers was doing
bit-reversed ascii ... leading bit went in the byte low order bit
position ... so every ascii character arriving in memory was bit
reversed pattern (and similarly on transmission) ... and IBM translate
tables had to handle the byte bit-reversed convention (note that IBM
"selectric" terminals didn't actually do EBCDIC ... they did tilt-rotate
code to select position on the selectric typeball, so had to do
EBCDIC<->tilt/rotate ... and account for the byte bit-reversed
convention).
This brings back unpleasant memories. For some reason I was working with
TTY support in CICS and spent a lot of time trying to wrap,my mind around
what was going on. At this remove I’ve forgotten what I was trying to do,
but CICS support for TTYs was poor to nonexistent.
--
Pete
Christian Brunschen
2021-05-05 18:07:00 UTC
Permalink
In article <***@127.0.0.1>,
Kerr-Mudd, John <***@127.0.0.1> wrote:

[ much snippage ]
Post by Kerr-Mudd, John
WIWAL there weren't 256 characters defined!
(fails to provide a link to a pdf from Bitsavers of a yellow card)
Well, there's the ECMA-44 standard that does, in fact, describe how to
represent 256 characters on punched cards:

https://www.ecma-international.org/wp-content/uploads/ECMA-44_1st_edition_september_1975.pdf

// Christian
Scott Lurndal
2021-05-05 13:42:42 UTC
Permalink
Post by Louis Krupp
Post by Robin Vowels
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 14:26:19 -0400
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the
scans, to one person (Christian C., liest Du hier mit? :-) claiming to
be able to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Oh sure anyone can look it up, I meant from memory as a result of
using the hand punch rather than wait for an 029.
.
OK, what's +-6-8 ?
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.
My Burroughs V-series simulator supports the Card Reader DLP binary read
variant (albeit from a simh hollerith format input file...)
Anne & Lynn Wheeler
2021-05-05 17:44:44 UTC
Permalink
Post by Louis Krupp
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.bobbemer.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 ...
--
virtualization experience starting Jan1968, online at home since Mar1970
Robin Vowels
2021-05-13 13:01:34 UTC
Permalink
Post by Anne & Lynn Wheeler
Post by Louis Krupp
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.bobbemer.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.
Peter Flass
2021-05-13 21:07:01 UTC
Permalink
Post by Robin Vowels
Post by Anne & Lynn Wheeler
Post by Louis Krupp
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.bobbemer.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
Ahem A Rivet's Shot
2021-05-13 21:41:30 UTC
Permalink
On Thu, 13 May 2021 14:07:01 -0700
Post by Peter Flass
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 ?
--
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/
Peter Flass
2021-05-13 22:52:51 UTC
Permalink
Post by Ahem A Rivet's Shot
On Thu, 13 May 2021 14:07:01 -0700
Post by Peter Flass
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
Ahem A Rivet's Shot
2021-05-14 05:55:29 UTC
Permalink
On Thu, 13 May 2021 15:52:51 -0700
Post by Peter Flass
Post by Ahem A Rivet's Shot
On Thu, 13 May 2021 14:07:01 -0700
Post by Peter Flass
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/
Quadibloc
2021-05-14 11:11:10 UTC
Permalink
Post by Ahem A Rivet's Shot
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
J. Clarke
2021-05-14 09:30:29 UTC
Permalink
On Thu, 13 May 2021 15:52:51 -0700, Peter Flass
Post by Peter Flass
Post by Ahem A Rivet's Shot
On Thu, 13 May 2021 14:07:01 -0700
Post by Peter Flass
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.
Quadibloc
2021-05-13 22:52:53 UTC
Permalink
Post by Ahem A Rivet's Shot
On Thu, 13 May 2021 14:07:01 -0700
Post by Peter Flass
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
Quadibloc
2021-05-13 22:55:03 UTC
Permalink
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
Quadibloc
2021-05-14 11:26:41 UTC
Permalink
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
Quadibloc
2021-05-14 11:50:41 UTC
Permalink
Post by Quadibloc
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
Peter Flass
2021-05-14 19:01:25 UTC
Permalink
Post by Quadibloc
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
Scott Lurndal
2021-05-14 22:31:17 UTC
Permalink
Post by Peter Flass
Post by Quadibloc
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.
Peter Flass
2021-05-14 23:15:49 UTC
Permalink
Post by Scott Lurndal
Post by Peter Flass
Post by Quadibloc
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
John Levine
2021-05-15 02:22:06 UTC
Permalink
Post by Peter Flass
Post by Scott Lurndal
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, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Quadibloc
2021-05-15 11:52:01 UTC
Permalink
Post by John Levine
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
Quadibloc
2021-05-15 11:54:29 UTC
Permalink
Post by Quadibloc
the cartridges for the Superbrain
My memory is failing too. The cartridges for the Exidy Sorcerer,
of course, not the Superbrain that was made in imitation of an
ADDS terminal and used ordinary 5 1/4" floppies.

John Savard

Scott Lurndal
2021-05-03 19:43:32 UTC
Permalink
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
The Burroughs reference cards were yellow, generally, although I have
a couple of green ones from the Electrodata 220 days.

Mine is still on my desk - has the EBCDIC mappings and for each
EBCDIC byte, shows the punch sequence (e.g. DLE, EBCDIC 0x10 is 12-11-9-8-1).
Peter Flass
2021-05-04 01:38:35 UTC
Permalink
Post by Scott Lurndal
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
The Burroughs reference cards were yellow, generally, although I have
a couple of green ones from the Electrodata 220 days.
Mine is still on my desk - has the EBCDIC mappings and for each
EBCDIC byte, shows the punch sequence (e.g. DLE, EBCDIC 0x10 is 12-11-9-8-1).
I have a couple, too. EBCDIC I have no problem with, I have to look up lots
of ASCII codes.
--
Pete
Scott Lurndal
2021-05-04 14:12:19 UTC
Permalink
Post by Peter Flass
Post by Scott Lurndal
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
The Burroughs reference cards were yellow, generally, although I have
a couple of green ones from the Electrodata 220 days.
Mine is still on my desk - has the EBCDIC mappings and for each
EBCDIC byte, shows the punch sequence (e.g. DLE, EBCDIC 0x10 is 12-11-9-8-1).
I have a couple, too. EBCDIC I have no problem with, I have to look up lots
of ASCII codes.
My mouse-pad (trade show giveaway from www.keil.com) has an ASCII character
set chart on it :-)
J. Clarke
2021-05-03 21:06:19 UTC
Permalink
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Somewhere here I have (or had at one time) a yellow green card. My
green green card is the bookmark in my Assembler reference at work.
Dan Espen
2021-05-03 21:15:44 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by Ahem A Rivet's Shot
On Mon, 03 May 2021 08:29:22 -0400
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
I used to be able to do that, more than forty years ago.
Any main-framer has a green card (it may not actually be green)
that shows the punch codes.
Somewhere here I have (or had at one time) a yellow green card. My
green green card is the bookmark in my Assembler reference at work.
They're in easy reach. 2 pink pamphlets, 1 yellow pamphlet, one white
reference card.

The multi-page reference card is falling apart.
--
Dan Espen
Dennis Boone
2021-05-03 17:04:39 UTC
Permalink
Post by Andreas Kohlbach
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.


De
Peter Flass
2021-05-04 01:38:34 UTC
Permalink
Post by Andreas Kohlbach
Post by Charlie Gibbs
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
A 1/2-inch tape are punch cards?
In the German folklore usenet group <news:de.alt.folklore.computer> is by
chance (what are the odds! :-) a topic about how to rescue old punch
cards with the subject "Lochkarten lesen". Lochkarte is the German term
for punch cards (or is it punchED cards?), literally "hole card".
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
One problem not solved how to get some 1000 cards scanned
automatically. Scanning 1000 cards manually might otherwise take quite
some time.
The other problem was to know what format the data are, because punch
cards just produce data without declaring any meta-data. In the case of
the German news group the original poster said it was some kind of
spreadsheet, classifying bird, where they live (some kind of latitude and
longitude) and other things.
The thread later deviated into programming languages (FORTRAN) and other
things, and the problem wasn't solved yet.
If someone interested can read and understand German, I mentioned the
usenet group and subject above. I think the thread has well over 300
articles by now. If not, and any working solution to scan and read the
data comes up, I can then post it here.
Someone else will probably reply, but there’s a youtube video of a guy that
built a card reader out of - legos, maybe - it was slow, but it worked.
--
Pete
J. Clarke
2021-05-04 10:02:46 UTC
Permalink
Post by Peter Flass
Post by Andreas Kohlbach
Post by Charlie Gibbs
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
A 1/2-inch tape are punch cards?
In the German folklore usenet group <news:de.alt.folklore.computer> is by
chance (what are the odds! :-) a topic about how to rescue old punch
cards with the subject "Lochkarten lesen". Lochkarte is the German term
for punch cards (or is it punchED cards?), literally "hole card".
Ideas range from scanning them and run some OCR software over the scans,
to one person (Christian C., liest Du hier mit? :-) claiming to be able
to read the cards just by looking at them.
One problem not solved how to get some 1000 cards scanned
automatically. Scanning 1000 cards manually might otherwise take quite
some time.
The other problem was to know what format the data are, because punch
cards just produce data without declaring any meta-data. In the case of
the German news group the original poster said it was some kind of
spreadsheet, classifying bird, where they live (some kind of latitude and
longitude) and other things.
The thread later deviated into programming languages (FORTRAN) and other
things, and the problem wasn't solved yet.
If someone interested can read and understand German, I mentioned the
usenet group and subject above. I think the thread has well over 300
articles by now. If not, and any working solution to scan and read the
data comes up, I can then post it here.
Someone else will probably reply, but there’s a youtube video of a guy that
built a card reader out of - legos, maybe - it was slow, but it worked.
There's this one.
http://youtu.be/LcwxW2ne-UU

With the stuff he had and another servo he could likely have automated
the process.

Note that he's basically scanning the card, he's just using a digital
camera to do it instead of a scanner. I suspect my cell phone could
do for the camera part. A skilled Android programmer could probably
program the phone to orchestrate the whole process.

Hmm. If I every decide that I want to learn Android that might be a
good project--a card reader for the phone--take a picture of a card,
maybe tell it whether it's ASCII or EBCDIC, and it handles the rest.
For extra points handle multiples.

And before you check the play store, card reader apps abound, but they
read business cards, credit cards, loyalty cards and whatnot--didn't
find any that would read the kind of cards we're talking about.
Grant Taylor
2021-05-03 14:50:23 UTC
Permalink
Post by Charlie Gibbs
Is anyone running unit record equipment who wants more blank cards?
I'm not. But if you divide things up, I'd be interested in a small
number (10-100) of them. I think they make great bookmarks.
Post by Charlie Gibbs
While cleaning things out I came across an unopened case of good
old form 5081 (5 boxes at 2000 cards per box). I have a couple more
boxes of blank cards as well. Anyone in the Vancouver, B.C. area who
is interested (or who is elsewhere and are willing to pay shipping)
is welcome to them.
That's just a few.
Post by Charlie Gibbs
I also have lots reels of 1/2-inch tape. Extra points if you have
something that can read them, because there are some files I'd love
to recover.
I need 1/2-inch tape like I need hanging chads.

But I /might/, /want/ some 1/2-inch tape to add to my types of media
collection.

Please email me directly if you are willing to divvy things up if you
don't have anything better to do with them.
--
Grant. . . .
unix || die
Loading...