Hardware boffin starts work on simulation of an entire IBM S/360 Model 50 mainframe Hardware guru Ken Shirriff is working on a simulator for the IBM S/360 Model 50 mainframe, launched in April 1964. His program runs the original machine's microcode so it can control and be controlled by an original front panel. Circuitry-wizard Ken has featured on The Reg quite a few times, from reverse-engineering a Sinclair …
The Hercules simulator has been around for a while (though it simulates S/370 and later, not S/360). However, since S/370 is a superset of S/360 it will boot both MVT as well as MVS along with a selection of other IBM OSs.
There's a list of available operating systems here and a list of the compilers for MVS, MVT and others here.
A 360/44?!? We had one at my school (New Mexico Tech); doing some research, found it was installed in 1966, making it one of the first installs of that model. No SS instructions (which meant no OS/360 :-( ), but a blinding fast (for its time) floating point processor.
Ahh, the paper cuts from the punch cards....
I got to Tech when the 360 was being replaced by a DEC-20. For a semester or so it was very impressive to see both machines running side-by-side in the same computer room especially considering the school was only about 1200 students back then (a bit bigger now but still small for an engineering college). I've returned to Tech working as a DBA but no big iron any more--just lots of virtualized servers.
Cheers to my fellow Techie. :-))
[Article author here]
Pour encourages les autres... "TMMM" is _the Mythical Man Month_ by Fred Brooks.
It's the seminal text on project management.
I often use it to explain why multi-core processors are not the wonderful performance benefit they're often taken to be.
I tell people they should read it to understand about the overheads of resource allocation. But it's quite thick – so they should buy two copies, so they can read it in half the time. Or if they're really short of time, four or even eight copies...
I remember reading assembler code for a 360 communications program I was supposed to duplicate onto another architecture. Got very confused as it didn't have near enough booleans and not enough conditional checks against current state. Then noticed code was checking a couple strange values against some very odd addresses.
The pseudo-booleans were opcodes at those odd _code_ addresses, and the strange values were for NOP vs. BRanch. The program was flipping instructions between fall-through and jump elsewhere, reflecting current 'state'.
Not your usual Fortran or Cobol code, that.
Cambridge University bought an IBM 360 in the 1970s. Since JCL is not fit for humans, they wrote an operating system called Phoenix, a scheduler called Eagle, a scripting language called Wren and lots of other bird-themed programs. Meanwhile, the top American universities were developing Unix and the FOSS world. I saw Knuth's TeXbook in a bookshop and asked, why can't we have clever software? Of course Phoenix was abandoned in the end. Such a tragedy that all of this intellectual effort went down the drain!
(Separate story) A friend of mine who had been to school in Moscow had an IBM360 manual in Russian, because the Soviet's had "emulated" it.
Not as pretty as the EEC/ICL System 4/70**. A flat panel matrix of coloured squares backlit by an array of pea-bulbs. I have some 8mm film footage of one somewhere.
Some people would insist that the illuminated buttons of a KDF8 (RCA 501***) console in a darkened room was art in itself.
** an IBM 360 compatible based on the RCA Spectra 70/55 paper specification.
***The Spectra 7/45 microcode had an option to emulate an RCA 501 - and possibly also another early computer.
Princeton University had one in the early 1970s which ran a standalone program called Thor, open for public use, which provided two functions: printing a listing of a program from cards, or duplicating a card deck onto blank cards. That's all it did, but it was very helpful given that all your code was on cards then.
I always fancied mounting one of the front panels on the wall as decoration, art even.
Never got one but love browsing through the pics on http://www.righto.com/2019/04/iconic-consoles-of-ibm-system360.html Iconic indeed - how many of us grew up thinking that computers look like that. That site also has an interesting discussion of the 555 timer chip.
Curious how he got ahold of the S/360-50 microcode. On several of the S/360 models (40,50,65,67), the microcode was held in arrays of capacitors formed by large plastic sheets with conductors etched on one side of them held between large steel plates. These capacitors were quite sensitive to the pressure applied to them by the steel plates (which were sensitive to the temperature inside the machine's cabinet) and the IBM customer engineer (CE) would occasionally have to re-torque the screws which applied pressure to the plates. A microcode update required demounting the plates, replacing the plastic sheet with the new one, replacing the plates and then re-torquing them until they read properly. Model 30 used plastic 80-column punch cards inserted in slots in the machine for its microcode. Models 44, 75 and 91 were "hard-wired" for best performance and didn't have microcode, which made fixing engineering mistakes more costly. S/370 microcode was held in semiconductor memory and loaded during machine power-up initialization from 8-inch floppy disks which IBM invented for that purpose.
The Model 30 microcode was as stated on 80 column punch cards with silver contact plates for each of the 80 by 12 location that could be punched out to change the code. They were held against the 'read' plate by air pressure. To update the microcode you had to deflate the bag and then remove and replace the necessary cards. The problems we had as engineers were that over time the silver on the card would stick to the base board which meant a major cleaning job and the other common problem was loss of pressure in the airbags that pressed them against the read plate. The model 25 I think had a loadable microcode from punched cards that had to be reloaded after every power down. The model 40 had TROS which was Transformer Read Only Storage on long flexible tapes stacked around transformer cores.
World Health Organization (WHO?)
I learned coding via those 80 column sheets not understanding that they needed to be punched onto cards, read in and stored on tape, sorted, compiled, mashed and reports spewed (days later.) I can almost remember the BALR and other instructions.
Later I was an operator for a system with real spinning disks but nobody knew how to run sorts using them. Paper tape readers for factory interfaces. Multiple pass card sorts before.
My career in IT started as a trainee operator on a 360/30 with 32k memory and 2311 disks. It was running a manufacturing plant in Trafford Park, Manchester (quite close to Old Trafford so very convenient to go and watch United). I progressed through programming (Cobol), leaving millennium bugs all over the place as two bytes were very precious, into management roles - Director of Computer Services, Head of Business Development etc, and now retired. Still remember the 360/30 with affection.
In a previous life at a bank, I had the joy of working with a real S390 system. Absolutely solid as a rock; but that perhaps was also a reflection of the quality of the software on it, written with very well known user requirements and acknowledging of the limitations of the communications systems of the time.
I also keep a model around written originally for S390. Former administrators of the model decided that rather than migrating the Fortran to a modern architecture, that they would instead run it in one of those (rare) commercial emulators... for DOS.
How many layers of emulation do you want?!? S390 in DOS in VirtualBox (or other VM of choice). It works well in Dosbox though of course such use is definitely against the legal boilerplate of Dosbox.
Oh no it wasn't!
The Ferranti Atlas got there first and had been running it for years before IBM even thought about it. I remember a face-off at an IFIP conference around 1968 between an iBM-er discussing certain problems that they had discussed while *emulating* virtualisation and paging, and an Atlas man who just said " We have been running it IRL for 10 years now without hitting that problem."
At my first (commercial) job in 1972 at BP we were just thinking of switching from /360 to /370.
Citation, please.
The Atlas was the first machine to have virtual memory, including simple memory protection, but I can't find any reference (aside from your post) that claims it had virtualization. And the Atlas Supervisor paper doesn't say anything about virtualization either.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
