2. UBC (University of British Columbia)

posted Oct 30, 2010, 5:30 AM by Jeff Ogden   [ updated Dec 26, 2014, 6:50 PM ]
In 1968 the Computing Center at the University of British Columbia became the first site after Michigan to install and run MTS.

The following is from two articles posted to Tom Valerio's MTS Wiki in late March and early April 2005. Not sure who the main author was, but it was certainly someone from UBC.  If I had to guess, I'd think it was very likely John Hogg, although when he was asked in October 2010 John wasn't sure.

From http://mtswiki.westwood-tech.com/mtswiki-index.php/MTS%20at%20UBC:


In 1967, the Computing Centre at the University of British Columbia was offering services to the campus based on an IBM 7044 model 2 running IBSYS. The first director of the Computing Centre had left to pursue other interests at the centre of the universe (Toronto - this is a Canadian joke) and had been replaced by Dr. James Kennedy. Dr. Kennedy had previously been in charge of computing at the Chalk River site of Atomic Energy of Canada. The associate director was Alvin Fowler. The 7044 was running flat out 24 hours a day and its limitations (slow CPU, small memory, all of 10 megabytes of disk storage) were widely recognized on campus. Dr. Kennedy and Mr. Fowler embarked on the difficult political task of persuading the University management to commit an outrageous sum of money to acquire a replacement computing system.

The technical members of the CC staff, blissfully unaware of the nature and size of the political challenge (we were all much younger then), champed at the bit while waiting and spent their spare hours reading every scrap of information they could find on candidate replacement systems. This, you will recall, was before the Net, so it involved visits to the Library, heavy paper proceedings of IEEE and IFIPS and ACM conferences, and every piece of literature the various vendors would send us.

When the UBC administration finally (reluctantly) gave the goahead, we were ready with an RFP for vendors. The serious responders were GE, Univac, and IBM. To cut a long story short, the finalists were Univac (the 1108) and IBM (the 360/67). There were two major factions in the Centre: to oversimplify a lot, those who preferred the 1108 liked its resemblance to the 7044 (word machine, good Fortran compiler, high floating point performance per dollar) and those who liked the 360/67 (while holding their nose about the vendor) liked its future possibilities (byte addressing for text work, virtual memory). The directory (Kennedy) made the 360/67 decision based on a belief that  time sharing and virtual memory would be better elements to build a future on.

The fact that IBM had recently admitted that TSS/360 was not ready for production use meant that we would not have an operating system which would provide either time sharing or virtual memory. Kennedy posed this as a challenge to the staff. We thought this was neat, little realizing that he was betting his job that somehow we'd find a solution to this problem. So we embarked on the task of designing and implementing our own operating system. A subset of the staff rapidly came to the conclusion that we were not up to the job. They said so, and this generated no little heat. Our regular design meetings were degenerating rapidly when news arrived from two different sources that the University of Michigan was working on a system for the 360/67 called MTS.

After some long distance phone calls with UM management, two UBC staff members [John Hogg and Peter Madderom] went to UM to evaluate MTS. The UM CC staff [Mike Alexander, Don Boettner, and others] were most congenial and helpful during the visit, and they converted the UBC visitors into enthusiastic evangelists. Truth to tell, they had an easy job of it. UBC had committed to the 67, they had no operating system, and UM had one they were willing to share. What other conclusion would a reasonable observer expect?

The UBC visitors [John and Peter again] returned later in the summer of 1968 and spent weeks in the famous basement of the UM Computing Centre [North University Building on UM's main campus]. Working with UM staff [Mike, Don, and apparently just about everyone else on the staff pitched in], they helped copy endless reams of punched cards (!) onto several reels of tape which they took home as MTS Distribution 1.

UBC made various contributions to MTS. You should note that none of these contributions was made in isolation. In other words, UBC didn't do all the work on these parts of MTS. MTS was very much a cooperative effort, even in its very early stages. Anyway, here are a few of the MTS components which originated at UBC:
  • The 2260 and 3270 DSRs - Device Support Routines for IBM CRT terminals
  • The Resource Manager - a spooling system on legal steroids
  • Plus - systems programming language
  • CLParser - command-language parser
  • Forum - teleconferencing system
  • CDUpdate - patch equivalent
  • Interactive FORTRAN - a FORTRAN interpreter
  • STASS360? - a fast assembler for use by students
  • Virtual machine? - the MTS virtual 360/370, used primarily for system test and debugging

From http://mtswiki.westwood-tech.com/mtswiki-index.php/Installing%20MTS%20Distribution%201%20at%20UBC:

Installing MTS Distribution 1 at UBC

MTS Distribution 1 was ready well before the 360/67 was. Of course, this just about drove us insane.

John Campbell's father had a connection to a business in Burnaby that had a 360/50. John said he could get us some midnight shift hours on that machine. Peter Madderom enthusiastically volunteered for the task of performing surgery on UMMPS to remove the virtual memory support. This was difficult, but feasible, because UMMPS was originally LLMPS, which ran on vanilla 360s. Taking the virtual memory support out that UM had painstakingly added was a retrograde step, but hey, any way we could actually get something running was worth considering. John Campbell had experience with DOS/360 on the 360/50, so he undertook to get the source code off the tape and assist with making the assembly code acceptable to the DOS assembler.

Peter and John managed to get a severely crippled UMMPS and MTS running on that 360/50, and it wasn't an idle exercise. Peter learned things about UMMPS that served us well in the following year.

Our 360 hardware configuration included a 360/67 CPU, 768K of memory, a 2301 drum, and 2x2314 disk units, for an astounding total of about 400 megabytes of disk storage. We had to build a new machine room in the basement of the Civil Engineering building to house it. The trucks arrived in November of 1968 and a team of about a dozen IBM Customer Engineers began the arduous task of assembling the pieces. It took them a couple of weeks. They arrived in jackets and ties, of course, but because this was a university they removed their jackets and ties when no IBM manager was on campus.

To say that IBM was unhappy about our decision to run MTS on their precious hardware would be to understate the case. They were downright upset, and they said so to the University administration. Sober IBM executives in blue suits let it be known that those young whippersnappers in the Computing Centre were taking liberties with very expensive IBM hardware. IBM thought we ought to run MVT while TSS/360 matured. We had visited a university (UCLA) that ran MVT on a 360/75, and their systems people had unprintable things to say about the suitability of MVT for university work. You can imagine how keen were were on that idea.

IBM had written into the lease contract that they would certify the 67 with MVT before turning it over to us. Oh, how we chafed at that. All this lovely new hardware sitting idle on the midnight shift and we couldn't play with it.

From time to time, Dr. Kennedy would visit us and ask delicately about our level of confidence that we could make MTS work and that it would do useful things for our campus users. Our confidence was unbounded. Whether it was justified remained to be seen.

We finally cheated. We promised the CEs that if they let us tinker with the machine after midnight, we'd never ever, ever, tell anyone about it. Cross our hearts and hope to die. We pleaded. We put on our best innocent smiles. We brought them pizza. They finally caved under the relentless pressure and identified a 2314 disk pack we could use. Then they left at midnight and pretended they didn't know what was about to happen. What happened was that Peter booted a deck of cards he had prepared on the model 50, copied the contents of a tape to disk, booted the disk, and after a few minor hassles we were greeted with the MTS prompt on the console. We felt an immense weight fall off our shoulders, and that taught us that we hadn't been quite as confident as we had been saying we were.

After the Customer Engineers signed off on the hardware installation, the IBM Systems Engineers took over. It was their task to build OS MVT for our system and show that it would run successfully. This involved booting the sysgen software from tape and processing the system definition in phases. The guy in charge of this was a really nice SE by the name of Terry McKim?. It must have been a difficult job for him. All the UBC technical guys liked him personally but hated IBM. He, being a true career IBMer, believed in IBM. There we were, looking over his shoulder while he defined stage 1 on sysgen on cards. We were also looking over his shoulder while he ran sysgen stage 1, which took some hours of tape spinning and generated a deck of about 2,000 cards which was input to sysgen stage 2. Terry was a remarkably nice guy. If I had been in his shoes, I would have told us to take a hike.

Stage 2 sysgen croaked. Perhaps partly because we had been looking over his shoulder, Terry had specified our disks in his stage 1 definition as "DASD". This was a generic type which was unavailable until after stage 2. He should have specified "2314". He was faced with going back to his original stage 1 card deck, changing one instance of "DASD" to "2314" and spending another few hours watching tapes spin.

I liked Terry. Plus which I wanted to show off. So I said "Terry, take a break. Give me 15 minutes with the machine." "Why?", he asked, not unreasonably. "Watch", said I. I booted MTS, signed on at the console, loaded the cards into the reader, copied the cards to a file, started the MTS line editor, changed all instances of "DASD" to "2314", copied the file to the card punch, and handed Terry a brand new tray full of cards that stage 2 sysgen would accept. I think  that was the first time that one of the local IBM people started to get the idea that maybe there was something to this MTS stuff after all.

Eventually, IBM handed the machine over to us. By early January, we had real live campus users on the machine. We didn't get much sleep over that Christmas "holiday", but we had a lot of fun. As we said at the time, we got our 67 in 68 and put it into service in 69.

An e-mail from John Hogg

[Sent to Jeff Ogden and Mike Alexander in late October 2010 in reply to some questions from Jeff. In the following "MVS" should probably be "OS/360-MVT".]

Bruce Arden came to UBC at the invitation of the nascent Computing Science department (which I don't think was a department of its own at that time). The talk he gave wasn't MTS related, but we had heard about MTS and the Computing Centre people (including me) mobbed him after his talk to ask him about MTS. I can no longer remember how we had originally heard about MTS. I think some prof had been in central Canada somewhere and had heard about it and passed on what he learned, so we were primed for Bruce when he came to UBC.

The background was that our director (Jim Kennedy) and his second in command (Al Fowler) had gone out on a limb and ordered a 360/67 because they believed on principle that virtual memory was a key resource for a time sharing system, and their mandate from the university was to provide a time sharing system for campus wide use. They went out on a limb for at least 3 reasons:
  • They didn't have any personal experience with a virtual memory time sharing system. Neither did anybody else at UBC.
  • TSS wasn't ready and the prospects weren't good.
  • There were people on campus who were strong advocates for a Univac 1108 (mostly engineers who thought that computing == Fortran).
  • If we hadn't been able to do something reasonable with the 67, Kennedy's name would have been mud.
IBM Vancouver's plan B was to run MVS while we waited for TSS. So we visited UCLA where they ran MVS on a 360/75 (so many console lights! ). We were accompanied by an IBM Vancouver SE who was a nice guy but out of his depth. We walked into the machine room and were introduced to the operator. When we explained who were and what we were there for, he got passionate. He grabbed us and took us over to the console and said "Look! See that? That's the wait light. When that's on the system is doing damn all. See how it's on almost all the time? OK, now come over here. Here are two strings of 2314 disk drives. 14 drives available. 13 of them are like the CPU. Doing damn all. Just spinning. Come over and get down close and look inside this one, the 14th one. This one is beating its brains out, seeking like crazy. This is the MVS spool disk and for reasons known only to God and IBM this stupid operating system spends all its time thrashing the job queue on the spool disk and doing no useful work. I wish we had our 7094 back. It may have been obsolete as far as some people were concerned but at least it would get some work done." Of course that's a reconstruction, but it conveys the impression we got. Our IBM SE was mortified and upset. We assured him we wouldn't say anything in public about the experience because we knew that if it got out he might be scapegoated. And as I said, he was a nice guy.

The Computing Centre Plan B for the TSS fail case was to write our own operating system. Don't laugh. Or do laugh, it was laughable. It wasn't completely crazy though. Kennedy thought it might be possible because he had previously been in charge of computing at Chalk River and they had written their own operating system and compiler for their computer - paper tape in, printer out, single thread batch. It was not a trivial accomplishment, but writing a time sharing system for a virtual memory system with terminals and disk drives was a task of a different order. I attended the so-called design meetings but rapidly turned off because all the discussion was about low level trivia like allocating space on disk drives. They were all good guys and meant well, but this task was well beyond us. Me included, I knew enough to know there was no way I knew how to do this. I didn't even know what questions to ask.

So when Bruce Arden showed up he was a straw to grasp and we grasped hard. I think he was a bit taken aback by the intensity. We were drowning and he looked like a life raft. He was careful to explain that UM didn't consider MTS a production quality system yet and it might never be if TSS was a success. From our point of view an operating system in the hand was worth any number in the bush. So he kindly agreed to arrange a visit.

Peter and I visited UM and yes, everybody was really nice to us. It was a treat. Here was a real 360/67 (we hadn't seen one before) and it was in a university and real live university profs and students were using it and getting work done. Wow! Cool! Gotta have one of these. Please? Pretty please?

Peter and I must have slept during that visit, but not much. We were soaking up everything we could, and lots of people answered our fevered questions. I can't remember who all was part of it. We spent most of our time with Mike and Don, and one of the really good parts of the experience was that in spite of the fact that they were justifiably proud of their accomplishments, they were honest about the limits of MTS as well as its advantages.

We went home and worked hard at selling MTS. After all, how many choices did we have? I believed that we either made MTS work or we were up the proverbial creek. Thinking back, Kennedy and Fowler must have taken a really deep breath before risking their campus reputations on these young crazies who seemed to think that programming around the clock was fun. But then they were more than smart enough to realize that they really didn't have a whole lot of options.

So Peter and I went back to UM, and this time most of the Computing Center pitched in to make Distribution 1.0. It was exhausting and exhilarating all at the same time. I can still just barely remember what the basement smelled like. It was kind of musty and dusty and busy and ugly fluorescent light but full of people who really passionate about what they were doing. We were on an adrenalin high the whole time. Slept all the way home, after some difficulty getting the reels of tape through Canadian Customs ("Magnetic tape? What's that? Is this movie film? No? What, then? Go get the supervisor. You two wait over there.").

So then we got home. No 360/67 yet and it wasn't due for a couple of months. We cadged some time on a 360/30 in a local business - they didn't use it at night. Peter grabbed the UUMPS source off tape and managed to devolve it back to its previous non-DAT state and get it running, sort of, on the 360/30. We didn't get MTS running, but the experience was useful.

Meanwhile IBM was politicking. The idea of running a non-IBM operating system on their precious hardware was deeply offensive to many IBM people. When I say deeply offensive, I mean some of these guys literally would not talk to us. Mind you, we were probably offensive in our own way. So some IBM Canada brass leaned on the University brass in the way IBM used to be able to do back when they ruled the computing roost. They managed to impose a condition: they wouldn't turn the system over to us until their SEs got MVS running on it. They claimed it was a necessary part of the hardware certification process. Bullshit.

The hardware arrived. In multiple semi trailers. It took a whole day just to move the boxes into position on our brand new shiny machine room floor. Then came the agonizingly slow process of bringing it up. We were officially forbidden to touch it, but they couldn't keep us from being in the machine room and watching. Not unless they brought in people with shotguns, and they weren't quite up to that.

Peter and I were really antsy. Really. Put yourself in our shoes. We were committed to make MTS work, and we still weren't really 100% sure we could do it. Here was all this delicious state of the art hardware, all shiny and new, and it was in our very own machine room, right in front of us, and we couldn't touch it! For days! It's a wonder we didn't explode.

A few days into the process, we embarked on subversion. The hardware IBM guys were there 24 hours, albeit in shifts. The software guys wimped out: they were working 12 hour days. Dilletantes. But we got along much better with the hardware guys than we did with the software guys. So one night at about 1 am, Peter and I started sweet talking the hardware crew. The hardware had passed all the hardware diagnostics, so the machine was basically working. There really wasn't much for the midnight shift to do. We promised we wouldn't tell anyone, so could we please have the machine for a few hours? Come on, take a break. So they agreed. We went into blitz mode and after a lot of IPLs and some false starts and some core patching from the toggle switches on the console, we got MTS up. I didn't fully realize how tense I had been until I realized how relieved I felt.

That's not quite the end of the story. We could relax, but the IBM software guys were still trying to get MVS going. We started to feel sorry for them. They knew that the work they were doing would be thrown away, but they had to do it anyway. And we hadn't exactly been considerate.

Late one evening, one of the better SEs (the same guy who had been to UCLA with us) had managed to get first pass SYSGEN to work and had punched out a deck of about 2,000 cards for input to pass 2. Yes, cards. He started up pass 2 and discovered he had made a mistake. The generated card deck said "UNIT=SYSDA" in a few hundred places but pass 2 SYSGEN didn't know about those generic names. If I recall correctly, it was pass 2 that defined them. It wanted "UNIT=2314" in its input. So he was crestfallen. Back to pass 1.

So instead of sneering, I offered to help. How? Give me the machine for a while, take a break. I dug out the MTS system residence disk pack we had squirreled away, IPLed MTS, read the card deck into a file, used the editor to change all instances of "UNIT=SYSDA" to "UNIT=2314", and sent the result to the card punch.

I think that was the first time that a local IBM guy got an inkling that maybe there was some substance to this MTS thing.

When I asked John if it was OK to use his e-mail message here, he added the following qualification:

Of course you have to discount appropriately for the failings of memory and the tendency I share with many people to dress up a story ... still, I think it's a fair representation of how I felt, even if some of the factual details might be disputed by other participants. The basic facts are accurate as far as I know.

The following appears as part of footnote 59 in Soviet-American Computer Trade: A Facet of International Interdependence, Michael John Mcghie, Masters Thesis, Department of Political Science, University of British Columbia, 1979:

59 Ron McQuiggan, "In the Beginning: How MTS Came to UBC", ComputerData, Vol. 4, No. 3 (1979), p. 12.

ComputerData is a long defunct Canadian computer magazine. After several years of searching, we finally found a copy of the one page article.