Discussion:
IBM System/32, System/34 implementation technology?
(too old to reply)
n***@gmail.com
2015-04-28 13:56:04 UTC
Permalink
I know this post is from a very long time ago, but I just came across it this morning.

If any of you worked on System 32 at the IBM location in Rochester, MN, I would love to hear about your experience with the project. My father, Nicholas Mitrofanoff, played a major role in the design of this system, but I don't know very much about it. Over the past few years, I have been searching online for information about the project, but as you may have noticed, very little has been posted.

From what I have gathered, it seems as if System 32 was the first computer that was accessible for small businesses. I would assume, then, that this project made computers available to a multitude more people than had ever had access previously. I may be biased, but I would think that this project should be considered a milestone in computer history.

That being said, I would be honored to hear from anyone who played a part in the creation or design of System 32.
Al Kossow
2015-04-28 14:43:21 UTC
Permalink
Post by n***@gmail.com
From what I have gathered, it seems as if System 32 was the first computer that was accessible for small businesses.
It was an early system that IBM targeted to that market. Other vendors had been in that market for a while.
System 3 was actually the first system out of Rochester.

There is a history of the 3x series in the back of one of the books on S38. I'm blanking on which one right now. I'm
not thinking of "Fortress Rochester"
Peter Flass
2015-04-28 15:33:09 UTC
Permalink
Post by n***@gmail.com
I know this post is from a very long time ago, but I just came across it this morning.
If any of you worked on System 32 at the IBM location in Rochester, MN, I
would love to hear about your experience with the project. My father,
Nicholas Mitrofanoff, played a major role in the design of this system,
but I don't know very much about it. Over the past few years, I have
been searching online for information about the project, but as you may
have noticed, very little has been posted.
From what I have gathered, it seems as if System 32 was the first
computer that was accessible for small businesses.
It was a milestone, but probably there are other candidates for that role.
I would say within the IBM line either the 1130 or the 360/20 fit that
niche also, although it depends on your definition of "small business".

I'd be interested in finding out more about the System 32, good luck with
your search.

I would assume, then, that this project made computers available to a
multitude more people than had ever had access previously. I may be
biased, but I would think that this project should be considered a
milestone in computer history.
Post by n***@gmail.com
That being said, I would be honored to hear from anyone who played a part
in the creation or design of System 32.
--
Pete
Dan Espen
2015-04-28 17:42:22 UTC
Permalink
Post by Peter Flass
Post by n***@gmail.com
I know this post is from a very long time ago, but I just came across it this morning.
If any of you worked on System 32 at the IBM location in Rochester, MN, I
would love to hear about your experience with the project. My father,
Nicholas Mitrofanoff, played a major role in the design of this system,
but I don't know very much about it. Over the past few years, I have
been searching online for information about the project, but as you may
have noticed, very little has been posted.
From what I have gathered, it seems as if System 32 was the first
computer that was accessible for small businesses.
It was a milestone, but probably there are other candidates for that role.
I would say within the IBM line either the 1130 or the 360/20 fit that
niche also, although it depends on your definition of "small business".
I'd be interested in finding out more about the System 32, good luck with
your search.
I would assume, then, that this project made computers available to a
multitude more people than had ever had access previously. I may be
biased, but I would think that this project should be considered a
milestone in computer history.
Post by n***@gmail.com
That being said, I would be honored to hear from anyone who played a part
in the creation or design of System 32.
Most of my experience was System 34.
The 32 was a small system built like a desk.
Each time IBM made a smaller unit, smaller businesses got to get their computer.

There were other small systems from IBM around, like the mod 20 and the
Series 1.

The 32 was smaller and I would guess cheaper than a 20.

I don't know what the story with the System 3x software is.
Lynn has mentioned some relation to the FS project but I think
that showed up first in the 38.

I can say that the System 34 was unlike any IBM software I had
encountered up until then. It was pretty good.
I was particularly surprised by the control language.
I was used to JCL and the CL beat JCL to death for ease of use
and power.
--
Dan Espen
Shmuel (Seymour J.) Metz
2015-04-29 00:26:12 UTC
Permalink
In
<1369579502451927856.999946peter_flass-***@news.eternal-september.org>,
on 04/28/2015
Post by Peter Flass
It was a milestone, but probably there are other candidates for that
role. I would say within the IBM line either the 1130 or the 360/20
fit that niche also, although it depends on your definition of "small
business".
All of 305, 650, 1401, S/1, S/7 were marketted as small business
machines at various times.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to ***@library.lspace.org
John Levine
2015-04-28 16:26:48 UTC
Permalink
Post by n***@gmail.com
From what I have gathered, it seems as if System 32 was the first computer
that was accessible for small businesses.
It was arguably IBM's first computer specifically aimed at small
businesses, but there were plenty of computers from other vendors in
that market. DEC had offerings based on PDP-8 and PDP-11, Data
General had Nova and Supernova systems, and so forth.
h***@bbs.cpcn.com
2015-04-29 01:17:32 UTC
Permalink
Post by John Levine
Post by n***@gmail.com
From what I have gathered, it seems as if System 32 was the first computer
that was accessible for small businesses.
It was arguably IBM's first computer specifically aimed at small
businesses, but there were plenty of computers from other vendors in
that market.
I thought the IBM System/3 was IBM's first computer for small business, and the S/3x series were just later improved models.
Post by John Levine
DEC had offerings based on PDP-8 and PDP-11, Data
General had Nova and Supernova systems, and so forth.
Did a lot of businesses acquire the PDP-8 to do things like payroll and accounting? The DEC PDP-8 brochure says "scientific, engineering, process control, data acquisition, quality control (circuit testing), and educational applications". Not a word about any business applications. The brochure touts the floating point point package and mathematical function routines. It offered FORTRAN but not COBOL. It did not appear to offer disk. The tape at 200 bpi seemed weak for 1965.
Dan Espen
2015-04-29 01:34:07 UTC
Permalink
Post by John Levine
Post by n***@gmail.com
From what I have gathered, it seems as if System 32 was the first computer
that was accessible for small businesses.
It was arguably IBM's first computer specifically aimed at small
businesses, but there were plenty of computers from other vendors in
that market.
I thought the IBM System/3 was IBM's first computer for small
business, and the S/3x series were just later improved models.
That's right.
(Just looked it up.)

Since I never saw or worked on a S/3 my memory of it is poor.
I guess what made the biggest impression at the time
was the 96 character card.

It was normally configured like a S/360 20.
Including another version of the MFCM.
(Very slick card reader/punch which sometimes mangled cards.)

The Wikipedia article mentions that the S/3 used OCL too.
I still wonder why the software on that line was so much
more inspired than on S/360.

I remember reading some technical stuff from IBM for S/34
and the book was full of HIPO charts.
--
Dan Espen
Charles Richmond
2015-04-29 21:05:18 UTC
Permalink
Post by Dan Espen
Post by John Levine
Post by n***@gmail.com
From what I have gathered, it seems as if System 32 was the first computer
that was accessible for small businesses.
It was arguably IBM's first computer specifically aimed at small
businesses, but there were plenty of computers from other vendors in
that market.
I thought the IBM System/3 was IBM's first computer for small
business, and the S/3x series were just later improved models.
That's right.
(Just looked it up.)
Since I never saw or worked on a S/3 my memory of it is poor.
I guess what made the biggest impression at the time
was the 96 character card.
Note that there were three rows of punches on the 96 column cardand the
holes punched were circular. Each character was represented by holes that
encoded the ASCII value of the character... similar to the way paper tape
was punched.

See a picture of the IBM 96 column card here:

http://www.aquaporin4.com/card96/
--
numerist at aquaporin4 dot com
Quadibloc
2015-04-30 00:32:07 UTC
Permalink
Post by Charles Richmond
Note that there were three rows of punches on the 96 column cardand the
holes punched were circular. Each character was represented by holes that
encoded the ASCII value of the character... similar to the way paper tape
was punched.
You're close. The holes encoded the EBCDIC value of the character, with some bits modified so that a space, rather than the null control character, would equal no punches, just like on a regular punched card.

John Savard
Charlie Gibbs
2015-04-30 18:19:16 UTC
Permalink
Post by Quadibloc
Post by Charles Richmond
Note that there were three rows of punches on the 96 column cardand the
holes punched were circular. Each character was represented by holes that
encoded the ASCII value of the character... similar to the way paper tape
was punched.
You're close. The holes encoded the EBCDIC value of the character, with
some bits modified so that a space, rather than the null control character,
would equal no punches, just like on a regular punched card.
<nit>
Since the cards only contained 6 rows per character, it wasn't a complete
EBCDIC coding either, although the low-order 4 bits corresponded exactly.
It was the other two rows, corresponding to the zone bits, that underwent
fiddling similar to what happened with 80-column cards.
</nit>
--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Charles Richmond
2015-04-30 21:10:17 UTC
Permalink
Post by Charlie Gibbs
Post by Quadibloc
Post by Charles Richmond
Note that there were three rows of punches on the 96 column cardand the
holes punched were circular. Each character was represented by holes that
encoded the ASCII value of the character... similar to the way paper tape
was punched.
You're close. The holes encoded the EBCDIC value of the character, with
some bits modified so that a space, rather than the null control character,
would equal no punches, just like on a regular punched card.
<nit>
Since the cards only contained 6 rows per character, it wasn't a complete
EBCDIC coding either, although the low-order 4 bits corresponded exactly.
It was the other two rows, corresponding to the zone bits, that underwent
fiddling similar to what happened with 80-column cards.
</nit>
Hey, Charlie! You're right!!! Somehow I did *not* look closely enough and
thought that all 8 bits were represented on the 96-column card. Hmmm...
That's disappointing!

A cow-orker at a PPoE told me that these 96-column cards were difficult to
get to read correctly. I have *no* experience with them myself, except:
this guy gave me one of the cards as a curiosity. He had a large box of
left-over unpunched 96-column cards that he used as note cards.
--
numerist at aquaporin4 dot com
Charlie Gibbs
2015-05-01 02:42:02 UTC
Permalink
Post by Charles Richmond
Post by Charlie Gibbs
<nit>
Since the cards only contained 6 rows per character, it wasn't a complete
EBCDIC coding either, although the low-order 4 bits corresponded exactly.
It was the other two rows, corresponding to the zone bits, that underwent
fiddling similar to what happened with 80-column cards.
</nit>
Hey, Charlie! You're right!!! Somehow I did *not* look closely enough and
thought that all 8 bits were represented on the 96-column card. Hmmm...
That's disappointing!
As ever, you gotta make compromises when you make things small.
Post by Charles Richmond
A cow-orker at a PPoE told me that these 96-column cards were difficult to
this guy gave me one of the cards as a curiosity. He had a large box of
left-over unpunched 96-column cards that he used as note cards.
I suppose those tiny holes would be quite sensitive to dust build-up in
card readers. Heck, the operators in some of the 80-column shops I worked
in didn't vacuum the card reader and punch until they started getting errors.

I used to tell people, "Here's my card," and hand them a 96-column card
into which I had punched characters such that the holes spelled out MY CARD.
I still have a few around somewhere.
--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
h***@bbs.cpcn.com
2015-05-01 05:17:10 UTC
Permalink
Post by Charles Richmond
A cow-orker at a PPoE told me that these 96-column cards were difficult to
this guy gave me one of the cards as a curiosity. He had a large box of
left-over unpunched 96-column cards that he used as note cards.
Did the System/3 support an 80 column card reader for customers having decks of such cards?

The IBM S/360 says the S/3 was targeted toward the remaining IBM tab machine shops that were too small to cost-justify a S/360.

Would anyone know if the 96 column card was continued onto the System/3x (34, 36, 38) line? I don't think it was.

Bitsavers had manuals on the System/3, including an intro on the low-end machine. IIRC, it wasn't too powerful, almost more like a low-end 1401, serving as a "super tabulator" in a card based environment.
Charles Richmond
2015-04-30 20:21:25 UTC
Permalink
Post by Quadibloc
Post by Charles Richmond
Note that there were three rows of punches on the 96 column cardand the
holes punched were circular. Each character was represented by holes that
encoded the ASCII value of the character... similar to the way paper tape
was punched.
You're close. The holes encoded the EBCDIC value of the character, with
some bits modified so that a space, rather than the null control
character, would equal no punches, just like on a regular punched card.
Oh, yeah... EBCDIC!!! What was I thinking!!! Would you believe that the
first assembly language I learned... was for the IBM 370???

But it *was* a character code that was punched and *not* some odd-ball,
separatedly defined punch code.
--
numerist at aquaporin4 dot com
Quadibloc
2015-04-30 00:32:33 UTC
Permalink
Post by Charles Richmond
Note that there were three rows of punches on the 96 column cardand the
holes punched were circular. Each character was represented by holes that
encoded the ASCII value of the character... similar to the way paper tape
was punched.
You're close. The holes encoded the EBCDIC value of the character, with some bits modified so that a space, rather than the null control character, would equal no punches, just like on a regular punched card.

John Savard
Dan Espen
2015-04-30 01:13:09 UTC
Permalink
Post by Charles Richmond
Post by Dan Espen
Post by John Levine
Post by n***@gmail.com
From what I have gathered, it seems as if System 32 was the first computer
that was accessible for small businesses.
It was arguably IBM's first computer specifically aimed at small
businesses, but there were plenty of computers from other vendors in
that market.
I thought the IBM System/3 was IBM's first computer for small
business, and the S/3x series were just later improved models.
That's right.
(Just looked it up.)
Since I never saw or worked on a S/3 my memory of it is poor.
I guess what made the biggest impression at the time
was the 96 character card.
Note that there were three rows of punches on the 96 column cardand
the holes punched were circular. Each character was represented by
holes that encoded the ASCII value of the character... similar to the
way paper tape was punched.
http://www.aquaporin4.com/card96/
Based on the picture, that's BCD.
BA8421 is 6 bit BCD.
A "Z" as A81 is BCD.
--
Dan Espen
Quadibloc
2015-04-30 03:33:56 UTC
Permalink
Post by Dan Espen
Based on the picture, that's BCD.
ITYM BCDIC. BCD is a four-bit coding of decimal digits.

However, the 96-column card could handle EBCDIC. For the other characters in the 8-bit code, the card could no longer be interpreted, since the two extra hole positions were where the printing was.

John Savard
Dan Espen
2015-04-30 04:13:56 UTC
Permalink
Post by Quadibloc
Post by Dan Espen
Based on the picture, that's BCD.
ITYM BCDIC. BCD is a four-bit coding of decimal digits.
The 1401 BA8421 configuration was called BCD.
Post by Quadibloc
However, the 96-column card could handle EBCDIC. For the other
characters in the 8-bit code, the card could no longer be interpreted,
since the two extra hole positions were where the printing was.
I fail so see how EBCDIC is going to fit into BA8421.
I think the card comes up 2 bits short.

Maybe it had a binary mode.
--
Dan Espen
Quadibloc
2015-04-30 09:59:58 UTC
Permalink
Post by Dan Espen
Post by Quadibloc
However, the 96-column card could handle EBCDIC. For the other
characters in the 8-bit code, the card could no longer be interpreted,
since the two extra hole positions were where the printing was.
I fail so see how EBCDIC is going to fit into BA8421.
I think the card comes up 2 bits short.
I told you where the extra 2 bits - or, more precisely, the extra 2 holes -
went. The place on top of the card where the printing normally goes.

John Savard
Dan Espen
2015-04-30 13:01:16 UTC
Permalink
Post by Quadibloc
Post by Dan Espen
Post by Quadibloc
However, the 96-column card could handle EBCDIC. For the other
characters in the 8-bit code, the card could no longer be interpreted,
since the two extra hole positions were where the printing was.
I fail so see how EBCDIC is going to fit into BA8421.
I think the card comes up 2 bits short.
I told you where the extra 2 bits - or, more precisely, the extra 2 holes -
went. The place on top of the card where the printing normally goes.
See it now. Sorry and thanks.
--
Dan Espen
Charlie Gibbs
2015-04-30 18:19:16 UTC
Permalink
Post by Quadibloc
Post by Dan Espen
Post by Quadibloc
However, the 96-column card could handle EBCDIC. For the other
characters in the 8-bit code, the card could no longer be interpreted,
since the two extra hole positions were where the printing was.
I fail so see how EBCDIC is going to fit into BA8421.
I think the card comes up 2 bits short.
I told you where the extra 2 bits - or, more precisely, the extra 2 holes -
went. The place on top of the card where the printing normally goes.
Nope. There was enough unpunched space at the top of the card for all three
tiers to be interpreted. For an example, see

Loading Image...

which shows column numbers where the punch or interpreter would print all
96 columns' data. In fact, if you look closely you'll see a fourth row
in the printing area, with numbers from 97 through 128; it was possible
to print up to 128 characters on a fully-punched 96-column card (if you
had a machine smart enough to do so).

For an example of a fully-interpreted card with all three tiers punched, see

http://ibmcollectable.com/gallery/album63/s_96card_set_a?full=1
--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Charles Richmond
2015-04-30 21:13:24 UTC
Permalink
Post by Quadibloc
Post by Dan Espen
Post by Quadibloc
However, the 96-column card could handle EBCDIC. For the other
characters in the 8-bit code, the card could no longer be interpreted,
since the two extra hole positions were where the printing was.
I fail so see how EBCDIC is going to fit into BA8421.
I think the card comes up 2 bits short.
I told you where the extra 2 bits - or, more precisely, the extra 2 holes -
went. The place on top of the card where the printing normally goes.
Do you mean just under the printing... where the digits "1 2 3 4 5 ...
" are located??? There are three rows of these digits with enough room under
each to handle two more punch holes.

Now why would the cards separate the punchs like this???
--
numerist at aquaporin4 dot com
Dan Espen
2015-05-01 00:10:20 UTC
Permalink
Post by Charles Richmond
Post by Quadibloc
Post by Dan Espen
Post by Quadibloc
However, the 96-column card could handle EBCDIC. For the other
characters in the 8-bit code, the card could no longer be interpreted,
since the two extra hole positions were where the printing was.
I fail so see how EBCDIC is going to fit into BA8421.
I think the card comes up 2 bits short.
I told you where the extra 2 bits - or, more precisely, the extra 2 holes -
went. The place on top of the card where the printing normally goes.
Do you mean just under the printing... where the digits "1 2 3 4 5
... " are located??? There are three rows of these digits with enough
room under each to handle two more punch holes.
That's what I concluded.
Post by Charles Richmond
Now why would the cards separate the punchs like this???
One reason:

For "normal" data entry cards, the top area of the card would be
unpunched leaving the print unobscured.

Only object decks (assuming they contain literal program text)
would need punches in the top area.
--
Dan Espen
h***@bbs.cpcn.com
2015-04-30 01:48:31 UTC
Permalink
Post by Dan Espen
Since I never saw or worked on a S/3 my memory of it is poor.
I guess what made the biggest impression at the time
was the 96 character card.
I never worked on the S/3, but I remember it was a big deal when it was announced. The 96 column card was a big deal since it was half the size, yet held more information. The S/3 supposedly, IIRC, supported BASIC, making it easier to program.

I did see a few, and they were physically small. Actually, that was partly how IBM saved money on them since they used less metal.

The S/3 lncluded an offline card sorter, the last pure "tab" (punched card) unit ever built.
Post by Dan Espen
The Wikipedia article mentions that the S/3 used OCL too.
I still wonder why the software on that line was so much
more inspired than on S/360.
IBM S/360 history has some info about S/3.

Fred Brooks, developer of OS/360, said himself it stunk. My guess is that they were in a rush to get OS/360 out the door, plus, initially had to squeeze it down to run on low-end machines.

For System/3, IBM had to break with policy and develop a non-compatible machine. Keeping costs down were the prime objective, so the machine would be attractive to small businesses which until now didn't have the data volume to justify a real computer.

They took RPG from the 1401 and enhanced it to become RPG-II.

AFAIK, System/3 was a big success in the marketplace, as were its successors.

I think after the AS/400, IBM came out with the "i series" to replace it, but I don't know where that stands. That is, if someone had an AS/400 with lots of software written for it, what would they be using today?
John Levine
2015-04-30 02:23:34 UTC
Permalink
Post by h***@bbs.cpcn.com
Fred Brooks, developer of OS/360, said himself it stunk. My guess is that they were in a
rush to get OS/360 out the door, plus, initially had to squeeze it down to run on low-end
machines.
No guess, it's well documented. See The Mythical Man Month.
Post by h***@bbs.cpcn.com
I think after the AS/400, IBM came out with the "i series" to replace it, but I don't know
where that stands. That is, if someone had an AS/400 with lots of software written for it,
what would they be using today?
IBM Power Systems. The S/38 had a virtual instruction set that's been
carried forward through many generations of hardware. The virtual
instructions have never been physically implemented; instead each
machine had a translator to the native instruction set. The
translators are good enough that you can do instruction level virtual
machine debugging. You can buy a Power System with an OS to run as a
S/38 style machine, or on the same hardware you can run AIX or Linux.
Dan Espen
2015-04-30 02:41:37 UTC
Permalink
Post by h***@bbs.cpcn.com
Post by Dan Espen
The Wikipedia article mentions that the S/3 used OCL too.
I still wonder why the software on that line was so much
more inspired than on S/360.
IBM S/360 history has some info about S/3.
Fred Brooks, developer of OS/360, said himself it stunk. My guess is
that they were in a rush to get OS/360 out the door, plus, initially
had to squeeze it down to run on low-end machines.
For System/3, IBM had to break with policy and develop a
non-compatible machine. Keeping costs down were the prime objective,
so the machine would be attractive to small businesses which until now
didn't have the data volume to justify a real computer.
They took RPG from the 1401 and enhanced it to become RPG-II.
I never encountered 1401 RPG.
One place I worked asked me if it would useful
so I read the books and said no.

I did a bit of real RPG on S/360 DOS and model 20s.
RPG-II was a welcome redesign of RPG.
So, RPG went from

no way
to
this hurts
to
no problem boss.
Post by h***@bbs.cpcn.com
AFAIK, System/3 was a big success in the marketplace, as were its successors.
I think after the AS/400, IBM came out with the "i series" to replace
it, but I don't know where that stands. That is, if someone had an
AS/400 with lots of software written for it, what would they be using
today?
Now I'm sorry I looked:

In April 2008, IBM announced its integration with the System p
platform. The unified product line is called IBM Power Systems and
features support for the IBM i (previously known as i5/OS or OS/400),
AIX and GNU/Linux operating systems.

So you get an IBM Power System with IBM i support.
--
Dan Espen
Charlie Gibbs
2015-04-30 18:19:20 UTC
Permalink
Post by Dan Espen
Post by h***@bbs.cpcn.com
They took RPG from the 1401 and enhanced it to become RPG-II.
I never encountered 1401 RPG.
One place I worked asked me if it would useful
so I read the books and said no.
I did a bit of real RPG on S/360 DOS and model 20s.
RPG-II was a welcome redesign of RPG.
So, RPG went from
no way
to
this hurts
to
no problem boss.
Our rule of thumb was that if it was easy to do in RPG, do so;
otherwise write it in assembly language. RPG was good for the
job for which it was designed: generating report programs.
The trouble began when someone at IBM forgot what RPG stood
for, and hacked it to do things like interactive programming.
I once modified a 3000-line S/3x interactive RPG program to
run under Univac's equivalent of CICS. I think I re-wrote
it in COBOL, although my memory is hazy - painful experiences
are like that.
--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Anne & Lynn Wheeler
2015-04-30 03:55:50 UTC
Permalink
Post by h***@bbs.cpcn.com
I think after the AS/400, IBM came out with the "i series" to replace
it, but I don't know where that stands. That is, if someone had an
AS/400 with lots of software written for it, what would they be using
today?
FS had some bluesky ideas that hadn't been very well thought out from
performance standpoint. object-like instructions with lots of data
indirection for every instruction ... simulation showed that a FS
machine made out of 370/195 level technology would have throughput of
370/145 (something like 30times slowdown). The single-level store was
good from ease of use ... but terrible from throughput standpoint
(because of the synchronous page faults crippling any sort of
asynchronous high-throughput techniques). That and lots of other issues
contributed to its failure

some additional discussion here
http://www.jfsowa.com/computer/memo125.htm
past posts
http://www.garlic.com/~lynn/submain.html#futuresys

folklore is that some number of FS retreated to rochester did
significantly simplified FS as S/38 ... in marketplace where ease-of-use
significantly dominated throughput and performance issues.

Part of S/38 single-level-store was it treated all physical disks as
common space pool with scattere allocation. As a result, the complete
system had to be backed up as single filesystem entity. At the time,
single disk failures were relatively common ... but because of S/38
characteristic ... whenever there was a single disk falure, the disk had
to be replaced and then the complete system had to be restored ... which
could take 24hrs or more.

The move to as/400 was to be a combination S/36 & S/38 ... that included
eliminating some of the S/38 FS features.
http://en.wikipedia.org/wiki/IBM_System_i

from above:

The IBM System i, then known as the AS/400, was the continuation of the
System/38 database machine architecture (announced by IBM in October
1978 and delivered in August 1979). The AS/400 removed capability-based
addressing.[3] The AS/400 added source compatibility with the System/36
combining the two primary computers manufactured by the IBM Rochester
plant. The System/36 was IBM's most successful mini-computer but the
architecture had reached its limit. The first AS/400 systems (known by
the development code names Silverlake and Olympic) were delivered in
1988 under the tag line "Best of Both Worlds" and the product line has
been refreshed continually since then. Guy Dehond from Inventive
Designers was one of the beta-testers of Silverlake. The programmers who
worked on OS/400, the operating system of the AS/400, did not have a
UNIX background. Dr Frank Soltis, the chief architect, says that this is
the main difference between this and any other operating system.

... snip ...

In that timeframe (late 70s & early 80s) there was an effort to convert
wide variety of corporate microprocessors to 801/risc (low & mid-range
370s, as/400, embedded controller microprocessors, etc). For emulation
there was a flavor of 801/risc chips called Iliad that had some
extensions for architecture emulation. However for various reasons, all
the efforts floundered and reverted to custom CISC chips (and in the
early 80s, some number of 801/risc engineers leave and show up at other
vendors working on risc efforts). some past 801/risc posts
http://www.garlic.com/~lynn/subtopic.html#801

A different OPD (office products) / Research 801/risc effort was ROMP as
a displaywriter followon. When this project got canceled they looked
around and decided on retargeting to the workstation market and got the
company that had done AT&T unix port for the IBM/PC (PC/IX) to do one
for ROMP ... which becomes PC/RT & AIX. The followon is RIOS for
RS/6000.

A single chip effort is then done as joint project with Apple, IBM,
and Motorola (AIM)
http://en.wikipedia.org/wiki/AIM_alliance
for power/pc
http://en.wikipedia.org/wiki/PowerPC

Rochester works with power/pc group for 801/risc chip for as/400 ... a
decade after as/400 had abandoned 801/risc and went with CISC.
--
virtualization experience starting Jan1968, online at home since Mar1970
Quadibloc
2015-04-30 09:58:38 UTC
Permalink
Post by Anne & Lynn Wheeler
simulation showed that a FS
machine made out of 370/195 level technology would have throughput of
370/145 (something like 30times slowdown).
And yet that didn't stop IBM from coming out with the AS/400 later on...
Post by Anne & Lynn Wheeler
folklore is that some number of FS retreated to rochester did
significantly simplified FS as S/38 ... in marketplace where ease-of-use
significantly dominated throughput and performance issues.
The move to as/400 was to be a combination S/36 & S/38 ... that included
eliminating some of the S/38 FS features.
And the S/34 was a combination S/3 and S/32... so the pattern continued.
Post by Anne & Lynn Wheeler
The IBM System i, then known as the AS/400, was the continuation of the
System/38 database machine architecture (announced by IBM in October
1978 and delivered in August 1979). The AS/400 removed capability-based
addressing.[3]
Hmm. So capability-based addressing tends to be expensive to implement, I
presume.
Post by Anne & Lynn Wheeler
In that timeframe (late 70s & early 80s) there was an effort to convert
wide variety of corporate microprocessors to 801/risc (low & mid-range
370s, as/400, embedded controller microprocessors, etc). For emulation
there was a flavor of 801/risc chips called Iliad that had some
extensions for architecture emulation. However for various reasons, all
the efforts floundered and reverted to custom CISC chips (and in the
early 80s, some number of 801/risc engineers leave and show up at other
vendors working on risc efforts).
And now that the technology of just-in-time compilation has advanced, things became ripe for using the PowerPC to implement System i. But not for everything else.

John Savard
Peter Flass
2015-04-30 14:29:19 UTC
Permalink
Post by Quadibloc
Post by Anne & Lynn Wheeler
simulation showed that a FS
machine made out of 370/195 level technology would have throughput of
370/145 (something like 30times slowdown).
And yet that didn't stop IBM from coming out with the AS/400 later on...
Post by Anne & Lynn Wheeler
folklore is that some number of FS retreated to rochester did
significantly simplified FS as S/38 ... in marketplace where ease-of-use
significantly dominated throughput and performance issues.
The move to as/400 was to be a combination S/36 & S/38 ... that included
eliminating some of the S/38 FS features.
And the S/34 was a combination S/3 and S/32... so the pattern continued.
Post by Anne & Lynn Wheeler
The IBM System i, then known as the AS/400, was the continuation of the
System/38 database machine architecture (announced by IBM in October
1978 and delivered in August 1979). The AS/400 removed capability-based
addressing.[3]
Hmm. So capability-based addressing tends to be expensive to implement, I
presume.
With all the chip real estate available today I'd like to see someone
implement it today with a big cache of capability data to see what kind of
performance could be achieved with current hardware.
--
Pete
Anne & Lynn Wheeler
2015-04-30 15:38:34 UTC
Permalink
Post by Quadibloc
And now that the technology of just-in-time compilation has advanced,
things became ripe for using the PowerPC to implement System i. But
not for everything else.
re:
http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?

claim is that for a couple decades, i86 has been risc core with
hardware layer that translates i86 instructions into risc microops.

in the late 70s when 801/risc/iliad was targeted to become of the core
for everything ... including low-end & mid-range 370s ... the
state-of-the art was sequential microcode implementing/decoding 370
instructions ... sort of like modern day hercules
http://www.hercules-390.org/

... that avg. 10 native instructions for each 370 instruction. these
had been cisc microprocessors and 801/risc iliad would just replace that
... but using same approach (although circa 1980, I got sucked into some
discussion with the efforts about doing just-in-time conversion) ... a
one mip 370 implementation required a ten mip native cisc engine.

earlier in 1975, I had been involved in project that moved 6kbytes of
high useage kernel 370 instructions into 6kbytes of native
microprocessor instructions (static compilation) that showed a 10:1
performance improvement ... old post with some details of that effort:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

the current implementation for i86 to risc micro-ops isn't serialized
but pipelined ... so to get 1 mip 370 doesn't require 10mip native
... it just requires more circuits that are running concurrently ... the
latency for the pipeline is longer (but current pipelines tend to many
stages and relatively long latency) ... each instruction pipeline stage
is handled sequentially, but there are several instructions going on
concurrently in parallel.

as a result, the throughput difference of risc & i86 cisc has largely
been mitigated. i86 has larger install base so they can devote more $$$
to newer generations of chips that run faster, cheaper, better, lower
power, etc

the claim has been the apple switch from power/pc to i86 was that
power/pc efforts weren't keeping up with low-power chips for laptops and
mobile.

posts mentioning 801/risc, iliad, romp, rios, aim, somerset, power,
power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801
--
virtualization experience starting Jan1968, online at home since Mar1970
Quadibloc
2015-04-30 22:12:29 UTC
Permalink
Post by Anne & Lynn Wheeler
claim is that for a couple decades, i86 has been risc core with
hardware layer that translates i86 instructions into risc microops.
My understanding is that this claim came from some oversimplified articles in the
technical press.

The Pentium II, and contemporary chips from AMD and Cyrix (their 6x86) were
noted as having a "decoupled microarchitecture". That term was apparently
wrongly defined in articles about the chips to imply that x86 instructions were
being translated on-the-fly into RISC instructions for an (undisclosed)
RISC-style ISA.

If one looks up the term "decoupled architecture", though, one can find out
what was _really_ happening.

The chips were taking the x86 code and making it more RISC-like in *one*
respect. When feeding the things the instructions were calling for to their
out-of-order execution engine, they split off the "fetch" part from the "do
arithmetic" part of memory-reference arithmetic instructions.

That allowed the fetch to be scheduled to a time earlier than when the other
operand for the arithmetic would be available in a register.

And that was it. There was really no implication that x86 code was translated
to some RISC-like intermediate code, although it may well be that micro-ops
were moved around as sequences of bits as opposed to operations being specified
as signals on individual wires. But even if that were done, the micro-ops
wouldn't look much like the ISA of any RISC processor.

John Savard
h***@bbs.cpcn.com
2015-04-30 19:23:24 UTC
Permalink
... The single-level store was
good from ease of use ... but terrible from throughput standpoint
(because of the synchronous page faults crippling any sort of
asynchronous high-throughput techniques).
In my humble opinion, the single level store, as implemented on the AS/400, was not easy to use. (Perhaps I was prejudiced being used to MVS).
Anne & Lynn Wheeler
2015-04-30 19:41:22 UTC
Permalink
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
re:
http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?

OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).

MVS eventually gets SMS/DFSMS that automates a lot of the issues
managing multiple disks
http://2000clicks.com/links/Computers/IBMMainframeHistory/mvshist5.htm

DFSMS/MVS announced in May 1992, integrates and expands the storage and
program management functions previously available in MVS/DFP V3, DFHSM
and DFDSS. A new feature, Removable Media Manager, was also
added. DFSMSrmm allows tapes, both automated and manual libraries, to
have the full automated management support provided by DFSMS.

... snip ...

system/38 single drive failure recovery issues were so bad that it
becomes early RAID adopter (as way of masking single drive failures and
elminating excessive downtime during recovery).


... past refs S/38 RAID refs:
http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2007t.html#72 Remembering the CDC 6600
http://www.garlic.com/~lynn/2009e.html#44 Architectural Diversity
http://www.garlic.com/~lynn/2009s.html#33 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2010g.html#67 Interesting presentation
http://www.garlic.com/~lynn/2010n.html#84 Hashing for DISTINCT or GROUP BY in SQL
http://www.garlic.com/~lynn/2010o.html#7 When will MVS be able to use cheap dasd
http://www.garlic.com/~lynn/2011.html#14 IBM Future System
http://www.garlic.com/~lynn/2011c.html#14 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011c.html#91 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011d.html#71 Multiple Virtual Memory
http://www.garlic.com/~lynn/2011l.html#15 Selectric Typewriter--50th Anniversary
http://www.garlic.com/~lynn/2013f.html#29 Delay between idea and implementation
http://www.garlic.com/~lynn/2013i.html#33 DRAM is the new Bulk Core
http://www.garlic.com/~lynn/2013o.html#7 Something to Think About - Optimal PDS Blocking
http://www.garlic.com/~lynn/2014b.html#68 Salesmen--IBM and Coca Cola
http://www.garlic.com/~lynn/2014c.html#76 assembler
http://www.garlic.com/~lynn/2014i.html#73 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014i.html#74 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014m.html#115 Mill Computing talk in Estonia on 12/10/2104

... past posts mentioning original RAID patent
http://www.garlic.com/~lynn/2002e.html#4 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2004d.html#29 cheaper low quality drives
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006x.html#15 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2009s.html#33 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2010n.html#84 Hashing for DISTINCT or GROUP BY in SQL
http://www.garlic.com/~lynn/2011.html#14 IBM Future System
http://www.garlic.com/~lynn/2011h.html#34 Happy 100th Birthday, IBM!
http://www.garlic.com/~lynn/2013f.html#29 Delay between idea and implementation
http://www.garlic.com/~lynn/2013f.html#80 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2013i.html#33 DRAM is the new Bulk Core
http://www.garlic.com/~lynn/2013o.html#7 Something to Think About - Optimal PDS Blocking
http://www.garlic.com/~lynn/2014b.html#68 Salesmen--IBM and Coca Cola
http://www.garlic.com/~lynn/2014c.html#76 assembler
http://www.garlic.com/~lynn/2014g.html#79 non-IBM: SONY new tape storage - 185 Terabytes on a tape
http://www.garlic.com/~lynn/2014i.html#73 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014m.html#115 Mill Computing talk in Estonia on 12/10/2104

trivia ... while at SJR and got to play disk engineering over in
bldg. 14&15, I had opportunity to work with the person that got the raid
patent
http://www.garlic.com/~lynn/subtopic.html#disk
--
virtualization experience starting Jan1968, online at home since Mar1970
Dan Espen
2015-04-30 20:28:32 UTC
Permalink
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
From my S/34 perspective,
I felt the same way.
I never had to use a 38 or above, but it looked like a lot
of complication solving a problem that didn't exist.
Post by Anne & Lynn Wheeler
OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).
Seems to me, they could have dealt with that using hierarchical names
and maps that indicate which names go where.
--
Dan Espen
Peter Flass
2015-04-30 22:12:41 UTC
Permalink
Post by Dan Espen
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
From my S/34 perspective,
I felt the same way.
I never had to use a 38 or above, but it looked like a lot
of complication solving a problem that didn't exist.
Post by Anne & Lynn Wheeler
OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).
Seems to me, they could have dealt with that using hierarchical names
and maps that indicate which names go where.
Which, of course, is DFSMS.
--
Pete
Dan Espen
2015-05-01 00:58:13 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
From my S/34 perspective,
I felt the same way.
I never had to use a 38 or above, but it looked like a lot
of complication solving a problem that didn't exist.
Post by Anne & Lynn Wheeler
OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).
Seems to me, they could have dealt with that using hierarchical names
and maps that indicate which names go where.
Which, of course, is DFSMS.
Gee, I hope not.

:)

Instead of managing files, this would assign volumes to fields when on disk.
Lot's of fields.
--
Dan Espen
Scott Lurndal
2015-05-01 14:10:10 UTC
Permalink
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?
OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).
The burroughs medium systems had disk and pack pooling from
the start. An individual drive configured for 100-byte sectors
(called DISK) would be part of one of up to 8 "Disk Subsystems" (the
subsystem number selected the allocation pool to use). One of the
disk subsystems was reserved for the MCP and associated data files;
one was typically marked default (for use by applications that didn't
explicitly specify which subsystem to use for allocation).

A bit later, 180-byte sector media was also supported. This was called
PACK. One or more packs could be concatenated (like modern RAID-0) into
a multi-pack "Family". An application would specify the family name
and the MCP would handle allocation across the set of units in that
family. One could configure a "resource" family that would be selected
when the family name was blank or the generic "PACK".

A file could have up to 100 "areas" allocated on a family or
subsystem. The size of the area depended on the record size,
blocking factor and blocks-per-area parameters specified when
the file was created.

Given that the size of an area will differ from file to file,
checkerboarding was a problem. The SQUASH utility would be
run if fragementation got too bad and would move areas around
to create larger units of free-space. The PACK SQUASH utility
was written in COBOL :-)

scott
alexander george
2022-03-07 07:35:35 UTC
Permalink
Post by Scott Lurndal
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?
OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).
The burroughs medium systems had disk and pack pooling from
the start. An individual drive configured for 100-byte sectors
(called DISK) would be part of one of up to 8 "Disk Subsystems" (the
subsystem number selected the allocation pool to use). One of the
disk subsystems was reserved for the MCP and associated data files;
one was typically marked default (for use by applications that didn't
explicitly specify which subsystem to use for allocation).
A bit later, 180-byte sector media was also supported. This was called
PACK. One or more packs could be concatenated (like modern RAID-0) into
a multi-pack "Family". An application would specify the family name
and the MCP would handle allocation across the set of units in that
family. One could configure a "resource" family that would be selected
when the family name was blank or the generic "PACK".
A file could have up to 100 "areas" allocated on a family or
subsystem. The size of the area depended on the record size,
blocking factor and blocks-per-area parameters specified when
the file was created.
Given that the size of an area will differ from file to file,
checkerboarding was a problem. The SQUASH utility would be
run if fragementation got too bad and would move areas around
to create larger units of free-space. The PACK SQUASH utility
was written in COBOL :-)
scott
Very Nice Information
Thanks for sharing with us
https://paradigm.in/structural-design/
https://paradigm.in/geotechnical-design/
https://paradigm.in/bim-services/
https://paradigm.in/structural-steel-fabrication-drawings/
https://paradigm.in/reinforcement-steel-detailing/
https://paradigm.in/preconstruction-cad-services/
Michael Trew
2022-03-08 07:19:21 UTC
Permalink
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?
I still have an IBM System/23 in my cellar. It operates, as far as I
know. Numbers come up on the screen when booted. It has it's original
dot-matrix style printer as well. All of the documentation seems to be
there, but I never learned to use the thing.

alexander george
2022-03-07 07:36:13 UTC
Permalink
Post by Scott Lurndal
Post by Anne & Lynn Wheeler
Post by h***@bbs.cpcn.com
In my humble opinion, the single level store, as implemented on the
AS/400, was not easy to use. (Perhaps I was prejudiced being used to
MVS).
http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?
OS/360 and MVS had filesystem mapped to drive ... so had all the issues
with managing large number of drives. single level store obfuscated all
that treating all disk space as one large pool (but enormously
complicating recovery from single drive failure).
The burroughs medium systems had disk and pack pooling from
the start. An individual drive configured for 100-byte sectors
(called DISK) would be part of one of up to 8 "Disk Subsystems" (the
subsystem number selected the allocation pool to use). One of the
disk subsystems was reserved for the MCP and associated data files;
one was typically marked default (for use by applications that didn't
explicitly specify which subsystem to use for allocation).
A bit later, 180-byte sector media was also supported. This was called
PACK. One or more packs could be concatenated (like modern RAID-0) into
a multi-pack "Family". An application would specify the family name
and the MCP would handle allocation across the set of units in that
family. One could configure a "resource" family that would be selected
when the family name was blank or the generic "PACK".
A file could have up to 100 "areas" allocated on a family or
subsystem. The size of the area depended on the record size,
blocking factor and blocks-per-area parameters specified when
the file was created.
Given that the size of an area will differ from file to file,
checkerboarding was a problem. The SQUASH utility would be
run if fragementation got too bad and would move areas around
to create larger units of free-space. The PACK SQUASH utility
was written in COBOL :-)
scott
https://paradigm.in/structural-design/
https://paradigm.in/geotechnical-design/
https://paradigm.in/bim-services/
https://paradigm.in/structural-steel-fabrication-drawings/
https://paradigm.in/reinforcement-steel-detailing/
https://paradigm.in/preconstruction-cad-services/
John Levine
2015-04-29 03:53:27 UTC
Permalink
Post by h***@bbs.cpcn.com
I thought the IBM System/3 was IBM's first computer for small business, and
the S/3x series were just later improved models.
The S/3x were quite different internally from the S/3, although they apparently
did software emulation for backward compatibility.
Post by h***@bbs.cpcn.com
Post by John Levine
DEC had offerings based on PDP-8 and PDP-11, Data
General had Nova and Supernova systems, and so forth.
Did a lot of businesses acquire the PDP-8 to do things like payroll and
accounting? The DEC PDP-8 brochure says "scientific, engineering, process
control, data acquisition, quality control (circuit testing), and
educational applications". Not a word about any business applications.
The brochure touts the floating point point package and mathematical
function routines. It offered FORTRAN but not COBOL. It did not appear to
offer disk. The tape at 200 bpi seemed weak for 1965.
People definitely attached disks to PDP-8's; I used them. There was
even a small timesharing system that gave each user a fairly close
approximation of a bare machine with the usual peripherals and a disk.

DEC invented a business language called DIBOL in 1970 originally for
the PDP-8, eventually ported to many other machines and defined in an
ANSI standard. It's still in use, and it's easy to find online help
wanted ads looking for DIBOL programmers. Another famous PDP-8
business application was newspaper typesetting, see
http://www.pdp8online.com/miscdocs/PDP-8.pdf

Then there's MUMPS, a database system originally implemented in 1966
on a PDP-7 at Mass General Hospital (that's what the first M stands for),
later widely used as Digital Standard MUMPS (DSM, the standard was
ANSI X11.1) on PDP-11s and Vaxen. It's still widely used in the
healthcare and financial industries because it's fast, it works, and
they have ginormous databases hosted in it. One of our neighbors
makes good money as a MUMPS programmer.
Charles Richmond
2015-04-29 21:13:54 UTC
Permalink
Post by John Levine
Post by h***@bbs.cpcn.com
I thought the IBM System/3 was IBM's first computer for small business, and
the S/3x series were just later improved models.
The S/3x were quite different internally from the S/3, although they apparently
did software emulation for backward compatibility.
Post by h***@bbs.cpcn.com
Post by John Levine
DEC had offerings based on PDP-8 and PDP-11, Data
General had Nova and Supernova systems, and so forth.
Did a lot of businesses acquire the PDP-8 to do things like payroll and
accounting? The DEC PDP-8 brochure says "scientific, engineering, process
control, data acquisition, quality control (circuit testing), and
educational applications". Not a word about any business applications.
The brochure touts the floating point point package and mathematical
function routines. It offered FORTRAN but not COBOL. It did not appear to
offer disk. The tape at 200 bpi seemed weak for 1965.
People definitely attached disks to PDP-8's; I used them. There was
even a small timesharing system that gave each user a fairly close
approximation of a bare machine with the usual peripherals and a disk.
DEC invented a business language called DIBOL in 1970 originally for
the PDP-8, eventually ported to many other machines and defined in an
ANSI standard. It's still in use, and it's easy to find online help
wanted ads looking for DIBOL programmers. Another famous PDP-8
business application was newspaper typesetting, see
http://www.pdp8online.com/miscdocs/PDP-8.pdf
NCR had a business-oriented language for their small (medium size) business
systems called NEAT. I remember seeing ads in the classified section of the
newspaper for NEAT programmers. Is NEAT still in use???
Post by John Levine
Then there's MUMPS, a database system originally implemented in 1966
on a PDP-7 at Mass General Hospital (that's what the first M stands for),
later widely used as Digital Standard MUMPS (DSM, the standard was
ANSI X11.1) on PDP-11s and Vaxen. It's still widely used in the
healthcare and financial industries because it's fast, it works, and
they have ginormous databases hosted in it. One of our neighbors
makes good money as a MUMPS programmer.
ISTM that the MUMPS language is now sometimes called M:

http://en.wikipedia.org/wiki/MUMPS
--
numerist at aquaporin4 dot com
Charles Richmond
2015-04-29 20:10:02 UTC
Permalink
Post by h***@bbs.cpcn.com
[snip...] [snip...]
[snip...]
DEC had offerings based on PDP-8 and PDP-11, Data
General had Nova and Supernova systems, and so forth.
Did a lot of businesses acquire the PDP-8 to do things like payroll and
accounting? The DEC PDP-8 >brochure says "scientific, engineering, process
control, data acquisition, quality control (circuit testing), >and
educational applications". Not a word about any business applications.
The brochure touts the >floating point point package and mathematical
function routines. It offered FORTRAN but not >COBOL. It did not appear
to offer disk. The tape at 200 bpi seemed weak for 1965.
A Wikipedia article says there was a business-oriented language for the
PDP-8:

"The original version, DIBOL-8, was produced for PDP-8, PDP-11 and DIBOL-32
VAX/VMS systems, though it can also be run on other systems through
emulators."

http://en.wikipedia.org/wiki/DIBOL
--
numerist at aquaporin4 dot com
Quadibloc
2015-04-29 20:06:23 UTC
Permalink
This won't help to answer your specific question, but I was reading a brochure on
the IBM 9370 from Al Kossow's web site the other day.

This machine was from the early 1980s, as the original IBM PC was contemporary
with it.

The brochure noted that it was implemented with RAM chips that contained one million bits each, and had a 1.2 micron feature size. But the internal logic was bipolar, on chips that only had 4,000 gates or so each.

John Savard
Quadibloc
2015-04-29 20:21:57 UTC
Permalink
(1) I may have an opportunity to acquire a System/34, but I won't get
manuals and software with it.
This lets me narrow down my Google search. According to Wikipedia, the System/34 was announced in April, 1977.

No real answers here, but someone got one of those beasts running:
http://www.corestore.org/34.htm

Couldn't find an ad brochure, but there are FE manuals for it on Bitsavers.

John Savard
Quadibloc
2015-04-30 00:28:31 UTC
Permalink
The IBM 3033 also came out in 1977. So, as their top-of-the-line product, I felt that perhaps more information would be available about its technology - the System/34 might not have embodied any fundamental innovations of its own, but instead used the same general kind of chip.

From the 3033 announcement, it is noted that this computer used chips that were twice as dense as, and significantly faster than, those on the Model 168-3.

John Savard
Anne & Lynn Wheeler
2015-04-30 04:09:31 UTC
Permalink
Post by Quadibloc
The IBM 3033 also came out in 1977. So, as their top-of-the-line
product, I felt that perhaps more information would be available about
its technology - the System/34 might not have embodied any fundamental
innovations of its own, but instead used the same general kind of
chip.
From the 3033 announcement, it is noted that this computer used chips
that were twice as dense as, and significantly faster than, those on
the Model 168-3.
3033 was Q&D effort after FS imploded (in parallel with 3081) started
out mapping 168-3 logic to 20% faster chips from FS ... some detail
here:
http://www.jfsowa.com/computer/memo125.htm
past FS posts
http://www.garlic.com/~lynn/submain.html#futuresys

however the chips has had ten times the circuits of those used in 168-3
... initially going unused. there was some logic optimization to take
advantage of onchip circuits .... getting 3033 to 50% faster than 168-3
(4.5mips up from 3mips).

303x used 158-3 integrated channels as external channel box. a 3031 was
then 158-3 engine with 370 microcode and w/o the integrated channel
microcode and a 2nd 158-3 engine with the integrated channel microcode
(and w/o the 370 microcode). a 3032 was 168-3 with 303x "channel
director" (in place of 168-3 external channels). A 3033 would have 1-3
channel directors. (aka up to three 158-3 engines running integrated
channel microcode). Note that the 158-3 integrated channels were slower
than the (native) 168-3 external channels ... so for some I/O things, a
3032 might have lower throughput than real 168-3 (with its real hardware
external channels).

recent posts mentioning 3033
http://www.garlic.com/~lynn/2015.html#85 a bit of hope? What was old is new again
http://www.garlic.com/~lynn/2015b.html#40 OS/360
http://www.garlic.com/~lynn/2015b.html#45 Connecting memory to 370/145 with only 36 bits
http://www.garlic.com/~lynn/2015b.html#46 Connecting memory to 370/145 with only 36 bits
http://www.garlic.com/~lynn/2015b.html#60 ou sont les VAXen d'antan, was Variable-Length Instructions that aren't
http://www.garlic.com/~lynn/2015b.html#61 ou sont les VAXen d'antan, was Variable-Length Instructions that aren't
http://www.garlic.com/~lynn/2015c.html#30 IBM Z13
http://www.garlic.com/~lynn/2015c.html#39 Virtual Memory Management
http://www.garlic.com/~lynn/2015c.html#44 John Titor was right? IBM 5100
http://www.garlic.com/~lynn/2015c.html#57 The Stack Depth
http://www.garlic.com/~lynn/2015c.html#91 Critique of System/360, 1967
--
virtualization experience starting Jan1968, online at home since Mar1970
Continue reading on narkive:
Loading...