Talk:IBM System/360

From Wikipedia, the free encyclopedia

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
This article is within the scope of the Technology WikiProject, a group related to the the study of Technology. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.
??? This article has not yet received a rating on the quality scale.

Contents

[edit] Does this make sense?

The S/360 was the most expensive CPU project in history. (The most expensive project of the 1960s was the Apollo program for moon exploration. IBM's System/360 was the second most expensive. S/360 machines were also heavily used in the Apollo project.)

Does this make sense to you? --Spankthecrumpet 13:38, 4 Jun 2005 (UTC)

No, and I removed it. Feel free to rephrase it and put it back. Removed text follows below --Apoc2400 08:06, 26 October 2006 (UTC)
 
 ===The project's size and gravity===
 The S/360 was the most expensive CPU project in history. (The most expensive project of the 1960s was the Apollo program 
 for moon exploration. IBM's System/360 was the second most expensive. S/360 machines were also heavily used in the Apollo project.)
 Fortune Magazine at the time referred to the project as IBM's "$5 billion gamble," and they were right. IBM absolutely bet
 the company on the System/360 (US$5 billion in 1964 dollars translates to about $30 billion in 2005 dollars), which paid off.
 

[edit] Naming the System/360 family

There's a certain awkwardness in pages I've seen that talk about IBM mainframe systems, in that they sometimes refer to System/370, sometimes System/390, sometimes z/OS and so on.

As time goes by, pages will become out-of-date, and each rebranding will mean someone has to add a new brand name to existing pages.

I would suggest that something like "System/360 Family" be used as a generic name which doesn't need changing, and which could point to its own page on which the specific individual members of the family might be enumerated or linked.

I could just go ahead and do it, but I'd like to hear opinions first.

Brent Longborough 12:24 Dec 27, 2002 (UTC)

I think we should just merge all those pages into one, and then create redirects from all alternative names. — Monedula 07:58, 27 Aug 2004 (UTC)
I, too, have noticed this quite unsatisfactory condition. Another example is the IBM mainframe article, which is mostly about the S/360 family while also listing some previous systems. Please note the following, anyway: In the interest of Wikipedia standardization, the title of a potential single "S/360..." article should be "System/360 family" (lowercase "f"). --Wernher 18:59, 27 Aug 2004 (UTC)
Would "family" or "series" be more appropriate? e.g. IBM 700/7000 series and UNIVAC 1100/2200 series -- RTC 20:53, 29 Sep 2004 (UTC)
I would suggest 'family', because there were/are a wide range of models available at the same time, often quite different internally (designed by different laboratories in IBM), covering different uses. 'series' perhaps gives the sense of a line of machines, each one a follow-on to the previous model. mfc
Makes sense. -- RTC 23:36, 30 Sep 2004 (UTC)

[edit] Leasing vs buying

The second paragraph notes that before the S/360 people were reluctant to buy computers. To recall history, prior to about 1964, you couldn't buy an IBM computer since the company only leased them. They lost a court decision before changing that policy. I started to edit the article to describe this, but may simply alter the paragraph rather than complicate the article with this discussion. Any comments? Lou I 18:55, 23 Jan 2004 (UTC)

[edit] Costing an arm and a leg

System/360 is described as the second most expensive project of the 1960s (after Apollo). SAGE is estimated to upto 12 billion 1964 dollars by some. Drhex 13:59, 2004 Aug 26 (UTC)

[edit] Featured article nomination?

Yes, how'bout it? Should we Just Do It? (no reference to expensive high profile brand sneakers here). Or, would the article perhaps need peer review to polish it a little (or a lot)? Tell me what you think, folks. --Wernher 17:25, 17 Dec 2004 (UTC)

[edit] Channel Architecture

There is no mention of the channel architecture. It is sufficiently complicated that it probably use its own article. I am probably qualified to write such an article for the pre-1985 channel. I don't know if the channel architecture should be considered something of lasting importance. I know that it has changed with fibre optic cables etc. In the 3081 the relatively simple view from the main-frame (a small number of instructions (Start I/O, Halt Device, etc) was replaced by complex data structures which shared between the OS and the CPU.


IMHO the idea of retaining the DMA storage address within the CPU/channel rather than storing it in the device as in UNIVAC 1107 ESI and many DMA schemes seems more secure. The idea of a channel command code which was partially decoded in the channel: write, read and read-backwards and fully decoded in the device was an improvement over the 7090 channel scheme. Rdmoore6 02:17, 4 January 2006 (UTC)

I think an article on IBM's channel architecture would be very valuable. --agr 19:32, 7 February 2006 (UTC)

[edit] 1620 emulation?

The article state that the IBM 1620 was one of the architectures that the IBM 360 could emulate in microcode. I'm dubious about this claim. I don't remember such an option and I can't imagine much of a market for it then (the IBM 1130 was the successor in the 1620's market niche), but it's hard to prove a negative. Does anyone have a reference?--agr 19:32, 7 February 2006 (UTC)

I don't have a reference, but it seems reasonable. The 360 architecture was the first one to use microcode, wasn't it? Customer's existing base of applications was then, and remains today, one of the roadblocks to moving to a new architecture. I am old enough to remember when the IBMPC was first introduced. One of the points made, during the first months of introduction, was that there were tools to recompile your existing CP/M applications, so they would run under MS-DOS, preserving customer's software investment. The enduring legacy of backward compatibility with CP/m was a chain around MS-DOS's ankle for decades. -- Geo Swan 19:55, 7 February 2006 (UTC)
Microcode existed long before S/360; Maurice Wilkes came up with the idea, and it was used in an early research machine, and might have been used by processors before S/360. That doesn't mean that the 1620 was necessarily emulated in microcode by any S/360 machines, however; it might have been simulated in software, if that provided adequate performance (S/360 hardware could, at least, add two decimal digits without doing a table lookup, unlike the 1620 Model I :-)). I think pure-software simulators existed to simulate at least some other IBM computers on S/360. Guy Harris 20:29, 7 February 2006 (UTC)

I am old enough to remember when the IBM 1620 was first introduced. :-)>>> Some programmers at the time were unhappy that it was not compatible with the older IBM 650. IBM's main interest was back then leasing or selling hardware. The low end 360's were targeted at the commercial market and had rather poor scientific performance. It's unlikely many 1620 shops upgraded to these machines. The larger 360's were much more expensive than a 1620 so again there were likely to be few upgrades in that direction. The IBM 1130 was the preferred upgrade path for 1620 customers. And microcode was not cheap to develop or install. [1] All the literature I can find only mentions 1400 series emulation on the low end 360s and 7000 emulation on the high end machines.

As for software emulation, it may have existed, but I never heard of it for the 1620. The idea was known, but it would have been difficult to simulate a 1620 in the memory available on a low end 360/30 (64KB max, and that was an expensive configuration). And performance would have been pretty poor, even without the need for table look up. The main reason for writing in assembly language was performance, so simulation of such programs would have been less than ideal. By contrast most 1400 software was probably written in assembly language because memory space was tiny. Also I believe most 1620 software was written in Fortran, which provided a relatively easy upgrade path for most customers. --agr 23:30, 7 February 2006 (UTC)

See: converting to IBM System/360 page 5.
"Compatibility features and associated emulator programs are designed to protect your investment in 1620, 1400- and 7000-series programs. Emulators make it possible for you to execute your current programs on System/360 with little or no reprogramming. Using these features, the appropriate model of System/360 will normally execute your 1620,1400- or 7000-series programs as fast or faster than they run on your present system"
-- RTC 01:00, 20 September 2006 (UTC)
See: Laurie Robertson, "Anecdotes," IEEE Annals of the History of Computing, vol. 27, no. 2, pp. 82-84, IEEE, Apr-Jun, 2005.[2]
"A couple of years later, Fairchild bought its first IBM 360/30. It had firmware microcode stored in ROM that let it emulate both the 1620 and 1401. ..." (Emphasis added)
I found this by a Google search for ibm 1620 microcode, it was the first item. Apparently at least one 360/30 was delivered with 1620 emulation microcode. -- RTC 23:35, 27 September 2006 (UTC)
Thanks, I stand corrected. Nice find. I guess the moral is "Google first, ask questions later." --agr 23:46, 27 September 2006 (UTC)
It is possible that IBM sold a small number of systems with 1620 emulation, like the Fairchild one above, but when they saw the poor sales reevaluated the market and designed the 1130 to fill the void left below the low end 360 systems. A very similar problem occured when IBM attempted to sell the IBM 7070 as a common replacement for both the 650 and 705. It did so poorly as a 705 replacement that they were forced to design the IBM 7080. -- RTC 23:48, 27 September 2006 (UTC)

The 1620 simulator was a deck of cards that was booted. It was basically a stand alone program that ran on the bare 360 without running under an operating system. I believe it was compiled and punched out with the various options for its emulation compiled in. When I was in college, the big machine down the street was a 360/40, and they kept a copy of the simulator around (supposedly) in case of a catastrophic failure of one of the 1620s that were on campus (supposedly with options to match the features in the better optioned 1620). Also, in reading the model specific CPU manuals, I do not recall ever seeing an option listed for a 1620 emulator in firmware on any of the models. I expect the simulator probably could have squeezed into a 64K machine, if only emulating a 20k 1620, since that would have left about 45000 bytes for the simulator. I vaguely recall seeing the simulator run one time, but it was (of course) many years ago. Alan Larson 00:09, 17 October 2007 (UTC)

It would be worth adding monthly lease rates and purchase prices to the article, but i think we are talking about very different price points. The 360/30 was the low end of the 360 line, but still a medium priced machine. The 1130 was very cheap at the time and affordable for a small engineering company or a high school. The 360/30 was not considered a good scientific machine. Also most 1620s and 1130s were run open shop. i doubt many 360/30s were. Remember 360s had to be restarted to run in emulation mode and it tied up the machine(the 370s fixed that). It may be that some large customers had production programs running on the 1620 that they didn't want to convert, but I doubt there were many. As I mentioned above, converting a Fortran program was pretty easy. My guess is that the 1620 emulator was mostly used as a selling tool to get customers to upgrade to the more expensive 360 line.--agr 18:22, 28 September 2006 (UTC)
Thats also the reason the 360/20 was done (to fill the void left below the 360/30), but it was so stripped down that emulating much of anything on it would have been rather silly (even calling it a 360 was stretching things a bit!). And I suspect even the crippled 360/20 would have been overpriced for a lot of 1620 customers (e.g., 20,000 digit machines) which would be the only 1620s the 360/20 could hope to emulate in its tiny memory. A 1620 customer with a full up system (i.e. 60,000 digits, 4 - 1311 disks, 1622 card reader/punch, 1443 printer, 1627 plotter, and a lot of investment in custom in house special purpose code written in SPS) and outgrowing that system would likely be very willing to get a 360/30 with 1620 emulation, as a "transition" machine, then upgrade later to one of the larger machines. Also not all 1620s were used as scientific computers. For example several newspapers (e.g., The Kansas City Star) used the 1620 for typesetting with custom software all written in SPS. A 360/30 with 1620 emulation could easily handle typesetting for a newspaper with similar if not better performance to the old 1620. -- RTC 19:44, 28 September 2006 (UTC)
I'm sure it could, but I wonder if it would be cost effective (not that that ever stopped an IBM salesman). Not only would the lease rate be higher, but you'd probably need a bigger computer room, power and air conditioning. Did the 360/30 have a paper tape punch available? Might be cheaper to keep running the 1620. In any case, I don't think such situations represented the bulk of the 1620 business. Might be fun to contact the Kansas City Star to see if anyone remembers.--agr 21:41, 28 September 2006 (UTC)

Check the 1966 and 1968 history of Krohm International Ltd. It covers the Kansas City Star and their 1620. They upgraded to a 360 (not sure which model though, probably either a 30 or a 40, but it almost certainly had 1620 emulation). This was then replaced by a PDP-11. -- RTC 17:30, 29 September 2006 (UTC)

Very interesting, but I interpret what he said a little differently. It sounds to me like IBM was pushing an S/360-based typesetting product of its own and convinced the Star to upgrade to it. I suspect the IBM system was far more ambitious than the Star's the home-grown 1620 paper tape system. It likely had multiple terminals, perhaps IBM 2741s, for direct input of text instead of using paper tape produced off-line. I doubt the 1620 software was reused, tho the emulation capability may have been part of the sell. --agr 19:13, 29 September 2006 (UTC)

[edit] Benchmark info?

No info on clock speeds or MIPS in article? How does it compare to eg Pentium?

I don't see any CPU clock rates in System/360 Instruction Timing Information, but the memory speeds vary from 2 microseconds per memory reference on System/360 Model 30, with each memory reference fetching or storing 1 byte (so a 4-byte word would be 8 microseconds) to 1 microsecond per memory reference on the "Model 70" (which never came out, but it's probably close to the Model 75), with each memory reference fetching or storing 4 bytes. A register-to-register add takes from 29 microseconds on the Model 30 to .4 microseconds on the "Model 70".
According to IBM System/360 Model 30 Functional Characteristics, the memory cycle was 1.5 microseconds, with early models having a 2 microsecond memory cycle. It lists the CPU cycle time as .75 microseconds for the 1.5 microsecond memory cycle systems and 1 microsecond for the 2 microsecond memory cycle systems, so that'd be 1.33 MHz for the 1.5 microsecond memory cycle machines and 1 MHz for the 2 microsecond memory cycle machines. The CPU data path in the Model 30 was 1 byte long, so an instruction adding 2 4-byte words would process each of those bytes in a separate cycle. Note also that the general registers were stored in a special chunk of core memory, and access to one of them took 6 microseconds on the 1.5 microsecond memory cycle systems (4 1.5 microsecond memory cycles).
The Model 65 (not the top of the line - that was the Model 75) had, according to IBM System/360 Model 65 Functional Characteristics, a 200 nanosecond CPU cycle time (5 MHz), and a .75 microsecond cycle time for main memory (with a 64-bit memory bus, letting two 32-bit words be fetched at the same time) and an 8 microsecond cycle time for the (again 64-bit) add-on storage unit.
Unlike most modern microprocessors, the main System/360 processors were not pipelined, so it couldn't finish one instruction per clock cycle - instruction N+1 wasn't started until instruction N finished, and instruction N might well take more than one clock cycle. The Model 91 was not only pipelined, but, to a limited degree, superscalar; see IBM System/360 Model 91 Functional Characteristics. It cost many many cubic dollars.
If you were to run the Hercules emulator on a modern PC, it would be a lot faster than even the fastest System/360. I don't know how well it'd do on a Pentium (where "Pentium" means "P5", i.e. Intel's first superscalar x86 chip). Guy Harris 09:46, 5 July 2006 (UTC)

[edit] Peripherals

I just added a "Peripherals" section, which includes a one-sentence description of I/O channels ahnd their importance. I consider this section to be a stub, but it is a crucial part of the S/360 story, so much so that a stub is better than nothing. Please improve it if you can.

Do recall that this article is about the S/360 and not about the S/370 or later architectures, at least as I understand it.

Thanks. -Arch dude 00:41, 21 October 2006 (UTC)

[edit] UWA 360

No longer at Shenton Park - in storage at the Australian Computer Museum Society WA warehouse

Search for UWA University Computer Club