Article: 41039 of alt.folklore.computers
Xref: tridom alt.amateur-comp:1735 comp.sys.att:2919 comp.unix.misc:8299 sci.edu:3214 alt.folklore.computers:41039
Path: tridom!emory!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!montego!not-for-mail
From: jrh@umcc.umcc.umich.edu (Jay Hauben)
Newsgroups: alt.amateur-comp,comp.sys.att,comp.unix.misc,sci.edu,alt.folklore.computers
Subject: Repost:Automating Phone Support Operations
Date: 5 Aug 1994 09:34:53 -0400
Organization: UMCC, Ann Arbor, MI
Lines: 413
Message-ID: <31tf5t$cbn@umcc.umcc.umich.edu>
NNTP-Posting-Host: umcc.umcc.umich.edu
X-Newsreader: TIN [version 1.2 PL2]

            Automating Telephone Support Operations:
                 An Interview with Berkley Tague
 
[Editor's Note: The following interview with Berkley Tague was 
also done while I was doing research for a paper on the history 
and significance of UNIX. During the course of this research, I 
found an interview which had appeared in UNIX Review, ("Interview 
with Berkley Tague," June, 1985) The interview suggested some 
further questions which I sent to Berkley Tague via E-mail. His 
responses were very helpful and I thought that others would find 
them interesting as well. Therefore, we asked for permission to 
print them in the special issue of The Amateur Computerist to 
commemorate the 25th Anniversary of UNIX. Following are the 
questions and his responses. He emphasized that his answers were 
his personal experience as part of the UNIX development project 
and represent only one of many such views of the Bell Labs 
project. -RH]*
 
Q(1): Can you explain what the problem was that AT&T was trying 
to solve in the 1960's and 1970's with regard to labor intensive 
support operations that had to be automated (i.e., mechanized)? 
What kinds of operations were the problem and why did they need 
to be automated?
 
Tague: The push -- it began about 1969 -- was to use the computer 
to support the operation of the Bell System network. The effort 
was quite broad in scope: monitoring and alarms, maintenance and 
staff management, inventory and order control, revenue data 
collection and billing, traffic measurement and control, circuit 
provisioning, etc.
   To take one example, the data that has to be collected to bill 
for calls was being stored on a variety of media -- e.g. paper AMA 
tape, a punched paper tape a few inches wide, IBM compatible mag. 
tape, and probably a few others. These tapes had to be mounted, 
saved, trucked to DP [Data Processing -ed] centers for 
processing, etc. They could be lost or damaged in handling. An 
obvious solution was to send the data over datalinks -- our own 
network -- to the DP centers. Minicomputer-based systems were 
designed to collect, preprocesss and transmit this data in some 
cases; in others, the electronic switches themselves were 
programmed to do the job. The goal was to eliminate the need for 
people handling physical media   a process that is both expensive 
and error-prone.
 
Q(2): What work was done by Bell Labs in 1964-68 as part of the 
Multics Project? Why did AT&T get involved with the Multics 
collaboration? (Can you explain what were the labs' objectives?) 
A reference I have found mentioned that "Bell Labs' purpose was 
to have a good environment for our people to work in." (See 
"Putting UNIX in Prespective: An Interview with Victor 
Vyssotsky," UNIX Review, Jan., 1985, pg. 59) If that seems 
accurate to you, can you explain why that was the objective and 
what it meant? And what happened with the project that AT&T 
decided they had to drop out?
 
Tague: The Multics Project was a joint project of Bell Labs, the 
GE Computer Systems Division, and MIT's Project MAC to develop a 
new computer and operating system that would replace MIT's CTSS 
system, Bell Labs BESYS, and support the new GE machine. Bell 
Lab's objective was to obtain a computing system that could 
simultaneously support batch, time-shared and real-time 
processing under an operating system that provided a full set of 
features with exceptional security. GE, and MIT's Project MAC, 
had overlapping, but somewhat different sets of objectives. Why 
the project ended as it did -- Multics never was used by Bell Labs 
or AT&T as other than a research tool -- is a complex story that I 
don't fully know. (The part I think I know also may be only 
partly correct.) What is clear is that Multics was a seminal 
effort in computing science and operating systems design. It 
established principles and features of operating system design 
that today are taken for granted in any modern operating system. 
This design experience and the UNIX(r) system itself were the 
payoff for Bell Labs in the long run.
   Vic's remark covers one of the objectives. Multics was 
intended to be a standard operating environment to support Bell 
Labs computing. That role was eventually filled by the UNIX(r) 
system, not Multics.
 
Q(3): What was learned from the project and was there a sense how 
this could be helpful at Bell Labs?
 
Tague: Much that was learned from the project was embedded in C 
and the UNIX(r) system. The security rings and related concepts 
also have had impact on subsequent computer security even though 
the full-blown security apparatus of Multics was not propagated 
in the UNIX(r) system. There are undoubtedly many other Multics 
features and concepts that were not in UNIX(r) but still had 
impact on computing science. I don't know all of the work that 
was done, especially after I left the project in 1967; the system 
was almost entirely rewritten after I left the project. 
 
Q(4): What was going on with computer science research during 
this period at the Labs?
 
Tague: Bell Labs terminated its participation in the Multics 
project (except for a couple of people wrapping up loose ends) in 
the summer of 1969. At the same time, Bell Labs turned the large 
internal computing centers over to a new central Bell Labs 
organization called Computing Technology. This included the 
Murray Hill Computing Center that up to then had been operated by 
Computing Research.
   These changes meant that a number of researchers in Computing 
Science were asked to redirect their efforts. In the review and 
redirection that ensued, one point of view was that Computing 
Research should focus exclusively on theoretical subjects such as 
automata theory, computing complexity theory, formal linguistics, 
etc. Since this would have excluded the UNIX system experiments, 
it is fortunate that this viewpoint didn't prevail. (I don't 
think it ever got beyond a talking point in the debate.)
 
Q(5): You mentioned you came back to Bell Labs in 1970. What was 
the situation that brought you back there (if it was related to 
the development of UNIX)? Were you involved with the development 
of UNIX during that period?
 
Tague: I have never left Bell Labs. The confusion is the internal 
nomenclature. In 1967, I left Bell Labs Research -- this is the 
basic research area that is located at Murray Hill and Holmdel -- 
and took a position managing a software development group in Bell 
Labs Federal Systems division in Whippany, N.J. that was part of 
the Safeguard ABM project. I returned from that assignment in 
September of 1969 to Murray Hill to join the Murray Hill 
Computing Center. This was during the transition that ended Bell 
Labs participation in Multics and transferred the MH Computing 
Center to the new central organization (see #4). I reported to 
co-directors -- one in Research and one in the newly formed 
Computing Technology organization. All of these organizations 
were part of Bell Labs.
   I was not involved with Multics development after 1967 when I 
joined Safeguard and only became involved with UNIX(r) officially 
in late 1971 or so. I began exploring its use in development for 
telephony applications late in 1972 or thereabouts. This led to 
requiring the UNIX(r) system for some development projects and 
forming the UNIX Support Group in September of 1973. This was a 
supervisory group of about five people that reported to me and 
was also part of Bell Labs. It was responsible for moving the 
UNIX(r) system from research to an internally supported product 
for software development and operations services.
 
Q(6): Can you explain when the work at Bell Labs on UNIX was 
thought of as being helpful toward the problem that AT&T faced in 
automating support operations? Was there an awareness at the Labs 
that the work they were doing on UNIX was not only towards 
creating a good programming environment to do their research in, 
but also to be able to create a good programming environment for 
others at AT&T who would be doing programming? If so how early 
was there this awareness? (If you know.)
 
Tague: The researchers involved had as their goal an operating 
system that would be good for software development from the 
start. Because they were their own first customers, the system 
was aimed at their fellow researchers. There is really not that 
much difference between the needs of research and [the needs of -
ed] development in terms of tools and features, the difference is 
primarily in support, stability and reliability. Developers have 
deadlines and don't want any more dependence on new invention 
than absolutely necessary. Also, if you have development 
deadlines, you certainly don't want anyone changing the system 
independently as you do your work. As a researcher you may 
tolerate a fair amount of upset and revision if it improves your 
toolkit significantly. The creation of the UNIX(r) Support Group 
was precisely to provide the stability and support that would 
buffer developers from the experiments that researchers were 
daily imposing on the evolving UNIX(r) system.
   As mentioned above, the UNIX(r) system was used by developers 
and supported operations in the field as early as 1972. There 
were about three different systems at that time that had been 
built in research for minicomputers, but I felt that UNIX was the 
best of the lot since it had captured most of the best features 
of Multics in a small, elegant package. (See my UNIX Review 
interview, pages 60ff.)
 
Q(7): What difficulties were involved in trying to have UNIX used 
for the task of automating support operations? Why was it being 
proposed? What obstacles did it face?
 
Tague: One major difficulty was convincing developers that they 
could depend on an operating system that had no official support 
and consisted of some 12,000 lines of uncommented code. 
(Proposing the UNIX Support Group was the obvious answer to 
this.) But UNIX(r) had one major advantage: I knew of no 
minicomputer vendor that had anything approaching it as part of 
their product line. Most minicomputer systems at that time were 
inferior to DOS 1 in function, speed and reliability. UNIX(r) had 
a rare opportunity to fill what was effectively a vacuum. I was 
pushing UNIX(r) onto our development community because I knew 
they needed it in spite of its shortcomings. A number of 
developers were planning to build their own operating systems   
typically their first system and often their first major program. 
It was quite rational to suggest that someone who had been 
working for several years on his third operating system might be 
ahead of them.
 
Q(8): What led to the creation of the UNIX Support Group (USG)? 
When? What was its mandate?
 
Tague: I think I answered this one in the answer to #7. One of 
the nice properties of Bell Labs is that when you perceive a 
need, you can propose a solution with a good chance of being 
asked to go do it yourself. In 1973, I pointed out that there was 
a need to provide central support for the UNIX systems we had 
been propagating into projects and volunteered to form the group 
in my department. By September, I was in business.
 
Q(9): Once the USG was formed (in 1973) was there a distinction 
between the priorities of the Bell Labs people and the USG people 
in their collaboration? August Mohr's article [i.e., August Mohr, 
"The Genesis Story," UNIX Review, Jan., 1985] seems to indicate 
that they both agreed there was a need for portability despite 
different priorities.
 
Tague: When the USG was formed in September, 1973, Dennis Ritchie 
promised me the portable version in October and delivered it. It 
was a "no brainer" to go into business with the portable version. 
A goal of my effort was to gain vendor independence so we could 
get competitive bids on volume buys when we deployed these mini-
based systems across the Bell System. There was one project that 
decided it couldn't wait until October and committed to the 
nonportable version, but that was the only project that used the 
nonportable version as far as I know.
 
Q(10): What were the problems and successes of USG?
 
Tague: The biggest problem was controlling the UNIX(r) system 
variants that continually emerged. New features and function were 
added by every project and the USG had to choose among or merge 
the variants in a continuing effort to filter out the 
redundancies and keep the best. Berkeley, the University not me, 
was doing this in parallel with us and with only loose 
coordination possible.
   The success of USG was its contribution to the success of the 
UNIX(r) system. UNIX(r) created open systems and a multibillion 
dollar market. Not bad for a two person research initiative on an 
obsolete mini.
 
Q(11): Did Rudd Canaday's work represent similar objectives? What 
was the division between the two groups and why?
 
Tague: I am not sure what you mean by "Rudd Canaday's work" in 
this context. Rudd shares in the patent on the UNIX(r) file 
system which he did in Research as a colleague of Ken and Dennis. 
Later, he moved to the Business Information Systems (BIS) project 
and brought the UNIX(r) system with him. The Programmer's 
WorkBench (PWB) variant grew up in his department.
   The BIS problem was to get a common "workbench" that would 
drive code onto any of the three or four commercial vendor's 
mainframes that were used by BIS. By putting a UNIX(r) system in 
front of the large mainframe systems, developers got the 
advantages of UNIX(r) in developing code and a place they could 
store debugged standard command sequences that drove development 
and testing on the target mainframe.
   The PWB support group was merged with the USG in about 1975 
and the USG and PWB versions were integrated. Note that during 
the 70s, every development group modified the UNIX system for its 
needs. The PWB group was one of many and was distinguished only 
by the quality of its work and the fact that it was widely 
deployed through a large and important project (BIS). But there 
were also very active groups at Columbus and at Holmdel Bell Labs 
locations that were modifying the system and offering their mods 
to the USG for inclusion in the base version.
   The vice and virtue of UNIX has always been its flexibility. 
You love its flexibility when you meet a new need, but you want a 
single standard version once it meets your needs. COSE is just 
the latest of many efforts to coalesce the variants into a common 
base.
 
Q(12): Who invited John Lions to the Labs? When? Why? What did he 
do once there?
 
Tague: Research asked me to invite him to work with the USG. He 
had written his wonderful book on the UNIX(r) system early in the 
game and we had found it most useful. We agreed to publish and 
distribute the book and wanted John to continue his work as one 
of the UNIX apostles in Europe and Australia. He wanted to come 
to Murray Hill for his sabbatical so it was a win/win situation. 
He spent two or three sessions at Bell Labs over the years and 
supplied us with many of his graduate students for sabbaticals 
and permanent employment. For me, he became not only a valued 
contributor, but a good friend. A truly delightful gentleman!
   At this distance, I don't remember exactly what he worked on, 
but I asked him to extend his documentation of the system to some 
new features while giving him license to work with the 
researchers in whatever way was mutually fruitful. His book is a 
classic that is still worth reading by the would-be operating 
systems designer.
 
Q(13): Was his book A Commentary on the UNIX Operating System 
used at the Labs or in the USG? If so how?
 
Tague: Yes. We offered it as a part of the documentation package 
for those who wanted to understand or modify the UNIX(r) source 
that the USG shipped. It was very useful as an introduction even 
though the code no longer matched the book. It outlined the 
conceptual architecture very clearly in the early short form of 
the system before it had accreted all the minor changes and 
feature additions that disguised the original clarity of its 
structure. All new people were given a copy when they joined the 
USG and I suspect most development groups did the same.
 
Q(14): Who else did you invite from his school and why? What work 
did they do?
 
Tague: It's a long list and I don't trust my memory, but Andrew 
Hume is still in research at Murray Hill. Ian Johnstone left us 
for Sequent and I believe is now working in Boston with another 
firm. Peter Ivanov and Piers Dick-Lauder were two others who were 
part of my department, and there were likely others who came 
along after I left the scene. They all worked on UNIX system 
development, but I couldn't tell you what parts they worked on. I 
do remember that Ian worked on the first multiprocessor versions, 
but he did many other things prior to that. I used to kid about 
running the "Australian Chair of Computing Science" at Bell Labs.
 
Q(15): In the UNIX Review interview you are quoted saying that 
you originally opposed having UNIX go out to colleges. But it did 
anyway. What was the reason you opposed it (if anything in 
addition to what you said in the interview)? Why was it allowed 
to go out over your objections? What would you say was the result 
of making it available to academic institutions outside of AT&T?
 
Tague: I don't have anything substantive to add to what I said in 
the interview, but perhaps I can clarify what I was trying to say 
there. My position in the early '70s was that we should make C 
available outside Bell Labs in the way we released other tools 
for university (and occasionally for commercial) use through our 
patent licensing organization. This release was "caveat emptor" 
-- i.e., dollars on the table up front with no support included. I 
opposed the release of the UNIX system without support because I 
was afraid it would be adopted for commercial use by someone who 
could call up the president of AT&T and demand help. I knew that 
any such request would likely find its way to my department and 
we were not ready to provide outside support. I also had a vague 
idea that the system might be more valuable to AT&T as a 
proprietary AT&T system. I was wrong. The system was rapidly 
picked up by academic and industrial research groups that were 
well prepared to deal with the no support proviso and it had no 
takers in the DP community until it was offered as a supported 
product. The value of the system as a portable open standard was 
evident early and when AT&T was allowed to enter the computing 
business, it was a clear winner as a de facto standard.
 
Q(16): How has UNIX been used for support operations? When was it 
understood that it could be used? Does it continue to be used?
 
Tague: The UNIX(r) system is the standard operating environment 
for almost all internal development and much research at Bell 
Labs and has been so since the early eighties. The BaseWorX(tm) 
platform that we use and sell for operations support systems 
includes UNIX(r) SVR4 as an essential component. Operations 
support usage started in about 1971 and continues today.
 
Q(17): Was portability the only problem that had to be solved 
before UNIX could be used internally for support operations? If 
there were other such problems what were they?
 
Tague: See the answers above. There were many extensions and 
features that have been added over the years -- interprocess 
communications mechanisms, streams, transaction processing, 
databases, etc. -- and most of these are useful to the broad 
community of Bell Labs users. Each was originally motivated by 
some perceived user problem. As the UNIX system has evolved, it 
has incorporated valuable features from other systems and served 
as a base for pioneering new ideas. It is interesting to see the 
UNIX to Mach to NT evolution as the kernel is subdivided to meet 
new fundamental needs while still maintaining original functions 
in almost the same form as the original V6. Even DOS imitates a 
good bit of the command set in a roughly familiar way.
 
Q(18): In the UNIX Review Interview you are quoted saying that 
you expected the internal development of UNIX within AT&T to be 
mirrored outside of AT&T. Has that happened or not? Do you have 
any insight why?
 
Tague: I am going to duck this one. I am not sure what I had in 
mind when I said it at this point. I guess I was thinking that 
the external market would continue the process of expanding the 
system rapidly to include new features, followed by attempts to 
filter them into a coherent extended standard. Neither the 
internal development nor the external development has gone as I 
might have predicted (or might have hoped) a decade ago, but the 
system is still alive, evolving and providing service on a 
broader spectrum of hardware than any other system around.
 
Q(19): What are the successes of it all that you see? (of the 
UNIX and USG developments?) the problems?
 
Tague: See my answer to #10 above. The biggest problem continues 
to be the variants and the difficulty of getting an industry 
standard API that supports "shrink wrapped" software packages. 
The issue of a standard "desktop" GUI is probably a close second. 
COSE is trying again and I wish them well.
 
Q(20): What would you see as an appropriate way to commemorate 
the 25th anniversary of these achievements?
 
Tague: Stop for a moment and contemplate how much of what we take 
for granted in today's operating systems was established in that 
post-Multics synthesis by Ken and Dennis, acknowledge the 
pioneers of Projects MAC and Multics, and then go back to work on 
defining the next plateau.
___________________________________________
[*Note: Please understand that what you have is my personal view 
of the UNIX(r) system developments and not necessarily those of 
Bell Labs. Your questions made me go over an interesting part of 
my career with Bell Labs and you likely got more than you 
bargained for. Each participant in UNIX(r) system development has 
his or her own view of this period and they don't always agree as 
to the order or interpretation of events. I cannot claim to more 
than one such view and, as an early enthusiast, may well 
overestimate my personal role in the story. Berk Tague]
---------------------------------------------------------------
Reprinted from the Amateur Computerist Vol 6 no 1 Winter/Spring 1994