`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VM AND THE VM COMMUNITY: Past, Present, and Future
`
`Melinda Varian
`
`Office of Computing and Information Technology
`Princeton University
`87 Prospect Avenue
`Princeton, NJ 08544 USA
`—.—
`BITNET: MAINT@PUCC
`Internet: maint@pucc.princeton.edu
`Telephone: (609) 258-6016
`
`April, 1991
`
`I. INTRODUCTION
`
`I will be talking today about the past, present, and future of VM, with an emphasis on the
`influence of the VM community on the growth of the VM product.
`
`This paper was originally presented at Australasian
`SHARE/GUIDE in Melbourne in 1989. My husband Lee
`and I had a delightful time at ASG and are most grateful to
`ASG for being our host in Australia and to SHARE for
`giving us the opportunity to represent it there.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Cecilia Cowles
`
`When I spoke at ASG, I began by conveying greetings
`from the President of SHARE, Cecilia Cowles. I will do
`that again today, because the pictures are too good not to
`use again.
`
`In the past, when I’ve spoken at SHARE and SEAS, my
`talks have been strictly technical. This talk was the first
`time I’d been asked to give my opinions, so you may find
`that you get more opinion than you wanted. Certainly, I
`should make sure you understand that my views are not
`necessarily those of my management (and are sometimes
`not those of SHARE management either).
`
`I must also ask you in advance to forgive me my
`ethnocentricity. Though I speak of “the VM community”,
`I realize that there are actually several overlapping
`communities of VM people, located in different parts of
`the world, both inside and outside of IBM. For the most
`part, I will be speaking of the community of which I’m a
`long-time member, whose center is the VMSHARE
`
`Microsoft Ex. 1046, p. 1
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 2
`———————————————————————————————————————
`
`electronic conference. This community overlaps heavily with SHARE and SEAS, with the
`annual VM Workshops in North America, and with various regional VM user groups. It includes
`many participants from IBM as well.
`
`I’ll be showing you pictures of some members
`of this community, but because there’s not
`nearly enough time to show all the people who
`have made outstanding contributions to VM and
`to the VM community, my choice of who to
`show was semi-random, depending a lot on
`which pictures I was able to get. I owe thanks to
`many photographers who lent me their pictures,
`but especially to Joe Morris of SHARE and
`Stuart McRae of SEAS.1 I am also indebted to
`Sandra Hassenplug and John Hartmann for their
`assistance in preparing slides, as well as to
`several of my colleagues at Princeton.
`
`
`Joe Morris
`
`
`
`Stuart McRae
`
`Sandra Hassenplug
`
`————————————————————
`
`1
`I am grateful to the many people who succumbed good-naturedly when I badgered them for
`photographs. I wish particularly to thank Bob Creasy, Adenah DeAngelis, Jerry DePass, Walt
`
` Doherty, Lyn Hadley, Ed Hendricks, Peter and Carol Jobusch, Ted Johnston, Ken Holt, John
` Shaw, Dave Tuttle, Lee Varian, John Wagner, Lynn Wheeler, Rich Wiggins, and Joan
` Winters.
`
`Microsoft Ex. 1046, p. 2
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 3
`VM and the VM Community
`———————————————————————————————————————
`
`
`
`
`
`John Hartmann
`
`Princeton Interactive Computer Graphics Laboratory
`
`Microsoft Ex. 1046, p. 3
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 4
`———————————————————————————————————————
`
`I should probably also explain the iconography
`I’ll be using. For many years, the SHARE VM
`Group lamented the fact that VM had no
`symbol, no totem. A couple of attempts were
`made to select one, but they fell flat, because, of
`course,
`such
`things can’t be mandated.
`Meanwhile, the MVS Group had the turkey
`(which they chose of their own volition), and
`they went around wearing turkey hats and
`putting turkey stickers on elevator doors, and so
`on. The legend is that the MVS Performance
`Project began using the turkey as a symbol in
`the early days when MVS performance was
`definitely a turkey, and the symbol soon got
`extrapolated to the whole MVS Group.
`
`With VM’s amazing growth, the VM Group in SHARE has always had a problem making
`newcomers feel at home, simply because they always outnumber the oldtimers. In 1983, the
`Group was going through yet another attempt to overcome this problem, and it was decided that
`at SHARE 60 we would hand out little square yellow stickers to newcomers to the VM Group
`and little square blue stickers to oldtimers, with the idea that if they all put the stickers on their
`badges, the oldtimers could identify the newcomers and help make them feel at home. The
`problem with that, of course, was that nobody could remember which sticker was which, so it
`didn’t work out at all. A couple of days into that week, however, Carol Jobusch bought a few
`hundred teddy bear stickers, with the idea of affixing them to the cuddlier of the oldtimers so that
`the newcomers would know that here was a warm cuddly person who ran the warm cuddly
`system and who could be counted on to be friendly if approached. Within hours, the teddy bear
`had become the de facto symbol for VM, and everybody in the VM Group, old or new, cuddly or
`prickly, was wearing a teddy bear on his badge. (The Jobusches subsequently got a 50-KB roll of
`stickers, to keep SHARE well supplied.)
`
`
`
`Carol Jobusch
`
`Microsoft Ex. 1046, p. 4
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 5
`VM and the VM Community
`———————————————————————————————————————
`
`One rather strange result of all this has been that the offices of many hard-bitten system
`programmers are now full of teddy bears.
`
`
`
`Typical VM system programmer’s office
`
`However, even without being reminded of it by the MVS Group, we would have been careful not
`to let our arctophilia degenerate into icky sweetness.
`
`Microsoft Ex. 1046, p. 5
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 6
`———————————————————————————————————————
`
`Not surprisingly, soon after VM adopted the
`teddy bear, the MVS Group decided that the
`turkey was no longer an appropriate symbol for
`MVS, and opted instead to use the eagle.
`
`But, of course, such things can’t be mandated.
`
`I should also warn you that you may notice in my presentation a few slides that indicate a certain
`rivalry between the VM and MVS Groups.
`
`
`
`“Is this any way to treat a guest?”
`
`“The light at the end of the tunnel”
`
`Microsoft Ex. 1046, p. 6
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 7
`VM and the VM Community
`———————————————————————————————————————
`
`I hope that none of you will take offense at our banter, for I assure you that the rivalry is a
`good-natured one and only skin deep.
`
`
`
`
`Donna Walker: “VM—half the size, twice the power”
`Jimmy Pittman: “VM still doesn’t measure up to MVS”
`
`Microsoft Ex. 1046, p. 7
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 8
`———————————————————————————————————————
`
`
`
`“He ain’t heavy—he’s my brother”
`
`In fact, most installations in the SHARE VM Group run MVS, and most Group members use
`MVS every day, although, of course, very few of us use TSO.
`
`Running TSO
`
`is like kicking
`
`a dead whale
`
`along the beach.
`
`
`
`
`
`
`
`
`
`
`
`Horace: “Ars Poetica”
`
`Microsoft Ex. 1046, p. 8
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 9
`VM and the VM Community
`———————————————————————————————————————
`
`
`
`
`II. DIGRESSION: ON WHERE REALLY GOOD SOFTWARE
`COMES FROM
`
`Before getting into the history of VM, I’d like to discuss briefly some observations I’ve made
`over the years on where really good software comes from. I want to talk about this topic a bit
`because I think it may serve as a theme for what follows.
`
`First of all, let me define my terms. To me, “really good software” is simply software that greatly
`enhances the ability of people to use computers, software that lets people use computers to do
`easily things they couldn’t do at all before. Perhaps the best test of whether a program or a
`system is really good is whether people fall in love with it, whether their eyes light up when they
`talk about it.
`
`The reason that it’s important to understand where such software comes from is that it is the
`source of the real growth of our systems. Really good software enhances the productivity of our
`end users, makes our systems grow, and expands IBM’s markets. So, everyone of us in this room
`benefits when IBM or its customers find ways to create more really good software.
`
`In case it’s not already clear, let me add that I’m not talking about software with low APAR rates.
`Really good software often has extremely high APAR rates, especially when it is new. Indeed,
`I’m almost, but not quite, willing to assert that an extremely high APAR rate in a new product
`should be cause to give the author an award. Certainly, a very high APAR rate in a new product
`is often an indication of high product acceptance. If I may give a couple of examples:
`
`• First, let’s consider the early days of Xedit,2 although I always hate to use editors as examples
`
`because they’re so controversial. I can’t remember now who it was who said, “Editors are like
`
`religions, except that people don’t have such strong feelings about their religions.”
`
` There can be no question that by releasing Xedit in 1980, IBM gave CMS a new lease on life.
` Nevertheless, when Xedit first came out, its APAR rate was so high that an IBMer whom I
`
`greatly respect asked me whether releasing it had been a mistake. In fact, the APAR rate was
`
`quite high, but the problems that were being reported were almost all very small problems. It
`
`became clear that people were using Xedit so enthusiastically and so creatively that they were
`
`stretching it to its limits, and in the process running into little errors that hadn’t been
`
`discovered in IBM’s testing. While the errors that were being reported were genuine and
`
`needed to be fixed, the remarkable thing about many of them was that people cared enough
`
`————————————————————
`
`2 When asked what other editors influenced the design of Xedit, Xavier de Lamberterie
`
`graciously replied with the following note:
`
`
`
`
`
`
`
`
`
`
`
`
`
`Well, Xedit comes from a long way. It has been influenced by the editor from
`CP-67, then some other editors that were developed locally at the Grenoble
`University (including editors with macro capabilities, which were probably the first
`ones to have such a concept), and certainly from Ned that we had a long time ago
`(some Xedit target commands are inspired from Ned). Then later on, when
`full-screen displays were available, Xedit took some ideas from Edgar and ISPF
`(features like prefix line commands).
`
`But I guess the major feature of Xedit was to keep the “heart” relatively small and
`allow users to redefine and/or extend the existing commands via EXECs or REXX
`macros. This was one of the major successes of Xedit.
`
`Microsoft Ex. 1046, p. 9
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 10
`———————————————————————————————————————
`
`about the product to invest the time needed to get such a minor problem fixed. That they were
`
` willing to do that was a tribute to Xedit’s author, Xavier de Lamberterie. (If you’ve ever
` wondered where the “X” in “Xedit” came from, now you know—it was Xavier here.)
`
`
`
`
`Xavier de Lamberterie
`
`Noah Mendelsohn
`
` •
`
` Second, let’s look at the early days of Pass-thru. The original author of the system that
`became Pass-thru was Noah Mendelsohn. In 1974, Noah was given the task of inventing a
`
` way to allow the PSRs and Change Team people using a system in Mohansic to get access to
`
`the RETAIN system in Raleigh. His solution was “V6”, a server that provided the basic
` Pass-thru function in an elegant and extensible form. Bill Anzick, who had advised Noah on
` V6 from its beginning, took over the project in 1977 and expanded it into the product that was
`
`announced in 1980 as Pass-thru.
`
` Although I don’t believe that SHARE had asked for something like Pass-thru, as soon as we
`
`saw it, we wanted it badly. As soon as the tapes arrived, they were rushed to our computer
`
`rooms, and the product was installed right away, all over the world.
`
` Pass-thru had been used extensively inside IBM before it was released, so it had already been
`
`fairly well debugged. Many of us who had moderate-sized Pass-thru networks never saw a
`
`failure. However, within weeks of its release, Pass-thru started being used on quite large
`
`networks, with many more concurrent users than it had ever had before. Inevitably, it was
`
`found that some algorithms that worked perfectly well in smaller networks didn’t work so well
`
`in large networks. That was not surprising. What was surprising was the way the problem
` was handled. Anzick and Don Ariola, of Field Engineering, spent a year heroically expanding
`
`and strengthening Pass-thru to support the very large networks that customers were building.
` Their changes came out as APARs, so again we saw a new product with a very high APAR
`
`rate, and again that APAR rate meant that the customers were extremely happy with the
`
`product.
`
`Microsoft Ex. 1046, p. 10
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 11
`VM and the VM Community
`———————————————————————————————————————
`
`
`
`Bill Anzick
`
`Don Ariola
`
`Of course, I am not disappointed to find a piece of really good software that is also bug-free. The
`example that comes to mind is REXX, which was essentially flawless by the time it was released.
`This means that the author of REXX, Mike Cowlishaw, had managed to write a large piece of
`code that was coherent enough that it could actually be debugged, but it is also the result of his
`code having been exercised very thoroughly inside IBM before it was released.
`
`
`
`Mike Cowlishaw
`
`Microsoft Ex. 1046, p. 11
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 12
`———————————————————————————————————————
`
`These three examples and almost all other examples I know of really good software have
`common characteristics that I’ve come to believe are necessary in producing software that allows
`users to do wonderful new things with computers:
`
`1. Really good software can be written only by very small groups of very skilled
` programmers.
`
` A group size of one is not too small; twelve is probably too large. The group must be small
`
`enough that communication is not a problem and small enough that everyone involved feels
`
`responsible for the end result. The programmers themselves must be highly skilled, though
`
`perhaps we dissolve into a tautology if we say that really good programmers are the ones who
` write really good programs. Nevertheless, average programmers never write really good
`
`software. On a large project, using very good programmers is the only way to keep the size of
`
`the group small enough to maintain communications. But even on a small project, software
`
`produced by very good programmers is qualitatively different from that produced by the less
`
`talented, and no amount of procedure or process or standards can compensate for this
`
`difference.
`
` VM itself is the perfect example of what can be achieved by a very small number of very good
`
`programmers. During CMS’s formative years, 1965-1971, there were never more than half a
`
`dozen people working on it at any one time, including designing, developing, and
`
`documenting it. There were no more than eight people at a time working to develop the
` System/370 version of CMS. The original versions of the Control Program, CP-40 and
` CP-67, were also the work of very small groups. Most of the work on Release 1 of the
` VM/370 Control Program was done by just twelve people.
`
`
`
`
`
`
`
`
`Chuck Tesler
`
`Serge Goldstein
`
`I’ve already mentioned Xedit, Pass-thru, and REXX, which had one or two primary authors
`each. The same was true for Smart, which was written by Dick Jensen, and VMAP, which
`
`Microsoft Ex. 1046, p. 12
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 13
`VM and the VM Community
`———————————————————————————————————————
`
` was written by Chuck Tesler.3 Another good example is Track, the splendid system
`
`programmer tool written by my colleague at Princeton, Serge Goldstein.
`
`2. Really good software is almost always a labor of love.
`
` By this I mean that the programmer must really want to create this particular piece of
`
`software. A case in point is CMS Pipelines. John Hartmann, of IBM Denmark, the author of
` CMS Pipelines, has described its origin:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`I passed through Peter Capek’s office one day. We can’t really remember when it
`was—probably sometime late ’80 or early ’81. He had a box of the Bell Systems
`Technical Journal issue on UNIX4 under his table. I saw him slip a copy to
`someone, so I said gimme! Having read it (and ignoring their remarks about
`structured data), I ran off shouting from the rooftops and then began coding with
`both hands and my bare feet.5
`
`John Hartmann
`
`“The Pipeline is open” 6
`
`It’s not too far-fetched to say that the best programs are the ones written when the programmer
`is supposed to be working on something else. REXX is an obvious example of that.7 Since
`
`————————————————————
`
`3 Then with IBM, now with ProSoft.
`
`4 UNIX is a trademark of UNIX System Laboratories, Inc.
`
`5 J.P. Hartmann, private communication, 1990.
`
`6 This drawing by Michael Goodman is copyrighted (1989) by the VM Systems Group and is
`
`used with permission.
`
`7 “It was my good fortune to be in charge of the IBM Hursley Laboratory during the period
` when Mike Cowlishaw, who at the time was a member of IBM’s System Assurance
` Laboratory, created REXX. I should hasten to say that I claim no credit whatsoever; REXX is
`
`the product of a dedicated individual committed to the solution of a problem. He did so not
`
`Microsoft Ex. 1046, p. 13
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 14
`———————————————————————————————————————
`
` Serge isn’t here, I can say that Track is another good example of that, but it’s true of almost
`
`every really good program. Very good things happen when management is enlightened
`
`enough to appreciate the importance of allowing programmers some free time for projects of
`
`this sort.
`
` The programmer must also be allowed a sense of ownership, of personal responsibility. This
`
`is not “egoless programming”. Exciting software, the kind that expands the uses of
`
`computers, is not produced by people who feel themselves to be small cogs in vast machines.
`
`3. Really good software is almost always begun because the author himself needs it; it
` makes his computer do something that he really wants it to do.
`
` CP-40 was written because the folks in Cambridge needed a way to share their one small
`
`computer so that they could do all the things they wanted to do. The first communications
`
`component of VM was written so that people at the Cambridge Scientific Center could
`
`communicate with people at the Los Angeles Scientific Center. Smart and Track and CMS
` Pipelines were all written to assist their authors in their work. Dick Jensen, who had been a
` CP developer in the Burlington days, was a fire-fighting SE at the time he wrote Smart, just as
` Serge is a fire-fighting system programmer today.
`
`
`
`
`Wilt Byrum (self-portrait)
`
` Another good example here is Amdahl’s Analyze dump viewer. Analyze began as a massive
`
`set of local modifications to IPCS Dumpscan. The author was Wilt Byrum. Wilt was a
`
`system programmer being deluged by dumps, so he needed a better and faster dump reader
`
`badly enough to write it for himself. After Wilt left Amdahl, Analyze was adopted by John
`
`————————————————————
`
`because he was asked to; not because he was expected to; not even because there was any
`
`job-related requirement for him to do so, because he was supposed to be wholly dedicated to
`
`the evaluation of products developed by others; but he did so because Mike Cowlishaw saw
`
`the need and the solution, and got on with it, almost despite his management rather than
`
`because of them.” (Sir John Fairclough, in The REXX Handbook, Gabriel Goldberg and
`
` Philip H. Smith III, eds., McGraw-Hill, 1992, p. xi.)
`
`Microsoft Ex. 1046, p. 14
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 15
`VM and the VM Community
`———————————————————————————————————————
`
` Alvord,8 who massively extended and restructured Wilt’s massive extensions. John needed an
`
`even better and faster dump reader because he was reading dumps for lots of customers. After
`
`John left Amdahl, Keith Philip adopted Analyze and greatly extended it, out of a system
`
`programmer’s love for a great tool (even though he officially works on something else).
`
`
`
`
`
`
`John Alvord
`
`Keith Philip
`
`4. Really good software is never finished; it continues to grow. If it doesn’t grow, it decays.
`
`
`
`
`
`
`If a program or a system is good enough for users to exercise to its limits, they will always run
`up against those limits and will want them removed. They will always have ideas for making
`it more powerful and more useful. If a program or system doesn’t grow to fulfill users’
`evolving requirements, someone will write a replacement that will.
`
` You may have been surprised that I would cite Smart and VMAP as examples of really good
`
`software, since today there are clearly superior tools available. Yet, when they were first
`
`released, VMAP and Smart greatly enhanced our ability to understand and support our
`
`systems. Unfortunately, they have been allowed to stagnate since then.
`
` An even more extreme example is IPCS Dumpscan. We’ve all been scoffing at Dumpscan for
`
`so many years that it is difficult now to remember how revolutionary it was when it first came
`
`out, how tremendously it increased our productivity. Yet, I remember the day I learned to
`
`read dumps with Dumpscan as clearly as I remember the day I learned to read, and I
`
`remember feeling the same sort of triumph on both those days. Dumpscan was the brainchild
`
`of the late Dick Seymour. His original intent was not the creation of a tool to be used by
`
`customers or even by the Change Teams; Seymour was exploring the possibilities for
`
`automatic analysis of system failures. Dumpscan was an unexpected byproduct of that study.
`
`————————————————————
`
`8 Now with Candle Corporation.
`
`Microsoft Ex. 1046, p. 15
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 16
`———————————————————————————————————————
`
` The primary author of Dumpscan was John Shaw.9 Larry Estelle, a Regional VM Specialist
` who had been a CP developer, demonstrated Dumpscan’s potential as a service tool by dialing
`
`into a customer system and using Dumpscan to shoot dumps. Ultimately, Dumpscan was
` made available to customers, whereupon it quickly became the object of more customer
`
`enhancements than almost any other part of VM. Once people saw the usefulness of such a
`
`tool, other, far superior dump viewers soon appeared, while IBM allowed Dumpscan to waste
`
`away of neglect.
`
`
`
`
`
`
`
`
`
`Dick Seymour
`
`Larry Estelle
`
`Tom Pattison and John Shaw
`
`————————————————————
`
`9 Mike Ness and Tom Pattison also worked on Dumpscan and other parts of IPCS.
`
`Microsoft Ex. 1046, p. 16
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 17
`VM and the VM Community
`———————————————————————————————————————
`
` Software that we all recognize as good continues to grow. REXX is still evolving. One hears
`
`tales of Xavier’s having attempted to sneak new features into Xedit after the cutoff date for its
`
`first release. Hardly a week goes by without at least one new feature being added to Track and
`
`to CMS Pipelines.
`
`5. To evolve into really good software, a program or system must be “hacked at”.
`
` There’s no point in telling designers and programmers to “do it right the first time”. In fact,
`
`one learns what a program really should do only by writing it and using it. I think it’s safe to
`
`say that the first few designs and at least the first implementation should always be discarded,
`
`once the lessons they can teach have been learned. If an organization wishes to create really
`
`good software, software that will greatly expand the uses of its computers, then the
`
`programmers must be free to rework the design, the structure, and the code over and over until
`
`they are almost as good as they can possibly be.
`
`6. To evolve into really good software and remain good, a program or system must develop
`
`an intelligent, adventurous, passionate user community with enough influence to be able
`
`to guide its further development.
`
` No matter how good a piece of software is, in order to succeed it must have enthusiastic users
` who will proselytize for it and help teach others to use it. If it fails to win such support, it will
`
`die. If it does attract such support, then no matter how brilliant and complete its design, the
`
`users will always want to use it to do things the author never imagined. If the author is unable
`
`or unwilling to get and use feedback from the users to guide his further development of the
`
`software, then much of his effort will be wasted in adding features the users don’t care about.
` When software is good enough that users are concerned about its future and willing to
`
`contribute their time and ideas to provide direction, and the author or developer is willing to
`
`accept their direction, then the result can be a positive feedback loop, with the software
`
`becoming ever more successful, ever more widely used.
`
` VM itself is the ultimate example of this. The periods of its greatest improvement have been
`
`those when there were close ties between the developers and the users and when the
`
`developers were highly responsive to the users’ needs and concerns. VM’s only real failures
`
`have come in times when those ties were less close and when the developers appeared to be
`
`paying less attention to the users.
`
` Throughout VM’s history, real end users have played an indispensable role in teaching others
`
`to use CMS. An interesting recent example of this is seen in the spread of CMS Pipelines
` within IBM. As it matured, CMS Pipelines was distributed throughout IBM via the VNET
`
`network. Experienced CMS Pipelines users (known as “master plumbers”) soon developed a
`self-study course to help others learn to use CMS Pipelines.10 This self-study course later
`
`
`evolved into the excellent CMS Pipelines Tutorial (GG66-3158).
`
` Another very successful example of the role knowledgeable users play is seen in the evolution
`
`of REXX. Mike Cowlishaw made the decision to write a new CMS executor on March 20,
`
`1979. Two months later, he began circulating the first implementation of the new language,
`
`————————————————————
`
`10 “Larry Kraines wrote the first eight lessons of the course originally. John Lynn wrote one
` when Larry got busy elsewhere. Many other people contributed improvements after that.”
`
`(J.P. Hartmann, private communication, 1990.)
`
`Microsoft Ex. 1046, p. 17
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 18
`———————————————————————————————————————
`
` which was then called “REX”. Once Mike made REX available over VNET,11 users
`
`spontaneously formed the REX Language Committee, which Mike consulted before making
`
`further enhancements to the language. He was deluged with feedback from REX users, to the
`
`extent of about 350 mail files a day. By consulting with the Committee to decide which of the
`
`suggestions should be implemented and which pieces of contributed code should be
`
`incorporated, he rather quickly created a monumentally successful piece of software. When
` REXX celebrated its tenth birthday recently, it was still spreading to new systems and
`delighting new users.12
`
`
`
`
`
`“/* Best Language of the Year */”
`
`“TSO/E—Puttin’ on the REXX”
`
`
` Frequently, people who use a really good program or system will care so much about it that
`
`they will add desired new function themselves, if there are facilities for their doing so. If the
`
`author of the software makes a point of learning about the most successful of these new
`
`functions, he can gain much guidance in developing his product further.
`
`If you will keep this list in mind as I outline the history of VM, I think you may notice other cases
`where these factors resulted in innovations that accelerated the growth of our systems.
`
`————————————————————
`
`11 “The most important influence on the development of the REXX language was the IBM
`
`internal electronic network, VNET. Without the network (and the people who keep it
`
`running), there would have been little incentive to start a task of this magnitude; and without
`
`the constant flow of ideas and feedback from people using the network REXX would have
`
`been a much poorer language. Much credit for the effectiveness of VNET as a
`
`communication medium for this sort of work is due to Peter Capek who created the VM
` Newsletter (1973-1983). Today, REXX language design is carried out over the same network
`
`almost entirely with the aid of the Tools computer conference system—appropriately enough,
`
`a system written in REXX.” (M.F. Cowlishaw, The REXX Language: A Practical Approach to
` Programming, Prentice Hall, second edition, 1990, p. x.)
`
`12 Cowlishaw was made an IBM Fellow in 1990.
`
`Microsoft Ex. 1046, p. 18
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`Page 19
`VM and the VM Community
`———————————————————————————————————————
`
`
`
`III. A BRIEF HISTORY OF VM
`
`I owe many kind VMers thanks for having shared their memories and their memorabilia with me
`so that I could share them with you.13 I regret that this account will leave out many people who
`have made good and lasting contributions to VM, but this is inevitable, given our time constraints
`and my ignorance of much of what has happened inside IBM during the past twenty-five years. I
`would be delighted to hear any corrections or additions you may have to story I’m about to tell.
`
`A. CTSS
`
`In the beginning was CTSS, the “Compatible
`Time-Sharing System”. CTSS was written by a
`programmers14
`small
`group
`of
`at
`the
`Massachusetts Institute of Technology (MIT) in
`Cambridge, Massachusetts, under the leadership
`of Professor Fernando Corbato´. One of the
`CTSS programmers was Robert Creasy, who
`was later to become the leader of the CP-40
`project.
`
`Papers discussing the idea of a time-sharing
`system began being published about 1959.15
`There followed a period of experimentation at
`MIT and other institutions. An early version of
`CTSS was demonstrated on an IBM 709 at MIT
`in November, 1961. From that beginning, CTSS
`evolved rapidly over the next several years and
`taught the world how to do time-sharing.16
`
`————————————————————
`
`Fernando Corbato´
`
`13 I’ve managed to locate most of the people mentioned in this chapter. Without exception, they
`
`have been extremely generous with their time and assistance, regaling me with delightful tales
`
`of their days in VM and patiently enduring my endless questions. I am grateful to them all. I
`
`am also indebted to the people who have searched out physical evidence for me: the system
`
`programmers at Brown University, who donated an intact PID shipment of CP-67 Version 3;
` Bill Frantz, Scott Tyree, and Walt Hutchens, who sent me stacks of early manuals; Chuck
` Rodenberger, who sought out dozens of old “blue letters”; Alan Greenberg and Dewayne
` Hendricks, who sent me their archives from SHARE and GUIDE activities in the CP-67 and
`
`early VM/370 days; David Walker and Jacques Myon, who unearthed some amazing artifacts;
` Bob Cox, Gabe Goldberg, and Chuck Morse, who sent slide sets from VM demonstrations and
`
`announcements; Dave Tuttle, who wrote out his memoirs and also lent me an astonishing
`
`collection of VM relics; Fernando Corbato´, Les Comeau, and Don Wagler, who made me
`
`videotapes of rare old films; and Stu Madnick, who sent me the contents of his attic.
`
`14 Marjorie Merwin-Daggett, Robert Daley, Robert Creasy, Jessica Hellwig, Richard Orenstein,
`
`and Lyndalee Korn.
`
`15 C. Stratchey, “Time Sharing in Large Fast Computers,” Proceedings of the International
` Conference on Information Processing, Paper B.2.19, UNESCO, New York, June, 1959.
`
`Microsoft Ex. 1046, p. 19
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`VM and the VM Community
`Page 20
`———————————————————————————————————————
`
`CTSS was developed on a series of IBM processors. In the 1950’s, IBM’s president, T.J.
`Watson, Jr., had very shrewdly given MIT an IBM 704 for use by MIT and other New England
`schools.17 Then, each time IBM built a newer, bigger processor, it upgraded the system at MIT.18
`The 704 was followed by a 709, then by a 7090, and finally by a 7094. IBM also gave MIT the
`services of some highly skilled Systems Engineers and Customer Engineers, who formed its MIT
`Liaison Office, w