The folklore index. | Nigel's Home Page. | Next Story.
Newsgroups: alt.folklore.computers Subject: IBM 360/30 saga (long) Date: Thu, 29 Jun 95 18:50:26 GMT Lines: 417
For those looking forward to it, here it is. To the others, sorry for clogging up a.f.c. Having just re-read it, I can't believe I ever managed to do all this. LJW 29-Jun-95.
What follows is quite true, to the best of my recollections. I am a bit sketchy on many of the specifics, as most of this happened over ten years ago. I apologise in advance to anyone who helped out and has been denied a mention. LJW 16-May-93.
This story starts some time mid 1982, when I was in my second year of an electrical engineering degree and involved with the NZ Microcomputer Club. At that time I still had an 8080-based S100 system, complete with 8k RAM and KC standard cassette, but had done quite a bit of work on TRS80 clones, Sorcerers and the like.
Someone in the NZMC had been told of the existence of a computer in a cartage company's warehouse, which they wanted to get rid of. With no idea of what to expect, myself and several other club members (Selwyn Arrow and Trevor Sheffield, I think) went along one evening to the building in central Auckland to have a look. With virtually no light, all we could see almost buried in between sacks of spices and goodness knows what else were several large cabinets. After a bit of clambering and moving of stuff, we ascertained that it was an IBM, and the cabinets had the model numbers 2030 and 2841 on the side. There were also several smaller units, which were pretty obviously disk drives.
Never having had anything to do with IBM products before, none of us knew what it was, but I was sure of one thing: If they didn't want it, I did! The club had hopes of starting a BBS, but the size of the unit was a bit excessive, even if the price was right. Anyway, it was there for the asking, all we needed was somewhere to put it, and the company would move it for free. An agreement was drawn up between me and the club (the OSI club, represented by Brian Wilson, was also involved.)
At the time I was doing some programming work (1802, 6800 etc.) for a friend (Steven Murray) who had a small office (like about 3m square) in downtown Auckland, and next to him there was a larger vacant room. The rent was about $120 per month. I don't know how I afforded it back then, but I took it. The catch was, it was on the third floor, and there was only a winding staircase and a tiny lift for access, so it obviously wasn't going to fit up there in one piece.
I opted to have the main units brought home, where they took up most of one side of our carport, while the smaller pieces like the drives went straight to the office. There were plenty of huge blue manuals, about 50 disk packs and various other odds and ends. At some stage the identity of the machine was revealed when the nameplate turned up: "IBM System/360". After much reading at the library I worked out that what we had was a Model 30, hence the 2030 number, which was a bit of a disappointment when I would have liked a 91 or something.
All my spare time was taken up with studying the machine and the manuals. It was obvious that the two main units would have to be disassembled to get them into the office. The frames would fit up the stairs, but if we were going to lift them then all their contents would have to go separately. Unfortunately the IBM engineers had not taken such disassembly into account, so it was not just a matter of unplugging everything and unbolting it from the frame.
A few words about the construction of the unit are in order. As I became 'au fait' with the manuals I was able to identify the basic units. The whole CPU was about 1.5m high by 1m wide by 2m long. Looking from the front panel, the main power supply was at the left about 3/4 the way back. It consisted of a huge three- phase transformer/filter assembly and a high-frequency switching power supply. Behind it was an air compressor (yes - more about this later) and a relay panel.
At the front left, near ground level, were the two core memory units. Each was 32k bytes, and 64k was this system's maximum capability. Above the core was the microcode storage, known as CCROS (card-capacitor read only storage), in which microcode was stored on punched cards, sandwiched statically between circuit boards. Each card held twelve words of 60 bits, running long- ways along the card, and the card was pressed against the circuit board by an air bladder, kept filled by the aforementioned compressor. There were about 4k words of microcode, or about 340 cards.
Virtually the whole right hand side of the machine was occupied by the logic, on a 'gate' which swung out to provide access to the connections on the rear. There was provision for a second gate of similar size, though I learnt that this was only used if the floating point option (which also required an additional CCROS unit) or a second selector channel were fitted.
By the time I had sorted everything out I was pretty familiar with what was inside. While the IBM 360 is of course a 32 bit machine, the Model 30 was internally an 8 bit system, so it had to do any computations four times. Its addressing capability was restricted to 16 bits, hence the 64k core limit.
It had a single multiplexer channel and a single selector channel. The selector channel was all in hardware, but the multiplexer channel was implemented in microcode, with a small amount of dedicated hardware. There was some additional 'auxiliary storage' (outside the main 64k address space) which was used to store the 360's register contents (excluding the instruction pointer which was stored in hardware) and the multiplexer sub-channel status, where it kept track of up to 32 concurrent transfers.
The CPU clock was about 1.3MHz. In one cycle (750ns) the core could do a single read, and on the following cycle the data would have to be rewritten, as core reads were destructive, unless of course the data was to be modified before being re-stored. As registers were in core the same procedures applied there.
After much deliberation, the unit was dismembered into several large chunks: the power supplies (after removing a very dead rat), the CCROS unit, the core modules, the logic gate and the front panel. I didn't have to cut many wires, but kept good records to assist with reassembly. With the panels removed this left a bare frame, though still none too light.
The 2841 unit turned out to be the DASD (disk) controller. It was almost as complicated as the computer itself, having its own microcode, and an interface for each of the four drives. The drives were type 2311, with about 7MB each (that was a huge amount in those days) and I had plenty of disk packs. The 2841 was similarly dismantled, though it wasn't so much of a problem.
I made up small paper templates of each unit, and shuffled them around on a plan of the office so as to make sure I could open all the doors and still have the cables reach between units. An electrician friend, Doug Hook, wired three-phase power from the switchboard into the office.
All the moving was done at weekends, any other time it would have been too difficult with traffic and other tenants. The CPU frame and the logic gate were man-handled up the stairs without causing too much damage to the banisters, while everything else fitted into the lift, though at times it strained a bit.
Once everything was there, it was reassembly (reassembler?!) time. This went pretty well, my notes were good enough and nothing had been damaged. As this progressed, I was able to understand the FEMM manuals more and more. They contained all the circuit diagrams, including connector layouts, and while the components were unfamiliar I could still use them to trace connections. One unit that was a bit tricky was the 1051/1052 console typewriter. This was a Selectric-style unit which was wired directly into the circuitry of the CPU, and had been disconnected before being put into storage.
The logic was IBM's "SLT" (solid logic technology) which was similar to DTL, and based on 0.5" square modules, each of which contained about one gate. Four to eight modules would be mounted on a board about 2" by 3", and these boards were in turn plugged into boards about 8" x 12", of which there were about 30 in total on the main gate.
Once it was all back together to the best of my ability, the day came for the big start-up. I really can't remember it too well, as it wasn't really that eventful - in retrospect I was lucky that nothing blew up or caught fire.
We switched on the main power feed to the CPU. There was a small clunk from a relay somewhere, and the high-pitched squeal of the switching supply - this evidently ran all the time even when the computer was "off". I reached out and nervously pushed the "ON" button. There was a loud series of relay clacks, the sound of lots of fans and the air compressor starting, then another click and everything shut off.
I never really resolved what was happening, but I think I worked out that there was a problem with the emergency shut-off circuitry (there was a line running down the channel cable which linked the shut-off switches on each unit together - I think I may have had to move the terminator from the 2841 into the 2030 to temporarily override this) and this was fixed by cleaning the contacts on all of the relays.
Now starting the system would produce a continuous cacophony. The air compressor would stop after about 20 seconds, starting up every few minutes as the air bags leaked down, but there must have been 40 fans in there all whirring and pushing out vast quantities of hot air. I had to remove the false ceiling panels and open the window if I wanted to have it running for more than ten minutes.
I soon noticed that all was not well, and that the machine was stopping soon after startup with a microcode check. This led me down a convoluted path. The microcode is stored on a special punch card, which has silver conductive traces screened onto it. When fed through a card punch, some of the silver pads are removed, and the remaining pads become one half of a small capacitor, the other half being on the circuit board (hence the CCROS designation.) Over time, some of the silver had corroded, resulting in dropped bits. Luckily each microcode word had several parity bits, so these errors were picked up. I went out and bought a small bottle of silver conductive ink from Philips and proceeded to do my own repair jobs. It worked a treat.
Diagnosis was aided by the fact that each microcode bit had a lamp on the front panel, and there was a single-microcode-step mode of operation. There was also a complete set of manuals containing the microcode (CLDs), using a graphical representation, which I soon got to understand. Before then I had never encountered microcode. The microcode system was quite nifty and most instructions seemed to execute in the minimum time feasible, though even a simple register to register add would take some 33 cycles (25 microseconds).
As an aside, the mechanism used to implement microcode branches was quite cute. The 4k of microcode was divided into 256-word pages, and 4-way interleaved. A given microcode word specified only the top 6 bits of the next instruction's address within the current page, the bottom 2 bits were determined by two separate function codes, giving each instruction up to 4 possible successors (the function codes included force 0 and force 1 where no branch was needed). Since the four possible destinations were already read by the end of the cycle there was no branching delay.
There really were lots of 'blinkenlights' - a section for the microcode, a section for the selector channel, as well as the conventional IP, data and status displays. Quite a few of the lamps had blown, so they got moved around depending on what I was working on - I never got round to buying any new ones.
I now had a system that would start and stay running, even if it wouldn't do anything. I hadn't worried about the disk side of things yet. At this stage I had to start learning about what the 360 could do. I hadn't had to worry at all about the intricacies of 360 machine code or CCW programming, so now I had to find everything I could. All those books in the library on 'Learning IBM 360 Assembler Language' suddenly had a great new significance, though most of my initial work was derived from the listings in the diagnostic manuals, plus the fact that the 1802 mnemonics seemed to mirror those of the 360.
I wrote a few simple programs, and dialled them in on the front panel. There were four sixteen-position switches for the address, two for data, and 'Store' and 'Read' buttons. Things seemed to work much as expected, but there were a few anomalies which I eventually traced to a few faulty SLT components.
In one case I managed to trace the fault to a particular SLT gate, and verified the fault by swapping its board with an identical one elsewhere in the CPU (there was a cross-reference in the manual of where each type of board was used.) I eventually isolated it to a single input to a three or four input gate, and worked out that a single diode strategically placed on the back of the board would resurrect it. It worked!
In another case I managed to swap a faulty board into a position which didn't use the failed portion. Other than these, and the CCROS problems, the machine had survived about 10 years in storage remarkably well.
With the CPU sorted out, my attention turned to the disk storage. I had got sick of manually entering programs, though at least they stayed there forever (I had several programs scattered through the 64k space.)
As far as I can recall, the 2841 worked straight away. It didn't have CCROS microcode, but rather TROS, transformer ROS, which was a sort of second cousin which used small transformers to sense copper tracks on plastic strips. Depending on where a small hole was punched, the track would either go through, or bypass, a ferrite loop. I think that TROS was faster than CCROS, but wasn't so readily modified.
Each drive was connected to the 2841 by two cables, one data cable directly between the two, and one control cable daisy- chained from one to the next, somewhat like the ST506 cabling arrangement. Each drive could seek independently, but only one could be transferring data at a time. The 2841 had no buffering capability - data had to go down the channel and into the CPU as soon as it left the drive, at the rate of 145kB/second.
The heads on the 2311 drives are hydraulically actuated, and for their size move at astonishing speeds. With the weight of the head assembly, it's no wonder that whole drives can move during vigorous disk accessing. A lot of the hydraulic fluid had leaked out, but I drained one drive which gave me enough to top up the other three.
I picked a disk pack that didn't look important, fitted it, and hit the 'Power' button. It spun up as I watched nervously. Once it was up to speed, the heads slowly moved out onto the edge of the disk, loaded, and then there was a bang-bang as the head assembly seeked into the centre and back again. This turned out to be quite normal, but at the time it gave me a great fright, and I still don't know the real reason for it. Maybe it's just to get any head crashes over and done with right away.
By this time I knew that I should be able to set the address '190' on the front panel switches, and hit the 'IPL' button to boot the system up. I found the pack marked 'SYSVOL' and mounted it on drive 190. Once it had spun up I pressed IPL. The console typewriter sprung into life, banging out a prompt for the current date. I think it took me a while to get past this as I didn't have any manuals and didn't know exactly what it wanted, but eventually I had my own running DOS/360 system.
This was quite amazing, as the only DOS systems I had ever used were CP/M and TRSDOS, and here was something with a whole new terminology. At the same time, with only a console typewriter, there wasn't much I could do with it. There must have been a line printer and card reader with it at some stage, and the whole operation of the system was centred around being able to feed JCL in through the reader.
Luckily, a friend of a friend lent me a small DOS handbook which listed all the commands and proved invaluable. John Machin, I'm sorry I never gave it back! I went through the disk packs I had, looking for interesting programs. As far as I could tell, the machine had been used in a typical commercial billing environment. I never found any interesting data, not that I looked very hard. I was more interested in the programs, and trying each one out, as well as trying to extract COBOL source using the library utilities.
I managed to order some manuals from IBM, on the 360, DOS and COBOL. They must have wondered why anyone was ordering them, but to their credit they didn't take long to arrive and they were very cheap. I was a little coy because I wasn't too sure about the provenance of the machine.
Sometime around December 1982 I had a stroke of luck when I saw advertised an IBM 2203 RJE (remote job entry) station. This was being disposed of by a government department, and they put it up for tender. I tendered $151 for it, and got it. I think I was the only tenderer - I could probably have saved $150. The boss of the office that had used it was quite amused, maybe they expected to get $10000 for it or something.
The RJE station consisted of a card reader and a line printer. As I didn't have a card punch, automatic or manual, the reader wasn't much use, but the printer was. Unfortunately the whole system was designed to run to a mainframe via a modem, so access to the whole thing was via a serial link, and these were somewhat lacking on the /360. Still, once it was moved into the office I was able to play with printing out the test card deck, and again it came with a good set of manuals.
The printer was a reciprocating band type, in which the typeface moved back and forth, and a hammer in each print position fired as the appropriate character went past. With a full upper-case alphabet, and numbers, I think about 44 characters, it would do 300lpm, which would still be quite respectable. It made an awful racket, as the hammers were all cocked back for each line, then fired with a screech.
Anyway, back to connecting this station to the system. I decided that if I was going to do anything much I would need to have some way of getting data in and out other than the console typewriter. There was nothing for it but to design my own multiplexer channel peripheral. I can't believe it now, but with the benefit of the operation manuals, circuit diagrams and the microcode listings, I was able to deduce the operation of the channel.
I decided to make a unit based on the 6802, as I was familiar with 6800 programming, and worked out the minimum amount of add- on circuitry necessary to talk to the /360. Not having any spare channel cables (and because a channel connector would be larger than the whole microprocessor assembly), I wire-wrapped a new connector onto the appropriate points within the CPU and ran a piece of flat cable out to my little unit, including power feeds.
The channel interface circuitry was quite tricky, as the 6802 couldn't respond as fast as the 360 required, necessitating the use of latches and comparators to respond to the device addresses. Luckily, once a transfer cycle was underway speed wasn't a problem. All transfers were done a byte at a time, there was no buffering and no use of 'burst' mode.
The 6802, together with 4 6850 serial chips, looked like 8 independent subchannels, numbered 8 through F to tie in with the default device assignments. The 6802 could cope with all 8 running simultaneously. I can't remember how I set the baud rate for each channel, I think there were rotary switches. The RS-232 handshaking lines were used as the status indicators when a program queried the device's readiness. One full-duplex RS-232 link was run to the RJE station, and another to a "System 80" (TRS-80 clone) which served as my data entry station.
I did have a few mysterious problems with my device causing the CPU to stop with a channel check for no apparent reason. It happened so rarely that I couldn't track it down, but it was a bit annoying (pun not intended).
That aside, I was now able to invoke the COBOL compiler, feed a program in from the System 80 and produce a listing on the line printer. I wrote a few simple programs in COBOL, number guessing games and the like, but my heart wasn't really in it. The fun had been in getting the whole system going - once it was going I had no use for it.
After that the system languished. I occasionally fired it up to demonstrate it, but eventually I gave up paying the rent on the office and had the power disconnected. The building has gone through several owners since then. At some stage someone broke the office door down and stole the bookshelf that held my manuals. I haven't been back there since.
My experiences with the system have proved useful. I have a great respect for IBM hardware, and for the effort that goes into the design of any system that complex. I am glad it wasn't a 360/91, that little /30 was a lot cosier.
Lawrence Wilkinson
Auckland, New Zealand
May 18, 1993
--
Lawrence Wilkinson ---
"It is said you learn from your mistakes.
If so I must be an absolute genius!" - Tony Rudd