*** Please note, this page (and web site) are in early development.
Items are certainly not complete, and may be inaccurate.
Your information, comments, corrections, etc. are eagerly requested.
Send e-mail to Ed Thelen.
Please include the URL under discussion. Thank you ***
IBM System 360, Model 30
|Identification,ID ||IBM System 360, Model 30
|Date of first manufacture||1965
|Number produced ||-
|Estimated price or cost||-
|location in museum ||-
|donor ||Travelers Insurance
Contents of this page:
Placard by Ron Mak
by Ron Mak
The IBM System/360 Model 30
IBM dominated the computer industry after introducing the System/360 computers in 1964.
The 360 was not just one machine, but a series of upward-compatible machines designed to span
the full circle (hence the name "360") from commercial data processing to scientific
Programs written for one model could run on any higher model. The machines pioneered the
use of microcode to implement the same instruction set throughout the series and yet
optimize the performance of each model. At introduction, the series included six
models with a 25:1 performance range. The machines were so popular that IBM
initially had trouble filling the orders.
The Model 30 was near the low end of the series. The first shipped 360/30 was to
McDonnell Aircraft Corporation in June 1965.
||up to 64K bytes
|| Machine cycle time:
||750 nanoseconds (1.33 MHz)
Sources: Emerson W. Pugh, et al. IBM's 360 and Early 370 Systems. Cambridge, MA: MIT Press, 1991. p. 195
Paul E. Ceruzzi. A History of Modern Computing. Cambridge, MA: MIT Press, 1998. pp. 143-175
from LEONARD.BEARES.firstname.lastname@example.org December 2005
One interesting thing you might add to your 360/30 info is that in the early
70's a company in Edina Minnesota, Fabri-tek, manufactured core memory for
IBM computers. 32K was about $40,000 dollars. We actually engineered the
360's to take what we called double over capacity memory sizes. We could
actually take a 360/30 up to 128K. In response IBM began to offer an
upgrade to take the 360/30 to 96K. Having this extra memory allowed the
computer to do sorts in main memory instead of tape/disk. The result was
that sorts of an hour or more could be done in several minutes. We also did
upgrades for the 360/40, 50, etc. If you think this stuff is worthwhile, I
could give you more info.
Interesting Web Sites
In December 2011 there was a lecture series
"Legacy of the IBM System 360 Architecture", by Dan F. Greiner
with this graph 360 Instruction Count History
Ron Mak, of San Jose State
has conducted a
History of Computing Speaker Series
with recordings at
(The table-of-contents w links
is at the bottom of the page,
use the slider up&down )
Such luminaries as Gordon Bell, James Gosling,
and Donald Knuth spoke.
I was watching the most recently posted
"Legacy of the IBM System 360 Architecture"
Dan F. Greiner
and got blown away with the
- backward comparability
- quadrupling of the number of
instructions - see attached .jpg -
- big jumps in the architecture
- increasing memory address bits
- multiple processors
- and memory complexity
from 1962 (360) through to 2012
About 25 minutes into the presentation
(after a historical introduction)
he gets into the architecture of the 360 :-))
(24 bit addressing, ... )
At 31 minutes he gets into 370 (virtual memory) (1970)
and 13 new instructions, some for users
and 2 more bits of address space
At 33 minutes 370 Enhancements (1978-1982)
locks, address space flips, ... , transcendental functions, ...
High-accuracy arithmetic, more new instructions
At 34 minutes 370 Extended Arch... (1983)
31 bit addressing ( 2 gigabytes )
more new instructions, better hardware trace
multiple operating systems ala VMWare
At 36 minutes, "A Few Side Trips (1980s)
Vector facility and SIMD
At 37 minutes - 1989 - another extension -
"Access-register Translation) up to 4 T-bytes
more user instructions to manipulate the above
"Home address space", who is incharge? for abort processing
Linkage Stack, push-down stack not in original 360 spec.
more user instructions
At 39 minutes, 1990s
- Arithmetic instr w 16 bit immediate operands
- Branch w 16 bit relative
- floating point, IEEE standard
95 new instructions
- Compression facility
- TCP/IP check sum instruction
- UniCode complexity and excitement
and on and on !!!
Prediction of death of mainframes, 1991
Stewart Alsop eating his words ;-)) 1996
At 43 minutes, 2001 - and the z/Architecture
and its evolution
- 64 bit virtual address space
- 64 bit registers
- another 183 new instructions
- with access-register translation (above)
can address 2^75 bytes
- Trimodal addressing, 24, 31, or 64 bit (user mode)
- "Western civilization runs on z/OS" - Bob Rogers, IBM DE
... Decimal floating point facility
and much more -
At one time I could code in IBM 360.
for work and play
Apparently the binaries of the code I wrote
- for work the 1960s
- for play ( Pi on the Mod 91 ;-)) in the 80s
can still be executed without without change !!
DEBE - from Lowell DeFrance (07/2010)
Ed, I was just looking through your model 30 material when I noticed
that someone described DEBE as a print spooler. I wrote the 1st DEBE
program in 1963 while at the IBM Chicago Datacenter at Lake and
When the 360's first came into the datacenter the only
utilities available required complicated control cards to be completed
and inserted into the utility program deck and then loaded via the card
reader. I put together the DEBE program so using Basic Programming
System (BPS) and set it up so that the object program could be written
on a tape and IPL'd from tape.
At the Datacenter and apparently in
customer's shops a tool was needed to do simple things quickly. DEBE
did simple things quickly and easily, nothing fancy since it was a
systems person's and programmer's tool to be used for debugging, etc.
It was the first program I wrote for the 360 outside of a classroom.
After being transferred from the Datacenter I was encouraged to document
DEBE and submit it as an IBM Type III program, which meant it was free
with no guarantees and that IBM would send it out upon request.
I doubt if anyone ever ordered and built their own since it was easier
to find a DEBE tape, mount it on a tape drive, and go TT (tape to tape)
to make a copy on another drive after typing in the 5 digit tape drive
address for the 2 tapes.
I don't know those that went on to develop a disk version or DITTO or
the MVS Debe and I never had the chance to use any of these programs. I
heard a lot of good things about DITTO. It was supposed to have had a
lot more function and still very easy to use and, it even had error
correction - now why didn't I think of that!
from Dave Cortesi (10/2004)
... the /30 was the smallest of the line to support the 360 API.
There was also a 360/20, but it had a different instruction set.
from John Fryatt (March 2005)
The /20 was intended as a machine to upgrade customers who ran "unit
record" accounting shops based on the 402 and 407 punched card
accounting machines. These customers were assumed not to be interested
in general programming or in using tapes or disks.
The /20 was optimized for reading cards and printing reports, and was
almost exclusively programmed in RPG -- a language that embodied all
the concepts implemented in the 402 and 407, based on sequential
processing of pre-sorted records. Although the /20 was called a "360,"
used SLT, and had the same cabinet styling, it was not a 360 in the
sense of being upward-compatible with the /30, /40, etc.
The 360/30 was intended to be the natural upgrade for accounts with a
1401 system. The 1401 was a general-purpose computer with what was at
the time seen as a massive base of existing software. To that end, the
360/30 could be had with an optional 1401 emulator feature to run 1401
software in binary (well, in decimal actually) direct from tape or card
decks. Early on, short-sighted customers and salespeople ordered a lot
of 360/30s with 16K of memory -- because that was the maximum the 1401
could have, and who would need more?
But if your system had the full 64K, DOS/360 let you "partition" it
into two or even three partitions and load 2 or 3 concurrent jobs.
While it did actually work, this was very seldom actually done. The JCL
to accomplish it was tricky; plus each program had to be linked to the
hard starting address of the partition in which it would run; plus, the
reader and printer had to be assigned to a single partition, there was
no spooling software in DOS; and all console output came out on the one
console typewriter, mixed together line by line.
Concurrent jobs did become feasible in 360/30s and 360/40s a couple of
years after introduction when two software guys in the SF Bay Area --
sorry I don't remember their names -- implemented a spooling add-on for
DOS, giving each of the three partitions a virtual reader, punch, and
printer, multiplexed onto the real hardware.
I don't remember the names of those two guys, but I do remember the
day I was introduced to the brilliant idea of SPOOL: Simultaneous
Peripheral Output OnLine.
I was just digging around for IBM System/360 stuff and found your site.
I operated a 360/30 in the 70's. It had 32k of core memory built in,
plus another 32k in a third-party add-on box. This 32k stood about 5'
tall and 2'6" square!
The model 30 was *not* the smallest 'real' 360. Another local company,
whose machine we used at night, had a 360/25. This ran the same
instruction set as the 30 as we loaded our programs into it.
We originally ran the BOS operating system, then upgraded to DOS. We
also later got a spooler, GRASP, so we could run three partitions,
although GRASP itself occupied one of them.
BOS was very limited - all console messages, for instance, were
four-character codes which had to be looked up in book to make sense of.
Of course, the old hands knew them anyway, but if any problem occurred
there was little you could do except re-IPL the machine. DOS was a great
Odd things spring to mind, like the 2311 disk drives jigging around as
the heads moved in and out. These drives were very heavy engineering by
todays standards. Also, the machine room was very noisy - you got used
to it and didn't notice until you powered the system down at the
weekend, and thought you'd one suddenly deaf!
The 1403 line printer had a great feature, which was a powered lid that
opened when the box of paper was almost used up. The resulting
cacophony, as all the little slugs in the print train hammered on the
ribbon and paper reminded the ops to load a new box.
For a long time we did data input using punched paper tape, which was
pretty archaic even then, but did eventually move to key-to-disk
equipment and data input via magnetic tapes.
One trivial detail I could never work out the reason for was that on the
model 30 the lights on the console were behind number-shaped cut-outs,
whereas every other model 360 I saw had little round plug-in lights on
from Dan Espen (October 2007)
While the comment about the 360/25 being a lower end model is correct,
the 360/25 was introduced quite a bit after the initial 360 line.
from Charlie Cleveland Dec 2007
Another reason 16K wasn't enough for the 360/30 is that you could pack
a lot more logic into the 16K of the 1401 than the 360/30 even when
coding both machines in autocoder/assembly language. I made that
comment to my boss when we considering a 360 and had the IBM reps
show up and challenge me in front of him. I was able to explain in
detail why that was true. I was around 20 years old at the time.
Ed Thelen says - I bet that was fun! I'm glad I wasn't in the shoes of
those IBM reps :-((
A little fun and a little disappointing that my boss wouldn't believe me.
Found out when I left that they had IBM checking up on everything I did. Being young
it took me a while to realize how clueless a boss can be.
I just read your 360/30 page. I am amazed at the memories it conjured.
Gosh, I haven't heard the term ' IPL' in decades.
While going to school to learn programming (1970, they had a 360/30),
I was working as an operator at a shop (they had a 360/25) in the Wash DC area.
After graduating, I acquired a position as an operator at an insurance company (360/30).
A year and a half later, I finally landed a programming position (COBOL)
with a contracting firm (very fortunate for me as this company was started by the people
who worked with Grace Hopper, the "Mother of Computers"). During this time,
I realized that the 360/30 was by far the most widespread machine in the DC area.
I recall the 1401 emulation both as an operator as well as a contractor.
As an operator, I used the '// FETCH' JCL (I don't recall the parameters) to initiate
the 1401 emulation. You also had to turn off the I/O check at the CPU (this was
because the 1401 allowed a multi-punch in rows 4 thru 7 whereas the 360 did not).
As a contractor, I had to convert some systems from 1401 to 360. I recall, in the 1401 world,
the sign (+, -) was located in the high order byte, wherein the 360 and
all subsequent worlds, the sign is located in the low order byte.
I remember the partitioning and spooling. It seems to me, we used two programs in this area,
DEBE and DITTO. I believe DEBE was a print spooler and DITTO was a general utility (not sure).
One short story during my time with the insurance company as an operator:
What a wonderful site this is.
Thank you so much for the moment of fond memories you have inspired.
From time to time I had to go into the stock room for printer paper. I noticed
there was a small box on the top of one of the shelves. After several month's, I decided
to check it out. After blowing off a 1/4" of dust (this box was ancient even in 1971), I realized
that I had found an "IBM Port-a-Punch". I asked the DP manager if I could have it and he said OK.
Over 36 years later, I still have it here in my office in the original box.
The following is from Peter A. Goodwin - December, 2009
parked here until I can figure a better place -
The time-sharing machine that I worked on WAS at Mohansic. The guy who got the $7,000 prize was probably my boss, Andy Kinslow. An IBM Outstanding Contribution award. Andy is still alive -- at least he was a couple of years ago or so -- lives in western Connecticut near the New York border. He got a prize, I got a prize (not nearly so much) and two other guys got prizes for this. The system took the CTSS approach as a starting point. CTSS added memory relocation and protection registers to the CPU and trapped the attempted execution of all I/O or supervisory instructions. Our machine went further that this: It used high-speed (relatively!) drum storage for inactive program residence (program swapping) and a 1301 disk for the program library. I added relocation and protection registers to the 1301 data channel and to data channel A (card reader, card punch, printer, and a bank of 729 tape drives), and added other hardware that would prevent a user program from grabbing control of the machine. The result was that we created a set of virtual 7090s using an 8K-word resident supervisory program in a 32K-word system. You could run any program that didn't absolutely depend upon CPI-I/O synchronization (like the CPY instruction on the 704) or invoke compatibility-mode alterations (which would make the 7090 operate like it was a 704). You could even run standard IBM machine diagnostics in the time-sharing environment! (Of course, a memory diagnostic would only find 24K words available.) See H. A. Kinslow, The Time-Sharing Monitor System , AFIPS Spring 1964, http://portal.acm.org/citation.cfm?id=1464052.1464092&coll=ACM&dl=ACM&CFID=64753258&CFTOKEN=53621636 .
I also worked on TSS/360 for awhile. A bad mistake. O/S 360 hadn't settled town sufficiently when TSS began, and there was too much of a rush to completion. The 360 itself wasn't overly reliable and could fail leaving imprecise records behind. I was part of the TSS architecture group. One of my designs was for the configuration control section. Never made it into TSS/360, but the air traffic control guys in Kingston -- Roland Pampel's group. -- picked up the design and implemented it.
If you have comments or suggestions, Send e-mail
to Ed Thelen
Go to Antique Computer home page
Go to Visual Storage page
Go to top
Updated December 2011