BTL leaves Multics
Dennis Ritchie
and the start of Unix.
During 1966-67 I was writing a theoretical PhD thesis at Harvard and
supporting myself financially and intellectually by working part-time
at Project MAC on Multicsy things. I'm not sure I helped the project
much; I rewrote some introductory MSPM sections on the file/memory
system. Mostly I played with CTSS, since at the time I was most
active, Multics was still being simulated on the GE 635 and CTSS was
king. I grew less present at MAC (even though being paid) towards the
end of the time there as the thesis-writing became more intense.
Money to support hangers-on like me must have been more easily
available in those days.
Having arrived at Bell Labs at the end of 1967 and a wanting a fresh
start, I instantly withdrew from theory and also at first resisted
involvement in Multics work. Instead I helped Rudd Canaday port the
BCPL compiler to GECOS and reimplemented Ken Thompson's QED editor on
GE-TSS.
At the time, the BTL commitment to Multics was fairly substantial
though not complete. The Murray Hill facility (which in the corporate
scheme, could be identified approximately with the R of R&D) had
committed to the extent of tossing IBM 7094s and getting two GE 645s
to handle computational needs; other major locations (then Holmdel and
Whippany) had never bought into Multics and were in the 7094->360
transition throes. One of the MH 645 machines ran GECOS (not
especially well: the `K package' caused lots of problems) and the
other was used for Multics development.
The personnel commitment was down from its height; certainly it
included Neumann, Ossanna, Thompson, Molly Wagner; McIlroy and Morris
were still tweaking EPL. There were doubtless others still involved.
Some of the ongoing activities were the IO switch and the terminal
DIM.
Some months after arriving, I again ensnared myself in Multics. Peter
Neumann had picked up a new system tape from MIT and was going to try
it. I bashfully asked him, "Is this a public boot?" and he ushered
me into the machine room. The tape twitched fitfully for several
hours until boredom and anxiety compelled us to abort the process.
Subsequent analysis revealed that everything was indeed OK; booting
just took a long time. Fortunately, the bound_original_binder soon
made it quicker.
During the remainder of 1968 and into 1969 I helped port the BCPL
compiler to Multics and worked on a reimplementation of the TTY DIM; I
also worked on the runtime system for the new Fortran compiler from
GE. It gradually became clear that the future of Multics at the Labs
was doubtful. Simply, it showed poor prospects of being able to
handle the company's computational needs economically within a
reasonable time. The vision of the information utility, an admirable
research goal, had been oversold: it was costing too much, taking too
long. and even the affluent Bell System of 1969 couldn't afford it.
The real problem with Multics for the AT&T of 1969 was that even if
had succeeded wildly, it was hard to see the unique way it would have
helped the company. The potential payoff for both GE (share in the
computer market) and MIT (academic glory, bigger and better grants)
was obvious, but for AT&T the upside was not so evident and the
downside was becoming an embarrassment.
The decision to bail out was telegraphed months in advance, and even
before explicit telegraphy started, the number of local enthusiasts
and researchers actually working with Multics had dwindled; Neumann
and Ossanna remained the political flag-bearers. Moreover, well
before the decision was announced, Thompson had shown signs of wanting
to write a OS of his own; he wrote a paging system simulator (using
Multics), and he, Canaday, and I sketched out on a blackboard the data
structures for what became the Unix file system. Ken even created a
tiny kernel of a system for the 645, which actually printed out an
equivalent of `hello world.'
The final announcement did cause a jolt; Peter Neumann decided to go
elsewhere, others instead tried to reestablish a computing environment
with available means. I spent more time with GE-TSS, Ken found the
famous PDP-7, and Ossanna, Ken, I and others tried to get a PDP-10 to
write a new system on. All of the people I've mentioned were
interested in Multics and disappointed to be out of it, but only some
were utterly committed. Thompson in particular seized the opportunity
to create something of his own that drew much from the Multics
experience but was also his own invention and (as it turned out) was
much better adapted to economic and technical reality.
He and the rest of us learned a lot and took a lot from Multics.
Unix was neither unauthorized nor bootlegged, although we were made
aware that Bell Labs did not want to create another big operating
system project; this was the real reason for not buying a PDP-10 for
us to play with--a truly wise decision, as it turned out. At any
rate, our management remained very willing to support OS research on a
small scale. I can recall only two points of discouragement: while
struggling to find myself in the immediate aftermath of Multics's
banishment, I was explicitly asked to join a project I did not choose
(writing a compiler for the Altran algebra system); and it was harder
than it should have been to buy the first PDP-11. But none of the
work was hidden in any way and it did not take long before it began to
be rewarded.
By the way, it's amusing to relate these events of 1969 to a recent
thread: during the very last months of Multics's existence at the
Labs, our 645 was used remotely from Cambridge in the development of
some version of mail, since it was less loaded than MIT's machine.
The technical details of how to implement mail securely, reliably,
efficiently and attractively were in contention not only then but
before and after. I can even recall manifestos tacked up on the bulletin
board outside my and Padlipski's office in 1967! Indeed, throughout
the early years of Unix, the amount of churning in the implementation
of mail was probably higher than that for any other command;
sendmail's peculiarities figured prominently in the Internet Worm
incident, much as IBM's mail system was involved in their Christmas
Virus.
Mail is a strange attractor in the chaotic software world.
Dennis Ritchie
Bob_Fr...@frankston.com
the Berkeley version on the SDS-940 in 1966. It was a fancy editor using
control keys for intraline editing. I spoke to Peter Deutsch and think that
QED itself evolved from Expensive Typewriter (ET) on the PDP-1 in Bldg 26 at
MIT (though I might have this confused with Teco evolution). With the PDP-1,
especially that one, you need to be very specific about which PDP-1. My
assumption is that Ken Thompson took it from Berkeley to Multics and
implemented it in BCPL adding regular expressions. Perhaps there was a CTSS
version (??). QEDX (OK, "qedx") was the PL/1 implementation of a subset of
full QED. There was also TED which was an enhanced editor written by CISL
people (who?).
Of course, QED itself became ED on Unix. To this day, I rely on : mode to
give the commands I learned back in 1966 when confronted by most modern
version of Unix.
Details? Corrections?
Rob Aronson
> There was also TED which was an enhanced editor written by CISL
> people (who?).
I don't know if this gives the whole story or not, but the first comment
in the source code indicates that it was created by James Falksen, and is
dated 6/1/72.
Paul Green
>Speaking of history. I'm curious about the history of the QED editor. ...
>There was also TED which was an enhanced editor written by CISL people
(who?).
To the best of my knowledge, Jim Falksen (Falksenj) wrote TED. I think he
may have had help from Ed Wallman (author of compose; a runoff replacement).
I also think Jim started with the qedx source code; ted certainly had the
flavor of a super-enhanced qedx. Both of these people worked on Multics from
their location in Phoenix, not at CISL in Cambridge.
PG
--
Paul Green | Mail: Paul_...@vos.stratus.com
Senior Technical Consultant | Voice: (508) 460-2557 FAX: (508) 460-0397
Stratus Computer, Inc. | Video: PictureTel/AT&T by request.
Marlboro, MA 01752 | Disclaimer: I speak for myself, not Stratus.
Paul A. Karger
There definitely was a CTSS version of QED that (as I recall) had more
features than any of the Multics versions. There was a Multics version
of QED, written in BCPL, followed by qedx in PL/I.
Bernard S Greenberg
>In article <1994011003...@world.std.com> frankston.com!Bob_Frankston writes:
>To the best of my knowledge, Jim Falksen (Falksenj) wrote TED. I think he
>may have had help from Ed Wallman (author of compose; a runoff replacement).
>I also think Jim started with the qedx source code; ted certainly had the
>flavor of a super-enhanced qedx. Both of these people worked on Multics from
>their location in Phoenix, not at CISL in Cambridge.
This is exactly in concurrence with my recollections and written histories
of Emacs (now my Early Middle Age Claim to Standing, Mike?).
TED was quite controversial at CISL -- as I recall (and this is a very
partisan history, please correct me, someone, if I'm going overboard)
it was EXTREMELY POPULAR at Phoenix, where everyone realized that it
was far more powerful and useful than QEDX, which had not changed in
years, and looked like it was never going to change. At CISL, people
were by and large very shy about using it. There was a large amount
of Not-Invented-Here-ism, but more significantly, a feeling that
"The Editor Problem" had to be solved in some elegant and complete
and integrated way. Because no one had such a way, and various
TED-like proposals and enhancements to QEDX were routinely critiqued
and debated into the ground, no change happened. Like Bosnia,
everyone said something must be done about it, but nobody did anything
about it, or at least anything that was able to fly.
TED, not unlike the Emacs which usurped its covenant, was a Bolshevik,
"hell-with-the-design-process" effort, whose consumers cared less that the
thing was ritually unclean or unsanctioned by the Sanhedrin than that the
thing was Good.
I certainly was among the guilty parties who didn't use TED for
all the stupid and offensive reasons I listed above.
TED boasted clean, consistent, and ingenious extensions of QEDX
syntax to character addressing, as well as specific adaptations
for a Multics environment and typical Multics use (e.g., visible
line numbers), all of which and more were completely lacking in QEDX.
Not being a TEDophile, I am the not best source of TED history
or features.
Paul Benjamin
Paul_...@vos.stratus.com writes:
> To the best of my knowledge, Jim Falksen (Falksenj) wrote TED. I
think he
> may have had help from Ed Wallman (author of compose; a runoff
replacement).
> I also think Jim started with the qedx source code; ted certainly
had the
> flavor of a super-enhanced qedx. Both of these people worked on
Multics from
> their location in Phoenix, not at CISL in Cambridge.
Paul's recollection is correct. The history note in ted_.pl1 says:
/* ted is an editor based on qedx. There have been extensive
changes and */
/* additions
*/
/* ted 06/01/72 James Falksen
*/
It existed for years as an author-maintained program, although we
used to ship >system_library_auth_maint to all customers. It was
made a product in the early 80s. I know this because I did the
audit. The journal notice doesn't answer the question of whether or
not the qedx code was used. I don't think that Ed Wallman worked on
ted, his name does not appear in the code.
When I must do editing on GCOS 8 I use a QED derivative called FRED
that was written at the University of Waterloo.
---
Paul Benjamin Phone: (602) 862-4627
Bull HN Information Systems Fax: (602) 862-6973
Phoenix, Arizona E-mail: benj...@duckburg.az05.bull.com
Tom Van Vleck
He said at the time that many of its features derived
from QED on the SDS-940; but many others were new with
the CTSS version. QED was a vast improvement over other
editors on CTSS: EDIT and Saltzer's EDL and TYPSET were
still "deck of cards" editors, with no programmability.
QED had multiple buffers, could execute a buffer as commands,
used regular expression string matches, and allowed addresses
specified by line content. It was adopted by many "power" users.
(Did 940 QED have regular expressions? First paper I saw by Ken
was on a method for compiling regular expressions.)
As we moved from CTSS to Multics, programmers found that
Charlie Garman's Multics edit command was a step back to the
days of EDIT. A later editor, more closely derived from
EDL, was called edm; it was very minimal, almost stark.
At the same time, Ritchie and Canaday were exploring the BCPL
language brought to Project MAC by Strachey and Richards.
They wrote a version of QED in CTSS BCPL, ported BCPL to Multics,
and created a Multics qed command.
The power programmers on Multics loved qed, except that its
performance was poor. Using the BCPL qed during Multics
"console session" times was discouraged because of its impact,
but I think some of the system library maintenance operations
were programmed in qed macros and so that group had to use it.
In 1968 or 69, Bob Daley was the "chief engineer", and spent his
days in meetings listening to people fuss about issues like this.
He was also an outstanding programmer. One weekend he went home,
determined to solve the qed problem, and came back with qedx.
Daley had dropped a few features of QED that were costly to
implement, but 80% of it was there in qedx, and the performance
was vastly better, because he kept the whole file to be edited
as giant strings in a pair of buffer segments. (The BCPL version
kept the file as a linked list of linked lists.) qedx became
the standard editor for most uses. The BCPL qed stayed around
for a while because it had a few commands that qedx didn't.
Falksen's ted editor kept and added to the qedx command set.
Its performance was even faster that qedx, because instead of
a pair of buffers segments, it kept the file to be edited in a
single segment with a "gap" where the editing point was.
When I left in 1981, ted was still in >author_maintained.
Bernard S Greenberg
>The power programmers on Multics loved qed, except that its
>performance was poor. Using the BCPL qed during Multics
>"console session" times was discouraged because of its impact,
.....
>as giant strings in a pair of buffer segments. (The BCPL version
>kept the file as a linked list of linked lists.) qedx became
That's quite amazing that in 1968 there was a Multics editor that
maintained a buffer as a list of lines, that although everyone loved it,
people were discouraged from using on account of its performance.
<Insert Santayana saw.>
James J. Lippard
Yes, ted was Jim Falksen's software (Falksenj.Multics). He was in Phoenix,
at least during my time there (1983-1988).
Jim Lippard Lip...@CCIT.ARIZONA.EDU
Dept. of Philosophy Lip...@ARIZVMS.BITNET
University of Arizona
Tucson, AZ 85721
Bob_Fr...@frankston.com
implementation.
Arthur Evans
> As I remember, the regular expressions were new with Ken Thompson's
> CTSS implementation.
Regular expressions were perhaps new in editors at that time, but let's
not forget that regular expressions were then a long-accepted part of
mathematical notation. The "*" of REs in editors was (and is) just the
Kleene star.
Please note that I'm just keeping the record straight mathematically and
not commenting on who it was who introduced REs into text editors. I
entered EMA long ago; I guess I've got to confess to MMA.
Art Evans
Michael Padlipsky
picking on me, or are others having problems too?]
Tom, &&--
> Charlie Garman's Multics edit command was a step back to the
> days of EDIT. A later editor, more closely derived from
> EDL, was called edm; it was very minimal, almost stark.
Charlie's editor does, however, figure prominently in one of my all-time
favorite stories. For fear of another incomprehensible verbal volley
from the Samurai Hacker, I'm not sure I should post it to the List/'group',
though. Tellya what, if I get more than half-a-dozen off-list requests
for it in the next few days, I'll risk it (or if I get a pre-amnesty from
Bernie, of course). The late, intensely lamented Theodore Sturgeon quite
liked it, after all.
cheers, map
Bernard S Greenberg
>Charlie's editor does, however, figure prominently in one of my all-time
>favorite stories. For fear of another incomprehensible verbal volley
>from the Samurai Hacker, I'm not sure I should post it to the List/'group',
>though. Tellya what, if I get more than half-a-dozen off-list requests
>for it in the next few days, I'll risk it (or if I get a pre-amnesty from
>Bernie, of course). The late, intensely lamented Theodore Sturgeon quite
>liked it, after all.
What I had said in a language understood by 115000000 people which for
some reason you found incomprehensible, opaque, and cryptic was that I and
I alone in particular found your piece to which I was responding (the New
Year's puns) incomprehensible, opaque, and cryptic. I was merely trying
to give you a true taste of my experience; having succeeded and made my
point, enough said. Arigatou gozaimashita.
Edward Rice
PA> There definitely was a CTSS version of QED that (as I recall) had more
PA> features than any of the Multics versions. There was a Multics
PA> version of QED, written in BCPL, followed by qedx in PL/I.
Paul, are you sure the BCPL-based editor was QED and not qedx? I can remember
comments in the qedx source that were BCPL statements, which led me to believe
that it was qedx itself that started off in BCPL.
Edward Rice
BS> TED boasted clean, consistent, and ingenious extensions of QEDX syntax
BS> to character addressing, as well as specific adaptations for a Multics
BS> environment and typical Multics use (e.g., visible line numbers), all
BS> of which and more were completely lacking in QEDX. Not being a
BS> TEDophile, I am the not best source of TED history or features.
What I remember best about ted was its really powerful extensions... which is
why I used qedx most of the time. I wanted to be able to sit down with users,
working in their process, and help them with their own work, and if I'd become
too dependent on ted or on abbrevs or on heavy use of system privilege, I'd
have gone nuts working within a user's process.
But what I do remember clearly was a slightly maverick Air Force group, the
staff supporting the Office of the Secretary of Defense, Program Analysis &
Evaluation (OSD/PAE). They would go to HLSUA or talk with John Klensin (PAE
was a big, enthusiastic site for the Consistent System) and find out about
neat bells & whistles, and come downstairs demanding that they have access to
all kinds of things. Ted was on that list, and since it wasn't a serious
problem to make it available to them, it was brought into AML
(author-maintained library) and later IML (installation-maintained library).
It was a fine, un-buggy piece of code.
About once a week, we'd get a highly distressed call from someone who had used
the "J" command to sort the lines in a big PL/I program, not noticed the
effect, and who had then written-down the /sorted/ program. Usually a few
weeks afterwards, and always just before the Secretary needed a report on his
desk. Loved to get those phone calls...
Doug Wells
writes:
I am positive that the BCPL-based editor was QED and not qedx. I
sometimes used QED on CTSS. As I remember, that version of QED was
capable of dynamically compiling regular-expressions into 7094 machine
code and then executing that code to dramatically speed up searchs.
The Multics version of QED could not do that. I don't remember whether
it was simply that no one had taken the time to create a
regular-expression compiler for 645 machine code, or whether there was
some hardware problem such that you couldn't execute instructions from
segments with write permission enabled. In any case, the Multics QED
was incredibly slow. I used to use QED in the evening hours and edm
during the day.
When my earlier project switched from CTSS to Multics, Bob Daley showed
us the source code of edm as an example of the way to program in this
strange world where you didn't open files, but rather initiated
segments. Later, Bob was enthusiastic about how good the PL/I compiler
had become. He had been writing a new editor, qedx, and he pointed out
this sequence where the compiler had produced "perfect" code -- no
programmer could do better.
Bob had used much of the expression matching concepts in the BCPL
version, but he had changed the buffering strategy to use shuffling
between segments instead of the linked lists that were used in the BCPL
version -- something that would just not have worked on CTSS or GECOS.
Bob had overlaid the char (N) aligned string that was really in the
source segment with a (N/8) fixed binary (71) array. Then he assigned
the source fixed binary array to an identical overlay over the target
segment. And sure enough, the PL/I compiler generated "perfect" code
for that assignment statement.
As I remember, this sort of trick caused problems later when the PL/I
optimizer got smart enough to detect aliasing, except that it was based
on the concept of "defined" in the real language standard and assumed
that strings would never, ever be overlaid on top of numbers, or vice
versa. Of course, by then, the compiler could generate "perfect" code
for string copies, so some significant amount of time was spent going
though system code getting rid of these crocks.
Note: Despite my calling these special code sequences "crocks", let me
explain that I had a lot of respect (and have acquired more over time)
for the guys before me who managed to improve the speed of Multics.
They spent a lot of effort making Multics into a usable system -- so
that it was actually possible to consider logging in only when you
needed to do something, rather than logging in once in the morning when
you came in -- because it took 15 minutes or more for the login process
to complete. And I only know the stories about how the "first" boot of
Multics took days.
- dmw
--
Douglas M. Wells Voice: +1 617 621 7366
Research Institute Fax: +1 617 621 8696
Open Software Foundation Internet: d...@osf.org
Bob_Fr...@frankston.com
why I was using it instead of QED unless it predated QED). [Did I tell this
one already?] I wrote out a file with the "w" command. Or so I thought. Alas,
the 2741 had a shift character and I'd out typed it and lost it (IBM came out
to my apartment to tune the machine to reduce these problems). Alas, "W"
meant write out the rest of the file. When I quit the editor, everything
beyond the line I was one had been lost. (The lost shift was worse on CP/CMS
since @ was uppercase # and the former was line delete, the latter character
delete. Thus when I edited a line and with "#m all ..." everyone on the
system got the message and their responses confused m"
m was the CP/CMS message command (which inspired me to write send_message
while sitting out in Waltham at 3 AM in the morning during quiet time on
CP/CMS (Bob Mabee was my guinea pig at the other end))
Michael Padlipsky
> Multics took days.
>
> - dmw
I'm almost certain it wasn't even hours (as in more than 120 minutes),
but can't even recall who all was around. I THINK a fair-sized crowd.
Tom?
At any rate, although it FELT like days (and I think I recall Sue
Rosenbaum insisting the panel lights WERE making different patterns,
not looping), I'm pretty sure that part's apocryphal. 47 minutes
might be low-ish, but feels vaguely familiar. 87? Duh.
Talk about mistremembered (my latest coinage)....
foggy cheers, map
Tom Van Vleck
> > [...] And I only know the stories about how the "first" boot of
> > Multics took days.
> I'm almost certain it wasn't even hours (as in more than 120 minutes),
> but can't even recall who all was around. I THINK a fair-sized crowd.
> Tom?
>
> At any rate, although it FELT like days (and I think I recall Sue
> Rosenbaum insisting the panel lights WERE making different patterns,
> not looping), I'm pretty sure that part's apocryphal. 47 minutes
> might be low-ish, but feels vaguely familiar. 87? Duh.
There were a lot of "firsts." I think we have combined the attributes of
several in these postings. I posted the story of the Phase One milestone
way back in May.. I can repost it if it's a hassle to mine it from the
archives.
When we started the integration effort of of trying to boot the system,
crashing, fixing the bug, and trying again, system boots were painfully
slow. The first time we got into init_core_control, the CPU appeared
to freeze. Don Widrig, Karoly Martin, and I were in the machine room.
We single stepped it, and it was doing something, but there was no I/O
activity and the PSR was not changing. After 45 minutes we killed it
and took a dump. Fed the dumptape through the 7711 and alerted Molly
Wagner, the programmer of init_core_control, in Murray Hill. She
called us back in an hour and said, "Why'd you kill it? It was only
one-third done."
Turned out Molly had declared an array thus:
dcl 1 coremap based (cmp),
2 header_stuff ...,
2 cma (1000), /* packed core map array */
3 something bit (18),
3 something_else fixed bin (17),
3 inuse bit (1);
Actually this dcl is not the real one; we would have had to use
the "packed" attribute to get EPL to pack the stuff right. But you
see the problem: this is a 37-bit array, on a machine with a 36-bit
word. EPL produced TRULY AWFUL code in this case. The
initialization loop for cma had many thousands of instructions
in its inner loop, subroutine calls to stgop_$bsbs (string op,
move bit string to bit string), loading, masking, shifting.
Molly was able to change her dcls, and the EPL people improved the
compiler, and we got init_core_control down to a few seconds, and
went on to the next problem. But there were a lot of modules to
load and initialize; core control was early in Collection 1 and
there were 3 collections of segments to load. These corresponded
roughly to layers of the system, and to groups working on them..
there were actually 3 separate tapes, none near full, loaded in order.
Loading Collection 2 was a pain.. the tape would twitch and the
machine would page violently for about a minute, then repeat.
By the time of Phase 1, a whole system boot took about 55 minutes.
But the time varied from day to day: down after a performance
improvement was added, back up after a new function was added.
James H. Haynes
In article <CJL7y...@world.std.com> b...@world.std.com (Bernard S Greenberg) writes:
>Can anybody date the verb "to boot", as such, earlier than Multics? IBM
>machines IPL'ed, I remember...
>
Well of course the term derives from "bootstrap loader" - the idea that the
very first thing you do can pull in only enough code to get a little bit more
that can do something slightly more elaborate, so that IPL-ing is analogous
to pulling yourself up by your own bootstraps. When I got to G.E. in 1966
the term "bootload" was well established, and always abbreviated "boot".
But that was late. IBM was always fussy about what they called things:
"storage" instead of "memory", and "initial program load" instead of "bootload".
But the term was certainly old by 1966; I can't remember when or in what
context I first heard it, but when I got to G.E. and heard talk about
"bootload" I knew exactly what was being said. So I must have heard it
several years earlier.
--
hay...@cats.ucsc.edu
hay...@cats.bitnet
"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint! But ya gotta know the territory!"
Meredith Willson: "The Music Man"
Bernard S Greenberg
Tom Van Vleck
> Can anybody date the verb "to boot", as such, earlier than Multics? IBM
> machines IPL'ed, I remember...
TX-0 documents used the term for the paper tape bootstrap loader.
This takes us back to about 1961, well before Multics.
Followup directed to alt.folklore.computers.
PE. Smee
Bernard S Greenberg <b...@world.std.com> wrote:
>Can anybody date the verb "to boot", as such, earlier than Multics? IBM
>machines IPL'ed, I remember...
Well, early DEC machines had 'boot' (or 'bootstrap') loaders. On the
PDP9 at least, you toggled in the RIM loader, which loaded the boot
loader, which hauled in the rest of the system (by its bootstraps).
I have a feeling that nomenclature was common through the DEC range,
which would give you mid-60s/early-70s, at least. Could be older.
--
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
P.S...@bristol.ac.uk - Tel +44 272 303132 - FAX +44 272 291576
John Gintell
of the Billerica Software Factory was TED macros. People whose Multics names
end with their first initials, usually came from Billerica because that was their
name assignment algorithm.