John Fletcher = JF

George Michael = GAM

GAM: Today's the 7th of September, 1993, and I'm talking to John Fletcher. So, John, why don't you begin, and loosely follow that outline, but I'll butt in every now and then.

JF: My name is John George Fletcher. I started at the Lab in the summer of '61. I was just a summer employee for that summer. Then I came back permanently in late August of 1962.

I was a physicist. I got my Ph.D. at Princeton in physics, and I wrote my thesis on general relativity. And I had come out to the west coast to be a Miller Fellow at the Berkeley campus. So that first summer was between my two years as a Miller Fellow. When the fellowship ended, I had to go some place, and I decided to come to the Lab. I thought I was just sort of trying it at the time, because I had imagined all along I would end up on a university campus. I looked at this as kind of a half-way move, because it was a university. In fact, it seemed to me to be more closely associated with the University in a practical, everyday sense back then than it is now.

GAM: Who was your thesis advisor?

JF: John Wheeler. There was not really that much opportunity for general relativity work at the Lab. At that time they had some kind of group of people--Malcolm MacGregor, Mike Moravchek, and Pierre Noyes were in it--names I remember from the distant past. I was to be associated with that group, at least loosely. The idea was that I would have some chance to engage in highly impractical theoretical physics. But as it worked out, things did not seem permitted to be that loose. So I got involved in some things which I can't remember at all now--essentially physics application programming.

GAM: Hydro.

JF: Yes, hydro. There was a code called CEL which followed the particles, as opposed to assigning values to mesh points. You followed the particles as they moved through the mesh points. I was involved in that a bit. What happened to me is that I found that I gradually got more interested in the computer programs and putting them together, and their aesthetic qualities or whatever, than I was in their answers.

Also at that time, there was a group at the Lab that had been set up to do artificial intelligence, headed by Jim Slagle. There were--I don't know--a half dozen people in it. One way or another I got involved with them, and I cannot remember exactly how. I mean that I was involved not in any official sense, but I started talking to them, and I learned about the language LISP.

Another thing that happened sometime in those early years is that Mike May and Dick White got interested in doing stellar calculations. They had reasoned that a star was nothing but an enormous hydrogen bomb, and that maybe we had the codes to deal with it. But they did realize that you had to take general relativity into account, unlike in a real bomb. They were aware that I had worked on that, so I became kind of their resident expert. Eventually they picked my brains all they needed to, but for awhile I was telling them what I knew about general relativity.

One day Dick White came by, I can remember, and he said to me that it was extremely tedious--which it is--to do general relativity calculations, because they're all calculus and algebra. Well, eventually you get down to numbers. But first of all you have got to take metric tensors and differentiate them again and again--twice really--and add them up in various ways, and get things called Christoffel symbols and curvature tensors, and finally get to the Ricci tensor and the Einstein tensor. He said that was very tedious, and he thought that maybe a computer could help him do it. And I said that I was aware of that, because there were these guys over here in Jim Slagle's group who do something along that line. Actually, they were playing games--they were not doing algebra. But I was aware that there were algebra programs at that time that did symbolic algebra. So I said, "I'll look into it."

The next thing I knew I was writing a code that differentiated metric tensors enough times to come up with the Einstein tensor and put them together. The story was that there was an algebra program available, and all I had to do was plug my stuff in with that, and it would do all the algebraic simplifications. Well, it turned out that the program did not work very well. The next thing I knew, I was writing my own simplification program.

One anecdote from that time--which doesn't have much to do with the Lab--is that for some reason one day I was over at Stanford on Lab business, or maybe I was going to a talk. Whatever I did, it had two parts. There was an early part and a late part, with a couple-hour gap in between, when I had nothing to do but hang around Stanford.

So I naively just went to the Math Department and started walking down the halls. I was working on a math problem at that time: I had found that in dealing with the symbolic algebra there were expressions that I could invent that I didn't know how to simplify. I had arrived at them by working backwards from the simple form, but I did not know anything about the algorithm for going the other way. So I thought these guys would help me.

I just knocked on doors and talked to assorted mathematics types, and none of them were helpful. The greatest comment of all was from someone who--well, at that time he looked elderly to me. I expect he might have even been younger than I am now. But he listened to what I wanted to do, and then he looked at me and he said, "Young man, we stopped worrying about things like that in the last century!"

Anyway, it turns out, strictly speaking, that in some sense he was mistaken, because there were people worried about simplification. Of course, a lot of progress has been made since then.

Anyway, I bored ahead with this thing, and I wrote a program that I still have--a deck of cards, if you can believe that--that embodies the program today. It worked pretty well. I turned out some simple examples anyway. I don't know whether Dick White ever really used it or not. As a result of having done this, I went to a meeting of symbolic algebra types somewhere in the east, and I determined that I was more or less near the forefront of the field--without having gone very far. This was maybe '65. I had come to the Lab in '62, so this was about three years later.

It was clear that my interests were shifting in this computational direction. I was in the theoretical physics division, the head of which was Sid Fernbach, who also was the head of Computation. He was the dual head up until I guess about '68, when they split apart.

GAM: Yes.

JF: So one day, I screwed up my courage and confronted Sid and told him that I would really like to work on the symbolic algebra stuff as my job. It turns out that he outflanked me. He indicated that, no, that was not really the kind of thing that the Lab did, that it was not appropriate, but that he did have another job in computers that I might be interested in. It was in system programming. A fellow named Bob Abbott was leaving at that time. I think he came back again later, but anyway, he was leaving and there was a hole to be filled. After some hemming and hawing, I finally decided I would take the job on the theory that, once I was working in the Computation area, then I could eventually work myself around to the algebra work I was interested in.

But it turned out, as I said, that Sid had outflanked me, because it developed that I became interested in the system programming, and eventually I forgot about the algebra. Of course, we all know there are things like Macsyma today--that other people did not forget about the subject. Whatever I did is hopelessly out of date. Meanwhile, I was having fun.

GAM: Do you remember coming and talking to me about whether to take that job?

JF: Yes, I talked to you and to Bob Cralle.

GAM: Bob Cralle, yes. Alex Cecil.

JF: All of you pointed out that if I took the job, I'd be one of the first Ph.D.'s to enter system programming and I'd have to work under a non-Ph.D. So it was possible that some of my freedom to work in the way that I wanted would disappear. When I mentioned these thoughts to Sid, he agreed, and was about to withdraw the offer. But I reconsidered and took the job. As it turned out, there was so much to do that the supervision never was noticeable; we worked at our own pace and in our own way.

I started working on the system programming job. It turned out that there were three people working on a new project, which was centered around the PDP-6: Clarence Badger, Garret Boer, and Gale Marshall. They had worked as a team on the STRETCH. So I became kind of the "fourth horseman" or "d'Artagnan to fill in the Three Musketeers" or something. I was added to their group, and I was nominally their leader--because apparently Abbott had been nominally their leader. I gathered that Abbott hadn't done anything concrete except try to document what was going on. He gave me sheets full of stuff, but he hadn't actually done any programming.

I remember sort of being interviewed by Clarence for the job of being his leader, which was again a strange arrangement. From the questions he asked, he was trying to determine whether I would really program or not. I assured him I would, and of course, I did. But I think for several months there, when I actually did not get around to programming because I was trying to figure out what the hell was going on, he had considerable doubt.

I can remember, though, his great happiness the day I finally had a version of the program that I was working on. I didn't know what to call it, so I named it after myself. It was called FLETCH. It was a piece of the PDP-6 operating system. I can't even remember what piece anymore. So I inserted this thing into the operating system and started debugging it, and then I think Clarence heaved a sigh of relief that it turned out I could program.

GAM: Do you remember that one of the things that earned you somewhat a great notoriety was your polyomino program--the most intelligent use of macro facility ever done?

JF: Well, that actually was prior to what I have been discussing.

GAM: Yes.

JF: Somehow I had the idea, which actually I think is a good idea maybe, but it did not turn out to be an accurate idea, that real programmers worked in assembly language. I had the idea that there were people around writing physics codes in FORTRAN, but that the real aficionados didn't do that. So I set myself the goal of learning assembly language. I got out the FAP manual, because at that time FORTRAN was running on the 7094, so FAP seemed the thing to use. And I read it. It included not only the regular part of the assembly language, but also it had all kinds of other pseudo-operations, including a macro facility which, in retrospect, is better than anything that exists today as far as I know. It was just really a marvelous thing.

Somehow or other I had encountered Bob Cralle and regarded him as an elder statesman I could come to. Well, backing up a little--I decided that it was fair enough, since my purpose was to learn assembly language, that I could just pick any old problem and do it in assembly language as an exercise to learn. Maybe I was partly self-serving, because I had been very interested in the polyomino--actually pentomino--problem of fitting the 12 pentominos into a box. A friend of mine and I at Princeton had gotten all involved in trying to see how many solutions we could come up with. It said on the little set that I bought in a toy store in Annapolis, Maryland, I remember, that there were rumored to be over 200 solutions. Of course, we know now that there are more than 2,000. So that was a hideous underestimate.

But, anyway, I was interested in the problem, and I thought it could be reasonably attacked just by brute force with the computer, and I could get all the solutions, which I eventually did. But I also felt that speed--which of course would not be much of a problem today--would at that time be a serious issue, and I should do everything possible to speed it up. I concluded that if could mainline in the code most of the decisions about the shapes of the polyominos, that it would be much better than looking them up in a table. It seemed clear to me that the FAP macro facility could do that, and that I could have the macros recursively call themselves and essentially expand into a straight line code the entire structure of all 12 pentominos.

So having decided this, I went to Bob Cralle, and described my thoughts. He couldn't say why it wouldn't work, but he felt in his gut that it really couldn't be done, that something in the macro processor would not let me do it. But he did not discourage me from trying. Well, of course it turned out that it worked! The macro processor would do what the manual said, and it did it very well. I just set the thing aside after I had done it. I had a printout of the solutions that I've kept, and I still have it today.

Then, about a year later in the "Scientific American"--just as he had originally had an article on pentominos--Martin Gardner had one on hexiamonds, which are shapes made out of little triangles instead of little squares. And I thought I that could modify my program to do hexiamonds and answer a couple of the questions he raised. So I did that, and observed that one particular arrangement had no solution--or whatever. Anyway, I sent in my results to Gardner. He wrote back and said, "Great! What do I cite as the source?" It had not occurred to me that he wouldn't just take my word for it or something like that.

So I said to myself, "Gee, maybe I'd better check what one does to release something that I've done at the Lab to a magazine." The advice was that you had to make a UCRL report of it; that was the first step. So I did that, and then I was able to tell Gardner that it was UCRL 12345 or whatever. So now I had this UCRL report in my hand, and I thought: well, why the hell not? Why should I not try to publish it, since I had gone this far? So I sent it to the "Communications of the ACM" (a publication of the Association for Computing Machinery) and they liked it. In fact, of course, as you can well imagine, it was very picturesque, with pictures of the polyominos. So it made the cover of some issue in '65, I think it was. (xx) Then later on, I remember Cralle, I think, showed me that I was cited in a book by Brown, wasn't it?

GAM: Oh, yes, Brown's work on macroprocessors.

JF: Yes, and he referred to what I did as "Fletcher's Method," which of course is great. But it seems to me that if you look at the FAP manual, it is absolutely clear that it is set up to do what I did. In fact, there is a particular pseudo-op called the IRP--it means iterate-in-prototype--that was designed to do exactly what I did. In fact, I personally cannot imagine what else you would do with it. So, the question is: who invented the IRP, and what did they have in mind, if now this should be called Fletcher's Method? My suspicion is that this unnamed hero deserves the credit.

GAM: Well, that was Dave Ferguson. He's the guy who wrote the FAP. He was here. He came here--I remember he talked about your publication.

JF: It would seem that his work was like pebbles on the beach or something. It was just lying there waiting to be used.

GAM: Well, somebody has to see how to use it before others become aware of its value. I think you did a great thing--it's all right.

JF: Well, anyway, that is one of my two biggest successes in terms of publication in either physics or computer science. The other one is an error-correcting code that came later, which eventually worked its way into an American National Standard. Maybe at some later point we can discuss that.

Both of these publications were flukes, you see: If Gardner hadn't asked me for the reference, so that I had to produce one, then I might not have ever published it. The other one turns out to be like that, too.

GAM: I wouldn't call it fluke, I'd call it serendipity.

JF: Yes, right! Whereas things that I thought were publishable--tried to publish--I have often had a great deal of trouble publishing, because you have the referees to fight. Anyway, all this was a kind of sidelight that preceded my joining up with "the Musketeers."

GAM: Well, Alex had something to do with the polyomino problem, too, didn't he?

JF: Yes, Alex Cecil had a set of routines that would draw lines on--what was it called--the dd80, which by today's standards is a primitive CRT device.

GAM: It was a great device.

JF: Yes, because that was how you produced pictures. So, I used his routines, and he also gave me pointers about programming. I remember one day after I had Alex's routines in my program, all hell was happening in it, and I couldn't figure out what had gone wrong. I studied the thing before calling Alex. In those days you had to debug with print statements. If you were very good, which I wasn't, you could get in three batches a day. But mostly you could get in only one and a half. Anyway, I confronted Alex when I had finally determined that the trouble was his, and I said, "Where do you save the Accumulator and the MQ when you are called?" And he said, "No, the convention is you've got to save them yourself!" So there I learned a little bit about the rules of the game.

GAM: A lovely way to get initiated.

JF: Yes, I remember another discovery about computer conventions. It was when I was working on the CEL[2] code, and I was tracking particles through a mesh--just a one-dimensional mesh. I had made it a cylindrical symmetry. I wasn't really using the CEL code. I was using a code of my own like it. So, the idea was the particles that went over one end would appear at the other end.

GAM: On the side, yes.

JF: I said, well, you know, studying my FORTRAN manual, all I have to do is use a Mod function and apply it to the position. If a particle goes over the length of the mesh, it will come back to the beginning.

I started running that code, and it behaved very strangely. It would run for awhile. Some of the particles would start to disappear. (I kept a check on the total number of particles, and the total wasn't right.) Then the code would finally blow up. I scratched my head over that one for a long time.

Then, suddenly, something tinkled in my head: What did the mod function do to negative numbers? I expected that when a particle went through the left-hand origin it would pop up at the right-hand end. In other words I believe, and I still believe today, that it is mathematically correct that, for example, if you divide -5 by 3, you should get -2 and a remainder of +1.

GAM: No, -1, and a remainder of -2. Well, you're dividing 5 by 3. Three into 5 is 1, and 2 left over.

JF: Yes, but that would be a -2 left over. What I claim is that the remainder should always be positive, when you have a positive divisor. But anyway, the computer convention, which again I think is wrong, is that, as you say, the remainder is the same sign as the dividend.

GAM: Divisor. Dividend.

JF: Rather than as the divisor. So that's where my particles were going. They were going over the left edge of the mesh and off into whatever variables happened to be there. That was easily fixed once I realized what it was. Again, I had made an assumption, and I learned it was false.

GAM: That will happen.

JF: Back to my job with Clarence, and Garret, and Gale: I became a Group Leader, sort of, at that time, and I essentially had that same job until 1990--about 25 years. The organization would change, and leaders would come and go, and the name would change, but essentially there was a group that I was the head of. You could never point to a moment at which it was replaced by another group. You know, people would be added, others would go away. It split once, because it got too big. That was my group.

By 1990, the definition of what a Group Leader was had changed. I finally had to accept that. When I started out with four of us in 1966, or whenever it was, I was essentially a--"first among equals" maybe is the phrase. I was just another guy working on the thing and doing programming. I just had these little side things of going to a few meetings, and writing evaluations, which in those days didn't amount to much. It was all largely technical--90 to 95 percent of my time.

But by 1990 it had been decided not only was a Group Leader supposed to spend most of his time just being a Group Leader and not on programming, but he wasn't even a technical leader anymore.

GAM: He was administrative.

JF: Yes, right! They had developed the idea that Computation should be in the same matrix organization as everybody else, and that groups were horizontal. They didn't have anything to do with the project you were working on or anything. Well, my inability to come to terms with the change in the definition of my job had alienated my Division Leader, and essentially by mutual agreement, but under pressure from him, I finally threw in the towel on trying to be the new kind of Group Leader.

Part of the reason, I guess, that I gave up is that I had observed the Group Leaders no longer had much voice in what happened anyway.

GAM: Yes.

JF: I clung to the job in the hope that it would help me influence the way things went. It did not. Anyway, things were a lot different back in the early days. We had the PDP-6 as our main machine. That was because of the original conception of what Octopus was to be: There would be a head, like on an Octopus, with tentacles reaching out. The PDP-6 was to be that head.

Very soon after I got involved, it became clear to me, and I think to everybody, that this was not a good way to do it, because the head was very critical. Furthermore, it was very prone to going down, because every new thing had to be added to the head. You would have to be debugging it, and it would be down. So the idea of an octopus with a single head just really didn't fly.

Our next stage of design was the subnetwork approach, in which there were multiple heads, one for each function. There was a file system head, a teletypewriter head, and a printer head. It never really quite exactly got into that form, because the next thing that happened is that we began to realize that there could be, even within each of these functions, multiple heads. For instance, the teletypewriter function was originally in the PDP-6, like everything else; there was a piece of hardware built at the Lab that was going to be the multiplexer.

Then Dave Pehrson, who was in the Engineering Support at that time, got the idea that you could build a new multiplexer out of PDP-8 computers, which were available then. So, rather than try to put everything into hardware, some of it would be put into software in this computer. Again, his original conception was these were kind of like satellites to the PDP-6, but before very long, it became clear that, no, they were really free-standing little computers that were just in the network. That's the way it went. The only role the PDP-6 had for the PDP-8s was to load them with their software. That is the one sense in which they were satellite to the PDP-6--that's where their brains came from.

So Pehrson and I did that job together. He did the hardware, I did the software, and that has always been my model of how we did things in that day--how we should do things.

GAM: Do you mean an engineer and a programmer working together?

JF: Right. The way we worked together was he would propose something that put a lot of burden on the software. So I would study it, and I would make a counter-proposal--something that, probably from his point of view, put a lot of burden on the hardware.

GAM: Fair is fair.

JF: We would flip this back and forth, and I think we finally came to the right compromise. I don't think it ever worked quite as well again, but I think it worked very well then.

GAM: Well, you know, I'm not sure it's the right compromise, but it was a compromise to satisfy minimalist requirements. If you had a different set of requirements, you might have found a different compromise.

JF: That is true. We also had a limited computer. A PDP-8 had--what--4K, 12-bit words.

GAM: Yes, 4K memory.

JF: Boy, did I struggle to get everything in.

GAM: Yes, but the point is that you could have gone to a bigger machine just as readily, and not have to worry about shoehorning it into a PDP-8.

JF: Right. Of course, there were money considerations. I don't know how that was decided.

GAM: Yes, that's what I said--that was a minimalist thing.

JF: Well, you know, there were lots of other things going on at that time as we branched out into other machines and new things came.

GAM: Now this is what year, roughly?

JF: This is late '60s, I guess.

GAM: Like 1967?

JF: Yes. I'm not sure exactly.

GAM: All right. Well, you see the Photostore starts to rear its ugly head around '67.

JF: Right.

GAM: And you guys all jumped on that. I was complimenting Garret just before, saying that the work that had been done on that was seminal.

JF: Yes. Well, that was largely Garret's baby. He deserves the vast bulk of the credit for that.

GAM: Well, that's true, but before that there was John Fletcher interpreting the Multics file structure, and making it happen here, among other things.

JF: We all read those Multics papers. That is certainly the case. In fact, sometime I should try to find them, because I know one thing that we did in our system, I swear, is the way those papers read originally. Yet when Multics actually came out, it had done it differently. Namely, our security was what is today called capability-based--in the directories were coded objects called capabilities. If you could extract a capability from a directory, which essentially meant that there was a path to it from your root directory--I guess today what they would call a home directory--to a capability, and the capability showed the necessary permissions, it was yours. That is, unlike UNIX, you could not get at the entire directory structure. You had to start at your personal root or home directory, and trace from there. You could not go back to the root of roots, like you can in UNIX to find anything. And if you could get to a capability, if you could name it--that's another way of phrasing it--if you could name it, it was yours. We thought that was a great system, and I still do. There are arguments on both sides, but all in all, I think a capability-based system would be actually better than what we have today.

Multics, on the other hand, ultimately went the other way--if you could name it, it was not necessarily yours. It had things similar to what UNIX has today--access lists--whether you were in the right group, and who you were, and that kind of thing. So what is interesting is that either we misread their paper, or they changed their minds.

GAM: Yes, right. I think they changed their minds. Remember, there was a big troika there--General Electric, MIT, and Bell Labs. Too many cooks, etc.

JF: It might also have been that the Department of Defense, who I assume was one their sponsors or customers, might have insisted on that, because, as I said, there are arguments on both sides, and one thing a capabilities-based system does not do for you is give you a quick way to revoke someone's access. If someone had ever had a capability where he could reach it, he could have squirreled it away where you would not know where.

You can't just wipe off someone's access with a stroke of the pen, a stroke of the cursor, or the mouse, or whatever. So, yes, we used Multics. As you say, we brought in the Photostore, which was just amazing.

GAM: It was a signal event.

JF: We had three major storage devices at that time. The first one that arrived was the Data Cell. And the next one was the Librascope disk, and then the Photostore. The Librascope disk was a giant. I guess they were about 6-foot-diameter platters, rotating on a horizontal axis.

GAM: It had a head-per-track.

JF: Head-per-track, right. I have always had in my mind something that fortunately never happened--a picture of a catastrophic failure of the axle, and these giant, spinning things would detach themselves, and roll--there would be nothing stopping them. They would go right through the side of the cabinet and across the room, smashing everything in their path.

GAM: That's a neat fantasy.

JF: It always occurred to me that there was deadly stuff in there if it ever got loose.

GAM: Well, I suppose that's true. But it was an interesting piece of hardware. And it certainly fit nicely into the overall file structure.

JF: Yes. I remember when we first got going with the PDP-10, the only storage device we had on it was that Data Cell, which was--well, of course, it wasn't as capacious as the Photostore, but it was more capacious than a typical disk of that era. But it was slow. I would sit at the Model 33 Teletype, which is what we used in those days--down there in the machine room, which is the only place they were--and I would type the things I wanted to do. Well, of course, this was a little later. We used to write our programs on sheets of paper and have them keypunched, and feed them in as cards. But we got to where we had a primitive text editor--primitive because we didn't have a screen: We had to do it all on rolls of paper. We would edit programs down there in the machine room. I remember I would get done editing and I would ask for an assembly. Then I would spin my chair around and face the Data Cell, because it was going to take some time. And that thing would go "kerchunkity-chunkity-chunkity-chunkity-chunkity-chunkity-chunk." I could recognize the moment when it must be done. I would spin around, and sure enough, the machine would type out the result. This went on for many months--I don't know how long.

Then one day, Garret got the Librascope running. We all cheered. So for my next assembly, I went down, I did my editing, I typed, I spun the chair, and I could hear the typewriter going behind me--it was already done!

GAM: Huzzah! Huzzah!

JF: I just wasn't prepared for that. I guess, in fact, I was slightly thinking that I would hear the Data Cell do something, even though I knew now that the file was on the Librascope. But the idea that it took less time than to turn 180 degrees on the chair--it just took my breath away. What an advance!

GAM: Well, speed is just a remarkable stimulant.

JF: Yes. I guess one other silly story from that era had to do with those Model 33 Teletypes. They kept wearing out what is called the distributor, where a little motor ran a rotating member all the time. So, to protect them from wearing out, our engineers installed timers, so that if you didn't type for a certain period of time, the timer would shut off the running motor. Then before you could type again you had to flick a little switch; so you were used to that.

Well, one of the Teletypes down on the floor had a recalcitrant switch. You would flick it, and it wouldn't do its thing. So we gradually learned that you had to get a little violent--you had to bang the top of the machine to help it along. Eventually even that didn't help. I had finally decided that a well-placed blow of the foot to the front edge of this Teletype was what it needed. That was standard operating procedure for this particular Teletype.

So one day I was working down there, and the Teletype ran down. I pushed my chair back and I whanged the thing a couple times with my foot. Then I looked up in time to see Sid Fernbach with a bunch of visitors that he was leading by. He just left.

GAM: Oh, that's great.

JF: "Here's one of our highly trained scientific personnel kicking his machine."

GAM: You do what you have to do!

JF: That's right! Golly, we did all kinds of things. It was just the four of us for a long time, and then we began to add people to the group. We began to separate functions out of the machine. One function that we took over was because of Bob Cralle, and I'm sure that you remember this story. If someone has already told it, then I won't repeat it, but I will start.

GAM: No, tell it!

JF: It is about passwords, which we called combinations up until very recently. In fact, sometimes I find myself still using that word. It is in analogy with a safe: To get into your computing facilities you had to know a combination. I don't remember how it came to be, but I guess it had always been that a combination was six letters. I don't know how that was decided. Anyway, the combinations were stored on the mainframe computers, or worker computers as we called them, which at that time were CDC 6600s. The combinations were looked up by the computer.

The teletypewriter network had nothing to do with the passwords. It offered a facility for suppressing the printing of the password, which was that you typed a ctrl-Z, an arbitrary choice. Then the PDP-8 concentrator would know not to echo the immediately following characters. We did not have single-character interaction all the way to the mainframe. So echoing was done by the PDP-8. The PDP-8 did not understand the context in which a password would occur so, you know, you had to tell it with the ctrl-Z. But the combinations were looked up on the mainframe.

It turns out it had been documented about the 6600 that a field length violation, when the running program would try to access a word beyond the length of the memory which it had been given, would cause an interrupt. If the attempt was to store beyond the length, the store would be suppressed. But if the attempt was to fetch beyond the length, the fetch would not be suppressed, and the interrupt would occur after the fetch, which meant that the fetched information would end up in the core image of the program that was just now being dumped.

GAM: Right.

JF: This was a documented fact, and I don't know whether anybody had thought about it. I will absolve myself by the fact that I hadn't even read the documentation; so I didn't know one way or the other. In any event, Bob Cralle had read the documentation.

GAM: Well, he and Al Ciplickas.

JF: Is that right?

GAM: I think so.

JF: Yes, that's right, Al Ciplickas. Anyway, they had read it, and they had let the little gears in their heads run on this. They said to themselves, "You know, we could look at the entire memory of this machine in a kind of a haphazard fashion now. We can reach beyond our field length." I think they determined that you could pick up two words if you did it right. What would happen then is that their program would fault and be dumped.

But the facilities of the operating system were such that you could have another program standing by, watching for the dump to occur. It could then proceed, allegedly in the role of a debugger repairing the faulted program. It would copy the two words to a file and restart the program. This would be done again and again. Each time it would collect two words.

You didn't always know where you were in memory or what you were looking for, but if you just kept doing this long enough, pretty soon you had the whole damn memory copied. Then with a little bit of smarts, studying the memory, you could figure out where the passwords were kept. So Cralle did this.

Then, I think perhaps somewhat unwisely, he managed to use this information to demonstrate that he had beaten the system. If I remember correctly, he did it twice. After he did it the first time, someone put in an alleged fix, which was not a fix; so Cralle showed the guy that he didn't know what he was doing and stole the passwords again. As a result of this I think Cralle got into some degree of trouble, but the bottom line was that then people decided that the passwords (or combinations) should not be kept on the mainframes anymore.

So that is where the facility that came to be called Ostrich came about. It was a little PDP-11 in the network that was going to hold the passwords and check them. Ostrich became a job for our group, and I did the programming. The PDP-11 kept its records of the passwords on a disk--if you could believe this--which had 64K words; that was an entire disk. Its memory was, I think, 8K words, with 64K words for the entire disk.

GAM: That was one of those single disks. I remember those.

JF: Ostrich was retired not too long ago--maybe five years ago, if that much. We had replaced the disk, but there was never enough motivation, enough need, to really fix the program very much. What I did at that time was simulate the little tiny disk on the new, great big disk. So we only ever used a little bit of the great big disk, rather than rewrite the thing for the new disk.

GAM: No one ever compromised it, though, did they?

JF: No, the passwords were safe. There were all kinds of funny things about that. The whole security thing over all these years has to my mind always been highly irrational. They would worry about things that you don't need to worry about, and they would not worry about things that you should. You could never get a statement of policy--what is it we are trying to protect against--so that you could design for that. They would always tell you: Design something and then we will tell you whether it is all right. It was a strange business.

I remember one thing was that we had the audit tapes, so-called. They were DEC tapes--another antique device. In fact, I remember, since we were doing this in assembly language on this little tiny machine, we couldn't use any existing software. And I remember having a terrible time getting questions answered by DEC about how the DEC tape was formatted, which I needed to know. Everybody I would talk to would talk in terms of calling certain library routines. I said, "No, no. I want to know what the library routine does." I finally got the information I needed. All the audit information, which would tell who logged in and when--it would not tell the password, but it would tell everything else--had to be put out on the DEC tapes, even though it was perfectly feasible to ship the information through the network to--you name it--anywhere.

And the question is, why would they not let us ship the information through the network? The answer seems to be what I came to call the "frictional" theory of compromise. Namely, somehow such messages leaving the machine, carrying the audit information, might scrape up a password or two on the way; they just seemed to be afraid that something important would get out with the audit information if it was not put out on tape. I don't know why the frictional theory didn't apply to tape, but, again, it just seemed totally irrational.

When we were to redesign, and, well, did redesign the password-checking as a new facility called Kiwi a few years ago, they fortunately gave up that crazy requirement. It also had turned out that the audit tapes were particularly uninteresting--namely, even though Security insisted that we put them out, Security did not ever bother to look at them. I had put into the program a feature--there were two DEC tape drives--that, when a DEC tape would fill up, the program would detect it. It would then shift to the other drive, but I had the thing arranged so that somebody had to intervene and change the tape number before it would go back to the first drive. The theory was that he would unload the little tape and put another one in its place. Well, as a result, the operators had to regularly go over to the computer and turn the little numbered wheels, as if they had taken the tape off, but they had not. This went on for many years, this farce of supposedly forcing people to look at the tapes, but it really wasn't working. Then they finally agreed that the program could just flip back and forth between the tapes without having someone intervene.

GAM: So you're just keeping the most recent stuff that way?

JF: Yes, you had roughly two tapes' worth, one of which would be partly covered with the latest stuff.

GAM: Well, let me interpolate, here. One of the things that you are alleged to have said was that--I don't know where this was said, probably in some meeting or something like that--"If it was important, I would have thought of it!" Do you remember that?

JF: No, I don't.

GAM: Okay.

JF: I can imagine provocations when I might say that.

GAM: Well, the other thing is that there was allegedly some sort of a fight--not fight, but a big disagreement--about whether we had duplex or not duplex Teletypes in the beginning. And you fought that or something for awhile.

JF: Well, I wanted us to have full duplex, whereas typically terminals were half-duplex.

GAM: They were half-duplex, yes.

JF: The Teletypes could be rewired to be full duplex. When the PDP-8s came in, we went full duplex, so that the PDP-8s could look at every character typed and make decisions like the ctrl-Z thing. Then there were efforts to get successors to the Model 33, which, at 10 characters per second, seems primitive.

GAM: Yes. Now it does, of course, but in the '60s it was fast.

JF: So we went to the Silent 700, which was 30 characters a second, and then finally we started going to soft-copy terminals.

GAM: Glass Teletypes.

JF: Right. One of those efforts was to procure an official kind of glass terminal. They were starting to be called smart terminals, although by today's standards they were pretty stupid.

GAM: You're right, they weren't smart.

JF: They had to be controlled by the PDP-8--I guess by that time they had become PDP-11s. We wanted them to be full duplex. Well, it was amazing that the typical glass terminals were not full duplex. They were designed mainly to be half-duplex, but they had an option--either that you could flip a dip switch or you could send it a signal or something--that would make it full duplex. We specified in our spec, when we were picking our official terminal, that we wanted them to be capable of full duplex.

It was amazing that the first year that we put our spec out, none of the responses that came back were really full duplex. They would be full duplex for the letters, and digits, the graphic characters, but the outboard keys, like carriage returns and so on, they were not. You would hit carriage return, and the terminal would carriage return, without waiting for the computer to do anything. I can remember asking several of the vendor representatives that came by: "Why are you doing that? What kind of use of the terminal do you imagine, where someone would want this thing sort of partly full duplex?" None of them could tell me, but that's the way it was.

As a result, we rejected all the responses, because they did not meet our requirements. We told them why. The next year we tried again, and Hewlett Packard had their ears out, and they heard what we said. They didn't really believe us fully, but they had a dip switch that, if you flipped it and told the terminal to be full duplex, then it really would be. If the dip switch was the other way, then it would be like it had been the year before. They had what we wanted as an option. We called that the fully full duplex option. So that might have been what you meant about fighting for full duplex. It was hard to get--pretty hard.

GAM: Ah, but it finally got through, didn't it?

JF: Yes, and it really lasted until the modern terminals, where the terminals are really smart. I know I got a lot of flak in those days from people who wanted to customize their terminal to themselves. They said, "Why can't the terminal, as alternative to ctrl-X, for example, permit us to use backspace or delete?" I tried to explain, but some of those people would not accept it.

The model at that time--and I could not find anybody in charge who would say, "No, let's change the model"--was that terminals were basically available to anybody. Even though you had it in your office, in principle somebody else could use it. The problem is that a person walking up to a terminal would want it to behave as he expected it to. Now, of course, today we actually live with it when it is not like that. You go into someone else's office and try to use his keyboard, and if he uses backspace instead of delete, or ctrl-Y instead of ctrl-U, or something like that, it can get very irritating.

GAM: I'll say.

JF: So the question is, when in history was the crossover where the convenience of having the terminal your way outweighed the inconvenience to other people? You came to the point that it was so rare that other people would be using your terminal that it was no longer a consideration. So, anyway, that was one of our handicaps, with that little tiny PDP-8 and even the PDP-11 there was no way to customize it to you.

GAM: Well, in UNIX now they have a Term Cap, or whatever they call it, that allows you to set your terminal according to this set of prescriptions.

JF: Right. That's because the system that is making that setting knows who you are, whereas these little concentrators--PDP-8s and PDP-11s--did not know you.

GAM: Yes, I understand.

JF: Just about the time that it became clear that we probably would not have a next-generation terminal concentrator, because the terminals were getting smart enough that you didn't need a concentrator, I was planning how to do something like Term Cap. The mainframe, which knew who you were, would be able to send a message down to the concentrator, and say, "Okay, set everything this way." That was coming.

GAM: Well, that meant there had to be a profile of you every place that you came through.

JF: Right. Every machine that you dealt with would have to know about you or it would not work. In fact, we have a little bit of that, with the so-called Micromux, which was the last generation of concentrators. You could do things like load tab stops.

There was another big thing relatively early on: screen editing. When glass terminals came in, the first one we had was the ADM-1.

GAM: Yes, I remember.

JF: Whatever else was wrong with an ADM-1, by golly, you could edit on that screen. I don't know who, realized that early on: that would be a great thing. But I worked on it and came up with a feature that went into the PDP-11s, which was called the "Iditor" feature.

GAM: Iditor feature.

JF: Yes. At one time we were trying to get a generation of terminals that we called IDIOT--interactive display, i/o-terminal--something like that. Finally, it was decided that that was not a nice name. But it has survived in Iditor, which was the IDIOT-editor. So we early on got the Iditor feature, and Hank Moll incorporated it into--

GAM: TRIX.

JF: TRIX made use of it, and it was very successful. Another little story I can remember illustrates something I came to believe: The typical computer user cannot visualize what a new thing will be like. You ask a typical user, at least in those days, what would he like, he would say, sort of, "what I have now, but more." He wouldn't use those words, but that would be the gist of his statement.

GAM: Yes, I understand.

JF: If you would say, "Wouldn't you like...," and describe something somewhat new and different, he would say, "No, no. I get along fine the way I am." I saw that work very definitely in regard to the screen editor idea. I can't remember who it was, but I can remember very definitely describing to someone how the screen editor would work, and how it would be unlike what people were doing with TRIX and the TMDS at that time--where they would put their text up on the screen and then would pattern-match in it to make changes. They got very good at that. If you want to change this particular letter A, you type just enough pattern to catch only that A. I was trying to explain to him: Wouldn't it be better if you could point? Admittedly, we did not really have a mouse to move; you had to step the cursor over and step it up and down, but anyway, you could point to a letter. So, wouldn't it be better to point? Whoever I was talking to said, "Oh no!"

I kept working on the screen editor anyway, despite discouraging remarks like that. Finally I had it working. One day I was seated down in the computer room using it, and again the same guy--though I cannot remember who he was, I do remember that it was the same guy--came by, looked over my shoulder, and said, "Hey, what're you doing?" I said, "Well, this is a new feature." He said, "Gee, I'd like to be able to do that. How do I do it?" I said, "It's all in TRIX now--you can just do it." The difference was between having it described to him and his seeing it. What a difference that made!

GAM: He must have been a manager.

JF: Yes. So, we really had to make sure that they, how would you say--

GAM: Well, you know, a lot of those people are FORTRAN users, and they see everything through that set of eyes. But it's not very stimulating.

JF: I think I do that myself, too. People would talk about things like electronic mail. I didn't tell them, well, it is no good, or that I don't want it, but I certainly did not rush to make it available to myself. But then, now that it is available, it is just the normal course of events. I certainly use it a lot more than I probably would have guessed.

GAM: Boy, I know I use it a lot.

JF: I guess another thing is color. I don't use color at all. I just work with black and white text, but I have a suspicion that maybe if color were quickly available on my terminal--in fact, I have just now gotten one with color--it might be different.

GAM: I'm pretty sure you're right. Yes. The use of color probably has several facets. One of them is that just since you see in color, seeing on a screen in color is a little more useful or normal than black and white. The other thing is, if you're doing "applications" programming, you get to see highlighted stuff that way, which catches your eye much quicker, and that's what makes it useful.

JF: Of course, I do not do applications, so that might be part of the reason. I almost entirely work with text, either writing documents or writing programs. The lock screen picture is about the only thing in color.

Well, I am about out of things to say.

GAM: Well, I'm going to interview you again a little bit later, with another load of tape, essentially. I want to talk about your experiences at DAS, and flesh in some of these other things that we just glossed over today.

JF: There is a question here somewhere about what is my favorite machine, I think. In terms of programming in assembly language, which I did for a very long time, the PDP-6 and the PDP-10 were the nicest ones.

GAM: I'm sure everyone would agree with you.

JF: There is an appealing orderliness to an instruction set that is so orderly that--I think I counted them once--there are fourteen different no-ops. These resulted from trying to make complete, logical sets of things. They had all combinations of moving a half-word hither, thither, and yon. They had the possibility of doing it to a single word: You could copy the left half to the right half, and zero out the left half after you were done, and so on. If you analyze what constitutes a complete set, then one of them is that you are going to copy the right half to the right half and leave the left half alone. Or you can take the left half to the left half and leave the right half alone. So, those are just natural no-ops. They did not put some oddball thing into that slot in their instruction set; they just let it go.

GAM: Sure.

JF: The greatest no-op was the one called "jump." There was an instruction called jump, and it was a no-op. You might say, "Now, isn't that idiotic?" No, it was part of a set of eight ops that could jump on the sign and zero-ness of an accumulator. So you have two choices for what you do if it's negative, two choices for what you do if it's zero, two choices for what you do if it's positive--you can jump or not jump. So that's eight choices. And one of them will be that you always jump, and that was called jump A, meaning jump always. And then there is the one that meant you never jump, and that happened to be called jump, because you did not put a modifier after it; so it was the one that did nothing. It was logical, and I liked it.

GAM: Well, you know, it was alleged that that extremely baroque set of instructions cost the PDP-6, and perhaps the PDP-10, too, a lot of time. It slowed the machine down quite a bit.

JF: Well, they were a great set.

GAM: And they're still running today! There are hundreds of PDP-6s and PDP-10s running around all over the country.

JF: You know, in some sense the PDP-10 is still running here.

GAM: Oh?

JF: There were a number of programs on the PDP-10 that were essential to things in the network. The assemblers, for example, for a lot of the little machines were on the PDP-10. The assembler for the Octoport, for the SEL computers, we actually took off the PDP-10. We had a contract with Control Data to write us an assembler that would run on a VAX, which they finally produced. It was like pulling teeth to get it right, so that was not a good experience. But all the other assemblers--including the ones from the so-called regional processing units of the SEL, the ones for the 8X300s, which are peripheral to the SEL, the ones that were in the Micromux, which of course is now gone--all those assemblers were on the PDP-10.

When the PDP-10 was about to go, the question was, "What the hell do we do about this?" Gale Marshall had retired on a medical disability many years ago. He had been hired back a few times by the Lab to do some of what he did well, which was write assemblers. But the Lab's rules for hiring people that had retired had gotten worse and worse. Finally Gale Marshall just would not come back because he could not make enough money at it. So that avenue was not open to us, and people were talking about all the things needed to be done to move the assemblers off of the PDP-10s.

So one day at a meeting I said, "You know, the PDP-6--or PDP-10--instruction set is sufficiently simple that it would not be hard to write an emulator for it in C and run it on a Cray." So that is what we did. I wrote the instruction decoding part of it, and Mike Nemanic then put the thing into a working package. That thing now runs on the Crays, and I believe it runs faster than a real PDP-10, at least the one we had back then.

GAM: Oh yes?

JF: So, if, by some terrible chance, we had to, say, do a fresh assembly for something like an 8X300 or an RPU, that is where we would have to do it.

GAM: Well, if you remember how to do it. But there's not many others who do--it's kind of slowly disappearing into the mists of time.

JF: So, they will have to consider what the rules will be for getting me back if they need me back.

GAM: Come on bended knee!

JF: Yes.

GAM: Well, I certainly second your choice of the PDP-10 as being an interesting machine to work on.

JF: For high-level languages--actually, I like C. And FORTRAN was not bad. I guess it is recursive today. That was certainly a big handicap in the beginning. But all those languages of that ilk--ALGOL, PASCAL--to my mind are very similar. I am sure the PASCAL people look down their noses at FORTRAN, but the differences are small.

GAM: Well, the control structures are different.

JF: The languages where people tend to position themselves in order to look down on other languages are ones that take things away. They are proud that they don't have a go-to, or they don't have a this, or they don't have a that.

GAM: Ah, the go-to.

JF: I write go-to-less C just partly for fun, but it is much better to have go-to's available. Languages like PASCAL hem you in. A lot of people don't know that the switch structure in C is such that you can place the switch labels anywhere. If you have a loop inside a switch statement, you can switch your way right into the middle of that sucker. It is almost as powerful as a go-to.

GAM: And probably as enigmatic.

JF: That's right. But there are cases when it is very rational to switch your way inside an if-then-else sequence; you are coming in again, and you know you are in this case. You don't have to cascade your way into it and set a bunch of variables to fool yourself. But going into the side of a loop is something you really have to think about.

GAM: Well, I think you'd have to think about when it would pay at all. I don't think any of us are searching for microseconds anymore.

JF: Of course, another thing was the effort to save memory. In programming machines like the PDP-8 and the 8X300, the whole thing was to shoehorn the program into that tiny memory. Today, gosh, you can just throw memory away.

GAM: Well, I don't see it as throwing it away. I think you use it rather than to waste your strength on something that's just academic. Anyway, it's a new generation of programmers that doesn't understand that the UNIVAC had only a thousand words.

JF: A thousand?

GAM: The IBM 701 had 4K words.

JF: I remember doing something on the 7094, where you had 32K words. I had to use trickery. The natural way to do the job would have taken exactly 32K words of data--probably a few more, but 32K in the big array. So I figured out how to cut that by a factor of 4 by being sneaky. Then of course I had plenty of space for everything else.

GAM: Well, that's exactly one of the great rewards of programming--so to say--"programming in the small," or something like that. These are intellectual challenges that you meet and win, and they're good.

JF: There is the whole business in assembly language of managing the registers so that you don't have to touch a thing after you have overwritten it. I had a lot of fun with that, but I probably would not really enjoy going back to it. It is an intellectual puzzle, which I guess I have solved enough times that I'm not sure I would want to start solving them again.

GAM: Well, I expect that's correct.

JF: But as long as I kept doing it, it did not bother me. I guess it was kind of natural. Obviously, you have got to keep this one in this register is what I would think. You would get a real feeling for it.

GAM: How about you? Did you have to deal with Sid Fernbach a lot when you were in the early days of this group?

JF: Sid was pretty much a hands-off guy. He let us take the ball and run with it. The one thing--you have to give Garret credit for this--was that Hans Bruijnes liked to--

GAM: Impose his personality.

JF: When Garret was--we were--putting together the PDP-6 storage system, we discovered that Bruijnes had put a few of his group to work on an alternative version, his idea being that theirs was going to come in and be used instead of ours. He had done a similar thing earlier, I think, on the CDC 3600 or something.

GAM: Yes.

JF: Anyway, we got wind of it, and Garret came in and worked nights and weekends, and he got our scheme done first.

GAM: I remember that, yes.

JF: I have this clear impression--I do not know how I would have been present--of Sid telling someone in the other camp that, well, he was going to have to go with what Garret and Badger and the rest of us had done--sort of apologetic. But I cannot remember why it was that I would have been in a position to overhear that. Anyway, Sid was a results guy. You could see that if we had not been first, we probably would have been chopped off--there is no question about it.

I really liked Sid. He was a good guy to work for--well, present regime excepted--better than his immediate successor. I will put it that way. I will not judge the present regime.

GAM: Oh, I see.

JF: That is when everything that we did that was new and original either took place, or the seeds for it were planted. It may be that the world passed us by--we just could not possibly, single-handedly stay at the forefront like we used to, but I don't think that things would have gone quite the way they did if Sid had still been around.

GAM: Well, yes, I'm afraid we can't tell that. Sid's Waterloo so-to-say was two STARs. I think he spent an enormous amount of emotional and just day-to-day attention on that problem, and so other things just didn't get attended to so much.

JF: In my view the STAR certainly did not turn out the way one would have hoped. But you had to do something. Sid was trying to bring us more computing power. What was the alternative?

GAM: I don't know, but I'm just emphasizing that the Waterloo is not STAR, but two STARS, okay? One STAR is no more serious than one LARC, or one STRETCH.

JF: The mistake was to get two of them?

GAM: Yes. That's what everyone says.

JF: Well, that might have been, that might have been. Another thing that may be laid at his doorstep is the fact that we did not get our way of doing things out into the world. Had we worked harder at making some of our ideas--

GAM: I don't think it was needing to work harder so much as we ought to have published more.

JF: Yes, maybe just that. There was no encouragement, no pressure put on to get our ideas out. That probably was a mistake.

GAM: Well, mistake may be a strong word. I would say it may be implied that the job wasn't finished till the paperwork was done, or something like that. In any event, the major difference between us and anywhere else is the publication--just look. Other than that, the better stuff was in general made here, especially in the early days--far better.

JF: Yes. There were lots of things that people had to give up in one way or another when we went to UNICOS. We are fixing some of them now. We are working on restarting jobs.

GAM: It's a different computer world now.

JF: Yes.