Terminals to texting
Messaging from computers to mobile devices
Marty Lyons
University of Washington
CSEP590A – History of Computing
6 December 2006
Introduction
As computing moved into the 1960’s, systems increasingly began interacting with an operator
through a communications device. Most common of these was a variant of a teletype,
connecting to the system on a dedicated input-output channel. Although most equipment still
required manual loading of software, increasingly through media such as magnetic tape,
interaction with the operator had moved from a panel filled with flashing lamps to messages
written to an operator console.
As research in timesharing operating systems began, the availability of terminal devices such as
the Flexowriter became more commonplace. Development typically consisted of a number of
programmers operating in common terminal areas, sharing equipment.
Systems soon not only were able to connect to local devices, but by using telecommunications
networks. Common services included dial-based connections over the phone network as well as
dedicated services such as Telex. Larger research institutions often owned and managed their
own private telephone exchanges, which were also used in providing connectivity.
Early timesharing systems still suffered from a limited number of shared resources, and arranging
use of devices such as printers, drum storage, and tape drives often required coordination
between system users. In some operations, an operator was able to coordinate the allocation and
management of devices. Other systems employed queuing or some method of device locking to
provide automated scheduling.
The ability to communicate amongst users using terminal devices was a logical extension of these
systems. As many systems were still research tools rather than production services, new features
were often installed to increase productivity among the development and scientific staff.
This paper consider several systems at the beginning of timesharing, and reviews how inter-user
communications originated. Beginning with work near the MIT campus in Cambridge, we find
not only common themes in the development of these tools, but a lineage of research which
appears in systems to this day.
In addition to the tools integrated into operating systems, we also consider how user-user
communications expanded into the networking community, commercial systems, and ultimately
as standalone utilities; as well as some social considerations in their adoption.
Origins of time-sharing
MIT and Project MAC
The Massachusetts Institute of Technology (MIT) formed a focal point for computing technology
in the late 1950’s, led by a small group including Fernando J. Corbató. At the time, MIT had
been using an IBM 704 (in 1960 a 709, and in November of 1962 a 7090) for research purposes
and development of the Compatible Time Sharing System (CTSS) operating system, but had
already outgrown the capabilities of the hardware1 (which included three Flexowriters2 for
interacting with the system).
John McCarthy of Stanford University writes of his experiences there in 1957 3, as the concept of
time sharing 4 was gaining momentum:
At the same time that CTSS, the BBN system, and the EE Department systems were being
developed, M.I.T. had started to plan for a next generation computer system. … the actual
Lee, J.A.N.; McCarthy, J.; Licklider, J.C.R., "The beginnings at MIT," Annals of the History of
Computing, IEEE , vol.14, no.1pp.18-30, 1992. http://ieeexplore.ieee.org
/iel4/85/3898/00145317.pdf?isnumber=3898∏=JNL&arnumber=145317&arnumber=145317&arSt=1
8&ared=30&arAuthor=Lee%2C+J.A.N.%3B+McCarthy%2C+J.%3B+Licklider%2C+J.C.R..
Retrieved 1 December 2006.
1
Bodley, Nicholas. 25 November 1998. http://www.blinkenlights.com/classiccmp/friden/bodley.txt.
Retrieved 1 December 2006. Flexowriters were the standard “terminal” at the time, prior to the
emergence of teletypes such as the TTY33. They were originally manufactured by IBM and later sold by
Friden.
2
Reminiscences on the history of time sharing. 1983 Winter or Spring. http://wwwformal.stanford.edu/jmc/history/timesharing/timesharing.html. Retrieved 1 December 2006.
3
Lee, J.A.N., "Claims to the term `time-sharing'," Annals of the History of Computing, IEEE , vol.14,
no.1pp.16-17, 1992. http://ieeexplore.ieee.org
/iel4/85/3898/00145316.pdf?isnumber=3898∏=JNL&arnumber=145316&arnumber=145316&arSt=1
6. Retrieved 1 December 2006. This note addresses the syntactical differences between the earlier multiprogramming view and the later (now commonly accepted) version of time sharing a resource.
4
2
computer scientists were persuaded that a revolution in the way computers were used - to timesharing - was called for.
This was not a new consideration for MIT – similar efforts at installing state-of-the-art hardware
were discussed as early as 25 years prior.5
Corbató’s initial paper describing the concept of sharing one system amongst many users was
published in 1962 6, where he described the vision in detail:
To solve these interaction problems we would like to have a computer made simultaneously
available to many users in a manner somewhat like a telephone exchange. Each user would be
able to use a console at his own pace and with-out concern for the activity of others using the
system. This console could as a minimum be merely a typewriter but more ideally would contain
an incrementally modifiable self-sustaining display. In any case, data transmission requirements
should be such that it would be no major obstacle to have remote installation from the computer
proper.
This was, at the time, a fairly radical concept – that one system could be shared by many users.
Most importantly, the inclusion of remote access as a defined goal expanded the utility of such a
service beyond campus borders.
The MAC project which grew out of these ideas had taken note of time-sharing work underway
in other organizations, and declared that “score cards are being kept”:
“It is now abundantly clear that it is possible to create a general-purpose time-shared multi-access
system on many contemporary computers … Already two major and extensive systems have been
created, one on the IBM 7094 and one on the [AN/FS]Q-32 computer. In addition, there have
been numerous smaller scale systems, the most notable being on the DEC PDP-1, the IBM 7094,
7
the GE 235, the DEC PDP-6, and the SDS 930.”
Owens, L., "Where are we going, Phil Morse? Changing agendas and the rhetoric of obviousness in the
transformation of computing at MIT, 1939-1957," Annals of the History of Computing, IEEE , vol.18,
no.4pp.34-41, Oct-Dec 1996.
http://ieeexplore.ieee.org/iel4/85/11673/00539914.pdf?isnumber=11673∏=JNL&arnumber=539914
&arnumber=539914&arSt=34&ared=41&arAuthor=Owens%2C+L. Retrieved 1 December 2006.
5
Corbató, Fernando J., Daggett, Marjorie Merwin, Daley, Robert C. An experimental time-sharing
system. Proceedings of the Spring Joint Computer Conference, May 3, 1962. http://larchwww.lcs.mit.edu:8001/~corbato/sjcc62. Retrieved 1 December 2006.
6
Lee, J.A.N.; Fano, R.M.; Scherr, A.L.; Corbato, F.J.; Vyssotsky, V.A., "Project MAC [time-sharing
computing project]," Annals of the History of Computing, IEEE , vol.14, no.2 pp.9-13, 1992.
http://ieeexplore.ieee.org
/iel4/85/3967/00150016.pdf?isnumber=3967∏=JNL&arnumber=150016&arnumber=150016&arSt=9
&ared=13&arAuthor=Lee%2C+J.A.N.%3B+Fano%2C+R.M.%3B+Scherr%2C+A.L.%3B+Corbato%
2C+F.J.%3B+Vyssotsky%2C+V.A. Retrieved 1 December 2006.
7
3
It is interesting to note that the mere availability of computing power was not considered a
panacea for social ills. Most surprising, these views were considered and expressed by Robert
Fano, one of the proponents of the original work.8
… We are now at that stage with computers. Technical means are now available for bringing
computing and information service within easy reach of every individual in a community. … At
the same time, the benefits they may bring society will unquestionably be mixed with a dose of
new problems and frustrations.
On October 9, 1964, a progress report was released by the MAC project9 The number of
attached terminals was significant compared to similar systems. On page 3, the report notes:
The primary terminals of the MAC System are, at present, 52 Model 35 Teletypes and 56 IBM
1050 Selectric teletypewriters… Access to the MAC System can also be gained from any station
of the Telex or TWX telegraph networks.
Thus, beginning with CTSS development in November of 1961, Project MAC at MIT became
the first system to build a large-scale timesharing system connected to a network as a shared
resource.
IBM and the importance of MIT as a customer
IBM, and its president T.J. Watson, had seen MIT as a particularly important customer, and
donated a 704 system to the campus computation center. The processors, as new versions came
available, were upgraded (without cost), to a 709, a 7090, and ultimately a 7094. The CTSS
development group had produced a working system on the 709 by late 1961.
The 7094 became the base system as CTSS moved into production use in 1963, along with
hardware modifications requested by MIT and installed by IBM. In early 1964, IBM established
a permanent presence in Tech Square when the Cambridge Scientific Center (CSC) was located
there.
As Project MAC progressed, and despite IBM’s efforts, the lack of relocation hardware on the
newly available 360 series of processors was viewed as an insurmountable problem by MIT.
Lee, J.A.N.; David, E.E., Jr.; Fano, R.M., "The social impact [Project MAC]," Annals of the History of
Computing, IEEE , vol.14, no.2pp.36-41, 1992. http://ieeexplore.ieee.org
/iel4/85/3967/00150022.pdf?isnumber=3967∏=JNL&arnumber=150022&arnumber=150022&arSt=3
6&ared=41&arAuthor=Lee%2C+J.A.N.%3B+David%2C+E.E.%2C+Jr.%3B+Fano%2C+R.M.
Retrieved 1 December 2006.
8
Fano, R. M. The MAC System: A progress report. Massachussetts Institute of Technology, Project
MAC. Report MIT-LCS-TR-12. 9 October 1964.
http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-012.pdf. Retrieved 1 December 2006.
9
4
Inside IBM, losing the Project MAC bid was immediately recognized as a serious problem. A
corporate task force was formed to get the company into a position to be able to win bids for timesharing systems. The task force was composed of the most knowledgeable time-sharing people from
around the company.10
In August of 1965, MIT chose the GE-645 as the new MAC development system. Meanwhile,
IBM had been developing a new operating system for the new 360, known as Time Sharing
System (TSS/360).11
With the knowledge that TSS might not be successful, the staff at CSC began to investigate the
use of virtual memory systems on the 360 model 40 processor – this new effort was dubbed CP
(Control Program) 40. Development was initiated in 1965, and the system was in regular use by
the beginning of 1967. A new version CP-67, to support the 360 model 67, was quickly released.
The idea behind CP was novel, and used the concept of many “virtual machines” inside one
“real machine”. In the CP view of the world, a virtual machine (VM) looked like a real, physical
system, all emulated in software. Thus each VM had (virtual) card readers, printers, disk drives,
memory, and so on.
Other divisions within IBM were developing other operating systems (such as what later evolved
into MVS), and CSC considered the concept of virtual machines not just an academic exercise,
but one which could solve real problems for the corporation. Rather than needing real – and
expensive -- systems to test operating system code, a programmer could test in a fully virtualized
environment, without affecting other users – all of whom might be running their own virtual
machine, each testing yet another operating system.
In May of 1968, CP/67 was released by IBM; the first three sites for installation being IBM’s
Cambridge Scientific Center, MIT’s Lincoln Labs, and Washington State University12.
Varian, Melinda. VM and the VM Community: Past, Present, and Future. SHARE 89. August 1997.
p. 8. http://www.princeton.edu/~melinda/25paper.pdf. Retrieved 1 December 2006. This is
considered the best history of VM development ever produced. Melinda was a fixture with her excellent
presentations at IBM users groups including SHARE and VM Workshop. An interesting side note is that
her husband Lee was a VM developer at IBM.
10
11
Bitsavers.org. http://www.bitsavers.org/pdf/ibm/tss/. Retrieved 1 December 2006.
Wheeler, Lynn. TSS/360. http://www.garlic.com/~lynn/2001m.html#53. Retrieved 1 December
2006.
12
5
While development was underway at CSC, in order to make the hardware easier to diagnose
(and eliminate potential pitfalls)13 , innovative solutions were used:
It wasn't authorized, but CSC painted the disk drives in its machine room (2nd floor 545 tech sq).
There were five 8-drive 2314 strings and a short 5-drive string. Each string was painted a different
color so that strings could be referred to by color for mounting/unmounting disk packs.14 – Lynn
Wheeler
The CSC moved quickly to bolster the development staff on CP-67; several noteable hires in the
next few years period included Ed Hendricks (who would later write the Remote Spooling system
“RSCS”), Dave Tuttle, and Lynn Wheeler 15 (who had done extensive performance
improvements while a student at Washington State University).
CP was somewhat of a unique system. Virtual machines – in the eyes of the core operating
system – were standalone entities to some degree. Thus communications between them had to
appear to be via an actual network device. At the time, systems used physical channels for
connections, so a “channel to channel adapter” (CTCA) was ultimately coded to emulate that
device. Other ways to communicate included emulating cards arriving in a reader, and later in
development, two features to allow machines to communicate readily.
The first, the Virtual Machine Communication Facility (VMCF) defined a set of functions to
allow virtual machines to easily exchange data. Several years later, the Inter-User
Communication Vehicle (IUCV), fulfilled the same function in a slightly different way.
Finally, a product known as the Remote Spooling Communication Subsystem (RSCS) was
designed by Ed Hendricks to define a network method to both move files between machines, as
well as actual CP commands. RSCS was included in VM Release 3, and released in 1975.
David Tuttle, one of the authors of early CP-67 code, recalls the inclusion of messaging in the
system16:
What I remember is that Ed Hendricks was the initial implementer of a messaging capability, but
it was used primarily between remote systems. Ed and I developed the BSC protocol(s) to
connect CP-67 machines together, including the timing-independent tricks required for running
reliably in a virtual machine, in late 1968 and 1969. … The first versions of CPREMOTE
exchanged spool files between systems; the messaging trick was to send a "spool" file to the virtual
13
War stories from an old code-slinger. Larry Akerts. Z/Journal. 1 October 2005.
http://www.zjournal.com/index.cfm?section=article&aid=218. This is a classic story of why
programmers were told to stay away from the hardware.
Painting computers. Lynn Wheeler. 10 April 1994. http://www.garlic.com/~lynn/94.html#18.
Retrieved 1 December 2006.
14
15
Wheeler, Lynn. Personal web page. http://www.garlic.com/~lynn/. Retrieved 1 December 2006.
16
Tuttle, David B. Personal communication. 2 December 2006.
6
card reader of a target machine, thus generating an attention interrupt. It was certainly up and
running internally by late summer or fall of 1970, but I don't know precisely when. The
supporting feature in the CP-67 (and later VM/370-CP) spool support was the 'tag' command,
which allowed a sending user to specify a destination. The enabling features were in VM/370
Release 1.0 (Nov. 1972), long before VMCF and IUCV came along.
The first official release of VM/370 was formally announced by IBM on 2 August 197217, which
differs from David’s account of the date slightly.
Lynn Wheeler found the original “MSG” command listed in the CP/67 Release 3 manual (see
Appendix B), which would place use of the command as early November 197018. This was
confirmed in a separate communication by David Tuttle:
On further reflection and musing, I think that the CP 'message' or 'msg' command was originally
built into the CP-67 terminal service routines. I never used CP-40, so I don't know if the facility
existed there. It certainly was carried forward as part of the basic feature set in VM-CP. The
most common use was for notifying users about system-wide events, such as a scheduled
shutdown; a user with 'operator' privileges could do a "cp msg all", while ordinary users could
only send a message to one user at a time. For the record, Clyde Wildes did the bulk of the VMCP Release 1 terminal service routines; I rewrote much of it in a subsequent release when we
incorporated the 3704/5 support and George Saunders' 3270 support. The CP side of virtual
CTCA support was mine, too, because I had worked with a real CTCA at MIT (ASP 1.0).19
The evolution of messaging within the VM product was somewhat complex. In addition to the
original work in CP-67, and later RSCS, another version of code to allow virtual machines to
communicate (SPM, or “SPecial Message) across the network was written at the IBM Pisa (Italy)
Science Center. It was distributed on 12 August 1975 and included with VM Release 2,
although a version had originally been distributed as part of RSCS (as PRPQ for IBM’s VNET
network).20
IBM VM/370 Product Announcement Presentation. 2 August 1972.
http://www.sinenomine.net/fun/vm370. Retrieved 1 December 2006.
17
Varian, Melinda. VM and the VM Community: Past, Present, and Future. SHARE 89. August 1997.
p. 8. http://www.princeton.edu/~melinda/25paper.pdf. Retrieved 1 December 2006. p. 25.
18
19
Tuttle, David B. Personal communication. 3 December 2006.
Wheeler, Lynn. Personal communication. 1 December 2006; Wheeler, Lynn. Other cp/cpms history
Alt.folklore.computers. 24 May 2006. http://www.garlic.com/~lynn/2006k.html#51 Retrieved 1
December 2006. The full reference as cited in the URL above is interesting in that it discusses the Special
Message product as used internal to IBM, on the VNET network. It is attached here as Appendix F.
Lynn added in private email:
20
VNET ship with support both for SMSG ... as well as SPM (as noted in
Marty's email). SMSG was an option that a user could send a message to
VNET and have VNET process the message via software (typically as some
sort of command). However, responses typically came back as "MSG"
command ... which would then show up on the users terminal.
7
Lynn has a detailed note on the evolution of the communication between service virtual machine
evolution, including the “Inter-User Communication Vehicle” (IUCV)21.
So along comes VM/370 release 3 ... and they pick up the autolog command and a subset of the
VMM stuff for product release (the vmm subset was called DCSS ... or discontiguous shared
segments).
the other stuff included in VM/370 release 3 was vmcf and special message. standard
environment had message command that users could send messages to other users on the system
or send requests to the (human) operator to have something or other done. An issue was how to
request stuff from the "service virtual machines" that had no human operator. vmcf/spm allowed
a virtual machine to set option so that incoming messages were intercepted before physical display
on the terminal and placed in a buffer that could be read by program. so one thing you could do
was send messages to the network service machine ... which would parse it and do specific things.
… in any case, what i remember of IUCV was that it came out of people with engineering
background in the endicott lab ... as opposed to the vmcf/spm oriented stuff that. Folklore has the
guilty party as Tom DeForrest ... who long ago and far way had email address of
EG16TNDC@GDLS2. In theory, IUCV was going to be able to map directly into the microcode
of the real machine w/o needing to be handled via the DIAGNOSE code support in the cp
kernel.
Lynn Wheeler noted22 that Ed Hendricks had added support for sending messages through the
network using RSCS. The format was slightly different than the final (shipping) version. The
initial format was:
With SPM, VNET could intercept everything that might display on the
terminal ... and the user could use the standard MSG command for VNET.
Continuing, Lynn added in personal communication of 3 December 2006:
… SPM ... it was much more of a clean "user" architecture ... while the rest of the stuff was much
more of a programmers protocol. SPM allowed the recipient to decide how stuff was routed (to
the physical terminal or to software api) w/o regard to the originator (a virtual machine message
command or some message originating in the cp kernel). as marty's note references ... it was well
into the 80s before the hodge podge of other stuff could do everything that SPM could do ... aka
the other implementations required the originator and the recipient to be in agreement on
whether stuff went to the terminal or the software api (i.e. smsg/! required the originator to use a
different command/interface than standard msg ... in order for the recipient to process the
message in software).
Wheeler, Lynn. IUCV in VM/CMS. Alt.folklore.computers. 29 December 2004.
http://www.garlic.com/~lynn/2004q.html#72. Retrieved 1 December 2006.
21
Wheeler, Lynn. Instant messaging. Alt.os.multics. 23 May 2003.
http://www.garlic.com/~lynn/2003i.html#13. Retrieved 6 December 2006. Note this posting is
particularly interesting in that the initial question was posted by Tom Van Vleck.
22
8
msg vnet msg nodeid userid abcd.....
In the shipping version, to send a message across the network a user had two options. They
could “talk” to the RSCS virtual machine directly, using the SPecial Message (SMSG) command.
This had the somewhat cumbersome format:
SMSG RSCS MSG nodeid userid abcd…23
Or use the much simpler “TELL” command, which sent the message to the RSCS virtual
machine:
TELL userid AT nodeid abcd….
With the use of a “NAMES” file, a database of nodeid/userid pairs could be saved in the user’s
private minidisk, and then the user simply used the standard “MSG” command:
MSG nickname abcd….
From best available sources, the first use of varying communications capabilities in VM occurred
as follows:
Date
November
1970
2 August 1972
January 1975
February 1976
Type
User-user
Command
CP MSG
VM-VM file
exchange
CP SPOOL
(with TAG
option)
RSCS: Remote
SM RSCS
commands/message CMD / TELL
VMCF utility,
SPM
SPecial Message
Version
CP/67 Version
3
VM Release 1
Noted/(W)ritten
Lynn Wheeler
VM Release 2
PLC 11
VM Release 3
Melinda Varian
(W) David Tuttle
Lynn Wheeler,
Melinda Varian
As an aside, versions of IBM’s “other” operating system, OS/VS (which would become MVS),
enabled operators to send messages to “remote” systems, using HASP/JES commands such as
$DM. These were however, not designed to be available to normal interactive terminal users,
who would likely be using an interface such as TSO (Time Sharing Option).
Ultimately, 545 Tech Square was becoming crowded with people and machines, and from 197173 IBM had moved off the MIT campus to nearby Burlington, Massachusetts24.
Williams, A. Harry. Personal communication of 2 December 2006. Harry noted that while an intern
working at IBM, “SMSG” was actually denoted as “!”, thus this command would have been entered as “!
RSCS MSG …”
23
9
MIT Compatible Time Sharing System (CTSS)
The history of work in Tech Square is summarized by Tom Van Vleck, then with CTSS:
CTSS was begun in 1961 at MIT Comp Center. The CTSS core team, led by Corby, got ARPA
funding for a next generation system, Multics. CTSS by then was a prototype "computer utility"
for MIT, and was the tool used by the Multics development team to bootstrap Multics. Many of
the CTSS group moved over to Multics development; a few stayed on at Comp Center; a few
went to IBM and started the CP/CMS effort that later became VM. The Multics effort also
included Bell Labs and GE: this forced us into distributed development and made the use of
MAIL and messaging more important. Ken Thompson, Dennis Ritchie, and the other Bell Labs
folks would have been familiar with these CTSS features from the beginning of their work on
Multics. 25
CTSS was from its inception in 1961 pioneering new ground in the evolution of timesharing
systems. Although the IBM CP effort evolved messaging for a unique set of needs -- to
communicate between virtual machines, the motivation at CTSS was influenced more by
requirements of individuals.
Perhaps one of the first instances of interactive messaging between users was implemented on
CTSS. Tom Van Vleck writes 26
Noel and I also wrote a tool for CTSS called . SAVED (dot saved), inspired by the design for the
Multics shell, during 1965 that provided, among other features, a user interface that allowed users
to do "instant messaging." There were entry points to the CTSS supervisor that supported such
messaging (written by Bob Fenichel) but no user-level way to use them: our program provided a
user interface to Bob's code that allowed users to send lines of text to other logged-in users, and
managed deferring and allowing communication so that program output would not be
interrupted by messages. Noel did most of the programming on this feature, all in FAP. Multics
was still in the design phase then, so . SAVED was an example of a successor system influencing
its predecessor.
I think a hack was also added to to . SAVED to announce mail if it arrived while you were
logged in, by checking the length of MAIL BOX after every command.
Thus two features were enabled by the new facility – a method to send messages directly between
users, but also to allow a programmatic check of pending mail. While space limits discussing the
Varian, Melinda. VM and the VM Community: Past, Present, and Future. SHARE 89. August 1997.
p. 33. http://www.princeton.edu/~melinda/25paper.pdf. Retrieved 1 December 2006.
24
25
Van Vleck, Tom. Personal communication. 3 December 2006.
Van Vleck, Tom. The History of Electronic Mail. 10 September 2004.
http://www.multicians.org/thvv/mail-history.html. Retrieved 1 December 2006.
26
10
evolution of online mail here, it should be noted that the mail facility on CTSS appears to be the
first such implementation on any general purpose timesharing system.
Tom elaborated on the development in personal mail: 27
Bob Fenichel had created some interfaces that would allow inter-user messaging, but no system
command invoked them so users could not use them. Noel [Morris] and I had invented a
subsystem that could issue commands: this meant it was in control of the user's terminal between
commands, and that we could invent "builtin" subsystem commands that did not correspond to
system commands. This may seem obvious now, but it was a breakthrough then. So we added
the inter-user messaging to . SAVED.
The actual command was implemented as “WRITE”, and is described in the CTSS
Programmer’s Guide of December 1969 28, and is attached as Appendix A.
Because CTSS was used to develop Multics, the systems shared a common ancestry of sorts.
Prior to Project MAC migrating entirely to the new system, ideas flowed in both directions. Tom
notes that the use of .SAVED resulted in enabling additional functionality29:
We added sequencing and iteration, and most importantly allowed users to type the name of a
SAVED file in the user's directory as if it were a command, thus extending each user's command
set with personal commands.
Both the idea of a non-privileged program that parsed command lines and executed them, and
the idea of adjoining the user's set of programs to the command set, were influences from the
(then unbuilt) Multics design for the shell, by Louis Pouzin and Doug Eastwood. That is, these
ideas were retrograde influences, the mother inheriting from the daughter. Most CTSS power
users used . because it added these and other enhancements.
This facility for embedding power in user mode facilities carried forward not just into the Multics
shell30, but the Unix shell as well.
27
Van Vleck, Tom. Personal communication. 1 December 2006.
The Compatible Time-Sharing System, 2nd ed. A Programmer’s Guide. P.A. Crisman, ed. The
M.I.T. Press. December 1969. Section AH.2.19, p. 5.
http://bitsavers.vt100.net/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf. Retrieved 1 December 2006.
28
29
Van Vleck, Tom. Personal communication. 4 December 2006.
Pouzin, Louis. The Origin of the Shell. 25 November 2000. http://www.multicians.org/shell.html.
This is a brief historical overview of how work on the shell came to fruition.
30
11
Thus we can establish dates of first use of facilities at MIT CTSS:
Date
1965
Type
User-user message
Command
.SAVED /
WRITE
Version
CTSS
1965
Mail
Unknown
CTSS
Noted/(W)ritten
(W) Tom Van
Vleck, (W) Noel
Morris, (W) Robert
R. Fenichel31
(W) Tom Van
Vleck, (W) Noel
Morris, (W) Robert
R. Fenichel
MIT MULTICS
As work on the CTSS project progressed, plans were underway for the next generation system as
part of Project MAC. In 1965, after selecting General Electric to supply hardware for the project
(in the form of a 645 processor), Bell Labs joined MIT to develop the Multiplexed Information
and Computing Service – Multics.
As CTSS already had implemented functions to send messages between users, as well as a
mailbox, these facilities found their way into Multics as well.
The ability to send messages between users on Multics was first implemented by Bob
Frankston32, and is noted by Tom Van Vleck:33
Bob Frankston wrote the send_message and allied commands for Multics about 1970, to
provide Multics with instant messaging similar to that in CTSS. The accept_messages
command established an event-call channel in the user's process and wrote its ID into a shareable
segment in the user's home directory. Then typing
send_message VanVleck.Multics Want to go to the F&T?
would place the message in the shared segment and send a wakeup. The process that had
accepted messages would execute the event-call channel's handler, type out the message, and
remove it. Once again, these messages were forgeable and trashable.
Van Vleck, Tom. Personal communication. 8 December 2006. Tom was kind enough to ensure the
proper individuals received credit for this development:
31
“Credit for inter-user messaging on CTSS goes to Noel Morris (now deceased) and me for . SAVED,
and to Robert R. Fenichel for the CTSS supervisor features that we employed.”
Bob would later go on to author Visicalc. He has a personal homepage at http://www.frankston.com
Retrieved 1 December 2006.
32
Van Vleck, Tom. The History of Electronic Mail. 10 September 2004.
http://www.multicians.org/thvv/mail-history.html Retrieved 1 December 2006.
33
12
The inter-user messaging functionality on Multics was full-featured, and allowed for a much
great level of granularity of control on the part of users, both senders and receivers. Commands
included:34
accept_messages, defer_messages, delete_message, immediate_messages, [last_message],
[last_message_time], [last_message_sender], send_message, send_message_acknowledge,
send_message_silent and send_message_express.
A complete list of commands is available in the Multics Programmer’s Manual – Commands and
Active Functions. 35
Bob Frankston recalls the inspiration of the idea36 while working on the IBM CP system:
I know there was no send_message on Multics when I did mine. I do remember I tested it at 3AM
-- I was working at IDC (CP/CMS) and it was 3AM and I wanted to send a message so wrote the
program and I remember that I liked the idea of using those message segments. 3AM I
remember, but the year???
In the Internet-history mailing list, Bob had mentioned this development as well37 – along with
possible dates:
On Multics I was at my office at Interactive Data (the White Weld group had merged with a
Lincoln Lab group to form IDC) at about 3AM probably working on printing out my BS thesis
(to guess the year -- that would be 1970 or 73/74 if was my MS) and wanted to reach people at
Project MAC (now LCS) so I quickly cobbled together a program using message segments (an
inner-ring-defined file queue). It had the SM command for positing the message and a part that
could wait for the message in the background in a users process by taking advantage of the same
facility used for saying "New Mail". The actual facility was in the user space and just an app -nothing special in the system.
As with many tools, the usefulness of the function was not apparent until later:
I remember Jerry Saltzer wondering why we need it.38
Van Vleck, Tom. Multics glossary. http://www.multicians.org/mgi.html#interactivemessage.
Retrieved 1 December 2006.
34
Multics Programmer’s Manual, Commands and Active Functions. Series 60 (Level 68). Honeywell.
December 1979. http://www.bitsavers.org/pdf/honeywell/multics/AG92-03A_multicsCmds_Feb80.pdf.
Retrieved 1 December 2006.
35
36
Frankston, Bob. Personal communication. 3 December 2006.
Frankston, Bob. Origin of ‘talk’ command. Internet-history mailing list. 19 December 2002.
http://www.postel.org/pipermail/internet-history/2002-December/000178.html. Retrieved 1 December
2006.
37
38
Frankston, Bob. Personal communication. 1 December 2006.
13
The send_message feature was built upon (again, by Van Vleck) to write the “online consultant”
feature into Multics. Using the “olc” command, a user could send a message which would be
forwarded to any online staff member who might help. 39
Athena, a distributed system built around Unix technology, ultimately became the principal
computing facility at MIT. The online consultant feature lives on in that system:
Years later I discovered that there was an Athena olc program, same function, maintained by
some kid at MIT. A funny feeling to see something I thought of in 1969 still in use.40
– Tom Van Vleck
The mail system on Multics could also take advantage of the messaging function, to announce
when a user had mail.
I do remember the mail program alerts -- we'd use it to send a fake message that imitated a
Multics crash and used nulls for the deals that made it seem the system had come to a halt (at
15cps it didn't take that many) and some people shut off their terminals and walked away.41
– Bob Frankston
Multics later connected to the then emergent Arpanet. After BBN’s TENEX had added a
capability to communicate to another TENEX across the network, the net_atalk command was
added to Multics by Kenneth T. Pogran in 1974, 42 to allow connection to those systems.
In March 1969, Bell Labs left the Multics project. Unix – whose name is actually a play on
Multics – derived many of its ideas from the project.
We can establish the dates for messaging on Multics:
Date
1970 or 1974,
date unsure
1974
Type
User-user message
Command
send_message
Version
Multics
Noted/(W)ritten
(W) Bob Frankston
User-user message
(networked)
net_atalk
Multics
(W) Kenneth T.
Pogran
39
Van Vleck, Tom. Personal communication. 4 December 2006.
40
Van Vleck, Tom. Personal communication. 3 December 2006.
41
Frankston, Bob. Personal communication. 3 December 2006.
Pogran, Kenneth T. Multics Networking and Communications. Section 2.2.3 MAIL.
http://www.multicians.org/mx-net.html. Retrieved 1 December 2006.
42
14
Multics continued to serve for decades after its inception. The last system, at the Canadian
Department of National Defence, was shut down on 30 October 200043.
Bolt, Beranek, and Newman (BBN)
In November of 1962 44, Bolt, Beranek and Newman (BBN), located just north of MIT, had
completed work on the Digital Equipment Corporation (DEC) PDP-145 operating system in
conjunction with Jack Dennis 46 at the Institute. This system allowed for shared access by up to
five typewriter terminals.
The PDP-1 would claim the title as the “first” timesharing system (and would go on to fame as
the system used to develop SPACEWAR, the first video game). Dennis would then continue at
MIT during development of the Multics project. There was no capability in the PDP-1 for interuser messaging that I could locate.
BBN TENEX
At BBN, the need for an improved version of TOPS-10 was recognized at BBN (particularly to
support paging), and by September of 1967 the development of TENEX was underway. (A
concise history of the development of DEC’s early systems (including TOPS-10) was written by
Jack Stevens47.)
Less than three years later and ahead of schedule, development of TENEX concluded with an
announcement on July 16, 1970. 48 TENEX had several superior architectural features, and had
established itself in the research community as a useful research platform, especially on the
ARPANET 49. Ultimately, DEC purchased TENEX from BBN in 1973.
43
Multics History. http://www.multicians.org/history.html. Retrieved 6 December 2006.
MULTICS Chronology. http://www.multicians.org/chrono.html. Retrieved 1 December 2006. A
great deal of activity occurred in a small area of the MIT campus during the CTSS, MULTICS, CP-67
development periods..
44
45
Digital at Work. Digital Equipment Corporation. 1992. p. 35.
Dennis, Jack. http://www.computerhistory.org/pdp-1/index.php?f=theme&s=3&ss=3. Retrieved 1
December 2006.
46
Stevens, Jack. A History of TOPS. 13 January 1995. http://www.inwap.com/pdp10/tops-history.txt.
Retrieved 1 December 2006.
47
TENEX Newsletter. Bolt Beranek and Newman Inc.. 16 July 1970.
http://www.opost.com/dlm/tenex/tenexnews.txt. Retrieved 1 December 2006.
48
Origins and Development of TOPS-20. Dan Murphy. 1996.
http://www.opost.com/dlm/tenex/hbook.html. Retrieved 1 December 2006.
49
15
Dan Murphy explains how TENEX almost was not written on DEC hardware: 50
DEC announced that there would be no further PDP-6 models -- that is, that DEC was going out
of the 36-bit business. This (1966) was the first of several such occasions.
Taking DEC at its word, BBN turned its attention to selecting another machine, hopefully one
with an expanding future, that we could use to support our various research projects. The result
of this selection process was the purchase of an SDS-940. SDS was Scientific Data Systems in El
Segundo, California, later acquired by Xerox and known as XDS. The SDS-940 was a 24-bit
word machine with a modest virtual address space, but it did have hardware paging capabilities.
… the DEC KA-10 had been announced (or at least leaked), and we happily switched back to the
architecture we really wanted.
BBN did use the SDS-940 for a couple of years however, and we ran on it an operating system
developed by a group at U.C. Berkeley. That was significant because a number of features in the
Berkeley timesharing system were later modified and adopted into TENEX.
Butler Lampson, one of the developers of the Berkeley system, mentions this on his web page: 51
This system was copied directly in the design of the Tenex system for the PDP-10, except for the
memory management. Tenex later evolved into TOPS-20, the standard operating system for the
DecSystem 20.
Two things of note here: first, the SDS-940 was an important system from a communication
perspective (to be discussed later), and that ideas from the Berkeley system moving into TENEX
is a pattern we will see over and over again:
Three systems most directly affected the design of TENEX -- the MULTICS system at MIT, the
DEC TOPS-10 system, and the Berkeley timesharing system for the SDS 940 computer.
MULTICS was the newest and most "state of the art" system of that time, and it incorporated the
latest ideas in operating system structure.52
TENEX did have a command to link two terminals, 53 with an innovative feature to get
assistance, as described by Dan: 54
50
Origins and Development of TOPS-20.
Lampson, Butler. Personal webpage. http://research.microsoft.com/Lampson/Systems.html.
Retrieved 1 December 2006.
51
Origins and Development of TOPS-20. Dan Murphy. 1996.
http://www.opost.com/dlm/tenex/hbook.html. Retrieved 1 December 2006.
52
Unfortunately, I’ve been unable to find TENEX documentation to determine the name of this
command. Dan Murphy does not recall either (in personal communication of 6 December 2006).
53
54
Murphy, Dan. Personal communication. 1 December 2006.
16
One mechanism that TENEX had from its earliest versions (June, 1970) was a command to link
the output of two (or more) terminals together. With that, the two users could just converse by
typing comment lines. (It could also be used to get help, as one user could run programs and
the other could see exactly what was happening.)
Note that this type of “shared output” did not happen commonly except in some of the systems
considered here. In particular, IBM VM users could initiate a trace of a session using the CP
SPOOL command to copy their input command (although not 3270 full screen output). And
Unix users could use the “script” command to copy any line mode output sent to their terminal.
In addition to keeping a continuous connection between two terminals, there was also a directed
message capability. Note that this more closely parallels how IBM CP and Multics handled
messages:
TENEX also has a 'wall' -type command, and I think it had an option to send to just one
terminal. That would be more like an instant message than linked terminals.55
Dan noted in a later mail that sending a message to all terminals may not have been generally
available:
It was not (called) 'wall'. The general broadcast-to-all-terminals command required privileges,
and such commands began with ctrl-E. I can't remember the rest of it though.56
The early use of these tools seemed to parallel the experiences at Multics.
I don't recall that terminal linking or 'wall' was used very much though, and when it was, it was
usually for the getting help scenario rather than the IM-like communication.57
A network post to the Internet-history mailing list by John Day indicates that TENEX had a
method to link terminals over the Internet:58
… Tenex had such a facility. You could link terminals. And we were using a network version
implemented by Jim Calvin by 1972 or so. And I believe that it was demonstrated at the ICCC
conf.59
55
Murphy, Dan. Personal communication. 1 December 2006.
56
Murphy, Dan. Personal communication. 6 December 2006.
57
Murphy, Dan. Personal communication. 1 December 2006.
Day, John. Origin of ‘talk’ command. Internet-history mailing list. 19 December 2002.
http://www.postel.org/pipermail/internet-history/2002-December/000168.html. Retrieved 1 December
2006.
58
Day, John. Origin of ‘talk’ command. Internet-history mailing list. 19 December 2002.
http://www.postel.org/pipermail/internet-history/2002-December/000171.html. Retrieved 1 December
2006.
59
17
The 1972 date is confirmed by a posting by Dave Crocker:60
I first met Engelbart in the Arpanet coming out part, at the first ICCC, in the Fall of '72, via the
BBN Tenex link function.
Continuing in another post to the list, John Day added more information:
The Tenex facility was a bit different in that it actually linked the two terminals, so that anything
either typed was visible to the other. (EVEN if they typed at the same time. It would interleave it
on a character by character basis!! You can imagine how that looked!)
Jim's original teleconferencing program really was just an interface to allow more than 2. Later
he started adding bells and whistles that allowed someone to grab the floor and later yet allowed
someone to moderate the floor.
TOPS-20, the successor to TENEX, shipped by DEC in January 1976, 61 and was used for some
of the early inter-system messaging on the Arpanet, through the use of the “talk” command (see
Appendix C for the TOPS-20 version documentation). The “talk” command allowed
communication with up to four terminals at once. Users could prevent interruption by using the
REFUSE LINKS command (which would request mail be sent instead), or the TERMINAL
INHIBIT command (which would silently ignore all attempts at interruptions). 62
We can establish the dates for messaging on TENEX, and TOPS-20:
Date
June 1970
Unknown
1972 (?)
January 1976
Type
Linked terminals
Messaging
Linked terminals
(network)
Messaging
Command
Unknown
Unknown
Unknown
Version
TENEX
TENEX
TENEX
Noted/(W)ritten
Dan Murphy
Dan Murphy
(W) John Day
TALK
TOPS-20
(manual)
The PDP-10 had a following perhaps like no other (emulators are popular63); even sites such as
Columbia University, traditionally an IBM facility, installed DEC systems64. System shutdowns
were often treated as tragic events. Clive Dawson from the University of Texas recalled: 65
Crocker, Dave. This history of ‘talk’. Internet-history mailing list. 19 December 2002.
http://www.postel.org/pipermail/internet-history/2002-December/000380.html. Retrieved 1 December
2006.
60
Murphy, Dan. Origins and Development of TOPS-20. 1989. http://www.inwap.com/pdp10/papert20.txt. Retrieved 2 December 2006.
61
TOPS-20 Commands Reference Manual. July 1990.
http://zane.brouhaha.com/~healyzh/tops20_7/COMMANDS.MEM.txt. Retrieved 1 December 2006.
62
The DEC PDP-10 Emulation Webpage. 26 August 2006.
http://www.aracnet.com/~healyzh/pdp10emu.html Retrieved 1 December 2006.
63
18
At home very late that night, I felt the urge to dial up one last time. As I went through my
normal routine of checking mail, the Bboard, and the various system mailboxes, I discovered
something completely unexpected. During the last few hours users had logged in and sent mail
to the bboard and to other system mailboxes like Operator. The curious thing is that these
people had no way of knowing that anybody would ever be around to read these messages.
They were, in the best way they knew how, sharing their feelings directly with the machine.
Dartmouth Time Sharing System (DTSS)
In September of 1963, John Kemeny and Thomas Kurtz proposed building a time-sharing
system at Dartmouth. This came after a suggestion from John McCarthy of MIT:66
Around 1961 this is exactly (?) what John McCarthy, now at MIT, said to me. I repeated same to
John Kemeny, and he agreed without hesitation. McCarthy and others had built the first generalpurpose time sharing system on the DEC PDP-1 around 1959. He then became a vociferous
advocate for "time sharing" as a way to make useful chunks of computing available to a larger
audience. While his pleadings had little effect at MIT (except for CTSS and, later, Multics,) we
accepted the idea full bore at Dartmouth.
Tom Kurtz tells the story online: 67
In only two and a half months, the "kids" got the time-sharing system to service two teletypes and
run a simple BASIC program. The official legend is that this all took place at 4AM on May 1,
1964. Mean Time to Failure (MTTF) was about five minutes. However, by the middle of June the
system was "reliably" servicing 11 teletypes, well enough to allow John Kemeny to introduce the
new "baby" to the faculty. And by fall there were 20 terminals.
On May 1, 1964, the Dartmouth Time Sharing System (DTSS) was operational on a GE-225
connected to a DATANET-30 system.68
Da Cruz, Frank and Gianone, Christine. The DECsystem-20 at Columbia University. 29 December
1988. http://www.columbia.edu/kermit/dec20.html. Retrieved 1 December 2006.
64
Dawson, Clive. The soul of an old machine. 1984. http://www.inwap.com/pdp10/uta-shutdown.txt.
Retrieved 1 December 2006.
65
Kurtz, Tom. Dartmouth Computing 1960-1970. “You guys ought to do time sharing.” 10 July 2003.
http://www.kemenyskids.com/forums/viewtopic.php?t=24. Retrieved 1 December 2006.
66
Kurtz, Tom. Dartmouth Computing 1960-1970. Basic and DTSS is born on May 1, 1964, at 4 AM.
http://www.kemenyskids.com/forums/viewtopic.php?t=31. 14 July 2003. Retrieved 1 December 2006.
67
http://dtss.org/scans/D-30%20Exec/D-30%20Exec.pdf. Retrieved 6 December 2006. Listings of
some of the Executive programming have been scanned and are available here.
68
19
Although at one point inter-user communication was enabled on DTSS, it was apparently short
lived. There have been network posts69 that such a feature did exist, but I have been unable to
verify those claims.
A story on sending messages between two terminals at DTSS was told by Sidney Marshall during
an interview in 1974:70
S.N. "My name is Sidney Marshall. I am currently a scientist at the Xerox Corporation. And I
started out on the LGP 30 . .?. ., I think I was the first high school student to start stealing time
from the college. I was not in on the original conception of the 235 system. I wrote TSAP and the
MOLD system, and a good part of the exec for the current system, which I suspect has now been
chipped away by succeeding programmers." …
S.N. "I'd like to tell a story about some of these early days. You can sort of tell that we were sort of
misguided high school kids going to college. One of the games we would play would be to go
downstairs and there was a control teletype that could talk to any other teletype. One of the
features of this was that the other person didn't know that this had happened to him so that
suddenly he was talking to you rather than to whatever he thought was going on, And you'd
generally go down there just before a football game or something when everybody was up there
trying to impress their dates with the computer. You'd take control of the computer so they'd be
talking to you. You got some very interesting conversations. One I remember was ... one of the
games was to type as fast as possible so that they thought it was the computer rather than some
stupid person downstairs. And somebody realized that there was a little more intelligence in this
terminal than they thought and started asking questions. One of the questions they asked was
'What's the score of the football game going to be?' I typed something very fast. 14 to 7. And I was
right! And there was a big argument after the game up in that room. 'The computer can predict
things!' 'No, it can't!' I never did find out who it was. I just heard reports of it."
In mail, I asked (now) Professor Marshall if indeed the DTSS system allowed for inter-user
communication. His reply71 indicates that although possible, it was not a general user feature:
TTY #1 was the operator teletype and, in addition to being a normal terminal, could execute
several privileged commands … it was not a general inter-user communication technique. In
about 1967 or 1968 I implemented a general communication system which was implemented
"correctly" but it was never used in the working system much because of the disruption it caused
by people chatting all over the place.
The original system allowed teletype #1 (only) to use three privileged commands:
Mills, David L. This history of “talk”. Internet-history mailing list. 19 December 2002.
http://www.postel.org/pipermail/internet-history/2002-December/000173.html. Retrieved 1 December
2006.
69
American Federation of Information Processing Societies, History of computing project. Dartmouth
Timeshare System. Transcripts of 1974 National Computer Conference Pioneer Day Session.
http://www.dtss.org/transcript.php. Retrieved 1 December 2006.
70
71
Marshall, Sidney. Personal communication. 4 December 2006.
20
WARN - everything typed on TTY #1 was (poorly) echoed to all of the other teletypes. This
preempted everything the user was doing so they had to wait until the message, typed by a slow
typist, was finished.
DIAL - This provided two-way communication between TTY #1 and any selected teletype.
MONITOR - This "spied" on any given terminal. Anything typed or printed on the selected
terminal was echoed to TTY #1.
All of these features were implemented poorly by jamming in a character into the output buffer
without regard to timing etc. The output was generally correct but irregular.
We can establish the dates for messaging on DTSS:
Date
Type
1968 – removed Linked terminals
from service
Command
Unknown
Version
DTSS
Noted/(W)ritten
(W) Sidney
Marshall
Systems Development Corporation (SDC)
On the west coast, Systems Development Corporation (SDC) of Santa Monica, California, had a
timesharing system operating in 1963. The origins of the system are explained by Rosen:72
The IBM Military Computer was a very large computer designed and built in 1958-1962 for the
Strategic Air Command's command and control applications. During the first generation, IBM
had supplied many computers, similar in many ways to the 704 and 705, for use by the SAGE air
defense system. They hoped that the powerful transistorized Military Computer (rechristened the
ANFSQ-32) would be used for replacements. It was not so used and only a few were built. One of
these was installed at the headquarters of the System Development Corporation in Santa Monica
and years later became quite well known as the Q-32, the computer on which SDC's large timesharing system was developed.
The AN/FSQ-32, or Q-3273 for short, connected a considerable number of input devices, as
well as connections to networks:
There are now 52 teletype-typewriter channels available, of which 21 are open to distant
(Dataphone, TWX, TELEX) communications. The only significant configuration change is the
size of the drum memory, which is now approximately 750,000 words, as opposed to the 400,000
originally mentioned. One other change of interest is the installation of a RAND Tablet interface
in conjunction with the display scopes, which has permitted hand-written input to the computer.
In the area of computer networks, the one that existed between the CDC 160A and the Q-32 is
Rosen, S. 1969. Electronic Computers: A Historical Survey. ACM Comput. Surv. 1, 1 (Mar. 1969), p.
24. DOI= http://doi.acm.org/10.1145/356540.356543
72
73
Q32 (computer). Wikipedia. http://en.wikipedia.org/wiki/Q32. Retrieved 6 December 2006.
21
now obsolete. Currently, a connection exists between the Q-32 and the Lincoln Laboratory's TX2.74
Full system hardware specifications based on a 1961 report are available online.75
The DIAL command allowed for communication between terminals, and is explained in the
1966 paper by Linde and Chaney:76
At SDC the operator has two teletypes, one primarily for communication with users through the
DIAL command and the other as a TSS channel available for running background jobs, such as
compilations (Figure 3). The DIAL command connects the teletypes, through the system, for
direct communication and provides an efficient means for remote user communication with the
operator. The operator can DIAL ALL and send out timely messages to all users concerning such
events as last-minute schedule changes, and users
can dial specific teletypes to communicate with each other. …
In the same document, a comparison is made to MIT’s CTSS, and likely is referring to the
notification of waiting mail written by Tom Van Vleck. The “Berkeley system” refers to the SDS
930:
In contrast the system at MIT uses the "post office box" technique, in which a user who wishes to
communicate with another individual leaves a message with the system, to be passed on to the
addressee. He can only receive messages at the time that he enters the system. The Stanford
system uses a connection matrix, which will allow any keyboard to be in a "talk" status with any
other keyboard. A user at the Berkeley system types the query WHERE IS and is told the channel
number of the user he wishes to communicate with; he then can link to that channel number and
"talk" to the user. He can also "talk" to the operator's console teletype.
The use of the DIAL command is illustrated on p. 152 (see Appendix G for complete listing).
Schwartz in his 1967 paper makes a brief mention is made of inter-user communication through
the DIAL command. 77
Schwartz, J. I. and Weissman, C. 1967. The SDC Time-Sharing System revisited. In Proceedings of the
1967 22nd National Conference (Washington, D.C., United States). S. Rosenthal, Ed. ACM Press, New
York, NY, p. 263. DOI= http://doi.acm.org/10.1145/800196.805996
74
Weik, Martin H. A third survey of domestic electronic digital computing systems. BRL report number
1115. Aberdeen Proving Ground, Maryland. March 1961. http://ed-thelen.org/comp-hist/BRL61a.html#AN/FSQ-32. Retrieved 6 December 2006.
75
76
Linde, R. L. and Chaney, P. E. 1966. Operational management of time-sharing systems. In Proceedings of
the 1966 21st National Conference ACM Press, New York, NY, p. 150. DOI=
http://doi.acm.org/10.1145/800256.810691
Schwartz, J. I. and Weissman, C. 1967. The SDC Time-Sharing System revisited. In Proceedings of the
1967 22nd National Conference (Washington, D.C., United States). S. Rosenthal, Ed. ACM Press, New
York, NY, p. 268. DOI= http://doi.acm.org/10.1145/800196.805996
77
22
We can establish the dates for messaging on the SDC Q-32:
Date
1966
Type
Messaging
Command
DIAL
Version
Q-32
Noted/(W)ritten
R. Linde, P.
Chaney,
Scientific Data Systems (SDS) 940
Scientific Data Systems of Santa Monica, California joined with the University of California at
Berkeley in research and development of a new operating system, as a follow-on to their 930
product. Shortly after this effort began, SDS was acquired by Xerox Corporation and the system
was renamed the XDS 940. Many of the developers went on to found Xerox PARC, and work
on systems continued at that location.
The ongoing interplay of ideas between operating systems includes the Xerox 940. Butler
Lampson notes in his web page78:
Some of the 940 system's ideas are also embodied in Unix, whose designer Ken Thompson
worked on the 940 while at Berkeley.
The ability to link terminals together is show in the Terminal User’s Guide79 (dated 1968), and is
attached as Appendix D. Note that this functionality is also referenced in Linde and Chaney’s
SDC Q-32 paper80 (of 1966), so there was awareness of activity happening at other sites.
Butler Lampson, one of the principal researchers, notes:
I believe the Link feature was in the system more or less from the beginning, though I'm not sure
about that. … This was not really a way to send messages. It was more like today's remote
desktop--everything output to one terminal went to the other as well. It was often used much the
way people use IM today, though. 81
Lampson, Butler. Personal webpage. http://research.microsoft.com/Lampson/Systems.html.
Retrieved 1 December 2006.
78
Scientific Data Systems. Reference Manual. SDS 940 Terminal User’s Guide. April 1968. p. 15.
http://bitsavers.org/pdf/sds/9xx/940/901118B_940_TerminalUsersGuide_Apr68.pdf. Retrieved 1
December 2006.
79
Linde, R. L. and Chaney, P. E. 1966. Operational management of time-sharing systems. In Proceedings of
the 1966 21st National Conference ACM Press, New York, NY, p. 151. DOI=
http://doi.acm.org/10.1145/800256.810691
80
81
Lampson, Butler. Personal communication. 6 December 2006.
23
Peter Deutsch, also a member of the Berkeley project at the time commented: 82
I'm almost certain that we had the LINK command in the 940 research prototype at Berkeley,
which would mean it could have been implemented any time after late 1965. I believe it was
implemented using a more general facility for allowing one user to send output to, or "steal" input
from, a tty other than the user's own tty. That facility was implemented before (but not much
before) the time that we implemented pseudo-ttys, which was a key element in the use of
SNOBOL as an interactive scripting language (perhaps similar to 'expect'). I'm pretty sure a
paper was published on that SNOBOL system -- Butler might have a reference for that -- and as I
said, I'm pretty confident the LINK facility predates it.
The SNOBOL paper Peter references83 is dated 6 September 1968. The Berkeley Time Sharing
System paper, including the first mention of attaching teletypes for use, is dated 8 August 1966 84.
Reference manual pages with first mention of this capability are included in Appendix H. 85
As a historical note: possibly the last fully functioning SDS 930 system was saved by a volunteer
group in Colorado in 199586.
We can establish the dates for messaging on the SDS-940:
Date
1965
Type
Terminal capture
Command
LINK
Version
SDS-940
Noted/(W)ritten
(W) Deutsch, (W)
Lampson
Unix
Of all systems (perhaps because it was the last of the original timesharing systems), Unix
borrowed most heavily from other designs. Dennis Ritchie had worked on Multics directly
during the years of Bell Labs involvement. On the other coast, Ken Thompson had worked
along with Butler Lampson and Peter Deutsch on the SDS 940 system at Berkeley.
82
Deutsch, Peter L. Personal communication. 6 December 2006.
Sturgeon, Roger. Interactive SNOBOL4 System for the SDS 940. Document No. R-34. Issued 6
September 1968. http://www.bitsavers.org/pdf/sds/ucbProjectGenie/R-34_SDS940_SNOBOL4.pdf.
Retrieved 2 December 2006.
83
No author specified. Untitled. 8 August 1966. http://www.bitsavers.org/pdf/sds/ucbProjectGenie/R21_GenieMoniGuide_8Mar67.pdf. Retrieved 6 December 2006.
84
No author specified. Untitled. 8 August 1966. pp. 7-3 – 7-8.
http://www.bitsavers.org/pdf/sds/ucbProjectGenie/R-21_GenieMoniGuide_8Mar67.pdf. Retrieved 6
December 2006.
85
86
CHAC SDS 930 Rescue. http://www.chac.org/chsds930.html. Retrieved 6 December 2006.
24
The “write” command to link two terminals existed in the very first edition of Unix in
November of 1971 87 The write command was a very simple method to “link” two terminals. It
did not have any mechanism to take advantage of full screen support, and would have worked
equally well on teletypes.
At the University of California at Berkeley, a new type of message client was added, to take
advantage of the new “curses” screen library. Using the capability of a full screen CRT terminal,
the Berkeley “talk” command would divide the screen in half, so that both parties’ typed
messages remained visible at all times. This was the first time some type of formatting was
applied to messaging. “talk” appeared in the 4.2 release of BSD Unix, which shipped in August
1983.
Note that for a short period of time, there were two versions of talk which were incompatible.88
We can establish the dates for messaging on Unix:
Date
1971
1983
Type
Messaging (local)
Messaging (remote)
Command
Write
Talk
Version
Unix
Unix
Noted by
(manual)
(manual)
PLATO
Developed at the University of Illinois, the PLATO89 system pioneered research into computer
conferencing and computer assisted educational tools.
In the fall of 1973, a chat program known as “Talkomatic”90 was added to the system by Doug
Brown. This allowed for multiple users (up to five) to talk simultaneously as one group, in a
Unix manual. Volume 1. 3 November 1971. “write” command. http://cm.belllabs.com/cm/cs/who/dmr/pdfs/man11.pdf. Retrieved 1 December 2006.
87
Talk (derived from BSD 4.2) used USD port 517, ntalk (from BSD 4.3) used UDP port 518.
Craig Patridge wrote on 19 December 2002 in http://www.postel.org/pipermail/internet-history/2002December/000166.html:
It was a hack -- not a designed protocol. Someone wanted to enable interactive communications between
machines. One sign it was a hack – it didn't specify byte ordering, with the result that as soon as Sun
shipped talk and talkd, people promptly discovered that VAXen and Sun workstations talkd daemons
couldn't communicate with each other.
88
Additional discussions in that thread concern chat and linking of terminals.
Dear, Brian. PLATO People: A history book research project. http://www.platopeople.com/.
Retrieved 1 December 2006.
89
25
“channel”. Much like Unix “talk”, which would not appear until years later, users could see
others typing, character by character. In addition, users could join a channel, but not write (if
there were already five persons talking); channel could also be “protected”, which allowed for
private channels, admitted people by invitation only.
Several weeks later, on 19 December 1973 a user-user messaging feature known as “term talk”91
was added to the system.
The announcement on PLATO itself describes the facility:
An inter-station communication option has been provided… “term talk” will allow an author to
talk to another author at another station (cannot talk to student)
If you wish to talk to another author – type “term talk” and follow directions
You can specify from whom you wish to accept –talk- requests … from anyone, from anyone in
your course, or from no-one (press –data1- from the sign-on code-word entry page)
If someone is trying to talk to you, you can type “term talk” to reply or “term reject” to refuse to
talk
Note that this was the first time a system provided an extra degree of control over who one
chooses to talk with; other systems allowed the receiver to choose to ignore completely an
invitation to talk, but “term talk” allowed the additional choice of those in a course.
PLATO is the first example of an application system with features such as messaging and chat
built-in.
The community aspects of PLATO were considered one of its principle social features.92 Later
systems such as Lotus Notes and Groove (authored by Ray Ozzie, who had worked on PLATO)
built upon these core concepts using a distributed systems model.
We can establish the dates for messaging on PLATO:
Date
19 Dec 1973
Fall 1973
Type
Messaging
Multi-user chat
Command
Term talk
Talkomatic
Version
PLATO
PLATO
Noted/(W)ritten
(W) Doug Brown
Woolley, David R. PLATO: The emergence of online community. 1994.
http://www.thinkofit.com/plato/dwplato.htm. Retrieved 1 December 2006.
90
Dear, Brian. PLATO people: TERM-talk and Instant Messaging. 19 December 2002.
http://www.platopeople.com/termtalk.html. Retrieved 1 December 2006.
91
92
Woolley, David R. PLATO: The emergence of online community. 1994.
http://www.thinkofit.com/plato/dwplato.htm. Retrieved 1 December 2006.
26
Douglas Engebart’s Online System (NLS)
Bob Braden wrote on the Internet History mailing list93: of Engelbart’s research at SRI:
This is a long time ago and I am a bit fuzzy, but I think I first saw the linking concept on John
McCarthy's PDP/1 (?) time sharing system when I went to work at Stanford in 1966. It was
certainly present in Englebart's NLS system in the mid 1970s, and I believe it existed in the ITS
and Multics system, probably in the mid 1960s.
A review of a tape of a demonstration describes some of the collaborative features:94
Since the system was running on a single server, they added commands that would let two
monitors share a single view. That allowed person A to call person B, and give his view to person
B. From then on, they are both looking at the screen Person A has in front of him, each on their
own monitors.
Each person had their own cursor on the display. (Called a "bug" in 1968.) But the original user's
cursor was more powerful, and would dominate the proceedings until and unless control was
turned over to person B.
While one of the earliest examples of true collaboration, the messaging and chat capabilities
comparable to other systems were not included.
Braden, Bob. This history of talk. Internet-history (mailing list). 19 December 2002.
http://www.postel.org/pipermail/internet-history/2002-December/000167.html. Retrieved 1 December
2006.
93
Armstrong, Eric. Doug Engelbart’s NLS System (review of 1968 video). 22 June 2000.
http://www.treelight.com/software/collaboration/NLS_video.html.
94
27
Summary of messaging developments
Date
1965
1965
1966
1968 –
removed
from service
1970(?)
June 1970
November
1970
1970 or
1974, date
unsure
1971
1972 (?)
2 August
1972
Fall 1973
19 Dec
1973
1974
January
1975
January
1976
February
1976
1983
General
type
Messaging
(local)
Specific type
Command
System
Noted/(W)ritten
User-user
message
.SAVED /
WRITE
CTSS
Linked
terminals
Messaging
(local)
Linked
terminals
Terminal capture
LINK
SDS-940
Messaging
DIAL
Q-32
Linked terminals
Unknown
DTSS
(W) Tom Van
Vleck, (W) Noel
Morris, (W)
Robert R.
Fenichel
(W) Deutsch, (W)
Lampson
R. Linde, P.
Chaney
(W) Sidney Marshall
Messaging
(local)
Linked
terminals
Messaging
(local)
Messaging
(local)
Messaging
Unknown
TENEX
Dan Murphy
Linked terminals
Unknown
TENEX
Dan Murphy
User-user
CP MSG
Lynn Wheeler
User-user message
send_message
CP/67
Version 3
Multics
Messaging
(local)
Messaging
(remote)
Messaging
(local)
Messaging (local)
write
Unix
(manual)
Linked terminals
(network)
VM-VM file
exchange
Unknown
TENEX
(W) John Day
VM
Release 1
(W) David Tuttle
Chat
(local)
Messaging
(local)
Messaging
(remote)
Messaging
(remote)
Multi-user chat
CP SPOOL
(with TAG
option)
Talkomatic
PLATO
(W) Doug Brown
Messaging
Term talk
PLATO
User-user message
(networked)
RSCS: Remote
commands/message
net_atalk
Multics
Messaging
(local)
Messaging
(remote)
Messaging
(remote)
Messaging
SM RSCS
CMD /
TELL
TALK
VM
Release 2
PLC 11
TOPS-20
SPM
VM
Release 3
Unix
VMCF utility,
SPecial Message
Messaging (remote)
Talk
28
(W) Bob Frankston
(W) Kenneth T.
Pogran
Melinda Varian
(manual)
Lynn Wheeler,
Melinda Varian
(manual)
Messaging “firsts”
Date
1965
1965
1972 (?)
Fall 1973
General
type
Messaging
(local)
Specific type
Command
System
Noted/(W)ritten
User-user
message
.SAVED /
WRITE
CTSS
Linked
terminals
Messaging
(remote)
Chat (local)
Terminal capture LINK
SDS-940
Linked terminals
(network)
Multi-user chat
Unknown
TENEX
(W) Tom Van
Vleck, (W) Noel
Morris, (W) Robert
R. Fenichel
(W) Deutsch, (W)
Lampson
(W) John Day
Talkomatic
PLATO
(W) Doug Brown
The various types of messaging can be described as follows:
Messaging (local):
The sender transmits a short message which will appear on the recipient’s
terminal either immediately (interrupting whatever is occurring), or at the
next available interrupt (such as a keypress or receipt of scheduled output).
Messaging (remote): The sender transmits a short message using a telecommunications network
which will appear on the recipient’s terminal either immediately
(interrupting whatever is occuring), or at the next available interrupt (such
as a keypress or receipt of scheduled output). The receipt of the message
may be delayed due to the transmission characteristics of the network
(bandwidth, latency, noise).
Linked terminals:
The sender (which may be one, or either terminal) transmits characters
which immediately appear on the corresponding linked terminal. There
may be no provision for intelligent ordering of the output, such that
characters may print interspersed with other data being received at the
remote terminal. The transmission and robustness of the connection may
be delayed due to the transmission characteristics of the network
(bandwidth, latency, noise).
Chat:
Multiple users are connected such that conversations are shared in a
common output channel; all users receive a copy of any transmission made
by any sender. Some intelligent processing occurs at the processor such
that transmissions appear in some reasonable order by each recipient, to
allow the conversation to be followed in as close an order as possible to the
time messages were sent. Sender input may be transmitted as fast as
possible (i.e. character by character, as typed), or pending a end of
message indicator (i.e. pressing the return/enter key).
29
Density of development in the Cambridge area
The interactions between MIT, DEC, and BBN were strongly influenced by the sheer physical
proximity of the organizations. BBN in particular was only a short drive from the MIT campus.
Influences between the development groups could be significant. Dan Murphy writes:
During the design of TENEX, we invited some of the Multics designers and implementors to
review our progress and decisions. As is often the case, we had fallen into the trap of trying to do
too much in a number of areas and had produced some designs that were quite convoluted and
complex. Several people from Multics beat us up on those occasions, saying "this is too
complicated -- simplify it! Throw this out! Get rid of that!" We took much of that advice (and
could probably have taken more), and I credit these reviews with making the core capabilities
significantly easier to understand and program, as well as to implement and debug. 95
A novel feature to complete user commands was included: when the user entered a partial
command name and pressed ESCape, the system would complete the command if possible. This
capability finally appeared in the UNIX operating system in the “tcsh” shell, whose author was
influenced by this TENEX capability. 96
Tom Van Vleck writes of the incredible density of computing efforts in the Tech Square
97
building:
Project MAC used floors 5, 8, and 9 of the building for professor, staff, and graduate student
offices, and computer rooms. The computers were the main attraction; the Project MAC IBM
7094 and GE-645; the AI lab PDP-6 and PDP-10; the Dynamic Modeling group's PDP-10,
several other DEC machines, and the ARPANet IMP. … The IBM Cambridge Scientific Center
was on 4, the birthplace of CP/CMS and the 360/67. The GE Multics team, the Cambridge
Information Systems Laboratory (CISL), had offices on half of the seventh floor.
Operating system development benefited from the strong interaction between development
groups, and in many cases the mobility of researchers. Bob Frankston writes: 98
Remember that all these efforts are intertwined. For example Peter Deutsch's father was an MIT
professor so ET (Expensive Typewriter) influenced QED on the 940 which begat QED on CTTS
(and the control key editing was replaced by regulator expressions there but probably led to the
95
Origins and Development of TOPS-20. Dan Murphy. 1996.
http://www.opost.com/dlm/tenex/hbook.html. Retrieved 1 December 2006.
96
tcsh. Wikipedia. http://en.wikipedia.org/wiki/Tcsh. Retrieved 1 December 2006.
Van Vleck, Tom. Tech Square. http://www.multicians.org/tech-square.html. Retrieved 1 December
2006.
97
98
Frankston, Bob. Personal communication. 3 December 2006.
30
control character ^T mode in Teco which later created ^R mode which led to Emacs with went
onto Multics via Bernie Greenberg's fascination with Lisp and it's that version that led to GNU
EMacs).
Chat systems
BITNET: RSCS and RELAY
BITNET began in 1981 with a single leased-line connection between the City University of New
York and Yale University. Termed the “Because It’s Time Network”, the core idea was simple:
connect institutions running the IBM VM operating system together. Using 9600 baud leased
lines and the RSCS application, institutions could join with a simple agreement to connect to
another site by paying for the equipment, and equally agreeing to accept a connection from any
other site desiring one. In this way the network grow without much administrative overhead,
and at very low cost.
It was interesting that many users of systems that were members of BITNET did not seem to
know the network existed until shown an application such as retrieving files from a remote server.
Users helping other users was the norm, and perhaps because of the immediate nature of
feedback, “exploring” services on BITNET was a popular pastime, particular among students. 99
User documents were placed on the network, and retrieved as needed from various servers; Yale
published an overview of the network as BITNET USERHELP 100
The history of BITNET has been well documented 101,102, and Chris Condon has placed many
historical files online on his “nethistory” site 103. Many of the software packages (almost all
This was my experience as a system manager at the New Jersey Institute of Technology. Other sites
reported the same behavior, as told as conferences such as SHARE and VM Workshop.
99
BITNET USERHELP. Chris Condon, Yale University Computer Center. October 1990.
http://nethistory.dumbentia.com/bithelp.html. Retrieved 1 December 2006.
100
Grier, D.A.; Campbell, M., "A social history of Bitnet and Listserv, 1985-1991," Annals of the History
of Computing, IEEE , vol.22, no.2 pp.32-41, Apr-Jun 2000. http://ieeexplore.ieee.org
/iel5/85/18190/00841135.pdf?isnumber=18190∏=JNL&arnumber=841135&arnumber=841135&arSt
=32&ared=41&arAuthor=Grier%2C+D.A.%3B+Campbell%2C+M.
101
Access to the world through a network known as BITNET. Caroyln Gedney. UIUCnet V2-7.
December 1989. http://web.archive.org/web/19970808075757/http://www.uiuc.edu/uiucnet/2-71.html. Retrieved 1 December 2006. This is an interesting article based on the date is was written, by
1989 BITNET had been in existence for quite a long time, and Illinois was very well-connected both to
the Internet and other networks.
102
31
written by members of the BITNET community) used on the network are discussed in a 1991
paper 104.
With the built-in ability to send messages to other users on VM systems (based on the early work
at Cambridge), several virtual machines appeared on the network to act as chat servers. Many of
these systems had been poorly written, consumed large amounts of CPU time, and were often
installed by students without knowledge of system management. Chat servers were running at
North Carolina State, Penn State, University of Chicago, Texas A&M, and other campuses.
Henry Nussbacher, at the Weizmann Institute of Science, had been monitoring traffic caused by
the various chat servers on the network. His analysis of how these servers were amounting to a
dramatic increase in traffic was concise. It was published to the community as email on 26
February 1985, and drew an immediate response. 105
Chat server machines are very different from normal server machines. In essence, they are
message rebroadcasters (similar to a CB system). But when 20 users are on a CHAT system
channel and each user is sending approximately 4 messages per minute into the server machine,
that means that every minute, the server will have 80 incoming messages and will have 1520
OUTGOING messages to deliver. Yes, 1520 outgoing messages per minute! Since RSCS gives
priority to message buffers ahead of file buffers, this has a tendency to slow file transfer to a
standstill.
Jeff Kell at the University of Tennesee would later write an improved chat system which became
known as RELAY. 106
Jeff explains how he first learned of messaging: 107
Many, many moons ago (I'd prefer not to be specific) I was working at UTC as a student operator
on an IBM 360 which was connected to a larger IBM 360 at UT Knoxville which was running
Nethistory – an informal history of BITNET and the Internet. Chris Condon.
http://nethistory.dumbentia.com/archive.html. Retrieved 1 December 2006.
103
Manderson, L. 1991. A cornucopia of connections: getting from here to there, for little or no money
down. In Proceedings of the 19th Annual ACM SIGUCCS Conference on User Services (Seattle,
Washington, United States, November 03 - 06, 1991). SIGUCCS '91. ACM Press, New York, NY, 203210. DOI= http://doi.acm.org /10.1145/122898.122934
104
Nussbacher, Henry. Chat server machines. 26 February 1985.
http://nethistory.dumbentia.com/chatpol.html. Retrieved 1 December 2006.
105
Bitnet Relay Chat. Wikipedia. http://en.wikipedia.org/wiki/Bitnet_Relay_Chat. Retrieved 1
December 2006.
106
Kell, Jeff. Relay: Past, present, and future. 1987 Spring Netcon, New Orleans.
http://nethistory.dumbentia.com/relayhist.html. Retrieved 1 December 2006.
107
32
OS/MVT (an ancestor of MVS) with HASP (an ancestor of JES2). … About the most fun you
could have was displaying job queues for other campuses.
One evening, a strange message came over the console, something like: *$21.05.31 HASP0254I
0,'HAVING FUN LOOKING AT THE JOBS FOR MEMPHIS?'
Well, looking up the error code for HASP0254I, I discovered it was an operator message, and the
'0' meant it came from the host system which is remote number 0 (we were remote 4). I had just
received my first interactive message of my life. I looked up the command to send back a reply
and entered:
$DM0,'NOTHING ELSE TO DO UNTIL CAVANAUGHS BIG LIST FINISHES
PRINTING'
Now this WAS fun. We talked about 30 minutes.
Some time thereafter, Jeff had acquired a CMS account, and was exploring the various chat
servers on the network, in the same period when Henry’s analysis was released. Because the load
on the RSCS links comprising BITNET had severely increased, many of the chat servers were
deactivated. RELAY grow out of this frustration, to design a scalable system where messages
would be intelligently routed.
Arty Ecock of the City University of New York had authored IUCVTRAP in 1983, which
enabled a virtual machine to “intercept” messages sent to it. This was the foundation for nearly
all of the chat servers already deployed, and was also used by RELAY.
Jeff explains: 108
Version 1.11 was shipped in October 1985 and provided Relay polling (to check links every five
minutes), the /list command, and topics. It also included channel limits and some optional service
area checking. … Late November 1985 brought Version 1.14 with the quiesce feature.
Users eventually accepted the daytime 'split' of the Relay network and continued their use after
hours. More users came. And more Relays. … Central relays on smaller CPUs were seen running
40% or more CPU during peaks. Bitnic's Relay was processing 600-800 messages per minute.
And as you might guess, management was not pleased. Bitnic's Relay was all but shut down
altogether for days at a time because of the load it put on their CPU. Relay 'hackers' were
scanning private channels from EXECs or by brute force. Users were sending 'pictures' through
Relay without knowing the load it was generating. These and other things started to get
completely out of hand. Node managers and Relay owners alike were demanding some relief.
Optimization of RELAY happened in several stages, with the most resource intensive code being
redesigned first. Beginning in December 1985, Eric Thomas 109 did a considerable amount of
108
Kell, Jeff. Relay: Past, present, and future.
Eric went on to write LISTSERV, what became the de facto mailing list software in the VM
community. LISTSERV was written as an alternative to the “original” list code (aka “LISTSERV 1”)
which was written by Geert Marian at the City University of New York Computer Center. As opposed to
the original version, Eric’s took allow lists to work in a distributed manner, as opposed to to centralized
109
33
work in designing a replacement for IUCVTRAP. Despite the efforts at lowering the overhead
on sites running RELAYs, RSCS links between BITNET nodes continued to prioritize message
traffic higher than file transfers (which including mail).
Critical BITNET hubs, such as the City University of New York, which had already been
experiencing explosive growth in traffic, began manually processing mail flowing through its
system. Randi Robinson was managing mail traffic, including the links to Europe: 110
A link between nodes could fail at any time: phone lines, modems, CSU/DSUs, mainframes
could all have problems. The RSCS person could be on vacation or out sick and there’d be no
one to watch the links. When one of our outbound links would go down it might just come back
up or might need to be manually restarted. I might have to call the RSCS contact on the other
end to see if they were having problems. If they weren’t having a specific computer-related
problem, the issue would get handed off to the telecommunications folks. …
Any time a link was down, spool files would still be coming in and going out other links. Certain
sites carried more traffic than others – our link to France, for instance. For some time it carried
all the traffic for Europe.
The files would have to be removed from the offending link or links. The process involved getting
a list of the spool file IDs for RSCS, sorting them by link, mounting a tape on a drive and then
writing all those files to tape. …
The very worst episode of this was when our link to France went down. … We were told a shark
had chewed through the cable! While service was restored some weeks later, I still had a growing
pile of tapes filled with spool files just waiting to be loaded back and sent…
Eventually tape reels became tape cartridges, line speeds increased, traffic analyzed, redundancies
added. Princeton was a driving force in adding TCP/IP support to RSCS, allowing multiple
streams of data on a single link.
Ultimately, the design of RSCS and inability to manually define traffic priorities (i.e. giving mail
files precedence over messages) caused the decline of RELAY 111. Jeff wrote:
Relay is on the verge of collapse. NCSUVM's decision to cancel Relay at their site is a bad omen.
It is no longer due to network load. It is only marginally due to CPU load. It is due to the users.
112
model of the CUNY code. Eric has a history of the development of LISTSERV available at
http://www.lsoft.com/products/listserv-history.asp (Retrieved 1 December 2006).
Robinson, Randi. Personal communication. 6 December 2006. The full text of Randi’s experiences
running one of the largest BITNET nodes in the country is included in it’s entirety as Appendix E.
110
Valdis Kletnieks at Virgina Tech rewrote RELAY in Pascal in 1989. By this time, many BITNET sites
had moved to join the fast growing Internet, and despite a merger with Csnet in 1988, in 1996 BITNET
ceased operations.
111
34
Despite the inability of BITNET to handle RELAY traffic, individual users had designed tools to
manage messaging with smaller groups of friends. One such program, BITQUERY 113, would
send commands to remote systems to check if friends were logged in; the results were analyzed
then presented on one screen. The author knows of no other environment where this was
possible; the other utility which allowed checking for remote logged in users was “finger”, widely
deployed on Unix systems; however it had no mechanism to aggregate results from multiple sites.
As BITNET had grown, the design of RSCS began to contribute to difficult in scaling. The
increasing reliance of mail had continued to overburden the well-connected sites. Princeton
University designed an overlay so that RSCS traffic could be encapsulated on the Internet, using
IBM’s VM TCP/IP product. This “BITNET2” protocol114 by Peter Olenick in 1989 allowed
transparent encapsulation of the RSCS data:
VMNET is the name applied to the collection of programs which execute in a VM service
machine and provide the encapsulation of RSCS virtual channel-to-channel (CTC) data into
TCP buffers. The data blocks constructed by VMNET are passed to the TCP/IP VM
service machine via standard interface calls. The TCP/IP service machine will transport the
data via the IP network to the recipient VMNET.
A new version of RELAY was also deployed in 1989, written by Valdis Kletnieks of Virginia
Tech.
In writing about the number of deployed servers, Valdis notes: 115
… On the order of 20 or so servers, of which 12 to 15 were actually reliable. The code I wrote
was in Pascal, so it was stuck with fixed-sized arrays, so it was nailed to 300 or so simultaneous
users. I think the peak actual usage was pushing 200 or so - much higher than that, and the way
RSCS scheduled interactive messages meant that things got pear-shaped really fast.
The rewrite to handle the load was significant:
A very few sites got Pascal copies in early 1989, when I still worked at Clarkson. A bunch more
installed it after I moved to Virginia Tech in May 89. Quite the Pascal beast - I think the 2,000
lines of Rexx and 750 lines of assembler that were in V1 turned into about 11,000 lines of Pascal
and 1,500 lines of assembler (of which some 750 was system-interface stuff like IUCV message
trapping and the like, and the rest was various utility routines …
Kell, Jeff. Relay: Past, present, and future. 1987 Spring Netcon, New Orleans.
http://nethistory.dumbentia.com/relayhist.html. Retrieved 1 December 2006.
112
113
Original author unknown, dated 11 February 1986.
Olenick, Peter. Definition of the BITNETII Protocol. A technical overview of VMNET. BITNET
Network Working Group. RFC 0002. April 1989.
http://www.nic.funet.fi/pub/netinfo/CREN/brfc0002.text. Retrieved 6 December 2006.
114
115
Kletnieks, Valdis. Personal communication. 6 December 2006.
35
Since development tools in the mainframe community often used commercial licensing, the legal
dependences also impacted development:
Probably would have been bout 7,000 lines of C and 500 lines of assembler, and I was better at C
than Pascal, but there were licensing issues - I could ship a MODULE that contained statically
linked Pascal/VS runtime code, but I couldn't find a C compiler for VM that I could ship
runtime without paying extra.
Internet Relay Chat
Internet Relay Chat (IRC for short) first appeared in 1988 as a chat system for the Internet
proper. Somewhat surprisingly, this was an area where the technology which enabled IBM VM
systems (with origins in the late 1960’s), had given BITNET users an advantage over the
increasingly sophisticated Internet.
Written by Jarkko Oikarinen, IRC quickly grew to support hundreds of “channels” on various
topics. IRC quickly spread to servers throughout the world. Built as a distributed system, it did
not fall victim to the inefficiencies of BITNET’s chat system and underlying network.
IRC clients are available for all types of operating systems, and the command language is
straightforward enough to not require complex interfaces (in fact, most clients still use a
traditional text model). IRC was later codified in an Internet Request for Comment (RFC) as
1459, in May of 1993. 116
Electronic Mail and notification
An interesting feature which was never implemented or deployed on the Internet was part of the
Simple Mail Transfer Protocol (SMTP), documented as RFC 821 117 in August of 1982. SMTP
is the standard mechanism by which mail is delivered between systems. The SEND, SOML
(Send Or MaiL) and SAML (Send And MaiL) commands in the protocol were designed to send a
message directly to the users terminal -- much like an interactive message.
File Transfer and notification
As with the SMTP protocol (above), the File Transfer Protocol (FTP)118, also contained several
directives such as MSND (Mail SeNd to Terminal), which would display received data directly
Oikarinen, J., Reed, D. RFC 1459. Internet Relay Chat Protocol.
http://www.faqs.org/rfcs/rfc1459.html. Retrieved 5 December 2006.
116
Postel, Jonathan B. Simple Mail Transfer Protocol. RFC 821. August 1982.
http://www.ietf.org/rfc/rfc0821.txt. Retrieved 1 December 2006.
117
Postel, J. File Transfer Protocol. RFC 765. June 1980. p. 26. http://www.faqs.org/rfcs/rfc765.html.
Retrieved 1 December 2006.
118
36
on a users terminal; the XSEN FTP119 extension was also designed to send a message directly to
a user’s terminal. Neither was ever implemented (to the best of the author’s knowledge).
Social influences of computer communication
The history of tool development is often significantly influenced by the needs of those designing
systems. Particularly in the software development environment, efficiency can be realized by
adding some form rapid communication. Messaging and mail are easy ways for programmers in
particular to communicate – there is no disruption of the “rhythm” of coding in using the same
terminal session; for most, this is a far superior alternative to placing a phone call, which requires
mental task switching.
In the early days of time-sharing, terminals (often Flexowriters or Teletypes) were not
widespread, and much like the original days of sharing space around a keypunch, programming
was often still somewhat of a group activity:
In 1965, outside the system programming groups, only a few department heads had their own
terminal; most computer usage was done in terminal rooms with an instant community of
neighbors. Instant messaging and mail became important only when people were not face-toface. 120 – Tom Van Vleck
With the advent of networking and greater availability of terminals, messaging fulfilled an
important role in personal communication. At the time, the Bell System still had a monopoly on
voice calls, and most organizations closely tracked costs of telephone usage. Messaging would
thus fulfill a unique role in both enabling rapid exchange of information, as well as at a
marginally “free” cost, as the price of terminal connections had already been budgeted.
When the system programmers then began work on the Multics project, using CTSS as a tool,
they used both mail and messaging. This was especially useful for coordination between the Bell
Labs users in New Jersey and the MIT and GE programmers in Cambridge 121. – Tom Van
Vleck
Harrenstein, K. FTP Extension: XSEN. RFC 737. 31 October 1977.
http://www.apps.ietf.org/rfc/rfc737.html. Retrieved 6 December 2006.
119
120
Van Vleck, Tom. Personal communication. 1 December 2006.
121
Van Vleck, Tom.
37
Despite the immediate benefit of these tools, development environments were not at liberty to
treat systems as though they incurred no cost. It was not until the PDP-11 and availability of
lower cost department systems that accounting for computer time was seen as perhaps needless
overhead. Tom Van Vleck cites the work on CTSS: 122.
The idea of using system resources for personal communication encountered substantial
resistance. The time-sharing systems were much in demand and CPU, disk, and connection
resources were scarce. Funding came from agencies that had no sense of humor. Use of these
precious machines for personal convenience or entertainment was viewed as selfish and wasteful.
But everyone did it; the possibilities were too seductive, the pleasure in making a clever
convenience too great. … MAIL and messaging may have been documented and justified by
their use for projects and communication between system management and users, but they took
hold and spread because people found uses for them in their daily lives
David Tuttle of IBM wrote concerning the use of messaging:123
As to the 'social' aspects of messaging, it's hard to remember a time when inter-user messaging of
some kind was _not_ available. I joined the CSC Computer Graphics group in October 1968, …
The need for and benefit of communication between "computer people" was taken for granted
very early. The limiting factor in most cases was technology. I happened to be in the consultants'
room across the hall from the CTSS 7094 system in 1967 when the first successful trans-Atlantic
terminal session was established from England. In early 1969 at CSC, people at all of the
Scientific Centers (Los Angeles, Palo Alto, Houston, Grenoble) and several other IBM locations
(Time-Life and Yorktown Research) collaborated in what would now be called an "Amber Alert",
using a purpose-built database on the CP-67 machine in Cambridge. Engineers found a way
(and/or made a way) to talk and to exchange data…
Dan Murphy provided personal observations on developing TENEX while at BBN: 124
Supporting a collaborative environment of the kind that existed at BBN in the late 60's was
certainly a focus of our design efforts, and 'timesharing' turned out to provide a lot of
collaborative advantages besides just letting multiple people share use of a big, expensive
computer.
Most programmers know the value of collaboration in what may be an otherwise private and
intellectual profession. The ability to interact with others rapidly to exchange ideas becomes an
immensely valuable tool, particularly in situations requiring immediate action, such as when a
system or application is not functioning.
As computing moved from technical environments to offices, and ultimately, home use, the
desire to use systems in communications grew. Earlier research by Murray Turoff and Roxanne
122
Van Vleck, Tom. Personal communication. 1 December 2006.
123
Tuttle, David. Personal communication. 2 December 2006.
124
Murphy, Dan. Personal communication. 6 December 2006.
38
Hiltz on the Electronic Information Exchange System (EIES) at the New Jersey Institute of
Technology, showed the rapid acceptance of computers as a tool, particularly in collaboration.
The EIES system used various functions to enable group work: conferences, notebooks, voting,
mail, and messaging. While the various components of the system could be used individually,
they were designed to be used as together, each tool building on its strengths while
complementing the others. Users could build innovative environments using the tools with
relative ease. Customization of the system, as well as automation, was possible with the built-in
language, Interact.
Experiences at other systems emphasizing joint work, such as PLATO at University of Illinois,
and CONFER at University of Michigan, showed much of the same results and benefits from
interactive environments.
Ray Ozzie, who had worked on the PLATO system at Illinois, ultimately used many of these
concepts in the design of Lotus Notes, with great success.
Commercial growth
Before direct access to the Internet was possible for the consumer, maybe home users first
experienced access to online services through commercial services. Two of the largest,
Compuserve and America Online, enabled access through a client program for personal
computers, which integrated not only communications to the company’s servers but a graphical
interface.
These systems offered many of the functions available on conferencing systems (such as EIES),
albeit in a much easier and less feature-rich environment.
Bulletin Board Systems (BBS)
Prior to the emergence of large commercial services, many privately operated home systems
maintained dial-in modems for open access. Some of these BBS systems had a “chat room” type
functionality.
39
Built-in chat room functionality
Both Compuserve and America Online feature messaging capabilities, both inter-user as well as
“chat room” functionality.
COMPUSERVE Forum (“CB simulator”)
Compuserve ‘s version of a chat room came to be known as a “CB simulator”, (after the once
popular Citizens Band radio). First released in 1980, it became incredibly popular despite the
immature state of the PC industry at the time.
America Online – People connection
AOL maintained its own chat rooms under the name “People Connection”. It remained one of
the most popular areas of the service, even as the company subscriber count grew to nearly 30
million customers. Increasingly it became more and more complex to locate the right “room”
from an ever-growing list available to choose from.
Despite this, it remained one of the most widely used areas of the entire service, and received
attention by the system staff to ensure adequate system resources were available.125.
Direct messaging
Almost all timesharing systems use a login table of some sort, and thus users have a method to
query who is logged-on to the system at any given time. For example, on Unix systems, the
command “who” will list logged-on users. Remote systems can also be queried (although this is
allowed based on policy), and the Unix utility “finger” (named loosely on the old Yellow Pages
jingle “Let your fingers do the walking”) provided that service.
America Online
AOL included messaging between users from nearly the company’s inception, as part of its
standard PC software. Unfortunately, it initially suffered from the lack of a presence engine –
there was no simple way to determine if friends who you would like to chat with were online. For
125
Author’s personal experience as Director of Network Operations, 1993-97.
40
users coming from experience with a computer operating system (and the “who” type command),
this would have seemed a glaring omission.
America Online – Buddy Lists
In the fall of 1995, Barry Appelman, then Vice President of Advanced Technology (who had
come to AOL from IBM Research in Yorktown, NY), designed what became the “Buddy List”
application. Steve Williams was hired on a contract basis to write the software. Steve noted in
mail: 126
I started in May of 1995 I believe, and Buddylist was the first thing I was put to work on. It was
an idea of Barry's to build something into the system that was better than the client programs that
people were starting to build that polled the system constantly. There were some really vague
ideas about having up to 10 categories, only one of which would be active at a time. I rewrote
most of the early requirements to pretty much what it became, basically because I thought it
should work that way. I added the '*', the sounds, and the (n/m) notation.
I know that shortly after it was publicly live, it was adding users at a rate of more than 10 per
second during peak. I also calculated, in the fall a couple months before AOL went flat rate, that
the extra time that people were staying online to chat with each other was making AOL an
additional $1 million in usage charges every 3 days.
Buddy List quickly became one of the most used applications on the service, and was quickly
imitated by competitors.
Instant Messenger / Apple iChat
In May of 1997, AOL released standalone client software to allow access to its messaging system.
For the first time, users did not need the full America Online client in order to send messages to
another AOL subscriber. Surprisingly quickly, the AOL message client, then branded “AOL
Instant Messenger” (AIM) appeared on workplace computers, in universities, and other locations.
The company then made a decision to allow anyone, whether a paying AOL subscriber or not,
to acquire a “Screen Name” to login, and usage soared.
With the release of Apple’s OS X operating system, a client known as Apple iChat was built-in to
the operating system, which utilizes AOL’s messaging infrastructure.
126
Williams, Stephen D. Personal communication. 3 December 2006.
41
Other messaging clients
The market for messaging tools matured very quickly, with clients from Microsoft (MSN
Messenger), Yahoo (Messenger), ICQ (literally, “I seek you”), and more. Unfortunately, the
systems were proprietary and did not interconnect in any way.
An open source client – Jabber – supports the open XMPP127 standard.
Mobile communications
Short Message Service (SMS)
The concept of sending messages directly to mobile devices originated with the European GSM
standards group as early as 1985, with first implementation in 1992. Despite an initial slow usage
pattern, sending messages from one mobile device to another has become commonplace. GSM
World writes: 128
It is estimated that a worldwide total of 1 trillion text messages were sent in 2005.
There is a unique set of social dynamics using SMS, since not only is the user in instant
communication, but they are mobile while engaging in it. The user may be mobile in the locality
sense (away from home, traveling), but also in the literal sense (while driving an automobile).
These factors have led to new concerns in how communications devices are used, in the context
of socially acceptable (as in restaurants) to safety (attempting to send a text message while
driving).
Devices which have functionality in addition to phone usage even have spawned their own
terminology, such as “Blackberry thumbs”, for overuse injuries associated with that popular
device.
Extensible Messaging and Presence Protocol. Wikipedia.
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol. Retrieved 1 December
2006.
127
128
GSM World. http://www.gsmworld.com/services/messaging.shtml. Retrieved 6 December 2006.
42
Multimedia Message Service (MMS)
MMS, a superset of the SMS protocol, supports attachments such as photos, audio files, and
other multimedia content. This is bringing a whole new set of capabilities to mobile devices, and
is driving manufacturers to include increasingly advanced features (often at lower costs as well).
43
44
Conclusion
The development of messaging utilities have been influenced by several factors:
•
The physical proximity of development activity played a key role in sharing of ideas.
Particularly, the multiple projects which originated or were related to activity at MIT’s
Tech Square all benefited from a strong talent pool of research and technical staff.
•
The mobility of talent played a role in ensuring ideas moved quickly into new systems.
Some examples:
Dennis Ritchie -> Bell Labs (Multics) -> Bell Labs (Unix)
Ken Thompson -> Berkeley (SDS)-> Bell Labs (Unix)
(SDS project OS influences) -> BBN Tenex
Tom Van Vleck, Bob Frankston (CTSS) -> Multics
Dan Murphy -> BBN -> DEC
•
Perhaps by the non-commercial nature of the Cambridge environs, good ideas spread
quickly, unbounded by commercial concerns:
Remember that in those happy days there was less concern over intellectual property. If
operating system A had a feature, the users of system B would ask "why can't we have
that too?" and the system programmers would add it. Mail and messaging were such
memes. 129 -- Tom Van Vleck
•
Most of the great ideas have originated in research (not commercial) settings:
CTSS, Multics (MIT), Unix (Bell Labs), TENEX (BBN was doing a great deal of
government research), SDS 940 (Berkeley), PLATO (Illinois).
Only the Q32 project was run outside the relaxed corridors of pure research institutions,
and while it had origins in the Air Force, was technically linked to Lincoln Labs -- a
research organization.
Important systems from the development of time-sharing were researched, to find the earliest
examples of various types of communications: MIT CTSS with local messaging (1965),
SDS/Berkeley 940 with linked terminals (1965), BBN TENEX with remote messaging (1972?),
and U. Illinois PLATO with multi-user chat (Fall, 1973).
The usefulness of the communication tool is directly correlated to the ease of use. Although
difficult to quantify how easy the messaging tools in operating systems were, we can assume that
given the background of the community, any obstacles were quickly overcome.
129
Van Vleck, Tom. Personal communication. 3 December 2006.
45
In the growth of BITNET, it became evident that one valuable type of communication should
not override the capability of another. The ease of use of messaging in BITNET may have
helped lead to its premature demise. In the case of transport, the underlying RSCS protocol
hindered the effective functionality of mail, due to the built-in metric to prioritize messages over
other traffic. Even though systems such as RELAY were ultimately optimized to reduce the
imbalance, the topological inconsistencies of the network forced major corrective action such as
development of the BITNET2 transport. In only a five-year period, the overall utility of the
network diminished to the point where continued participation seemed unjustified to many
institutions.
As tools such as direct messaging moved into the commercial domain, the inclusion of a
graphical front end (as with the America Online client) proved critical to adoption and ongoing
use. Likewise, to grow the overall utility of the network, the widespread availability of an
interface with limited barriers to initial use is critical. In the case of AOL, AIM clients were
written for all types of operating systems.
The decision by the GSM standards body to settle quickly on a set of protocols to support SMS
led to its widespread use throughout Europe, where interfacing between systems is often key to
success. It is a plausible argument that the use of multiple competing standards in the United
States, with limited interoperability, has led to the slow growth in SMS usage.
Despite the origin of messaging in operating system research, the immediacy and utility of instant
messaging holds ongoing value. Messaging technology is one principle component in the
formation of productive collaborative environments, and helps build a true sense of
community130.
It is especially interesting, that over 40 years since Tom Van Vleck and colleagues at MIT sent
the first inter-terminal message, the technology looks much the same as it did then. This is a
testament to the foresight of the design, and should encourage researchers to improve these
systems, to help build the next generation of personal communication tools.
130
Hiltz, Starr Roxanne and Murray Turoff. The Network Nation. 2d Ed. MIT Press. 1993. p. 426.
46
About the contributors
Peter Deutsch and Butler Lampson designed and implemented the SDS 940 system at the
University of California at Berkeley.
Bob Frankston and Tom Van Vleck designed and implemented early work on the CTSS and
MULTICS efforts at MIT.
Valdis Kletnieks is a Computer Systems Senior Engineer at Virginia Tech and the author of
BITNET RELAY version 2.
Sidney Marshall was a principal developer on the Dartmouth Time Sharing System (DTSS).
Dan Murphy was the lead designer of the TENEX operating system at BBN and continued work
at DEC on the TOPS-20 operating system.
Randi Robinson was a systems programmer at the City University of New York responsible for
BITNET operations.
David Tuttle and Lynn Wheeler were two of the principals in design and implementation of the
CP component of what evolved into the IBM VM operating system.
Melinda Varian is formerly with Princeton University as leader of the VM systems group. She is
a long time contributor to SHARE and VM Workshop on the topic of VM and its history.
A. Harry Williams is Director of Technology & Systems at Marist College and long time
coordinator of VM Workshop.
Stephen D. Williams was a contract programmer at America Online in the fall of 1995. He was
the author of what became the “Buddy List” software.
I am deeply grateful to all of those who took the time to respond to my questions, often at great
length and in considerable detail. Any errors in using the information supplied by them are mine
alone.
47
Appendix A. MIT CTSS “WRITE” command
48
Appendix B. Manual page for IBM CP-67 MSG command
CP-67 Release 3 Program Logic Manual, p. 108
Courtesy of Lynn Wheeler
49
Appendix C. DEC TOPS-20 “talk” command 131
2-414
COMMAND DESCRIPTION
(TALK)
2.78
TALK
Allows you to converse with other users
terminals.
on
your
system
by
linking
Format
TALK
argument
@TALK (TO) argument
where:
argument
is a user name or terminal line number.
Characteristics
Typing TALK Conversation
During a TALK session, you must tell the system to regard
your
conversation as comments.
Otherwise, the system
interprets your input as attempts to give EXEC commands and
responds with the message ?Unrecognized command. To signal
your input as comments, begin each line with the exclamation
point (!) or semicolon (;) comment character. Or, if your
comment is several lines long, use the REMARK command.
Other Job Not Affected
As soon as you give a successful TALK command, both
terminals begin printing both users' input as well as the
system's responses to that input. Each job, however, will
receive input from its own terminal only.
Ending TALK
To end a conversation link between
can give the BREAK command.
terminals,
either
user
Refused TALK
Terminals can be set to refuse links with other terminals
with the REFUSE LINKS or TERMINAL INHIBIT command. If you
attempt to TALK to a user who has refused links from another
DEC TOPS-20 Commands Reference Manual. July 1990. Section 2.78, p. 2-414.
http://zane.brouhaha.com/~healyzh/tops20_7/COMMANDS.MEM.txt Retrieved 1 December 2006.
131
50
terminal, the system rings the bells on both terminals six
times, and then prints the message, ?Refused, Send mail to
user
instead.
If the user has refused all terminal
communication with the TERMINAL INHIBIT command, the system
does not ring the bell on his terminal.
If you have Wheel or Operator capabilities enabled, you
2-415
51
can
COMMAND DESCRIPTION
(TALK)
TALK to any user who has given the REFUSE LINKS command, but
not the TERMINAL INHIBIT command.
Maximum of Four Terminals
By using TALK commands, you can link up to four terminals at
once.
For all terminals to share the same display, each
pair of terminals must establish a link.
For example, if
terminal A is linked to B and C, terminals B and C will
display only A's input. B and C must establish a link to
display each other's input.
Hints
Signaling a Linked User
Once you have established links with another user's terminal
via the TALK command, you can get his attention by typing a
series of CTRL/Gs. Depending on the kind of terminal he
has,
these
will
be reproduced as ringing bells or
high-pitched beeps. This action can be especially useful
when
establishing links with the owner of a display
terminal, as display terminals are silent in ordinary
operation.
Special Cases
User Has More Than One Job
If more than one job is logged in under the user name you
specify, the system responds with a list of that user's
terminal line numbers and the programs being run. Type your
choice of terminal line number (if available, the one
running the EXEC) after the TTY: prompt.
Talking to a Batch Job or PTYCON Job
When you link to a PTY (pseudo-terminal) to talk to the
owner of a batch job or PTYCON job, the system informs you
of this with a message, to which you must reply with a
carriage return to confirm the link. To decline the link,
give a CTRL/C. See also Warning, Talking to a Batch Job,
below.
2-416
52
COMMAND DESCRIPTION
(TALK)
Warning
Talking to a Batch Job
Use
caution
when
communicating
through
a
PTY
(pseudo-terminal) that is controlling a batch job: do not
send a question mark (?) or percent sign (%), because these
characters can be attributed to errors occurring within the
job. Also, if an error actually does occur in the batch job
and the batch system's question mark is displaced (by your
remarks) from the beginning of a line, the system may not
recognize it as an error.
Talking Between a VT100 and a VT52
If links between VT100 and VT52 terminals are established
using a TALK (or ADVISE) command, the VT52 may function
improperly during or after the linked interval (such as by
requiring frequent CTRL/Q commands to print multiple lines
of output). Turning the terminal off and then on again
(after the linked interval) will correct this problem.
Related Commands
ADVISE
for sending commands to another user's job
BREAK
for ending communications
your terminal
RECEIVE LINKS
for allowing other users to talk to you
REFUSE LINKS
for preventing other users
you
REMARK
for telling the system to
terminal input as comment only
SEND
for sending
terminal
TERMINAL INHIBIT
for
refusing
all
types
of
terminal
communication including advice, links, system
messages, user messages, and notices of new
mail.
a
message
links
to
from
involving
talking
regard
to
another
your
user's
Examples
1.
Give the TALK command to establish links to another user.
2-417
53
COMMAND DESCRIPTION
(TALK)
____ ________
@TALK H.DAVIES
|
[Link from LATTA, TTY 230]
2.
Try to talk to a user who has given the REFUSE LINKS command,
then use the MAIL program to send your message.
____ ________
@TALK GEBHARDT
?Refused, send mail to user instead
____
@MAIL
________
To: GEBHARDT
_____
CC: LATTA
_____
Subject: HUNCH
.
.
.
|
3.
Talk to another user, giving the
after TALK.
(The other user's
by semicolons (;) or exclamation
to end REMARK before typing
conversation.
REMARK command immediately
reply must still be preceded
marks (!).) Give a CTRL/Z
the BREAK command to end the
____ ________
@TALK CARNAVON
|
[Link from LATTA, TTY 230]
______
@REMARK
Type remark. End with CTRL/Z.
_____ __ _ ___ _______ _______ _____ __________ ___ _____
WHERE DO I PUT "REQMD" RECORDS AFTER EXTRACTING THE ID'S?
@;in <accts>deft-77.cbl
@;you should have group access there...
______
THANKS
__
^Z
_____
@BREAK
4.
Give the TALK command to establish links to a user who has 3
jobs
on three different terminals; choose one of the
terminals running the TOPS-20 command processor.
____ _____
54
@TALK MCKAY
TTY19, DUMPER
TTY26, EXEC
TTY27, EXEC
__
TTY: 27
|
[Link from LATTA, TTY 230]
55
Appendix D. Xerox SDS 940 Link command
Scientific Data Systems. Reference Manual. SDS 940 Terminal User’s Guide. April 1968. p.
15. http://bitsavers.org/pdf/sds/9xx/940/901118B_940_TerminalUsersGuide_Apr68.pdf.
56
Appendix E. Experiences running the CUNYVM
mail relay on BITNET, 1984-1989
Randi Robinson
6 December 2006
These days, the concept of sending files across the internet is simple. Most people will simply
attach a file or files to a piece of email.
On BITNET things were done differently. Email didn’t HAVE attachments. We didn’t even
really call it “email” at that time. It was just “mail”. Any file you wanted to send to someone
was SPOOLED to them. On the IBM system, we SPOOLed our virtual “punch” (from punch
cards) or “print” to the RSCS virtual machine. Then we TAGged the file for whatever
userid@node we wanted it to go. Then we PUNCHed or PRINTed the file. That created a
copy of the file, sent it to the RSCS virtual machine and off it would go to follow the appropriate
“links” to reach it’s destination.
RSCS used routing tables that were generated by a single person at the time. We would get our
new monthly routing table, put it in the configuration file and restart the machine.
A routing table was created for every node on BITNET and it contained the names of every
node on BITNET. Each RSCS virtual machine had to know the next “hop” each file had to
take to reach it’s destination. That means one line in the routing table for each node that existed
on the network. Now, these were not IP addresses – it was all ENGLISH.
Now all this means that files and mail usually passed through multiple locations between
origination and destination. Each node on the network had a phone line to each node to which
it connected. A link between nodes could fail at any time: phone lines, modems, CSU/DSUs,
mainframes could all have problems. The RSCS person could be on vacation or out sick and
there’d be no one to watch the links. When one of our outbound links would go down it might
just come back up or might need to be manually restarted. I might have to call the RSCS
contact on the other end to see if they were having problems. If they weren’t having a specific
computer-related problem, the issue would get handed off to the telecommunications folks. They
would do all physical checking and call the line provider if necessary.
Any time a link was down, spool files would still be coming in and going out other links. Certain
sites carried more traffic than others – our link to France, for instance. For some time it carried
all the traffic for Europe.
Now, when an RSCS machine (or machines) had too many spool files sitting queued up on links
the entire system would start slowing down. Equivalently, if an issue was on the other side of our
link, our spool files would build up – fast. Performance would start being compromised and,
being a university, this would result in lots of complaints – also fast.
57
The files would have to be removed from the offending link or links. The process involved
getting a list of the spool file IDs for RSCS, sorting them by link, mounting a tape on a drive and
then writing all those files to tape. File size also played an important part – a large file could
cause quite a backlog behind it.
When files were offloaded to tape, system performance would be restored, at least temporarily.
Sometimes I’d have reels upon reels of tapes loaded with files that needed to be restored and sent
as soon as possible. Unfortunately, if the recipient of the file didn’t get it right away, the sender
would often keep sending copies. Impatient users would often call the helpdesk complaining and
the process would have to be explained. Most understood and would be patient.
I spent many a long night in my office babysitting those RSCS links and files. Feeding the files
back onto the system in batches a few thousand at a time.
The very worst episode of this was when our link to France went down. Every European and
Asian destination went across that single connection. This single connection was then via a
transatlantic cable. The link was often down for one reason or another – sometimes taken down
deliberately so they would receive no files while their system was trying to catch up sending files
out their other links! (This point of contention was eventually resolved.)
Now this time the link was down for technical reasons. We were told a shark had chewed
through the cable! While service was restored some weeks later, I still had a growing pile of tapes
filled with spool files just waiting to be loaded back and sent. Many phone calls including some
language difficulties were made. After much wrangling, the “who pays for what” details were
worked out. I then was asked to NOT send certain files – mostly the older ones. More work –
loading the files, purging those specified, dumping them back to tape. This was to result in fewer
tapes being sent. Eventually, three copy-paper boxes loaded with tapes containing several
hundred thousand files were sent.
The story was not over, however. There was still assistance to be rendered my counterpart to
make sure the files could be properly restored. Creating duplicate RSCS virtual machines with
special routing table and the like.
Eventually tape reels became tape cartridges, line speeds increased, traffic analyzed,
redundancies added. Princeton was a driving force in adding TCP/IP support to RSCS,
allowing multiple streams of data on a single link.
58
Appendix F. IBM VM SPecial Message (SPM)
(SPM, or “SPecial Message) across the network was written at the IBM Pisa (Italy) Science
Center. It was distributed on 12 August 1975 and included with VM Release 2, although a
version had originally been distributed as part of RSCS (as PRPQ for IBM’s VNET network)
The SPecial Message command to allow IBM virtual machines to communicate, in place of the
standard IUCV/VMCF mechanism, was written by Marty Shapiro from the IBM Pisa (Italy)
Science Center. This message originally appeared in alt.folklore.computers on 24 May 2006
from Lynn Wheeler as http://www.garlic.com/~lynn/2006k.html#51
To: wheeler
Date: 17 October 1985, 17:35:59 PDT
Yeah, you should!!!!!
Some facts about SPM.
Original version was written by xxxxx of IBM Pisa Scientific center
for CP-67. I installed his code in Poughkeepsie and, when TDC
converted to VM/370 Release 2, I re-wrote the entire function, using
the CP-67 code as a guide. Some stuff I kept the same, others I
redesigned.
I then gave this code to you, as xxxx was the one who had given me
some good feedback in the design. (In fact, it was through SPM that I
got to meet you originally.) It was at this time that xxxxx and xxxxx
added SPM support to the internal version of RSCS (which eventually
was released as the VNET PRPQ). In fact, the VNET PRPQ had, as
shipped to customers, all the SPM support. They just didn't get the
documentation and the CP updates to support it.
While VM development was still in Burlington, Mass., I shipped a copy
of the documentation for SPM (and possibly the code, but I don't
remember) to xxxxx, who tried to interest the product group in it. At
that time, the product group saw no value to the function in CP.
Virtual machines could communicate through virtual CTCAs and/or the
spool file system!
Also, although the product group has at least once that I'm aware of
disclaimed any knowledge of such a function, I did publish a
Poughkeepsie Lab Technical Report (TR 00.2701) in 1975 documenting
this facility.
My first "release of SPM" was on 8/12/75 to the following people:
1. Lynn Wheeler, Cambridge Scientific Center, Cambridge, Mass.
59
2. xxxx, RTP, Raleigh, North Carolina
3. xxxx, Palo Alto, California
4. xxxx, Washington Ed Center, Washington, DC.
5. xxxxx, GPD, Westlake, California
Subsequent releases were as follows:
08/21/75 6. xxxxx, RTP, Raleigh, North Carolina
09/18/75 7. xxxxx, Kingston, New York
09/26/75 8. xxxxx, Boulder, Colorado
10/27/75 9. xxxxx, Lyngby, Denmark
10/xx/75 10. xxxxx, Sindelfingen, Germany
11/xx/75 11. xxxxx, WTSC, Poughkeepsie, New York
11/xx/75 12. xxxxx, Boeblingen, Germany
03/15/76 13. xxxxx, Tel Aviv, Israel
03/17/76 14. xxxxx, Kingston, New York (Common System)
03/17/76 15. xxxxx, Vancouver, British Columbia, Canada
03/17/76 16. xxxxx, Paris, France
04/21/76 17. xxxxx, Uithoorn, Netherlands
05/10/76 18. xxxxx, Zurich, Switzerland
04/30/76 19. xxxxx, Los Angeles Scientific Center, Los Angeles, Ca.
03/xx/77 20. xxxxx, WTSC, Poughkeepsie, New York
03/xx/77 21. xxxxx, TOROLAB.
07/xx/77 22. xxxxx, Syndey, NSW, Australia
07/xx/77 23. xxxxx, Chicago, Illinois
02/22/78 24. xxxxx, San Francisco, California
02/23/78 25. xxxxx, Los Angeles, California
04/05/78 26. xxxxx, Sudbury, United Kingdom
05/24/79 27. xxxxx, Toronto, Ontario, Canada
The last distribution I did was for VM/370 Release 6 and there were
about 25 people on the distribution list. This was sometime in 1980.
SPM was mentioned in the second VM Newsletter published by xxxxx.
The combination of VMCF, SMSG, and extended diagnose code 8 provide
all functions of SPM EXCEPT the implicit message capability (this was
the ability to trap a CP message as a special message). Although the
initial version of IUCV did NOT supply this facility, IUCV was
enhanced (VM/SP R2 I think) to add this capability, giving the
product, after about 8 years, the functional equivalent of the SPM
facility to which they saw no value in the CP product.
Ever since the introduction of VM/SP, xxxxx of the Cambridge
Scientific Center, Cambridge, Massachusetts has supported these
modifications for a vanilla system. Kingston Common has also
continued to supply SPM with their system.
Since the product now finally offers the equivalent function, I have
recommended that SPM be removed. xxxxxx has no plans to convert this
function to SP/R4, Kingston Common plans to remove it when they go to
60
SP/R4, and I am in the process of removing it from the HONE systems.
I still think that the SPM concept is far superior to the approach
used by VMCF and IUCV in that the hypervisor has no business being
involved with the protocol of inter-virtual machine communication.
All the hypervisor should do is deliver the requested data to a
receiver who has informed the hypervisor that he is willing to receive
this type of communication. I am glad that so many people have been
able to profitably use code which I helped to create, but I really
doubt if I will ever make such an effort again….
61
Appendix G
Transcript of consoles showing use of Q32 DIAL command
Linde, R. L. and Chaney, P. E. 1966. Operational management of time-sharing systems. In
Proceedings of the 1966 21st National Conference ACM Press, New York, NY, 149-159. DOI=
http://doi.acm.org/10.1145/800256.810691
$TINE SHARING SYSTEM ON THE AIR
LOGIN 10335 JG025
$OK LOG ON 16
DRUMS
$4324 DRUM WDS,
DIAL 9 THIS IS JOHN JONES, I NEED 20H IN ORDER TO LOAD MY PROG,
$MSG IN
FROM 9 WE CAN GET YOU ON IN 5 MINUTES,
FROM 9 GO AHEAD AND LOAD,
LOAD ALPHA1
$LOAD OK
(CHANNEL 9'S TELETYPE COPY - THE OPERATOR'S TELETYPE)
$TIME SHARING SYSTEM ON THE AIR
LOGIN S762 JG025 MANAGR (LOAD REOUEST FOR MANAGER PROGRAM)
$LOAD OK
GO (OPERATOR TYPES 'GO' TO START pROGRAM)
ENTER SCOPE NO- 6 (PROG, OUERIES OPERATOR FOR SCOPE NO.)
AM,20 (REOUESTS MANAGER PROG, TO UPDATE SCOPE EVERY 20 SEC.)
FROM 16 THIS IS JOHN JONES, I NEED 20H IN ORDER TO LOAD MY PROG.
26 (REDUESTS MANAGER PROG. TO GIVE A DETAILED DISPLAY OF CH. 26)
!DIAL 26 CAN YOU FINISH IN 5 MIN. - WE HAVE A HIGH PRIORITY REOUEST,
$MSG IN
FROM 26 OK - I'LL FINISH UP IN 5 MINUTES.
DIAL 16 WE CAN GET YOU ON IN 5 MINUTES,
$MSG IN
FROM 26 I'M THROUGH
QT 26 (OPERATOR OUITS CHANNEL 26)
DIAL 16 GO AHEAD AND LOAD.
$MSG IN
62
Appendix H
(Berkeley) Genie Monitor Guide (SDS 940), 8 August 1966
pp. 7-3, 7-4 discussing use of teletypes.
(continued on next page)
63
64