Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Dartmouth Time-Sharing System
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Dartmouth Time-Sharing System, version 2== [[File:Honeywell GE 635 Computer Hardware at Kiewit, from The Kiewit Computing Center and the Dartmouth Time-Sharing System - Dartmouth College, early 1971.jpg|thumb|right|Honeywell GE 635 Computer Hardware architecture at Kiewit, early 1971]] From 1966 to 1968, DTSS was reimplemented on the [[GE 635]],<ref name="computing-at-dartmouth-1960s">{{cite web |url=http://www.dartmouth.edu/comp/about/archive/history/timeline/1960s.html |title=The 1960s |work=Computing at Dartmouth |archive-url=https://web.archive.org/web/20150425065704/http://www.dartmouth.edu/comp/about/archive/history/timeline/1960s.html |archive-date=2015-04-25 |url-status=dead}}</ref> still using the DATANET-30 for terminal control. The GE 635 system was delivered in November 1966. By October 1967, it was providing a service based on Phase I software, jointly developed by Dartmouth and GE, which GE subsequently marketed as the GE Mark II system.<ref name="Bull, page 14"/> In parallel with this work, Dartmouth embarked in 1967 on the development of Phase II under the direction of Professor John Kemeny, with programming carried out by students and faculty. Phase II of the Dartmouth Time-Sharing System replaced Phase I on April 1, 1969, at Dartmouth.<ref name="Bull, page 14"/> As described in 1969, the new DTSS architecture was influenced by three criteria:<ref name=Hargr >{{cite conference |author1=Robert F. Hargraves, Jr |author2=Andrew G. Stephenson |title=Design considerations for an educational timesharing system |conference=AFIPS Spring Joint Computer Conference 1969 |pages=657β664 |doi=10.1145/1476793.1476904}}</ref> * The experiences with the 265 system. * The published concepts of the [[Multics]] system. * A realization of the limitations of the capabilities of a part-time staff of Dartmouth students and faculty members. This new version was completely different internally from the earlier DTSS, but provided a near-identical user interface to enable a smooth transition for users and course materials. The 635 version provided interactive time-sharing to up to nearly 300 simultaneous users in the 1970s, a very large number at the time, and operated at eleven commercial and academic sites in the US, Canada and Europe.<ref>Bull, page 9</ref> As it evolved in the 1970s, later versions moved to [[Honeywell 6000]] series mainframes (1973) and [[Honeywell 316|Honeywell 716]] communication processors (1974).<ref>Bull, pages 15, 19</ref> In 1976 the GE-635 system was replaced by a Honeywell 66/40A computer. It remained in operation until the end of 1999.<ref>{{cite web |url=http://dtss.dartmouth.edu/timeline.php |title=Timeline - DTSS - Dartmouth Time-Sharing System}}</ref> DTSS, version 2, included a novel form of [[inter-process communication]] called "communication files". They significantly antedated [[Unix]] [[Pipeline (Unix)|pipes]], as design documents put their conceptual origin sometime in 1967,<ref>{{cite web |author=M. Douglas McIlroy |author-link=Douglas McIlroy |title=Communication Files: Interprocess IO before Pipes |website=Dartmouth College |date=February 2017 |url=https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf}}</ref> and were described briefly in a 1969 conference: :A communications file allows two jobs to interact directly without the use of secondary storage. A communications file has one end in each of two jobs. It is the software analog of a channel-to-channel adaptor. This structure allows job-to-job interactions using the same procedures as for more conventional files. The two ends are labeled master end and slave end. A job at the slave end of a communications file cannot easily distinguish this file from a conventional file. Since a job at the master end of a communications file can control and monitor all data transmitted on that file, a master end job can simulate a data file, thereby providing a useful [[debugging]] aid and also providing a convenient mechanism for interfacing running jobs to unexpected data structures.<ref name=Hargr /> Communication files supported read, write and close operations, but also synchronous and asynchronous data transfer, random access, status inquiries, out-of-band signaling, error reporting, and access control, with the precise semantics of each operation determined by the master process. As [[Douglas McIlroy]] notes: "In this, [communication files were] more akin to [[Plan 9 from Bell Labs|Plan 9]]'s [[9P (protocol)|9P protocol]] than to familiar IO."<ref>McIlroy, page 4</ref> A notable application of communication files was in support of multi-user conferences, which behaved somewhat like conference phone calls, and were implemented entirely as user-space application programs.<ref>{{cite journal |author=John McGeachie |title=Multiple terminals under user program control in a time-sharing environment |journal=[[Communications of the ACM]] |volume=16 |date=1973 |issue=10 |pages=587β590|doi=10.1145/362375.362376 }}</ref>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)