• "Computer Structures: Readings and Examples", (1971 edition) by C. Gordon Bell & Allen Newell, Part 6, Section 3, The IBM System/360- a series of planned machines which span a wide performance range
  The structure of SYSTEM/360,
  Part II-System implementations

  The IBM System 360 Model 30

  David Cotesi suggests:

  http://en.wikipedia.org/wiki/DOS/360

  http://en.wikipedia.org/wiki/BOS/360

  http://en.wikipedia.org/wiki/TOS/360

  http://bitsavers.vt100.net/pdf/ibm/360/dos/C24-5022-4_DOS_operGuide.pdf

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
   http://www.cs.sjsu.edu/~mak/
has conducted a
     History of Computing Speaker Series
     http://www.cs.sjsu.edu/~mak/SpeakerSeries/index.html
with recordings at
      http://www.sjsu.edu/atn/services/webcasting/archives/fall_2011/hist/computing.html

(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
          to handle
            - 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)
Operating Systems
   - z/OS
       - ...
       - "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 !!
 

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 1965 while at the IBM Chicago Datacenter at Lake and Michigan.

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!

Lowell DeFrance
Woodstock, IL

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.

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

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 the console.

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.

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 :-((

---

[Follow up]

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.