The interview date is unknown
Tague: ???????????????? But you and I were in Boston I guess at the same time. I was at MIT from September of '58 through February of '60.
MSM: I was there September '57 through June of '60.
Tague: Yeah, Okay. I spent a summer, I guess it was the summer of '56 I was at Wesleyan doing my undergraduate work after 4 years in the service in the middle of my checkered academic career. And I was sent up there. There was a 704 that was being run that IBM had 8 hours of and MIT had 8 hours of and a consortium of New England universities had 8 hours of. Wesleyan was part of the consortium. My professor took mercy on me one summer and gave me a grant to go up there in the summer to learn to program. Fernando J. Corbat`o, who I met again in the '60s on Multics, turned out to be my instructor in that course. That was my first real program for the 704. We had programming courses at Wesleyan but no machine and in retrospect it was really rather silly. We had a professor from Yale, an astronomer who came up and had us writing things on coding for him, and for ??????? in that era. I started out in physics and discovered indeed that, one, I didn't much care for the laboratory and, two, I didn't seem to have much talent for physical intuition of certain sorts. And math was easy but boring. And when I went away to the service they cleaned house in the Math department in Wesleyan and brought in this fellow [name] who was really terrific and brought in some real mathematicians. In correspondence courses in the service I had discovered what mathematics really was all about and fell into the camp of pure mathematics for a while there until I made some judgments about what my talents were in that area and my interests. ?????????? career at MIT.
MSM: So you went to MIT as pre-math?
Tague: Yes. I worked with Art Madduck who I guess just went emeritus as being head of the department. I did my Masters' Thesis under him. I edited a Ph.D. program and after a year and a half; looking myself in the mirror saying what are you going to be when you grow up and said let's get out of here and do something with it. I came down to the Labs. When I was in the service I discovered everything good in radar was done at a place called Bell Laboratories. I subscribed to one of the company magazines. I had a girlfriend who worked here one summer. I asked her to get me subscription to BSTJ and she got me a subscription of the Bell Labs Record instead. It was all right. I got some idea of what was going on. Those were exciting times. Shannon was around here. There was a lot going on in information theories. Still see some of those guys who were in early computing.
MSM: So you started out with systems research department? And doing ??????? simulation?
Tague: Yes, there was a program, indeed the program that when I got here there was a program that had been written by an electrical engineer under the guidance of my supervisor there, a fellow named Runyon who was interested in telephone traffic. He invented something called the sequence diagram which was just a diagram, kind of a block diagram, of the steps in call processing. In looking at these diagrams which he was putting together to understand the phone system at that time was a lot of interest up in research. They were doing PCM research and the T1 digital stuff was just coming in; I missed T0, actually, the very first micro and digital links. And they also had a system called diad which proved to be a fairly prescient runner up for toady's digital telephony. In trying to understand how the phone system worked John had put together these diagrams. He recognized he had the idea by his little marks kind of running through this diagram. I could actually simulate the office if I move them along according to these sort of timing machines. A professor from Wisconsin named Dietmeir came in for a summer and at the end of the summer he had 3000 lines of absolutely unaccommodating assembly codes that didn't work. My first assignment when I arrived in February was to work with a fellow named Jeff Gordon who was in Transmission and had some interest in the application of this, straighten it out. And Jeff had put some comments in it so the structure was a little more evident. I made the thing run and I really made my research career out of it. It turned out to be one of those really neat deals that I took it around and I simulated everything from missile traffic for the early Nike stuff to the telephone offices to the traffic at the World's Fair buildings to elevators at the Holmdel open house to factory lines down in Western Electric. It was really terrific. I got a really nice view of the company. And the program that Jeff Gordon got in one of these binds where his organization was moving south. He wanted out of his organization but they froze everybody. Meaning you have a choice. You can either quit or you can go to Holmdel. And he said he had no problem going to Holmdel, he didn't want to go with his organization. But that didn't wash. He went off to IBM carrying the program, which showed up a couple of years later as the general for the system simulator out at IBM, GPSS.
MSM: This was the forerunner of GPSS?
Tague: Yes, GPSS. At that point I was in research and by this time it was getting rather burdensome to in effect to spend all of my time running around helping people run simulations. So when GPSS came along they said use that, it's essentially the equivalent and I began the SDS and went off into what eventually became the Multics project.
MSM: What did you do in the Multics project?
Tague: I was in a couple of roles. First of all they got me involved with the documentation. Everything was done in triads. And there was a firm of Haig, Tague and McGee that were the GE, MIT and Bell Labs pieces that tried to get the documentation automated. They didn't think they could use CTSS to get this done so we were trying to use some punch paper tapes systems and other primitive stuff. I volunteered to do that because I became secretary of a triumvirate which was really ??????? started out with 3 people who were really running the project at the operational level. I became secretary to that committee which gave me a preview of what was going on and after a year or so was charging my obligations to get the documentation scheme going. I protested and got assigned to interprocess communication. I got to work with Jerry Saltzer designing that. And that brought me to about '67 where it was pretty clear to me that contradictions inherent in this 3 headed monster were not going to lead to success so I decided to get off the sinking ship before the last raft left and came over here to Whippany where Safeguard was going on.
MSM: I'm going to stop for a second here and talk a little bit more about Multics. What had attracted you to that project in the first place?
Tague: Oh, that's pretty simple. There was a, ... as I say, I got into simulation and when I got into simulation one of the things you ran up against, of course, was the deficiencies that occur in languages and so forth. And we had macro [fat] but I wrote my simulator. I did a re-write of it along about spring. I said I came in February of '60. I had the program running somewhere around March and in March I discovered there was a fatal flaw in the method of timing. There was just a basic logical flaw and I went to my boss and said I think I understand this program. I want to throw it away and re-write it. And he recoiled in horror and said don't do that. But I duplicated the deck and went home and did it anyway. And we came back and said I did it anyway. Tom and I got it running. How do you like that? He said that's terrific and then we went on from there. And then I re-wrote it from a 7094 series which was coming in the spring and I can really revise this thing and use the macros. And I got into data structures in a fairly heavy way and it became apparent to me that the real key to this program was really the data manipulations and well, things were not very well understood most days. But basically the eventless timing was something we invented and embedded in this program and those 2 things said that there was a pretty clear way to put the program together. I got that one done and set some records on the number of lines of working codes produced which is something I'm happy to brag about. But to be perfectly honest about it that was simply if you really thoroughly understand the program and are writing to a spec that's as good as that it really is pretty to set records. But it was a good deal. But that had shown me that the operating system first of all was lacking some things I needed. One of the things for example in those days, when you put your job in you put in an estimated running time with the operators but the operators thought they could tell when the program was looping. A simulator is basically a big loop and they couldn't tell when it was looping because subtle changes that would go through this thing weren't evident looking at flashing lights. They kept cutting my damned program. At some point in that era why IBM came in with a clock that was programmable so I can put on the card how much I'm willing to spend and then the rule was keep your hands off and if I get a, you know... occasionally would have a runaway which they had cut it. But it was a much better deal. And that got me involved in the operating interface with the Thesis series at that time. And there was a re-organization also where the computing systems research and those in acoustics research and those in math research and some others all kind of got blocked together under a math center Henry Pollack took over.
MSM: When was this?
Tague: This was probably around '62-'63. Somewhere around there.
MSM: Is this when computing research started?
Tague: Yes. Ed David came in. Let's see, Ed David became our Director with Crowley as head and David became executive director and Crowley became director on the Multics project which was starting at about that time. I'd gone down to an FJCC, a fellow joint in Washington in which there was a TRW system described down there where they took 3 screens, I think. It was quite elaborate for that day. It completely took over a rather sizable disk machine. It was a 650-like machine made by TRW, a brand that no longer exists, Bendix maybe, I don't know. But the thing that was intriguing was this was one of the first interactive systems ever put together. It was an interactive system to do mathematics. It essentially handled numerical analysis and algebra in a peculiar mix. And it would put up in real time it would graph equations for you and so forth. And there was a good paper given by somebody who had solved a significant mathematical problem. The problem was I think a differential equation solution and there were 3 or 4 other papers at this FJCC which was speaking to interactive use of computers. And I came back from that and I was sort of singing for my supper and gave a seminar within the research department saying we really ought to get in to this time sharing stuff. We didn't probably call it that at that time which we really ought to build our operating system to be interactive. And I was not the only one singing that by a long shot. There were a lot of people and essentially during that time why Ed David I know heard my talk. We talked a little bit about what was going on and out of that came the nucleus of the Multics project. The machine generations were changing. IBM was not doing ???????? in 7094. They came in with a 360 with a long suffering salesman who everyone felt quite sorry for. He was a very competent individual. I think he was carrying the message up to Poughkepsee repeatedly. You're not offering these guys what they want. You kept telling them to go back and sell them what we've got. And that ended up in a bidding war between GE and IBM which IBM won. I mean GE won. And I remember vividly that on the last day of acceptance of proposals a limousine from Poughkepsee raced up to the door and dropped off this proposal to the receptionist at Murray Hill. And it was the TSS system. But that was too little too late from our point of view. We'd been working with GE and they had a very good designer down there, I can't remember what his name was. He was the designer of the 635. And it just looked a lot better to us. And I'd say it didn't hurt that they had 6 bit bytes in a 36 bit word ?????? conversion from what we had was easier and of course in the event the TSS proposal was picked up by the switching people who were then down in Holmdel and who ????? the TSS out there, it eventually became an effective product for them at about '69 or thereabouts it actually began to work and at the same time GE went belly up in the computer business and Honeywell took it over and things looked good for a while. Honeywell ???????? basic structure of that project of course was kind of crazy. GE was in it to get into the computer business and get out a product. The deadlines of some financial accountability. MIT wanted to write the specifications of the ultimate operating system and we had a mixture of the 2 where we wanted researchers to participate in the MIT side of things and on the other hand we had a deadline where supposedly in 6 months or something we were supposed to have this operating system up and running on new hardware. It was just incredibly naive what set off to do. It was kind of recognized as to how much trouble we were in. Probably we were off by an order of magnitude even in our pessimistic views. It certainly was ????? I think for most of us. There were a number of people going on at that point trying to put up new software on new hardware at the same time and it took a while for people to learn that you have to do some kind of a cross compiling game. You've got to use the machine you've got. Corby wrote a good paper on Multics saying if he it to do over the first thing he would have done was move CTSS over to the 635 and go from there. That's probably a good idea.
MSM: Is this the '72 paper he did on "Multics, the First Seven Years"?
Tague: Yes. But at any rate I came out of Multics in '67. I came over here on Safeguard because I'd always felt that I should leave research and go into management. I was willing to wear a 3 piece suit and that might have been more telling of my talent than doing computing research in competition with some of the folks over at Murray Hill there. I came over to Safeguard and took kind of bath because I arrived here with a group of 8 people and by Christmas I had 70 reporting to me in 3 states and it was just an amazing circus. In retrospect a good learning experience but after 2 years of that I quit and came back to Murray Hill in the Comp Center just at the time that Multics had died. The summer of '69 one of my friends in Research Bill Baker called them all together one day and like Viet Nam he declared victory and got out of Multics.
MSM: He hadn't played any role or done any consulting at all in that decision?
MSM: Was that decision really made right at the time?
Tague: I suspect so. Yes. I think it was Bill, I think it was Bill Baker's decision to make it. He'd insisted from the start that it was a research project and there was a conflict in there from the beginning. Doug McIlroy, who was my boss during that period, had said, if we're going to do a research project on operating systems I don't want to be a part of it. My condition for getting involved in this is that it'd be the operating system for Bell Labs. It'd be the successor for the ?????? chain, and that was accepted at one level. On the other hand Bill Baker was very insistent that this was a research project not a development project and he was certainly right in the way it was run. And on the other hand there were people in Comp Centers such as here in Whippany, who bought 635's [and] had military business critically dependent on it. And there were the Holmdel folks who I say should have bought into TSS and were struggling trying to get something that actually worked there out of IBM and I don't know what was behind that bifurcation but I suspect that ESS was big enough and powerful enough at that time that they could just ????? But Bill Baker I think had one fundamental misunderstanding about the computer business that he didn't really cotton to until the end of the '60's. And that was that computing for research and computing research are 2 different things. I mean the legitimate niche when I was in the Comp Center ?????? was some hapless business coming in with this Fortran deck saying what have you guys done to screw me up? My program ran yesterday and doesn't run today and would you kindly not do me any favors. And perfectly legitimate beef and one that was not responded to at all. I mean the systems research people ran the computer at that time. We found nothing that?????? knocking it down for an hour or 2 in the middle of the day to put up some new stuff or to screw around with. We'd take it down at lunch time and play biological games. Some of which were quite stimulating and interesting. But nonetheless it didn't help the production along very well. It was batch processing so it wasn't what it would be in today's terms by a long shot. You expected kind of a half day turnaround on your job which was kind of the norm. But one of the reasons that I kind of got out of this whole circus was that I was leading ??????? about how computing should be done and they didn't quite agree with the way Research was doing things. But I came back one of the things I was delighted with was that they had made the split and the computers were taken over by a new division formed under a man named Thayer whose job was to take all these disks ??????? who ever happened to get the largest computer at each location first and pull them into a coherent computing service. And that spoke to me because I thought that the right role of this outfit was for the computing research guys to do their computing research on some machines that were appropriate and dedicated to the task and that should be in Murray Hill in Production System which should integrate the research technology with production au lieu and when we ran things to schedule and kept machines up and got service to customers was the primary goal. I came back in September of '69 and at the end of '69 I was offered a job, a promotion to head a department that had a very peculiar history. The government had requested that we put together a planning department. Again I wasn't in on this, this had all gone before I left Safeguard. But I think it was kind of in response to the Brooks Bill. Are you familiar with this?
Tague: The Brooks Bill in Congress was a bill that established how the government should buy computers. And it was a pretty horrible bureaucracy. It's still with us to the day. And it's the reason with these government people it takes them 2 years to get the permission to buy a machine. And then they have all these lawsuits anyway at the end of it. But the whole thing established a bidding structure and made sure that there was competition and the rest of this. And as part of the pressure on the organization... now, at that time Safeguard was something like 20% of Bell Laboratories; I mean it was a big project, multi-millions being spent on it and I think we got big enough that we fell under the Brooks Bill. The Whippany Comp Center here had to buy machines to procure them under these regulations and it was all pretty hairy, and pretty meaningless. The government didn't understand that you can't go out and put bids on a computer the same way you could on a two or three eighths film pencil. Brooks was smarter than that but not smart enough to understand what the degrees of freedom were and not to understand the locking that you had with the vendor unless you buy into their software. So the result was that everything sort of had the flavor of bidding but actually came out to the sole source. So outfits like RCA and Honeywell were offering IBM compatibility packages to try to pull this off and their weakness was typically that their hardware was just not nearly reliable enough relative to IBM's, that you touch with Honeywell and GE machines were multiprocessor ?????????????. One of my bosses said it's a good thing because you need it all. Half the machine is broken all the time. So if you didn't have twice as much gear it wouldn't run. Tape units were just disastrous. But the result of this was I asked them to create a department that would review computing purchases for Bell Laboratories. In any event the way it was set up in the job I was offered was to a head a department which would review every computing purchase in Bell Laboratories with my ED Thayer as head of the computing division had a sign off as to whether you could actually purchase a computer or not. On the one hand it was an impossible charter. I mean we were even then buying computers and many were just starting to come in. But the sales were in terms of hundreds a year and the department that had 2 groups of probably less than a dozen people total. One of the groups was occupied almost entirely with just finding out what we owned and put together the first real database on what computers we had and what they were running, and the other part was doing mixed reviews
MSM: Did the result of that survey surprise you?
Tague: Not particularly. I guess it surprised some people. I mean the growth rates were quite spectacular with all these exponential curves rising up in the prediction that it would saturate and they were met. And it kept repeating itself of course with maxis and minis.
MSM: Was that first list showing mostly big systems or was the mini beginning to show up?
Tague: No the mini was showing. The PEB series was around in a large way and there were many of them around. We also at one point there a little later kept track of terminals. And that was a real surprise as people discovered that there was more than one terminal per technical staff. Typically it ended up being 2 or 3 in the end. But that was a useful thing. One of things we did is we learned to manipulate that database so when someone at the top of the house would ask a question involving computing we almost always could get at, you know, reformulate the question in such a way to shed some light on the problem they were trying to shed some light on by going into this database and pulling some data off and manipulating it a little bit and coming back with it. The real stick was this business of having to sign off on computers and if you know the culture around here that was very much a counter culture kind of act. And indeed after I got the job I was then shown this correspondence which uniformly in the computer committee at that time which would have been the people representing each BP area. They all said that this shouldn't exist. And the good news was a comment from Ed David that if it's going to have to exist then ??????? might as well run it ????????????? But Thayer, the man I worked for, was a guy with some real backbone and some good sense he agreed early on that the thing to do was to choose our targets. That we couldn't review everything. We really rubber-stamped most of it. But if he saw some foolishness going on he'd really dig in and use really as a lever to try to clean up the computing business. And we started out at that time on the outside time sharing business. The total computing budget was probably under $50M in the Labs at that time. $30M of it was going out to time sharing. Outside time sharing sources. We had 35 or 40 suppliers with absolutely no rhyme or reason. It was sort off whatever salesmen did in the offices that made them sign up. We extended and interpreted the charter to say that outside time sharing contracts would cover it. We got sign off on that and pulled them down to 2. We ended up with GE that provided very good time sharing service. Basic and so forth. Based on Honeywell machines. And that fit with a lot of Honeywell traffic we had around. And then IBM VM-based services, VM had appeared on the horizon at that time and we got I think 1 or 2 VM suppliers and cut everybody down to that and just told them if you want to do outside time sharing here's what you do and then internally in the newly formed division to provide computing services we started racing like mad to try to get a time share with a decent interactive approach to Fortran ?????? computing going in most of GE contacts than IBM contacts. GE kind of led the charge on that since they had the ????? a pretty good system, again Multics ?????????????? There was still some Multics going on, research, buy it died pretty quickly. The VM stuff, we started getting into VM I think on some CICS that was tried for a while. Third party system I forgot. But basically we started chipping away at this outside time sharing business to try to bring it inside because we were nervous about having our databases outside. There were some things you couldn't do with the databases fragmented among the suppliers. The cost was getting pretty high. We thought ???????????
MSM: Were you aware of the CMS project that was going on at the Cambridge center?
MSM: Was that at all attractive?
Tague: It was but it came too late. By the time it came we were committed in other directions. The TSS business had really taken over. It was being effective for ESS which said there was a TSS community that was pretty large. And the GE stuff as well as the Honeywell stuff was beginning to work on ??????? so we had more ????? covered on that score. And we tried VM, we tried CMS, but the more popular system was, I'm trying to think of what it was. It was a proprietary system that was mostly interpretive and folks really liked it for interactive Fortran kind of computing???????? The NBS turned out to be satisfactory as far say the design engineering ??????? CAD/CAM ??????? by various minis ?????? But after we got the time sharing cleaned up we then went after consolidation with the Comp Centers and we bid off some budding comp centers in places like Allentown PA and made them go to remote stations to the larger centers of Holmdel and Murray Hill and whatever. And Indian Hill came into the fold. We took over that comp center as part of the division. We bounced off Columbus and Merrimac Valley for good reason. Merrimac Valley is where I can see it most clearly. That was the one place where I got into an argument with my boss because he wanted to fight on standards. And we told him we'd lose, and we fought and we lost. But they had an interesting setup. It turns out that the factory at Merrimac Valley and its attached lab had the property, had several things that came together. First of all they were beginning to feel outside competition. The Japanese and others were getting into the transmission business at that time. So they had to run a little tighter ship. The were the only place in the Bell System or in Bell Laboratories where you knew where your product was going to be produced. That factory was dedicated to transmission and the Merrimac Valley people knew where their designs were going to be produced. They were in the same building. They established a very good rapport with the factory and really started making some CAD/CAM, sort of putting the CIM kind of stuff work. But I'd go up there to talk to the guys I worked with. ?????????? downstairs now ???????? one of my customers again. ??????? The thing that fascinated me was that he justified his computers in quite a different way. He did not charge back by the job. He allocated the cost across his organization. The computing center was dedicated to his center. But it was only a center. It wasn't even a division. It was just one lab that was up there. But the way he justified it was to me absolutely the right way. Instead of talking in the number of jobs they processed every day and the number of ???????? and all this kind of stuff that the traditional comp center used he simply said before I put in the CDC machines and those that were CDC which was a different thing and he did hybrid. You know, he plugged hybrid stuff into the side of the CDC and that's pretty good service now. He said before I got these computers I would take one of my designers and they would turn out 2 designs a year. And they now turn out 10. Take a look at these economics. I can pay for that comp center 14 times over so don't give me a hard time. To me that said, hey, don't screw with this fella. We're down here counting jobs in Holmdel, 50% of which are JCL errors and we're calling it productivity. I said this is the way to do this thing so let's not screw. Well, my boss who also incidentally ran the DDS function and they were kind of out-grouped on DDS. It was pretty much a battle, although we won't get into that. But he lost, he lost ultimately gracefully and we went to Merrimac Valley. And to this day they're not part of my organization. They run their own comp center up there. They still run it with much the same flavor. We've gotten a lot smarter in the comp centers about how we allocate costs and we'll sell you dedicated and allocated machines and all kinds of stuff. That's been a big help in getting us to be more serviceable to our customers' bottom line. But after having done that part of things and kind of gotten the main comp centers under way the minis were then beginning to appear. And the affirmative thing was there were some HP based systems that had been developed by the Transmission folks. And they were measuring, on the one hand they were measuring traffic and on the other hand they were doing things like collecting alarm signals from these remote transmission towers and analyzing troubles and stuff like that, dispatching people. And I ran across a guy, again up in Merrimac Valley who happened, it was sort of accidental, a guy up there who complained that your guys are designing these systems and I have to go out and do bulk sales and the sole source purchases of HP machines. I can't go out for bids. I don't like that. And we talked a little bit and understood the problem and pointed out to him that it's kind of difficult to do otherwise. We really can't ????? around. But I was aware that my buddies in Research were working portability. We'd heard about this thing called UNIX. It actually took place over probably a year and a half but I got to the position where I said look the right answer in this area, we started calling these things Operations Support Systems or Operations Systems and there were a lot of them. So the right thing to do here is get a hold of UNIX, a portable UNIX, and I was able to go to my boss and say look, we put this stuff on UNIX. If you want me to I can fix say 3 vendors and well put UNIX up on those 3 vendors and people can now continue to develop on whatever UNIX they happen to have in their lab and when we go out for bids we can generally go out and among these 3 vendors get them to compete for the volume. The volumes weren't large. The typical problem was a program or somewhere between a dozen or 50 machines. They were typically regionalized. There weren't that many of them. Though there were a few of the smaller ones that had little PDP sitting out in the central offices and data collection peripheral roles, thousands of them. But the Labs wasn't ready for them.
MSM: When was this now?
Tague: This was probably around '73, '74. Yes. To get the timing right I got into the UNIX business. The date that's firm in my mind is in September of '73 I got permission to put together the first UNIX support group in Bell Laboratories. I put a supervisory group together and staffed that up. And at that time I was also interested in supporting MIRC. I thought I'd do MIRC for real time and UNIX for a time sharing kind of application. MIRC never got off the ground. We wasted energy on that. Though MIRC actually got embedded in some of the UNIX line systems that underlined the ESS processors. That stream did continue in a peculiar way. But what we discovered was that the real time part of the business we had in these OSS systems at that point was really handled in one of two ways. You can either write a specialized driver and do all the real tidy stuff down in the driver, or you can buy yourself a PDP8 and quaff it down and put the real time in the PDP8 and the PDP8 would then appear much like it did external in terms of its response needs. And we had to do, the other things we had to do some database activity in there. And the typical thing people did was to put a process up that would manage the database and then we added interprocess communication features. 3 of them. It seemed to be a surplus of things. But I was driven by my customers. When I went into business all of my customers knew more than my people did. So we spent the first year in documenting the product, getting an LDI to Western that made it an official product which is a submission of design information that had to be done. And my people learning to be as good as their customers were in understanding what it was we had. But we quickly got to the point where we understood what the business was and we were trying to gain control of the customers because in Columbus there were a bunch of people who were doing these things and even there they invented 3 different interprocess communication mechanisms which ??????????? smaller number. But typically they'd have it locked in the product and out in the field by the time that you raise the thing up to anybody's consciousness. We ended up just at the end putting in a lot of that stuff in UNIX to hold it together.
MSM: How did you find out about UNIX?
Tague: That was very easy. I left Multics you see in '67 and I overlapped a little bit with Thompson and Ritchie but I still knew those guys in Research and indeed part of my role in this planning job you see really became the planning department for the comp centers. So keeping in touch with Research was one of my officials chores anyway. And at that time you looked around the mini area at the end of the '70's. The typical mini computer operating system was all out like a PC DOS. The PC DOS would be sophisticated compared to many file system. Flat file system, ???????? processing and so on. And Thompson was sort of the legends in the Multics anyway.
MSM: What made him legendary?
Tague: Oh. It was very simple. Vic Vyssotsky was a very good friend for many years. And Vic made the comment, because Vic was sort of heading up the Multics effort at that time as far as his building was concerned. He said Thompson arrived on our premises with a sort of mixed story from UCLA, I mean from Berkeley, saying that we've got this guy out here who's really good. He writes terrific programs but we can't get him to write his thesis and we don't think he's going to make it. When we took him on, and as Vic said, Thompson had shuffled into his office and wrote on the blackboard saying there's sort of a problem here. Do you think it would be worthwhile solving. If you do something about that it would be terrific. Well about 2 days later he shuffled back in and said look what I've got. And it would be solved and solved very elegantly. But I say it was about that time that I departed from the Multics project and spent a couple of years over here in Safeguard, between '67 and '69. But by the time I came back to Murray Hill there were a couple of competing operating systems for minis. There were really 3 efforts that I remember. One was Sandy Fraser had done his spider thing, the forerunner of datakit. And he had some operating system stuff. It was pretty primitive but he did some multi programming things. That was really never much of a contender. But there was a crew not in Research but in a kind of an exploratory CAD/CAM department and they existed in Murray Hill was then under a fella named Charlie Rosenthal. A fella named Larry Rossel who was a very bright guy who subsequently made some contributions to UNIX put together a little operating system that ran the PDP series and looked like it could do some good stuff. And the other one was UNIX. And just talking to people it became apparent that UNIX looked like a class act and Stan Brown who I worked with at Alpac when I was in Research on Altran. He an I did some joint papers there back in the '60's. And Stan was interested in portability and was telling me good things about where we were on ?????? portability, and C indeed looked like B and C and its predecessors looked like a real good deal. I did enough time in development then to understand that it was going to very tough to wean the developers off the macro fat because as long as you could tell them that a compiler couldn't do certain things it was very difficult to get them to write in the high level language. And I would ???????? high speed routine ????? assembly. And B and C offered the promise that they could really write in the sort of semi higher level language from the start. And it was a big seller. C was no problem but the way I got interested in the business was in '62 I saw these guys starting
MSM: '72 ?
Tague: Yes, '72, I'm sorry. I can't get my decades right.
MSM: I know exactly how you feel. [laughter]
Tague: A long time ago. Yes, '72, for example, here in Whippany there were a bunch of people coming off of Safeguard who had gotten into this operations systems business. And I vividly remember the first guy I sold UNIX to. There was a fellow here at Whippany and he'd gotten a crew of pretty good programming talent off of Safeguard. They'd never written for anything but large machines. They'd never done an operating system before or a compiler or anything very sophisticated in the way of systems software. And they had a schedule that said they were going to buy a PDP1120 it probably was at that time. They're going to build an operating system. They were going to write their own language and they were going to compile an application that was going to be in the field in the spring. I came around to review this purchase. And I sat down with this fella, a fella named Jan Norton, a very nice Dutchman. And he and I were eyeball to eyeball pretty quickly because ??????? I'm not going to aprove this. And he got his dander up pretty good at that. I said look, here's the deal. I understand you guys will probably the world's most portable operating system, but what I'm going to insist you do, is you pick up UNIX and that you use it as a basis for your development because it'll get this machine running. And if you don't do that you don't have a prayer. I'll bet you money on that. So I said you can go on and do your own operating system. Of course I knew what would happen when they got this thing up. And they really realized what they were up against. UNIX would be the only way they had a prayer of getting anything done even close to the time schedule. And indeed that was. And Jan was a big enough guy that I got a very nice letter from him along about January. That deal took place in the fall. He said thanks very much. He said if my guys hadn't had the opportunity of reading Ken's admittedly uncommented code [laughter] he said that they would never have learned how to program this machine properly and never would made it without using the UNIX operating system as a base. And I repeated that process with several people and the PDP11 deck had a good reputation. It was clearly the machine they liked. The transmission people stuck with Hewlett Packard and they simply went into some volume price agreements with them and then DEC screwed up very badly which helped us out quite a bit. I can't remember the acronym for their operating system but they promised it eventually it was going to have a whole bunch of features and was going to be the world's most wonderful and be upward compatible. It was none of those. And when they de- committed from all that there was a project down in Holmdel associated with automatic intercept under a director named Townsend who had (a development) who's dependent on DEC following through on this, I guess. And when they bombed on it he really was just ????? and just screwed his schedules. And we made a deal with him that he actually funded me from September to December of '73 to get my department started. Gave me a key individual. A fella named Jerry Vogel who's right down the hall as a matter of fact who joined me as a member of that first UNIX group and put us in business. And we started delivering to him. His people eventually went to Columbus and were part of the nucleus of the operating systems at Columbus which were UNIX based and kind of made the business go. But at that point I was getting kind of tired of the planning job. I've got kind of a 3 year time constant personally. Every 3 years I change things and go to something different. So what I was doing at that time was maneuvering. It was clear that people wanted central support for UNIX. For a developer to take an uncommented batch or code from Research would normally be impossible. But you see these guys had (hooked) themselves. Because they were promising to write their own operating system from scratch. So I could point out to them look, you're going to have to support an operating system so you might as well support one that exists. And don't tell me it's going to be easier to write your own and to beat this guy who's doing his 3rd operating system and by that time it was beginning to get some momentum. So that was a seller. But I knew life would be easier if we had central support. So I went to my boss and in effect what we agreed to do was to split the planning department into 2 pieces. And I took on a department that became UNIX-MIRC development and the planning function went to calling to mind Russ Archer. And he took over all that business in carrying forward. And that really got me started. The PWB programer's workbench was an independent development under a bunch of people that at Piscataway in the BIS project. Are you familiar with this one?
MSM: Ted DeLotta and I were old swimming parents together.
Tague: Very good, okay. Well, Ted was key, Rudd Canaday who's still around was one guy. The inventor of the UNIX file system was down there and he kind of brought UNIX in. Ted was a key guy. Ivan, I said a minute ago, went out to Utah. And Dick Hague. Dick Hague was kind of the guy who became a proprietor of UNIX and he and Ted came in to work for me. They came in about '76. They brought a fella with them named Larry Weir. And a remarkable thing happened because I had some misgivings on these guys moving in.
MSM: Let's get the relationships clear. PWB had started up and then came under you?
MSM: It started up independently?
Tague: It started up independently and it had a quite different charter you see. I was really driven by these operations systems and they needed a database plus a little real time and stuff like that. Dick's thing was simply to put a time sharing front end on this huge array of machines that BIS was committed to. But they got out on a bid per project. So they had Xerox, they had RCA, they had IBM, they had Univac. And it was driving them crazy. Not only that of course the people behind UNIX had sense enough to realize this is really what you needed to edit and compare stuff. The big payoff you see was that they put a UNIX front end down in front of something like an IBM, say ?????? They put the IBM experts to work canning all those terrible JCL sequences and getting them down to the 2 parameters that people actually had to do. They embedded all in a shell and then offered somebody a shell. And they kicked this stuff off and the source would be driven across the channel link and put on the machine to run. The body would be brought back on to UNIX. They could walk over the body on the UNIX files, keep it or throw it away as they wished and all the code control that comes with bill control. They were the guys who made the SCCS the code control apparatus go with the rest. And it was a nice compliment as you see and we had these people doing these kind of real time database sort of things and people doing time sharing system. They were going to come together. We'd each been busily modifying the ??????? to some extent to get this thing done. But I was not looking forward to this clash between my established group under Joe Maranzano and Dick Hague again, and his guy ????? and my guy Tom Rolly. And I thought that there'd be great conflict. And to my delight Weir was so good. ??? [tape fades out, end of side one] ??? We said we'll use the PWB base and put this other stuff into the PWB base; with Larry's help it'd probably be the other way around, and that was a decision I never regretted. Weir was excellent at keeping track of that system and running it in his head. Quite remarkable.
MSM: I heard somewhere there had been some conflict.
Tague: There was, let's put it this way. Weir and Research didn't always get along very well. And Dick Hague was a very prickly character. He was working for me again up until last year. He retired; he's now got a venture operation down in Clemson. And Dick had strongly held opinions which he made no bones about sliding. On the other hand he was frequently right. My arguments with Dick generally were that I really believed that there were such things as large developments and they had to be handled somewhat differently than what I would consider kind of ?????? which Dick was very good at running. And Craig Dodd in Buffalo did work in that in that mode. But he for example thought nothing of changing the system incompatibly in a way that would just wipe out stuff. And his attitude was generally, things are 2 years old they ought to be redone anyway. Well, then there's context in which that is true and probably more context than we're willing to admit, but there are context in which that isn't true and that was where many of the tensions came. But that wasn't a big problem. It was manageable. We got that going and we managed to modulize things so that people could leave some stuff out if they didn't need it. Then we'd work from a standard system base but with sort of add-ons as needed to ?????? it free with the operations systems market or PWB market. And there were very good tools that Dick and his people had produced on the PWB for managing code and doing code control and that sort of thing. Dick was not very patient for that but he appreciated; his managers needed it. We referred to them as a manager's "Linus' blanket," and there was a certain amount of fairness about it. I personally wanted to have a configuration control of some formality and perfection is rarely obtainable. If you can't tell me what it is you're delivering to the field, I'd say you're probably in deep trouble on a project of any size.
MSM: I must say my job down in Holmdel working for Charlie Stenard was to scout out software development environments for the AWIPS project. I was the person who identified RDD100 as the most promising one. Cemented that relationship between Holmdel and Ascent Logic[?] [and] did the report on it. But before that project, before we did not get the contract, one of my concerns was how are we going to interface ??????? that but we were going to have to have some source control with configuration management on line. No question, talking about 200,000 lines of code just for the platform and then a million lines of government code that was somehow going to have to be introduced.
Tague: Yeah, projects like that, you just, you know, they're simply wrong. You can't run those by the senior pants. His retort to that, if he were, here would be to point out those projects were doomed to failure. They never worked anyway. The only way they worked is you break them off into smaller projects that can be run my way. Again there's a certain amount of truth in that. But again you won't get an ESS kind of effort.
MSM: I was watching a smaller project that wasn't doing too well either.
Tague: Yes. In credit to Dick there's not many people I would find as credible in promising to bring a small project off on schedule. He was very good at moving in the requirements, cutting them down to feasibility, hiring a lean and mean team, he very much believed in the 10 to 1 ratio of programmers. He knew who the 10's were and who the 1's were. He'd end up with the 10's and he didn't care what he had to pay. And there's no question in my mind that if you run a project that way it's very effective, cost effective ???? [voice fades out] ??????
MSM: I'm going to back you up a bit. Back to Klein. You said something earlier about coming in and talking about the comp centers, and the need to separate comp centers from the research people because computing in research and computing research are 2 different things. You can't have people tearing down the system over lunch. It seems to me one of the conclusions that we'd follow up on that is you set up the comp center and you take the machines you put in something actually possible. And you say look for computing in research that's the system. But we have a stake in computing research and therefore we ought to let these computing research people have a machine from which they can work. But the big story is that they couldn't get hold of a machine. But they lost their CTSS and their Multics. And here they were in 1969 sitting there without a machine that they named they really could play with. Had you recommended that they get a machine or was there anybody speaking for them?
Tague: No let me tell you the timing on that. When I arrived in '69, Research was really in a blue funk. They'd really been kind of ripped up. And there were a few last folks still working with a Multics that was up on the 5th floor being run as a Multics a few hours a day or something like that. Multics still wasn't working much. ????????? There was a last crew still on the shift. All of whom were no longer there within a couple of years. Joe died rather suddenly tragically, Peter went off to Stanford Research Institute and a few others have dispersed. And the computing research people were asked to divide themselves into 2 parts. When I came over to take the planning job I had 2 directors. Sam Morgan who was a director of computing research. He had a co-director named George Baldwin who had the Murray Hill or Whippany comp center and the Murray Hill comp center piece of this ???????? kind of split off in some way and Sam would manage the transition. And there were a number of difficult choices for people in Research. Because what they're all trying to do of course is they wanted the best of both worlds. They still wanted to influence the production computing but they wanted to do research. They weren't permitted to have that choice. And there were some fairly bitter personal conflicts that got in there. I was working for Charlie Roberts who was the department head when I came back. He was a physicist who co-opted in the comp center. And he was working very hard to make Fortran run in the G codes. And there was one other researchers, a fella named Sterling who had a competing thing called Guts. And Joel was an exceedingly and competent programmer who had already built things that mind you are rather fragile and it took him to keep them going. It didn't seem to have much appreciation of the fact that you couldn't build things that way, that the world just wasn't going to be that regular. He always had logic on his side but logic isn't the winning rule in most people's lives. I got caught between the 2. They're both good friends of mine and actually they're both people who I had known slightly but became friends with when I came back to Murray Hill. I was trying to be at some merger of best worlds here, but that eventually... well, Charlie always had the right idea. He knew he had to have G codes support. He couldn't afford to tinker (with) an operating system and worry that you hadn't done this or there was a whole bunch of custom code and datanet 355 front end which was at least at least a program and Charlie was trying to swim with GE or Honeywell's plans at that time to something ????????? He had continual problems and couldn't support it. And Joel stayed with Research and eventually left the company and basically came over here and ???????? for a while. It was sort of a difficult time and Haming was around at that time and Haming at that time was a department head without a department. He was sort of a ?????????? I was finding it very refreshing, you know finding and talking to other people and some of them would use other adjectives. But the thing I liked about Dick was that he'd sit you down, particularly in my younger years, he'd sit you down and kind of pull you up from the day to day hassle. Particularly when I was here on Safeguard. I was very unhappy and feeling very incompetent as I was wrestling with all these problems and not doing very well at it. He'd take me to lunch and kind of pull me back from all this and get me thinking about what the real problems were in a very useful role and research and take these people and tell them to quit writing papers, go out and write a book which is probably the right answer for anybody but for everybody. But for some people it's a good thing. One of his other quotes I gathered that I always liked is that the problem with computing is that most scientists stand on one anothers' shoulders and computing stand on each other's toes. And he had a sense I think of what computing science as a science ought to be. He wasn't always right about it. He's not one who ranks very high in clairvoyance as to where the business is going in certain ways. But he had a very keen sense I think of what people could do, what they should be doing and how research was going to be different from development and some of those issues. And he was going in to Ed David who was executive director at that time. I remember one of the quotes was, he said, Ed if you buy those guys a machine I'm going to lie down on your floor and scream. ?????????? everybody had just done that. There was a proposal in for PDP10. That was one that again I was in a position at that time, I was going to have to review that PDP10. And I went up talking to the research people, Sam Morgan, as to whether this was a good idea to get this thing or not. Let me back up a little bit. Henry said don't buy a machine until they get their act together and tell you what they're going to do. I think that was a good input. And David was certainly his own man. I don't know how much he was influenced by Hamming, but they go back a long ways together and he paid some attention to Dick. But by and large he did not let them get a machine. And it was partly made easy for him because there wasn't much with the demise of Multics. There were a lot of knives that had been sharpened for that over the years as it kept missing its schedules and screwed up development and so forth. So I think Bill Baker realized he was not in a very good position to go looking for a few mil to buy a machine for these guys if they didn't have a story just what they were going to do with it. And that forced his famous statement that they're going down and playing with left over PDP7s and stuff from the lab to get their thing done.
MSM: If you asked Ken, "What are you going to do with this?" he'd say, "I'm going to build an operating system." Now that would not have been an acceptable answer?
Tague: That might have been an acceptable answer but probably not. I would guess not. And if that sounded too much like you guys just want to do Multics again and this was not the time to do Multics again. One of the observations being made was if Multics was influencing various vendors in various ways and there were some case to be made that you'd see some of these things maybe not on the right path. But I think there was pretty good recognition that the computing business had matured that we're building your own operating system for a large machine which was probably not possible. And on the other hand I think Ken recognized was, about minis, it was not only possible it was needed. And jumped into that window. But you see they were going for kind of a mini. But that PDP10 was not really a mini. The deck couldn't think of it that way. They thought of it as their maxi entry.
MSM: Yes. If I remember it correctly what I've read, it is, "Can we have PDP-7 or a Sigma 7?" We're not talking minicomputers.
Tague: So as I say during that era I certainly wasn't playing much of a role around that time. As I say David I think was just digging in and shortly before David left I think he was feeling the penalties of having of having Multics come in proper and again I don't know any other little stories. But I think it's not coincidentally right now that he ?????? science advisor I think ??????? career ??????. He probably was taking a lack of from this thing. He was very bitter about GE I know. GE kind of backed away from this thing and there was some truth to that. On the one hand there were some other people rather early in the project somebody observing the ?????? that it looks to me like you can do jet engines, nuclear reactors, and computers. Maybe 2 out of the 3 but not all 3.
Tague: That was confirmed. We might have seen that coming.
MSM: Did Dick Hamming play a role in shaping the style of computing research? Is it a very theoretical group, or...?
Tague: Not really. Not really. Let's put it this way. Dick had a blind spot I think on computing and that is I really do believe and still believe that there's a sort of experimental computer and a guy like Thompson who's a typical practitioner in experimental research and computing. And there was a very narrow myth that I think I helped with where Sam Morgan was getting pressures at this time, '69-'70 to sort of turn the computing research department into an entirely computer complexity blah blah blah automota... you know, that kind of stuff. That was computing research. This other stuff was something else. And I spent a lot of time with Morgan pointing out to him that I thought it'd be a terrible mistake not to support this other strain. It may not publish the same kind of papers and doesn't look much like mathematics but it's terribly important and it's good stuff. We need it. We need it very badly. The other place where I personally think I played some role was in the time later on where it looked they were going to get a PDP10. This was about '72-'73. The issue was should they get a PDP10 or should they get a more than one smaller machine. And the machine they were looking at in that context was the first 32 bit mini: the south Jersey outfit; they later became ---
MSM: Oh, I know. Perkin.
Tague: Yeah, Perkin-Elmer took them over and whatever predecessor company was ????????
MSM: They're now, oh I forget. My wife is Princeton's technology transfer manager. And it was that company in south Jersey that took over from Perkin-Elmer and picked up the ????????????? machine. It's a household word for a while.
Tague: Yeah. In any case I intervened as accurately as I could on that. It was the research management saying,. and Ritchie and Thompson himself saying look I think they'll do more for the company if you get a lot of little machines in order to work them together. Rather than one big machine. If you do one big machine then put Unix on another machine. So ho hum so what. And, you know, DEC may have a future in the big machine business but that's pretty iffy. And it doesn't look en route too much. Whereas if you can learn to work a file system with us, clusters of machines and so forth that will be a good deal. It was somewhere in that era that I wrote up a little talk that I gave to Research entitled something like "The Cloudy Crystal Ball" but what I was saying I had this vision we ought to be able to take Unix as an operating system but as a company we can support this as an internal standard operating system along with C in an environment. And then we can then front end a large external agency and commercial agency in this. With the idea that people would sort of see the machine and use a common front. It was not well received by Research.
MSM: Partly PWB.
Tague: Yes. It was a PWB kind of proposal and it predated the PWB I think by a year or so. My story is they may not have appreciated it but it all came true. That really is pretty much the way the business has gone.
MSM: What was their objection to it?
Tague: Oh, just that they felt the right thing to do was to put it all together on one machine. They had a pretty clear picture of what the problems were of making a lot of little ones act like one big one and they didn't think this was very workable. But you see I was kind of coming at it from the developer's point of view. I knew what developers put up with. And there was a lot less elegant than what Research was used to and would it concern a decent support environment. And in that context the idea that you, that you--- and I also understood about you know what a project like ESS needs to make a bill. It isn't going to get done on a PDP10. They're going to be out there looking for the biggest machine they can fine with more bytes than you can possibly imagine and that isn't going to stop. It's driven that way. And you can say what you wish about there being a better way to do this or what have you. But, let's not kid ourselves. This kind of combination looked pretty good. Some of the laboratory things brought in with Unix. There's another tune that we were singing about that time is hard storms were in the system where you'd have a PDP8 in the lab with Unix behind it another elegant thing where you can download C programs. That was sort of a semi-Unix environment where the PDP8 you can sort of program pretty much as though you had full Unix. They would come back to the disk on the big machine across the line and make certain calls that didn't exist in the little machine with all the real timing stuff that was done out there. He had some rather ???? things to do. In the context of MIRC and all that I was trying to get some support for that but there was never a big enough market or enough bucks. I couldn't find a way to get funded.
MSM: Did you decide at a certain point then that it was time to take over the latest version of Unix and standardize it?
Tague: Yes. As I say in '73 it was apparent that we needed the support and the right thing to do was to go up to Research and tell Ritchie. And I might add that was a really nice interface where he worked with Dennis and Ken. They were quite good about telling me when they had things wrapped up, when it was time to go up and carry one away again. And we synchronized reasonably well in that and my people took care of the dog work of putting together the design information files and things that Western required in order to capture the configuration and to do configuration control. And graduated off some internal gurus that were competent at fixing the system and modifying the system as need be. And you could talked with our customers on a basis ???? and just containing the story of the next stage. The next major milestone by '76 as I say I've got to have the whole thing together here in terms of Unix support going and Unix internally was pretty much a sole product. In September of '78 Jack Scanlon was putting together the initial computing business center. They picked up, I guess there were 5 of us. I was brought in for Unix, Lee Thomas was brought in for the Mackie micro-processor chip, Nick Martalotto was brought in for some of the software support tools for Jay and Dick Haddon, database--- something like that. Tom Arnold had the... I believe there was another whole hardware center that did the 3B development. The 3B was going to kind of machine based and that started the real development and we got very quickly a lot more accepting with some of the Columbus fixings and tried to put together a single Unix that would sell very easily across the board in those places. The business in trying to get 3B hardware in shape to support it and--- one stranger I might mention that was of interest. During the '70's I had been telling other vendors that they ought to go get a license for C and put C on their machines. They were all eager to try to port Unix and I was sort of discouraging that. I wasn't sure that they would be able to do it and do it right. There was some feeling that they were going to port Unix to get it to come out right. It was probably going to be necessary that we do it ourselves. That was probably a mistake in retrospect. And I was saved by Research and ????????? down in Product License department and went out and licensed Unix. And I was very clear with Sam Morgan at that time that I want no part of this. My nightmare was, you know, bank one in Ohio with this guy from ????????? Miller who sits on their board and the AT&T board picking up Unix and putting something important to their bank on it, and my getting called out of bed at 2:00 in the morning to fix the thing. So I told Sam, you want to go into this business, that's terrific. But you guys support it. My support is fully occupied by my internal customers and I'm not going to answer the phone for these people outside. If you do that you can set up your own business. I have no regrets about the position I took. I am very glad that they went ahead and put it out because in effect it worked out just right. The people who picked it up were the Rand Corporations and the universities, the banks didn't touch it with a 10 foot pole. That was all an unnecessary concern on my part and there was tremendous payoff for all of us involved on getting this. I'm very glad they didn't pay any attention to me and my suggestion and licensed Unix. And I got religion on licensing Unix by the second half of the '70's because by the time we got there we came up to parent the deal for the systems picture. It was the right thing. But the problem I ran into was it was a real stone wall was that the computing business was being driven by by the western iron mongers and the idea was that this one early on that I finally had something to do there was that we thought we could build better iron than the next guy because we understood Unix in terms we could do it. Well it took me about a year of working in that problem to come to the conclusion that it was only a couple of things that made Unix run better, a fast process switch and a good handle on your memory pointers, a few things like this. Almost all of which really were coming along in the hardware designers from every vendor anyway. It was no big deal.
MSM: I was talking to Joe Condon and was surprised to learn from him that there had been in the Steve Johnson business of trying to build a C machine. Is this what you're referring to?
Tague: Yes. The idea was well, Steve Johnson had the C compiler so a C machine was one angle on it. But the other more generally was just Unix. The C machine was all very nice but they really wanted to have the hottest Unix in the marketplace out there.
MSM: So this would be a Unix machine?
Tague: Yes. The 3B should sell itself because it would be the hottest Unix box around was the idea behind it. And the hope was that if we can get the hottest Unix box around by building into the 3B hardware stuff that made Unix run better. Well, as I say, about a year I was trying to do that. After a year I became a proponent of it and it was probably the start of my departure from the DSG business in there. I never really reconciled that with my bosses and so indeed I made a serious personal mistake in not recognizing for almost a year that Scanlon really didn't have the same picture in mind as I did which I should have recognized. But I saw building of the OSS niche business as the place we could sell 3Bs and the rest. Incidentally if you look where our market is why that and the government is where it is at the moment.
MSM: Yes, I haven't seen a lot 3Bs outside the Labs.
Tague: They were busily ??????????? Cobol up on Unix and other chimeras and I understood the need to have Cobol there but I didn't think we'd ever get anybody to use the thing. I don't know how that one's come out in the marketplace. But I'd be surprised if there's very much Cobol code running on Unix anywhere in the world. But the business at time as I say was to sell iron and the management view of things as it was and perhaps still is, I've been out of that for, I left I think in '83, and was really out of the planning of it by '82, but still Unix was a vehicle for selling hardware and that you couldn't be in the computing business without a hardware base and there's no ?????? Nobody could find a software company that didn't want $50M a year. And AT&T's thinking $50M just isn't enough to pay any attention to.
MSM: Anyone see the micros coming?
Tague: Yes. And not to my knowledge anybody who saw how quickly and how pervasive they'd be. Lee Thomas who was a fellow I think with some vision was a great one for extrapolating the language of chips down and what you can do with those chips. And he was pretty accurate as to what was going to be achievable. Like everyone in the business he was probably off by a fact or two in how long he thought it would take. Except ?????? I suspect the politics in the game are you ???????? you insist everything is winning and say that you're going to be able to do this in the next year and you know there's going to be some second order pops up that's going to make it difficult to do that. You deal with that when it comes. But they go around that chain and they by and large deliver. That's how you just order later. The later we always because every time you push the technology down some term of the equation would surface and to deal with it when it was ?????????????????? There's been a lot of debate; there still is. I've always seen the business as having 3 layers. There's always been a top and middle and a small. And those have changed their definition over the years but from about the end of the '60s on I can always find those 3 layers and they're defined not just by machine size but the approach to the marketing machine was bundled is how it is. And it ranges from the large end which is this thing when you buy a machine we put people on your premises. It's all a package. The unbundling of course has attacked that a little bit but it still stems from that tradition. It's very much seen.
MSM: It's like selling telephones.
Tague: Yes. But you know that these guys become part of your team. These IBM guys, they work for me. And they're in my offices and they come down and you can't tell them from my people. And the minis coming off the low end came out of this. You know, buy and put your lab machine and your control apparatus together. So the support there was pretty much here's the hardware and do with it what you will. As they work in the operating systems it never got the elaborate structures there until the business was well matured and there is almost a continuum at this point between the high end minis and the low end maxis as to the way they're sold. But then the micros came along and it's the same thing. ?????????????? But it went much more rapidly then as people realized that what I really want for this marketplace is a turnkey package. And that says that's really a quite different business at this point. It's the mini business where I still see the kind of boards being delivered. You know it comes in Unix these days of course. But it's not all that different I guess in some sense in taking delivery on a PDP in the late '60s.
MSM: Yes, the contrast that we seem to be getting at it does strike me strange. You find that the high and the low now in the middle that you expect the owner or user of the machine to know about the machine. You buy a big system. I don't want to know about it. I just want to use it. And a lot of the micro business, development of software in the micro business, has been to free to use it but we need to know it. Whereas minis there has always been an assumption that people who buy these things are well to learn how to use them.
Tague: They're knowledgeable. The mini is the VAR business, is one way to look at it, the VAR business or value- added reseller. The guys bring these things in and the people who buy them put stuff around them and they turn them over to somebody who may view as a turnkey system.
MSM: This is what you were doing with OSS?
Tague: Yes, the operations systems were turnkey systems and the craft as we called it would sit at these things and they would well you started out knowing that much about computing. Of course pretty soon you'd walk into the operating company and you'd see there's acres and acres of minis. Practically guys on roller skates skating from console to console trying to find what was up and down.
MSM: You've been with the company a long time. When did Bell Labs realize that programming was going to become a major activity and indeed a problematic activity?
Tague: The 60's, I think. ESS did it. The history of the ESS project which started before I got here. I arrived in '60. But I got an early view because I went to work in Systems Research in February and Tom asked me to go over here to Whippany where the switching people were at that time on a 3 way bounce Whippany to Holmdel to Indian Hill was there oddessey. But they were over here at that time in the Morris trial, which was this first electronic switch was put in Morris Illinois that used all kinds of funny technology ?????.
MSM: Oh yes.
Tague: Stuff like that. And the flying fox store. An end marked network that broke down neon niods to make switching paths and stuff like that. He sent me over here to get out of the ivory tower and learn what switching was all about and also to look into the computing business because we were clearly heading in the direction of computing research. And this was a big software project. And that project in 1960 was in a very interesting position. The guy who started it had started it with the idea of taking the number 5 crossbar switch which was an electro-mechanical switch and turning the translation memory into a Williams tool okay. And the translation memory on that switch, I think this is the one, when you look at it there's a bunch of big iron yokes and they'd go down in the rack. And you take a wire up here and you run it in and out of these yokes. When that line is pulsed, an electromagnetic field--- that yoke, it does things like changing line numbers into calling numbers and stuff like this. All with a bunch of relays and things. But his idea was I could actually just store the bits that represented these numbers and to look them up and find a spot to store. So the idea was I'd take a number 5 switch. By the time I'd arrived the schedules had been missed, the project was growing ????????? but Morris actually had been put together. And if you asked what the Morris trial did for us since there wasn't a single bit of the product in that machine that ever made the field that's the final ESS number 1. What it really did was that project went through transition. This was in the last half of the '50s. From this idea of putting a Williams tube on a number 5 crossbar to a centrally programmed controlled machine. And somebody recognized that was what they were doing at that time. And I don't know who they were. Er, ... Keister, Ritchie and Washburn. Ritchie's father was the Ritchie involved. He wrote a book at that time which was the first hardware digital design bible, and all those 3 guys were here at Whippany handling the ESS project. They had a big training program going that was training people in the logical designers. There was for example Erna Hoover who I shared an office with and retired recently as a department head and whose husband was Charlie Hoover. He was an E.D. who retired here recently ???????? Yale. Erna had a degree in Philosophy from Welleselly. And she was busily teaching and learning boolean algebra in this other context. And indeed there are a whole bunch of philosophers in this office under Bill Keister who was in Systems Engineering ????????? they worked with. They're a delightful bunch of folks to work with. Since I've always been an amateur philosopher in science I think I'm a minor in that along the way. ???????? So these people were getting hardware training. Of course that gradually moved along to software training and the ESS people were the first people to miss their schedules and cost estimates by orders of magnitude. A dubious honor but pretty clear. But if you look at the Morris trials what it did, what they really had to do was for the first time to get a requirements description of what a switching office did in one place. And they discovered remarkable things. I was over here sort of on the fringe of this business. One of the papers I'm kind of proud of was at that time I said what you guys should do is buy a commercial computer and hook it up to a switching machine so that you can download the switching machine and drive it. You have to put a big memory on this thing. I don't care if you can't afford much memory when you get into the field. You need the memory for development. And of course I had some inkling that memory was going to get cheaper along the way. I had no idea how fast and how quick but we spend an awful lot of time honing code that fit into something that didn't need to be done. But the other thing was trying to get these people to understand and to get me to understand what the economics of the phone business were. One of the numbers I remember was they discovered they had 115 different kinds of trunks and signaling systems. And the word at that time was that's no problem. We could do it all in a program. 115 trunks. We'll just program them and even them up. Now noticed that we were talking of very complicated real time programming protocols and the context was a single CTU duplexed. Doing all this in real time all by its lonesome. The people I worked with, a very good engineer there, had invented a thing called the signal processor which was the first idea of an outboard peripheral that handled the real timing stuff. One of the key timing things of that first ESS was when your phone rings and you pick it up you've got to turn around very quickly something that shuts of ringing. Otherwise you're going to get that in your ear and you aren't going to be happy and it'll probably burn out the receiver on the handset as well. So one of the key timing loops was a loop that's spent all of it's time just looking to see if somebody had come of hook and get down and clamp that ringing tone ??????? [tape becomes unclear; sound of banging heard] ?????????????? Mike ??????? had invented this SB. So I put this old outboard in this little computer. Computers were getting cheaper, that sort of thing. The single processor finally came in. It took 8 years I think from the time, from 1960 when that was being proposed. But we had an upstairs and downstairs at that time here in Whippany. Downstairs were the Systems Engineers which is the group I was with. Upstairs were the developers who had done the Morris trial. The upstairs developers were used to programming bit by bit using bit oriented machines that worked. They knew how to use every bit. And word orientation, you know word organized machines were coming at them. They were existing vitally. "I can't do efficient programs with words. You waste bits." How many times had we gone around that kind of story in this business? It's just frightening to see.
MSM: Well, it was the time when throwing away bytes must have just seem too wasteful.
Tague: The bit cost at time was something like over a dollar and the idea that it was, we knew already it had to get down to around a penny before the stuff would really work and the idea to get down to tenths of hundreds of a cent was just science fiction. My favorite quote is in ?????? he said, I am always too optimistic in what I think I can get done in a year and much too pessimistic in what I think can be done in ten. That's something that I have to keep reminding myself. But during that thing we started training programmers. There were programming courses coming along, configuration control of a sort was invented with ESS, one of the first data dictionaries was embedded with ESS. It was to keep track of symbols on ESS. These would conflict and these huge hundreds of programmers all putting this stuff together, make and build techniques were developed in that context, and one of the unfortunate things is that resesarch never really made contact with these people. I don't know how many times that I would go out to Indian Hill or down to Holmdel or wherever they were at the time. We'd sit in on a research review. Frequent requests ??????? and it would go like this time and time again. The research guys would be there telling them how to write programs in the context of cottage industry. These other guys knew they had a factory going and it never came together. The sad part was that unfortunately each side kind of dismissed the other. And there were some things that they badly needed. Research was absolutely right about the necessity of getting some kind of notion of an operating system in higher level languages into the game. These folks just don't understand. One of the things they understood very early was that something like 90% of the programming of the ESS machines is for maintenance. In those days this mortal machine ??????????????? It was a pretty remarkable concept and it still is. People out there would change the operating system; never take the machine down. Try that on your IBM machine. There's a lot of very clever stuff that goes on that these people understand and if you know you have to do that you get very cautious about being too clever in things like moving things around in memory and dynamic memory management. They depended on sort of knowing where things were locked in core so they could do this step using their two processors where the old processors running the old operating system this one kind of starts running the new one and they slowly do this interchange. Lots of good stuff. One of the first research contributions that really took was Joe ????????? multi-dimensional analysis. The way it was used was ESS had invented a card in those days. They went around and every type of board they had they took multiple copies of that board and they took a copy of that board and put switches in. They could put hard zero one faults everywhere the made any sense to do so. They plugged the board, they'd flip a switch and they'd run their diagnostic programs and record the symptoms. And they'd build a big dictionary. The idea was to get it down to a board replacement. The craft simply when something went wrong he'd sit at this console and the console would come back and say we'd run this test if this happens, punch this button and then you go through a whole catechism and ?????? would say ???????????? And they pretty much did it. But Joe Cruscle went out there with his multi- dimensional analysis. He took all these troubles and tests and in effect was able to tell them something about which test they needn't bother to run because it wasn't doing any isolation for them, what dimensions they needed injected. But it took years to get the idea of operating system and languages in out there. They were very good in the tool area that as they recognized pretty quickly they ought to get on a commercial machine, an interactive commercial machine. They went on TSS and put all their support software. Those guys were very sophisticated. But there was real resistance on those people who did this real time programming on the system and insisting they couldn't stand having a compiler around and they were right. What you needed was this model that said you write stuff at higher level languages, you measure where the body is buried on the real time loops and then you code those that you have to in whatever assembly level [language] is appropriate. But that really didn't get broken in until C. With C they finally realized and plus the economics in this stuff. That was the other thing that made it tough. You knew a compiler was not going to be efficient ????????? code and they couldn't afford the memory. It was a valid excuse through much of the '60s. But it was not excused by the end of the '60s. Took another 5 years or so before they got religion. But that was the first one. BIS in the '70s was another one. Safeguard at the end of the '60s was another one. Safeguard profited tremendously from ESS. I was on Safeguard the year we picked up their macro assembly language. It saved my bacon. My first responsibility was a compiler that was going to be an extension of Fortran. It had real time, complex arithmetic and every other thing and Univac was going to build it. It's very embarrassing for me to say but it took me a year to kill that thing. I should have been faster. And there was another project that got started off. They were building this 10 processor machine which was a pretty hot machine in its time and only transistorized mill spec, all kinds of stuff, radiation hardened, and the only peripheral gear they had on it was a model 33 teletype and that was what they were going to do to debug the machine. That was one contribution I made. I was at that time in the language area and some guys ??????? as a matter of fact built a GE time sharing system on a GE engine here. We finally got them around to an MBS base set of tools on a standard IBM ??????? that really started making the thing go. We could pick up this stuff from ESS ???????? code control gave us language configuration control. The language PiDense, Program Identification. Unique identifiers in this program so you keep track of what it was. An elaborate scheme of course for keeping track of vintages and programs and what had to come together to do the build. So that continued and one of the things in both Safeguard and In BIS and almost every large BIS project I claim you can see the same phenomenon that occurred on ESS. You take on one of these big projects. First of all ?????????? You don't think you're going to build a prototype. Then you said you were calling it by a different name but you will. But what typically happens in the building of the prototype what you're really doing if you look back at it in retrospect is you're putting together a programmable requirement of the job to be done. And you're educating people on both the application in the computing end to understand enough about each other's business that you start talking sensibly about where you can understand what is feasible and what's possible and negotiate the right compromise. Typically the application side coming at you thinking computers are magic and if they get empowered insisting the magic be done. And, you know, it of course always results in disaster. And the computing people are trying to communicate what is truly feasible on the one hand but also understanding that when these guys tell you that this interface won't work for my clerks to pay attention to that. Those clerks are not the same as you guys at the terminal and have to get those things done. We've been around that wheel several times and I sort of despair that there's a better way to do it. But I don't think our company is unique. I hear less in detail about what goes on in other large corporations. But I watch enough large disasters going on. The airlines reservations system have their stories. It came out during the late '60s early '70s as they kind of got their act together.
MSM: The major book I'm working on is the origin of the software crisis as it emerged in the '60s and how the industry got into that situation.
Tague: ESS is an interesting study because it's pretty well documented. If you go through the BSTJ and read about the Morris trial and then there's probably a half a dozen issues that were just devoted entirely to ESS at various epics. And if you read those ---