Online_Team_Environment_Jun72 Online Team Environment Jun72

Online_Team_Environment_Jun72 Online_Team_Environment_Jun72

User Manual: Online_Team_Environment_Jun72

Open the PDF directly: View PDF .
Page Count: 274

Download
Open PDF In Browser	View PDF

RADC-TR-72-232
Final Report
8 June 1972
SR I Project 8457

ONLINE TEAM ENVIRONMENT
Network Information Center and
Computer Augmented Team Interaction

Augmentation Research Center
STANFORD RESEARCH INSTITUTE
MENLO PARK, CA. 94025

Sponsored by

Defense Advanced Research Projects Agency
ARPA ORDER NO. 967

Approved for publ ic release;
distribution unlimited.

The views and conc lusions contained in this document are those of the authors and
should not be interpreted as necessari Iy represent ing the official pol icies. ei lher
expressed pr implied. of t.he Defense Advanced Research Projects Agency or the U. ~;.
Government.

Rome Air Development Center
AIR FORCE SYSTEMS COMMAND
GRIFFISS AIR FORCE BASE, NEW YORK

Do not return this copy.

Retain or destroy.

ONLINE TEAM ENVIRONMENT
Network Information Center and
Computer Augmented Team Interaction

Con t r act 0 r: Stanford Research Institute
Con t r act Numb e r : F30602-70-C-02l9
E f f e c t i veDa teo f Con t r act: 8 February 1970
Expiration Dat~e of Contract and Amendments:
Amount of Contract: $2,676,533
Program Code Number: 62706D
SRI Proj ec t Number: 8457
Principal

Investigator:
Phone:

Project Engineer:
Phone:

Douglas C. Engelbart
(415) 326-6200, ext. 2220

Duane L. Stone
(315) 330-3857

Approved for public rele.se;
distribution unlimited.

T.i. re.earc' wa • • upported by the Defen.e
AdvaDced Re.earch Project. A,ency of the
Depart.ent of Defen.e aDd wa. monitored by
D. L. ItoDe, RADC (111M), OAPB, NY 13440
•• der CODtract P30602·70·C·0219.

iii

8 May 1972

PUBLICATION REVIEW
This technical report has been reviewed and is approved.

c#~~
RADC Project Engineer

CREDIT
T •• , •••• 'c. ,.,0".4 •• ,. i.

I., ••••••• , or

T • • • o,k

,.'.0 •• ;

I •• p,od.cl or co.cept •• I. de.i ••• a.d develop.eat work by •
t.e p'o" ••••• be ••• ctive ••• coordi •• ted te •• erfort ai.ce 196'.

"0•• Peb, •• "

1970 to 9 M.y 1972 involved tbe wbole ARC staff:'

•• ,'1, ••. A•• , •• c •• W.II., L .•••••

••• 1 ••••. 0. ••• 1. 00 •• 1•• C. B••• lb.,t.
W.I •••• a .•• , •••••.•••• A. B.' ••••••
•• ,,, • • . • • '4'. I. D••• 4 Bo".,.
C..,I •••.
14,.4 B.
D•••••.
1 D. K•• llck.
L •• 4. L. L•••• B., •• , O. L•• , ••••
00 •• 14 LI •• , •• P,I.cl.l ••. Li.te"
N. Da • • • • ,.,. I ••••• •. No, •• ,
I •••• C. No"o •• C, ••• I. P•• e •
• , ••• L. P., ••• ,. W.III •• B. P ••• o••
C. P.'.". a.I,. P' •••• ',
I ••• a•• IIII. P••• a.c •••• ,b.r. B. ao.,
I.c •••••. V.II ••••4.1. K. v •• D. aiet,
DI, ••.••• No ••• , •• &•••••• B. Victo"
0. •• 14 C. W.II.c •• a.c •• ,d W. W.t.oa,
•• 4 I •••• . . . . il.

I,., .••

&., •.• 'c •••

I.' •••••.

1.",.,

I • • dditio., t.e 'ollo.iD, CODlultantl:
0.. I. A.4' ••••
I •••• A.•• 41 •••

•• d I.e 'ollo.i., 'or •• r ••• b.rl O( tbe sta(r:

a., •• ,

O.olr,., •.•• 11. ao •• , D.
V.,.o. a .••••••••.•• " O. C.ldw.".
ao'.". A. C.,illo •• D.vid O. c •••• , ••.
0. •• 14 Co ••••• " S. C•• 'c •• aob.rl L. Dead,.
Willi •• K. B•• ,i ••. A•• a. O.orr,io ••
J.,.4 B. B."i ••
T. M.lvi ••
•• , ••• E. T, •• d, ••• d
M. Y.,boro •••

'0 •• '0 ••

SRI~ARC

8 JUNE 1972 13041
Abstract

ABSTRACT
1

TIME COVERED
This report covers in deta11 work from FebrUary
1971 to May 1972.
TENEX
Durin« that time our PDP-10 and accompanying
TENEX time-sharing systems became operational.
We have made small adaptations in TENEX and
developed a system that sends an~ retrieves
files from tape archive.
NETWORK INFORMATION CENTER
Use of the Network Information Center has
increased steadily, including regular creation
by experimenters at several sites of
special-purpose documents on our system and
severalfold increase in documents stored and
cataloged. both online and in hard copy
dispersed at the sites. We have prepared and
dispersed manuals and given regular courses in
our system to classes gathered from the Net. In
the last weekS of the contract our display
system ran experimentally from another site for
the first time.
HAHDWARE
We have added a Bryant Drum. Digital EQuipment
Corporation RP02 disc packS, and leased more
30-character-per-second thermal printing
terminals and compatible cassette recorders.
NEW FEATURES IN NLS
To our online system we have adde~:
a command language, DEX, Which allows entrY
of text on tape for later automatic
processing into NLS files;
several features whiCh alloW users to draw on
the power Of NLS more effectively, includ1n~
individual control of a buffer for compiling
various special purpose programs;
cross file editinr to our typewriter-oriented
command langua~e, TNLS, along with other
featUres that suit NLS to typewriter terminal
work; and
to our diSPlay system, the capacity to SPlit
the screen, load several files at once, and
transfer information from one file to
another.
.We have begun the redesign ot NLS in modular

online Team Environment
1

la
lal
lb

lbl
lC

1cl
ld

ldl
le
lel

lela

lelb

lelc

leld

SRI-ARC 8
Abstract

JUN~

1972

units which will, amonr. other things, ease
transfer of all or part of NLS to other systems.
MANAGEMENT SYSTEMS
In management apPlications we developed a first
cut task-and-assi~nment mana~ement
record-keepin~ sYstem, made ever-~rowin~ use of
our dialo~ supoort system in mana~ement, and,
near the end of the contract oeriod. reorganized
our ~roup into operational and project sUbgroups
(a matrix organization) with projects oriented
to~ard needs outside ARC.

online Team Environment
2

13041

le2
1f

lf1

SRI-ARC 8 JUNE 1972 13041
Contents

CONTENTS
statement Number

Content

ARSTRACT ••••••••••••••••••••••••••••••••••••• 1
CONTENTS ••••••••••••••••••••••••••••••••••••• 2
SrMMA~Y •••••••••••••••••••••••••••••••••••••• 3
Introduction •••••••••••••••••••••••••• )a
Highlights of 1970 •••••••••••••••••••• )b
Highlights of 1971 •••••••••••••••••••• 3c
Heferences •••••••••••••••••••••••••••• )d
TEAM AUGMENTATION •••••••••••••••••••••••••••• 4
Journal ••••••••••••••••••••••••••••••• 4a
Handbook •••••••••••••••••••••••••••••• hb
baseline Records System ••••••••••••••• 4c
Basic NLS ••••••••••••••••••••••••••••• 4d
Internal Or~anizat1on ••••••••••••••••• 4e
References •••••••••••••••••••••••••••• 4f
NETWORK INFORMATION CENTER:
DEV~LOPMENT AND OPERATIONS ••••••••••••••••••• S
Introduction •••••••••••••••••••••••••• 5a
The NIC Public •••••••••••••••••••••••• Sb
Present NIC Services •••••••••••••••••• 5c
Relation of the NIC to the AUgmentation
Research Center (AQC) ••••••••••••••••• 5d
Onerations •••••••••••••••••••••••••••• 5e
Online Services ••••••••••••••••••••••• 5!
Offline Services •••••••••••••••••••••• 5g
Experience Using the ARPANET •••••••••• Sh
Conclusion •••••••••••••••••••••••••••• 5i
References •••••••••••••••••••••••••••• Sj
N1TWORK PARTICIPATION •••••••••••••••••••••••• 6
Introduction •••••••••••••••••••••••••• 6a
Protocol D~velopment •••••••••••••••••• 60
Network Coordination •••••••••••••••••• 6c
Ref~rences •••••••••••••••••••••••••••• 6d

online Team Environment
3

SRI-ARC 0 JUNE 1972
Contents

13041

FACILITy •••••••••••••••••••••••••••• ?
Hardware •••••••••••••••••••••••••••••• 7a
Introduction •••••••••••••••••• 7al
Present Confi~uration ••••••••• 7a2
Problems We Have Been Facing •• 7a3
System Software ••••••••••••••••••••••• 7b
Imlac Support for DNLS •••••••• 7~1
TENEX ••••••••••••••••••••••••• 7b2
Superwatch •••••••••••••••••••• 7C]
References •••••••••••••••••••••••••••• 7c

COMPUTE~

PLANS •••••••••••••••••••••••••••••••••••••••• 8

Goals ••••••••••••••••••••••••••••••••• 8a
Service to Users •••••••••••••••••••••• 8b
Basic Project Work •••••••••••••••••••• 8c
References •••••••••••••••••••••••••••• 8d
GLOSSARY ••••••••••••••••••••••••••••••••••••• 9
APPENDICES ••••••••••••••••••••••••• ~ •••••••• lO
Handoook Contents •••••••••••••••••••••••• ll
Document Locator ••••••••••••••••••••••••• 12
A TY~ical Network Resource
NoteboOK Entry ••••••••••••••••••••••••••• 13
NIC Software Plans ••••••••••••••••••••••• lh

online Team Environment
4

SRI-ARC 8 JUNE 1972

13041
Summary
Introduction

SUMMARY
3
INTRODuCTION
We are developin~ a system of online computer aids for
augmenting the performance of individuals and teams engagea
in intellectual work and an Information Center for the ARPA
COMputer Network. This document reports hardware and
software development and applications in several areas, an~
summarizes plans for continuing development.

3al

We discus~ ner~ the work performed under a contract Which
extended from February 8, 1970 to May 9. 1972. but recount
in detail only work of the last fifteen months of that
period. our work from February 8, 1970 until February 8,
1971 is reported in the Interim Technical Report, dated 30
June lQ7l. NETWORK INFORMATION CENTER AND COMPUTER AUGMENTED
TEAM INTERACTION, RADC-TR-7l-l7S, AD 737 131 (8277,). The
1970 work is summarize~ below but discussed in the body of
this rePort only where necessary to eXPlain developments of
the last fifteen months.

3a2

To take adVantage of the automatic reference search of our
online system~ bibliographie citations in this report are a
little unusual lookin~. They will appear in two forms:
~See·- • a comma + a string of numbers and letters + a
right parenthesis" (e.g., see--,9an)} cites some other
part of this report as identified by the statement
nUMbers printed ri~ht. Online, a reader may cite such an
address and move automaticallY to the appropriate part of
the report.

or five-digit number in parenthesis {e.g.
(8277.)) cites a document in ARC's collection. The number
is the ARC catalo~ number. Most of the documents cited in
this report are online and an online reader may move to
that file automatically as above. A reference section at
the end of each chapter suPPlies bibliographic
information about these documents in the usual way.

A f~ur-

A glossary appears in (,9).

ARC has be~un to ~aintain online a detailed description of
the current state of its activities, the Handbook discussed
below (see --,~b).

Online Team Environment

3a3a

SRI-ARC 8 JUNE 1972

13041

SUMmarv
Introduction

The reader may find in documents cited in the Handbook
more detail~d Accounts of several rnat~ers than appear in
this report, particularly of command and COMPuter
lan~ua~es.

The detailed aCCO\lnts are in the following Handbook
documents:
TREE META (10869,),
~EX

3a4b1

3a4b2

USER GUIDE (9934,).

nNLS PRELIMINARY USER GUIDE (10703,),
~IC

3a4b3

TNLS USER GUIDE (7470,),

NIC JOURNAL USER GUIDE (7635,)
L10 PROGRAMMING GUIDE (USER GUIDE)

(9246,)

tlO - A Pro~ramming Langua~e for the Au~mentation
Research Center (Systems prorrammer's Guide) (7052,)
HIGHLIGHTS OF 1970
Durin~ that year we devoted our attention especially to our
continuing effort to improve the efficiencY Of our online
system and broaden and strengthen its usefulness to systems
programming, to workin~ with the ARPA Network, and to
augmentation of distributed teams.

3bl

During the latter part of the year We were deeplY involved
witn translating our software into forms compatible with a
PDP-IO and with Choosing and connecting its perioheril
equipment.

302

we pla~ned and began use of an important new group of tools
for usprs whi~h we now call User programming. They are
routin~s in Which the basic user feature~ of our online
system are building blOCKS in construction of programs that
carry ~ut specific, rather complicated tasks, 8uch as
chan~ing the order Of a citation index and at the same time
the format of the citations. Important User Pro~raMS are
the rewritten Content Analyzer, the Analyzer formatter, tne
Collector sorter, and Executable Text.

3b3

Online Team Environment
6

SRI-ARC 8 JUNE 1972

1)041
Summary
Highlights of 1970

Early tn 1970 we developed an arithmetic and alRebraic
calculator packa~e to our online system. The calculator has
not yet been transferred to the PDP-10 version of NLS.

)b4

1970 SaW new concentration on augmenting teams performing
work that is distributed in time, space, and discipline. By
way of communica~ion and archival and managerial record
Keeoinr. we added a mail system and a Journal system. Any
user might write a mail message from his terminal to any
other users. The message was automatically brought to the
reCipient'S attention when he lo~ged in. Mail was
particularlY Useful to our people temporarily or permanently
at a distance from the Center. Mail messages automatically
became part of the Journal.

3b5

The Journal is an online repository of the thoughts,
records. baselines, and evolving designs of the group.
Online is an index to the complete journal, including
various retrieving aidS such as sorting by title words.

3b6

Our participation in the ARPA Network in 1970 included:
using university of Utah's PDP-10 via the Network to aid in
our tranSfer to a new PDP-10, an~ development of th~ Network
Inform.tion Center (NIC).

3b7

In using the N~t to re-orogram our PDP-10 we tynically
sent blOCKS to UXAH that consisted of relocataole binary
data produced bY compilers executing in our XDS-940 and
prOducing code for the 10. The data was stored on a disc
at ntah by the network control crogram so that someone
here could reconnect and call on the Utah loader for tne
transmitted file. We found tnis service so useful that
we added mult1plexin~ at thiS end so that three of our
prOF-rammers could use the utah system at once. The link
to utah operated daily from August 1970 throu~h January
1971 and constituted the most substantial data
transmission over tne Net to that date.

3b7a

In 197n we established a collection of dOCUMents that form
tne basis of the Network Information Center, established
online technioues for handling the documents, and, most
important, began working dialo~ with the other centers. The
combination of our reference data storage technioues with
our programmin~ allows r~trieving documents according to a
Variety Of attributes and combinations thereOf; e.g., year
of PUblication combined with author, or sponsoring

online Team Environment

SRI-ARC 8 JUNE 1972

1)041

Su~rnary

HignliF-hts of 1970

institution. We organiZed with the other sites on the
Net~ork to establish station Agents to handle their
interaction with the Network Information Center and SUPPlied
the Station Agents with a catalot. of their collection an~
other working ~aterials. To stimulate dialog. pending full
operation by connected computers, we set up a central
telephone exchange a~d a system for circulating documents
and meMOS bY U.S. Mail through the NIC, includin~ an
intra-~et document numbering system.

3b8

In the Spring of 1970 we decided that DEC's PDP-10 with
associatea software and paging bOX from BBN mi~ht be a way
to increase the number of consoles and displaYs aVailable to
us, to strengthen our system in other waYs, and to ensure a
system that could be expanded further with ease. In June
after investlgating several competing machines, we ordered a
PDP-10 wnich was delivered in September. Our 940 was
removed Feoruary 1, 1971. Associated equipment for the
PDP-10 includes 128K of 1.O-microsecond core and the ~BN
Pagin~ Box.
After studYin~ the various alternatives, we
retained from th~ 940 system a 32K-word Ampex external core,
UNIVAC druMs as a swapping device, and a Bryant Disc for
mass storage. A drumldisc interface, an interface for the
external core system, and an IIO control bOX were built
locally to our specifications.

309

He-pro~ramming fer tne PDP-IO created the necessity and
opportunity for thorough-going revision of our software.
Our online system which had been written in a special
languave, ~PL, was rewritten in LI0, a language much more
machine independent ana more flexible in apPlication. our
NLS wa~ rationalize1 iJO allOW more routines to call on other
rou~in~s.
D1splay routines Were changed to allow division
into Uc to eight areas Which the user can load and edit
independently. t~any other featurps such as Mail, Journal,
calculator wer~ substantially improved in the transfer.

3010

HIGHLIGHTS OF 1971

Team

3cl

Au~mentation

In the last 15 months our worK toward TeaM AUgmentation
has fallen into five areas: ~niprovement of our dialog
support syst.em. the initial work on our nandbooK, our
baSeline record system, development of basic NLS, ana
reOrgan1zation of our laboratory staff.

Online Team Environment
8

3cla

SRI-ARC 8

130hl
Summary
Highlights of 1971
JU~E

Dialog Support System

1972

3clb

with the XDS-940 Journal system, the PDP-10 Journal
system serves as an open-end~d information storage ana
retrieval system, orientea toward recording the
thoughts, notes. designs, workpieces, ana reports
communicated by users.
AS

ARC and Network personnel use the Journal system
daily.

3clbl
3clbla

Since It became operational in April, 1971,
approximately 1600 documents have been generated
at ARC and submitted to the Journal.

3clblal

The ~DP-lO Journal system provides for automated entry
of online dOCUments in contrast to tne essentiallY
~anual technique used on the XDS-9kO.

3clb2

When a user sUbmits
with a numoer and a
directs delivery of
recipients the us~r

a document. the syste~ tags it
distribution note which later
the document to a list of
spells out.

3clb2a

A read-onlY copy of th~ submitted document is
then stored, along with information relevan~ to
th~ submission of the document (date/time,
titl~J keYWords, etc.).

,3clb2al

A b~ckground process will suhsequently tr4ns!Orm
this into the tinal and permanent Journal entry.

3clb2a2

Delivery of Journal sUbmissions to authors and
recipients nas been automated on the PDP-10 System.

3clb3

B3ra copy is automatically formatted and printed
with an address page so t~at mailing simplY
involves fOlding, sta=lin~, and stamping.

jclb3a

An online delivery technique has been developed
wherein a user may receive notice of documents
addressed to him bY the placement of statements in
his ini~ial file.

3clbJO

Thes~

alon~

statements contain a link to the docu~ent,
with the sender's identification,

Online

Environment

Tea~

SRI-ARC 8 JUNE 1972

Summa.ry
riighli,.hts of 1971

13041

date/time of submission,
title.

~ocument

number, and
3clb3'ol

A messa"e facility has been incorporated in the PDP-10
Journal, which eliminates the mail system used on the
XDS-940.

3clb4

online Journal documents may now be reached through
NLS Oy simplY using the Catalog number as a file name.

3cl'b5

Toe improved access to Journal documents h.S
resulted in increase~ linKing between Journal
documents l whereby ~1alogs may involve a numoer of
documents, all interlinked.

3clb5a

3clc

Ha.ndbooK
we ha.ve begun develo'Oment of a "Han~book," a
"super-document" that contains the beginnings of an
up-to-date, lar~e, detailed, highlY cross-referenced
and well-in1exe~ descr1ption of ARC project-team
;tctivity.

3clcl

SUCh a document will provide ARC, as a team

t.cklin~ complex system-development projects, with
tne highest-possible Visibility over its Working
environment.

3clcla

Toward the end of the contract period we set UP a
team to desi~n a HandOOOK system which will be usea
to construct. index. and ~aintain this documen~.

,3cIclo

~aSeline

kecord System

3clJ

for changes or
we have
resource~ to carry out. Therefore we have attempted to
use NLS to find ways to maKe ~ver ~ore effective~
coordinated analysis of our ideas, and of our peoPle,
system, and material resources.

3clal

The result of such coordinated analysis is the
;tcloption Qf a current Visible plan .. or "baseline" of
expected events, agreed upon system developments,
their external confi~urations. and resource
allocations.

3cld2

~e constantlY face more opoortunities
~ddit~onE to our evolving system than

onlin~

Tea~

Environment
10

SRI-ARC 8 JUNE 1972

13041

Summary
Highlights of 1971

The information relative to the planned system
developments is contain~din our Baseline Recor~.

3cld2a

The Base11ne Record is a special SUbcollect1on of the
Journal. It consists of a series of files speciallY
formatted to contain task and resource allocation
information, inclUding particUlarlY files of ~lans,
specifications, analyses, designs, etc.

3cl03

The present Baseline Record system has concentrated on
the recording of information relevant xo individual
taskS being performed or under consideraton bY various
ARC staff members.

3cld4

Tnere now are over 200 tasks of various magnitu~es
to co"si~er in our Planning and operational
environment at any point in time. These range from
simple bug-fixing to complex design or
iMPle~entation tasks that may be performed by
several people over many months.

we have developed a set of programs with an initial

data storage system that organizes information
recorded about these tasks with features that
permit routine summary Views to be prOduced ana
that also Make available flexible, user-created
views of the Baseline taSk information.

proceaureS have been developed for data collection
and input and for vieW production that aid in
weekly updating of the Record. These views are
produced in hardcopy and are also entered into the
Journal.
we are not sat1fied with the present

~aseline

~ecord

3cld5

~ystem.

fe~l

tra1n~d

3cld4c

that our ARC users were not well guided and
in BPS use and

the initial system did not prOduce views that were
useful enough - m~inlY because most of tne needed
data were not in the system.
Although we have started using ARC's Baseline Record
system on a current task-by-task bASiS durinr tne past

Online Team Environment
11

3cld5a

SRI-ARC 8 J0NE 1972
Summary
Highli«hts of 1971

13041

year. we still need to develop a more complete,
"h1~her level" picture of what new ARC system
developments (functions, 1eatures, stages ••• ) we want
and expect to see. Among other considerations. this
includes better definition of activity goals.

3cld6

3cle

Basic NLS
In this past contract period, we have taken several
steps to further augment the software engineer

.3cle1

-- in fact, we have coined the acronym SEAS (for
software Engineer Augmentation System) -to give
specific sYstem orientation towardS the end of
developing a fUll and balanced set of tOOls,
techniques, methods, principles, etc. for
augmenting software engineers.

3clela

The developments described below are part of an
acceleratin~ activity -- an important part of our
near-future plans in the next contract periOd
inVOlve a greater level of activity here.

;clelb
3cle2

TNLS a.nd DEX

A new and effective typewriter version (TNL~) has
found wide use botn at ARC and at Sites on the ARPA
NetworK.

3cle2a

ImproVements nave been made in the display verSion
(DNLS)

3cle20

and a first version of an Offline mode (DEX) has
been introduced.

3cle2c

Changes that maKe possible cross-file editing allOW
any two Passages to be involved by a g1vencommand.

3cle3

In TN I, 5 I add res s e sin a. comma. nd may be" 1 i n l< s II
which can call any passage in any file on tne
system;

,3cle3a

in DNtS, SPlit screens allOW the user to view any
two passa£es and control eross-file editin~
visua.lly.

3cle3b

Online TeaM Environment
12

SRI-ARC 8 JUNE 1972

1)Ou1
Summary
Highlights of 1971

Viewspecs make possible selective assimilation of
information from one file into another.

New special puroose SUbsystems have been developed or
improved.
These include a sort-merge system, a user program
system, and the output processor.
Language development has continued.

3cle3c
3clel1
3cle4a
3cle5

At present tne primary language systems developed
and in use at ARC are the Tree-Meta
Compiler-compiler System and the L10 Pro~rammin£
langu~ge system Which was written in Tree-Meta.
Work is currentlY progressing on a Modular
programming System (MPS) in collaboration witn a
Froup at the Xerox Palo Alto ResearCh Center.

3cle.Sb
3cll

During the past year, several ARC organizational
arrangempnts were introduced, centering. in the early
part of the period, mainly on line-activity structure
~rio associated roles.

3clfl

The creation of pusher (task leader) roles for
tasks and coordination roles for system
architecture. methodology. and personnel resources
placed the responsibility more directlY on
selected individuals.

3clfla

PUSher roles were· defined in the frameworK Of

the aevelo~1ng Baseline management system.
coordinating roles were also carried out in this
environment. our techniques for performing tnese
roles still leave much to be deSired. The
planned recording of taSk requirements and
designs in the journal will stren~then the
roles.

3clflal

In the' Fall of 19'71, we set up a four-man Executive
Managpment COMmittee (EMC) to carry out much of the
day-to-day operating management.

3clflt>

online Team Environment
13

SRI-ARC 8 JUNE 1972

13041

Summa~y

Highli(hts of 1971

During the cast few months Dr. Engelbart has
established, a new, broader overall or~an1zational
structure.

3clflc

This ~tructure consists of three maln activities
that coVer our framework and goal setting, line
operation, and personal and organiza~ional
development needS.

3clflcl

These activities are calleO: FRAMAC, LINAC, and
PODAC.

3clflC2

FRAMAC is to discuss and define the ARC
intellectual frameWork and set longer-range
goals and plans.

3c2flc2a

LINAC is to carry out activities within the
framework that move us toward toe ~oals,
inClUding more detaile~. shorter-range Plannin«.

3clflc2b

PODAC institutionalizes continuinR personal and
development.

3clflc2c

or~an1zational

Network Information Center: Operations and Development
The ARPANET can be viewed as a COllection ot resources,
people, hardware, sof~ware, data, and speCial services
which can be brought together for short or long perio1s
to work cooperatively.

3c2a

Built upon hardware and fundamental SOftware
connections are the processes that aSSist users to
find the geographically distributed facilities they
need· to solve or stUdY problems and to allow scat~ered
oeople to work together effectivelY in tasks of mutual
interest.

3c2al

we see the Network Information Center (NI~) as one
oart of the ARPANET experiment that is interested in
the latter prOblems.

3c2a2

The NlC helps to create and sustain the sense Of
community needed in an exoeriment SUch as that of
the ARPANET.

3c2a2a

The NIC is not a classical information center because

Online Team Environment

SRI·ARC 8 JUNE 1972

13041
Summary
Highlights of 1971

it provides a wider range than bibliograPhic and
library services.

3c2a3

3c2b

The NIC Public:
one of the problems in the design of an information
service is to determine the clientele and its needs.

'3c2bl

cur initial analysis

3c2b2

Refer~nce

showe~

us four main needs:

and General Network Information;

Collaboration Support;
Docum~nt

Handling and creation; and

.3c202a
3c2b2b

3c2b2c
,3c2b2d

Training.
The clientele for NIC appeared initially to be people
developing and building the Network, Who were to be
followed by tnose whose research or development
interests would be intimately connected with Network
resources or Who would be experimental users of
various Network resources.

3c2b3

3c2c

NIC Services

TO meet the above goals. the NIC services aVailaole at
the end of tne report periOd, May. 1972. through the
Net were:

Online:

3C2Cl

3c2cla.

(1) Access to the typewriter version (TNLS) of
the Augmentation Research Center Online System
(NLS) for communique creation, access. and
other. experimental Use.

3c2clal

(2)
Access to Journal. Number, and
IdPntification Systems Which allow messages and
documents to be transmitted to Network
participants.

3c2cla2

(3) Access·to a number of online information
bases through a special Locator file using NLS
linK mechanisms.

3c2cla3

Online Team Environment
15

SRI-ARC 8 JUNE 1972
SUl!1mary
Highli,nts of 1971

130hl

Offline:

3c2clb

(1) A Network Information Center Station set up
at each site with:
(a) A station Agent to

ai~

in use of the NIC.

(b) A Liaison to provide technical
information about his site.

3c2clbl
3c2clbla
3C2clblb

Techniques for ga.thering, producing and
NIC Functional Documents. such
as:

3c2clb2

( a. ) Current Catalog of the NIC Collection.

3c2clb2a

maintainin~

(b)

ARPA Network Resource Notebook.

Participants.

NIC User Guide.

3c~clb2b

3C2clb2c
3c2clo2d

(3 ) General Network referral and handling 01

(4)

document requests.

3c2clb3

Buildin~ Of a collection of documents
potentiallY valuable to the Network
Community.

3c2clbU

In thebeginnin~ we've tried to collect
dOCUMents valuable to network builders.

3c2clb4a

(5) Crude selective distribution to Station

COllections.

3C2Clb5

(6) Training.in use of NIC services and

facilities.

3c2clb6

NIC Goals

3c2d

In the course of its evolution, the ARPANET will

Online Team Environment
16

SRI-ARC 8 JUNE 1972

13041
Summary
Highlights of 1971

continue to ~enerate needs for new software services
in interactive data management.

Jc2dl

we propose to develop a user-o~iented information
facility cased upon the NLS system and initiallY
serving the needs identified in (,3c2a1). This
information facility is a new step in the
"bootstrapping" of the Augmentation Research center,
and is leading to the establishment of a new resource
to be made available to ARPANET users.

3c2d2

Network Participation

3c3

Our Network participation outside of NIC activity has
been in two main areas, protocol development through work
in several protocol design communities and general
Network coordination throu~h membership on the
short-lived Network Work1n~ Group Steering Committee and
its successor. Network Facilitators Group.

)c3a

Computer Facility
Hardware
At the end of the first year of this contract, we
transferred our computer operations from an XDS-940 to
a PDP-10 comouter. The transfer effort is described
in our interim report for the first year (8277,).
Hardware activity durin~ the
tuning of the new
maintenance. troubleshooting
facility, and some u~grading
system.
addit1on~1

cast year has focused on
configuration,
and operation of the
Of critical parts of the

our nardWare configuration contained a number of old,
one-of-a-kind ~ieces of equipment brought over to the
PDP-10 system from the previous XDS-940 system. These
nieces of eauioment have proven diffiCUlt to maintain
and stUdies were launched on how to replace or upgra~e
this equipment~ A new B8N network interface and a new
DEC RP-02 diSC system were installed in the spring of
1972. replacing older unreliable equiPment. Hardware
up~radin, of our display system and its special core
bOX has be~un to provide temporary relief until a
replacem~nt system can be planned.
An additional 32k

Online Team Environment
17

3chal

SRI-ARC 8 JUNE 1972

1)041

Su~mary

High11«hts of 1971

of core is to be added shortlY. Stu~ies leading to
recommen~ation8 to add another channel,
disc
controller and set Of disc drives have been completeO.
These additions will proviOe more file space and
backup swapping capability. Improved reliability
shoula begin to be manifest in the summer of 1972.

system Software
TENEX
we cooperate actively with BBN and other users in
and maintaining TENEX, and have developed
a few new features. both visible to users and
internal to the system.
debUgg1n~

within the system:
We have forsaken TENDMP for loading the monitor
from nECTAPE and use instead DTBOOT from DEC.

3c4blbl

We have added a JSYs, a jump to a monitor
subroutine, to say that padding (sending
ru~outs) is required for fast terminals wnen a
CR or LF is output.

3c~blb2

We have made many chan~es to the teletype
routines to accommodate our diSPlays.

3c4blb3

To greatlY simolifY startup we nave cnanged the
starting address of the monitor from 100 (which
goes im~ediatelY to DDT) to SYSG01.

3c~blb4

We no longer add code to existing files wnen we
get new monitor releases. Instead we have
defined a~ditional files ~hat are assembled witn
each ~roup of files and, where Possible. nave
made our a~~1tions in these new files with ~RSTs
and CALLs to the new code.

3c4blbS

we have modified the system such that if

CHECKDSK does not run succeSSfully, then nothing
else, e.g. AUTO-STARTUP jObS, can run (excep~
for the operator's console and one special
dial-up line) until the disc has been fixed and
CHECKDSK has run successfully.

Online Team Environment
18

3c4blb6

SRI-ARC 8 JUNE 1972

130~1

Summary
Highlights of 1971

In the User's View

3CUblc

We have set up an advise command so on~ terminal
may control a job loaded at another terminal.

3c4blcl

We have added routines that log out a user Who
does nothing for a certain time, and that refuse
entry if the systeM is overloaded.

3c4blc2

SUPERWATCH

3c402

TO help find out what is going on within our
timesharing system we have developed an information
gatherin~ and formattin, ~rogram called superwatch.

3c4b2a

In general superwatch has been valuable:

3c4b2b

To verify that the system is working as
designed.

3c4b2bl

To identifY the caUse of poor service at the
time it is happening (e.g. a bug, hardware
malfUnction, or just overloading).

3c4b2b2

To identify the "weak link" in the system
configuration (drum, diSk, memory or CPU
capacity).

3c4b2b3

To evaluate changes in the system or hardware

confi~urat1on.

3c4b2b4

Plans for the Future

3CS

ARC plans to resolve a set of interdependent goals by
conducting research and prOViding service under a new
"Base-project" contract, that concentrates primarily
UPon:

3cSa

the tec~niques available to ARC ana Network
system builders and users for augmentin« the
development and application of computer-based
information systems.

3c5al

Making the Network Information Center into both:

3c5a2

Advancin~

online Team Environment
19

SRI-ARC 8 JUNE 1972
SUMmary
Hignli(hts of 1971

13041

(l) an increasinglY useful service to the Network
co~munity

and

(2) an important part of the Network experiment (in
its distributed, collaborative operations and in
its Network-utility role).

And ~oving useful augumentation techniques ana
services out into the ARPA Network Community.

3c5a2a

3c5a2b
3cSa3

A c~ntra1 point of our proposed approach is our need to
learn to negotiate and provide extensive services to
distributed users.
Therefore, we plan to concentrate our efforts within a
fOUr-pronged project wherein coordinated advances can be
made:
(1) Developing service functions that will be the most
help to our aoove-mentioned goal structure,

lcScl

(2) Developing the knowhow and capability for
deliveri"g significantlY useful service to the
Network. as a utility.

3c5c2

()) Developing the knOWhOW and capability for
marketing a utility service to the Network,.

JcSc3

and wherein we become ever better at
(4) Operating a utility service.

Depending on funding availability an~ other
arran,ements to be ne~otiated we may find ways to
provide additional service capacity through
placement Of the computer-based portion of our
aug~entatio~ system on a computer or computers
operated for us bY a commercial timeSharing
utility.
REFhRENCES

3c5d

3c5dl

3c5dla
3d

(7052.) W. H. Paxton (SRI~ARC). L-10 - A Programming
for the Augmentation Research Center (a systems
pro~rammer's guiae). 29 May 1971. 46p.
LanKua~e

Online Team Environment
20

3dl

SRI-ARC 6 JUNE 1972

13041
Summary
References

(7470.) Network Information Center, Augmentation Research
Center, Stanford Research Institute, Menlo Park. California
94025. TNLS User Gui~e: preface, Syntax and Contents. 1
September 1971. SeparatelY paged.

Jd2

(7635.) Network Information Oenter, Augmentation Research
Center, Stanford Research Institute, Menlo Park. California
94025. NIC Journal User Guide. 1 October 1971. separately
paged.

3d3

(B277.) D. C. Engelbart (SRI-ARC). Network Information
Center and Computer Augmented Team Interaction, Interim
TeChnical Report. Au~mentation Research Center, Stanford
Research Institute, Menlo P~rk, California 94025. Rome Air
Develooment Center, ARPA. RADC-TR-1l-175, AD 737 131. 30
June 1971. l04p,

3d4

(92~6.) Augmentation Research Center, Stanford Researcn
Institute. Menlo park. California 94025. L-10 Programmin«
Guide (a user guide). 4 April 1972. lOOp.

3dS

(9934.) Au~mentation Research Center, Stanford Research
Institute. Menlo Park. California 94025. Deferred Execution
(DEX) user Guide. 16 June 1972. 66p.

3d6

D. C. ~ngelbart (SRI-ARC). Experimental Development of a
Small computer-Augmented Information System. Annual Report
Coverin~ the Period 15 April 1971 through l~ April 1972.
22p.

3d?

(10703,) Augmentation Research Center. Stanfor~ Research
Institute. Menlo ParK. California 94025. DNLS Preliminary
Reference Guide. 21 June 1972. separately paged.

3d8

(lOb69.) D. I. Andrews, H. G. Lehtman, W. H. Paxton
(SRI-APe). Tree Meta - A Metacompiler for tne AUgmentation
Research center. In process. Unpaged.

online Team Environment
21

SRI-ARC 8 JUNE 1972

Team Augmentation
The Journal

13041

online Team Environment
22

SRI-ARC 8 JUNE 1972 130h1
Team AUlmen~at1on
The Journal

TEAM AUGMENTATION
by Charles H Irby, William H Paxton.
William S Duvall. J~me8 C Norton,
Bruce L Parsley, Mary S Church, Harvey G Lehtman,
Walter L Bass, J David Hopper, Douglas C Engelbart,
L Peter Deutsch, and James G Mitchell.

JOURNAL

Introduction

4a1

ARC becomes more and more inVOlved in the au«mentation
of teams, we are giving serious conSideration to
improving intra team communication with Whatever mixture
of tools, conventions, an~ procedures will help.

4a1a

If a team is solving a problem that extends over a
considerable time, the members will begin to need help
remembering some of the important communications--i.e.,
some recordin, and recalling processes must be invoked,
and these processes become candida~es for augmentation.
To consider SOme of the different conditions where such
storage and recall may be useful, suppose Person A
communicates with person B about Item N at Time T.

4alb

They may well remember their exchange during the
nroblem-solv1ng period. But consider the case of
person C who, it will turn oUt6 is going to need to
know about this communication at time TT:

4albl

perhaps he was there at Time T, but
he was too heavily involved even to notice the
communication, and/or Item N was not relevant to
his work at that moment and so Was not implanted
for ready recall.
perhaps A and B did not anticipate his later need
and thus failed to invite him into their
interChange or inform him of its conclusion.
perhaps, although Persons A and B knew he would
l.ter need the information, they didn't want to
interrupt their own working sequence with the

online Team Environment
23

4alblal

SRI-ARC 8 JUNE 1972
Team Augmentation
The Journal

13041

procedure of interrupting Person C and getting him
involved.

~alblc

or, if the conseauences of the interchange carryover
into a lon~-last1ng series of other decisions. one or
both parties may fail to remember accurately, or may
remember differentlY because of different viewpoints,
and troublesome conflicts and waste of effort may
result.

4al02

A single person will make a list of things to do on a
shopping trip because he has learned that the
confusion and pressure may make nim for~et something
important. It is obvious that to be procurer for one
of a mutuallY developed. interdependent pair of lists
wOUld make it even more important to use a record.

4alb3

l'urther consider thp effect if the complexity of the
team'S problem relative to hu~an working capacity
reouires partitioning of the problem into many parts
~here each part is independently attacked, but where
amOn~ the parts tnere is considerable interdependence
through interactions on mutual factors SUCh as total
reseurce. timin~. weight. physical space, and functional
meshin~.
~ere, the communication betWeen Persons A and d may
well be too complex for their own accurate recall.
For example, their communication periOd resulted in
scratch paper or a Chalkboard covereQ with
oossibilities and the essence of the agreed-upon
solution, WhiCh has since disappeared.

4alcl

we envision augmentin~ our collaborative team by having a
"DialOg Support System (DSS)." containing current and
thorou~hly used working recor~s of the group's plans,
desi~ns, notes, etc.
Therefore, we have begun to develop
a systeM for entering and managing those records. The
ARC Journal 18 the central feature of this intragroup
documentation system.
Th~ DSS involves techni~ues for use by distributed
oarties to collaborate effectively by means of the
inter-linked referencing between NLS files, particularly
within the reeorded·dialo~ medium of an NLS Journal.

Online Team Environment
24

uale

SRI-ARC 8 JUNE 1972 1)041
Tea~ Augmentation
The Journal

FIGURE 1. ARC Dialog Support System hardcopy cave.
Third shelf from the top is the Handbook; fourth is
the Baseline Records; fifth is Journal indices.
4alel
Our DSS will provide the fOllowing general online
aids: mUltiwindowed displays; simultaneous and
independent mObility and view control among many
files; link-setup automation; back-link annunciators
and jumpin~; aids for the formation, manipulation, and
stUdY of sets of arbitrary passages from among the
dialog entries: inte~ration of cross-reference
information into hardCOPY printouts.

4ale2

It also will include people-system developments:
conventions and working procedures for using these
aids effectively in conducting collaborative dialo~
among various kinds of peoPle, at various kindS of
terminals, and under various conditions; working
~ethodology for teams doing planning, deSign,
implementation coordination, and so on.
4a2

The PDP-10 Journal
During 1971, implementation of the initial PDP-10 Journal
system was completed.

Online Team Environment

4a2a

SRI-ARC 8 JUNE 1972
Team Augmentation
The Journal

13041

As with the XDS-9kO Journal system, the PDP-10 Journal
system provides us an open-ended information storage and
retrieval, oriented toward recording the thoughts, notes,
workPieces, and reports produced bY users.
The system is in dailY use

by ARC

personnel.

Since the first version of the system beca~e
operational in APril, 1971, approximately 1600
dOCUments have been generated and sUbmitted to the
Journal.
The system is alSo offered as a NIO service.
The PDP-10 Journal system provides for automated pntry of
Online documents in contrast to the essentially manual
technique used on the XDS-9~O.

An NLS user can submit any portion of an NLS file
(which mayor maY not be currently in his viewing
area) to the Journal without leaving NLS.
In order to dO this, he simplY executes a command
Which places NLS into a sub-command level whicn
recognizes commands relevant to Journal operation.
AS a document is sUbmitted, it is assigned a number,
cataloged. and a distribu~ion record is created which
will later cau~e delivery of a copy of the document to
a list of recinients indicated during the SUbmission
nrocess.

4a2b
4a2bl

~a2bla

4a2b2

4a2c

~a2cl

4a2cla

4a2c2

A rea~-onlY copy of the submitted document is then
stored, alon~ ~1th information relevant to the
SUbmission of the document (date/time, etc.)
A background oroces! will SUbseQuently transform
this into the final Journal entry.
Delivery of Journal SUbmissions to authors and recipients
has been automated on the PDP-10 System.
Hardcopy is automatically formatted and printed with
an address page so that mailing simplY involves
foldtng, stapling, and stamping.

Online Team Environment
26

4a2dl

SRI-ARC

JUNE 1912 13041
Team Augmentation
The Journal

~n online delivery technique has been developed
wherein a user may receive notice of documents
addressed to him by the placement of links in his
initial file.

4a2d2

A message facility has been incorporated in the PDP-10
Journal, which reolaces tnemail system used on the
XDS-940.

4a2e

online Journal documents maY now be accessed through NLS
by simply using the catalog number as a file name.

ha2f

A catalo~ search is done which determines the real
name and locat~on of the file containinR the document
with the indicated number.

ha2fl

This search 1s transparent to the user, and once
located, the document is loaded as if the user had
typed in the n~me and directory information containe~
jn the catalog.

4a2f2

User

aopearanc~

the user initially addresses the Journal system for
document sUbmission, he must define the document as any
legal NLS structural entity (Statement, Branch, Group,
Plex. or File) or as a ~essage (literal) to be typed in.
AS

The document is lmmediatelY assigned a catalog number,
and copied into a wcrK area.
AS this is oe1ng done, information relevant to the
document (date/time, author, etc.) is recorded in
the document header, alon~ with default parameter
settings.

4a3ala

The USer is now Placed into an interactive submode, Where
the following parameters relevant to document submission
may be specified:
Author: ~erson (persons) or
document.
clerK: person actuallY

~roup

sponsorine the
4aJbl

sUbmittin~

the aocument.

Online Team Environment
27

~a3b2

SRI-ARC 8 JUNE 1972

Team Augmentation
Th~ Journal

l3041

comments~ A co~ment which is kept in the document
header as an appendage to the document.

4a3b)

Distribution: A list of persons or groups to receive
copies of the document.

ha)b4

Keywords: Key words which may be used for document
retrieval at a later time.

ha)b5

Obsoletes: A list of documents obsoleted bY the
document being SUbmitted.

ha3b6

SUbcollectlons: A list of sUbcollections in which this
document 18 to be inclUded.

4a3b7

The sUbcollections listed here are in addition to:
Any subcollections aSSOCiated with the SUbmitter
oy defaUlt.

~a3b7al

Any groups included in the distribution list.

4a)b7a2

Title: A title for the document. This title will
appear as a defaUlt page header in the final formatted
version.

4a3b8

UPdates: A list of dOCUments updated by the document.

4a)b9

Additional to the parameter specification commands are:
ka)cl

commands for control
Quit: Leave the Journal submission sUbmode, and
abort the entry.
Go: Terminate the parameter specification phase and
be~in the actual document entry.
status Com~and: Shows the current status of the entry
parameters
place Link command: Allows the user to specifY a
location in a !ile, which will be used for inserting a
statement containin~ a link pointing to the SUbmitted
document when submission is COMPlete.

online Team Environment
28

4a)clb
4a3c2

SRI-ARC 8 JUNE 1972 13041
Team Au~mentation
The Journal

Interrogate Command: Places the user in a passive
rather than active interactive mode. SUbSequent to
this command, the system will request specification of
certain parameters from the user.

4a3c4

After the user has initiated the GO command, the system
proceeds to eXecute the necessary functions for making a
Journal entry from the Working document.
when this proc~ss has been successfully completed, a
link locating the just-submitted document is typed or
displayed to the user.

4a3dl

The user is then returned to the NLS command mode.

4a3d2

The Journal System User Guide (7637,) provides
additional information on the use of the system.

FIGURE 2. Someone calling the Journal System in TNLS.

Online Team Environment
29

4a3e

SRI-ARC 8 JUNE 1972
Team Augmentation
The Journal

13041

FIGURE 3. In the Journal System, a file has been
sUbmitted, and the user is waiting for a number.

FIGURE 4. The user commands the System to Quiz hi"m for
the information it needs.

Online Team Environment
30

SRI-ARC 8 JUNE 1972 13041
Team Augmentation
The Journal

FIGURE 5. The user has responded to the System's
promPtings with the title and is about to fill in the
distribution list.

FIGURE 6. Journal system in progress.

online Team Environment
31

SRI-ARC 8 JUNE 1972
Team Augmentation
The Journal

13041

FIGURE 7. Submission complete.

I~entification

SYstem

4a4

the Journal system WaS being ~esigne~, the nee~ for
uniouelY i~entifYing persons an~ groups within the
environment of the system became apparent.

4a4a

GiVen this identification, the system coUl~ keep track of
a bo~y of ' information about each user, such as a~~ress,
telephone, TENEX user name use~ by the user, etc.

4a4b

The outgrowth of this

4a4c

nee~

is the Identification system.

With this system each user/group is assigne~ a unique
two-to-six-letter co~e, which is subsequently used as a
'handle' for that person.
wherever possible, the co~e (IDENT) for a person is
the initials Of that person, an~ for groups the
acronym for the group.
The IDENT may be use~ to locate an entry in a file which
contains the necessary information about that person or
~roup.

Online Team Environment
32

4a4dl

S~I-ARC

8 JUNE 1972 13041
Team Augmentation
The Journal

provided in the Identification system are not only
handles for retrieving information about any IDENT, but a
com~ana sub-level for generatin~ new IDENTS and mOdifying
inf~rmation for Old ones~
The Identification system is used extensively by all
phases of the Journal.
The Identification System User Guide (7638,) provides
additional information on the use of the system.
Number system

ha4h

4a5

The Number system provides a capability for centrallY
assigning Master catalo~ and Network Working
Group/Request for comments (NWG/RFC) numbers.

ha5a

There is a set of NLS commands for directly assigning
catalog numhers, and for pre-assi~nin~ RFe and Journal
numbers.

ha50

There is also a set of handles that allows numbers to be
assigned to internal processes. e.g. the Journal.

The Number system User Guide (7639.) provides adaitiona1
information on the use of the system.
Document Access

4a5d
4a6

The XDS-9~O Journal syste~ provided essentiallY offline
hardcoPY access to Jour~al documents.

4a6a

With the PDP-10 Journal system. an effort has been made

to provide convenient online access to Journal
addition to imoroved offline access.

~ocumente

4a6b

HardCOpy master and access collections (libraries) are
maintained of all Journal dOCUments.

4a6bl

while tne master collection is maintained in its
original form, documents from the access collection
May be Cheeked out, annotated, and copied by AkC
personnel.

ha601a

The master catalog number is still the key to
identifYing documents.

online Team Environment
33

4a6b2

SRI-ARC 8 JUNE 1972
Team Augmentation
The Journal

13041

4S indispensable aids to the user. ARC
author, number, and titleword indices.

~rovide,

4a6b.3

These indices are automatically produced from the
ARC Master catolog by a series of L10 user
programs.

}J.a.6b,3a.

ARC JOURNAL INDEX BY AUTHOR
Tit.le

*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

48,6b4

Dat.e

The T!NEX SCheduler
response aemo
response .. erno

21 Jul 71

No t.1 tle

known porformance problem.
SCEEDl problem
POd ~e8hu!fle prooo.al
•
Re~lY to 10954 (replY t.o 109S3)
Re~lY ~o your co~~ent.s on NIC document.at.1on
re: unGat.e
let n~ ~ell you about the Handbook
re: a.tt.ac:n/
V1.s1 tors>
Vacat1on.>
Mee6s'poss1bl11tl.a
RINS HP)
•
•
cat Data ~lement Rovi.e)
RINS Entry convention')

Ixternal Collaborator Ooord)

FIGURE 8.

Ixxx
,
'xxx
•
Ixxxxx
I
Ixxxxxx
I
,xxxxxx
•
'ltxxxx)tx
I
Ixxxxxxxxx
1
Ixxxxxxxxxxxxx)(l

.-._----.-----.,
1--··--_·_····-1

.I,'
~il

512

Sit

(DVM7 Jetl !IF-R
(PXH JCN DlIN

kll
'11

611

kl1

612

7'1'1

61k
'177
'l'l7

(fKY ~"..H JCN.,
(JCN DVM "fA 777
(DVN JCN ~FA CHI VRP RVV HoL vaD DCI
(dCN FKV R~W DeV

V2a

(DCE JeH J6N771

51_
611

(JeN

(RWW JCIf DCE
TIflE. NlS.2.

RESEARCH.NlS.'. 2-0CT-72

("701

',21 OVN I

"70 SUllllllory of
'970 Pro Ject
'97' SUlllllloryof
("711 '97' Project Activity
(Abstracts) IlllAC IV
(Abstracts) lLllAC IV
(Abstracts) lLLIAC IV
(Access) prlll1ary ACCess
(AcceSS) HWG/RFC 2U, TELNET
(Access) A study 01 Opt I ilia I

("70)
("71)

(AcceSS)

NWG/RFC " "

(Access)

SOllie l egel and
0 esl gn. rhru
Multiple ACCeBS
5yst ... control In
A 8raft.d

(eccus)
(Ace . . . )

(Aeeu.)
(Ace...)

Data

FIGURE 9. Cross file information manipulation
with SPlit screens: initially the screen is split
with a title index on the left and a new empty
file named research on the right. Titles are
truncated to show more lines.

Online Team Environment
.53

4dlblb2

SRI-ARC 8 JUNE 1972
Team Augmentation
Basic NLS

13041

FIGURE 10. Use r c alls the Goto Programs Subsystem
by entering the f i rst letter of each command via a
keyset. on the ke yse t he can enter with one hand
all charac t ers th at can be entered from a
keyboard. The oth e r hand is free to use the mouse
(below ).

,.,101

r 1 Tl£. HlS 11 .
"7 0 SU/lft6 r)'

,,,' 0 1

!fl O Project

f .,111

' '' '11

un P('oJ'ct Activit,

< "'A H " OUHU'l'S~

'IAH HOUHU'I' S~ ~{S[d CH . NlS II, 1 ·0C r · 12
t ,l l DVN I

SU I'MI6ry 01

{Abltrechl lLLI AC IV
I Abnr. ctal
lLll AC 1'1
CAbrtre ct.al
ILU AC 1'1
l Ace ... ' Prillar 'l Ace."
' Ace.ul HWB/ AH 1 U , TElH ET

' Acc tUI

A stu d, 01 Opt 1,,6 '

I Ace . ,,1

HWG/ RF C \ ,5 , Dtt_

' Ace.,,1

50111. llge ' .nd
Dutgn. rhN

'&ee,'"

I Ace,,,l
f Ace . .. 1

l1ulttpl. Ace . ..
51 ft ... control In

" ,,.eft . o

FIGURE 11. The Got o Programs Subsystem (~ee
command feed bac k lin e i n the upper middle of the
photo) incl ud e s seve r a l user service subsystems.

onli ne Team Environment

SRI-ARC 8

~orrt.nt

-". 'IUI"

• VAHH OUIiUVS· n rlf . IIILS 11 .
' \flO l U10Su ....r'of
{ lfl OI "'0 Pro J.ct
(1 " , 1 "'1 SUM.,., of
flU l 1 U11 Pro J'ct Act IVi t ,

IAbn. ,.. ct,l

lLllAe IV

fAbl'tr.cttl

lLllAC h'

fAbl't,..ct .)

JLlaC IV

I Ace ... l
( "CCIU)

PrIll .... ' ACC U'
HWI/AFt 1" I TELHEr

' Ace."}

A st ud, of opt , •• 1

CAce ... }
f Ace.n)
I ~ c ... l

' Ace .., )

lAce ... )

H.. S/ II:Fe " 5.

pett.,.. . . compt l •

c'l"'HHOUIiU'S. ~£S(AIIICH . Hl511. 2.0CT-H

',UDVN,

O.t.

Sor.. L.ge l en d
DUlgn . rhN
Multl p l . Ace ...

5)'ft ... control In
A

FIGURE 12.

JUN~

Team

.,...rt,d

He calls one of the user systems, the
content analyser.

FIGURE 13. To insert text of more than a few
characters. this user switches hands to the
keyboard. practice varies among users.

online Team Environment
5S

1972

13041

Au~mentation

Basic NLS

SRI-ARC 8 JUNE 1972
Team Augmentation
Basic NLS

13041

FIGURE 14. The user returns his left hand to the
keyset and hi s ri(ht hand to the mouse. To
confirm his command to compile the pattern
"Research" he presses the right hand button on top

"'iA'U'OU~UTS·

Tl fLE . NlS 12.

Ilt7I1'tJOSu. ..,.,o(
I U701
1t10 Pro J.ct
I't"l "71 Su • .,., 01

nUll

VAHHOUHUl' S~~[5EAltCH. HlS II. l-OC T-7 2

',UOVN,

,,,, ProJ'ct Activit,

U,bn, r&ct.J
U,bn.r. chl
(Abn.,.. chl

lLllAC IV
lLL lAe IV
lLl lA C IV

CAce.ul

P,-, • .,., Ace . ..

{ Ace . . .1

NWflltfC 2", TEL NET

I Ace ...1 A st ud, 01 Opt t n l
I Ace ...1 NW llltfC u s . O.t.
( Ace ...1 So •• L'9- 1 and
1..:" ..1 0 .. ,91'1. rhN
I Ace . .. ' "Ultlpl . Ace. "
( Ace ... l 51ft . . control In
A , ,.. ft. d

FIGURE 15. The text he entered appears in the
literal feed ba ck l ine on the upper l eft. The
content analyser will ac~ as a filter and pass
only state ment s t hat contain the word Research.
Patterns may be much more complex and inc l Ude
logical ope r at ors and classes of charac t ers as
we ll a s s pecific characters.

Onli ne Team Enviro nme nt
.5 6

SRI-ARC 8 JUNE 1972 1)041
Team Augmentation
Basic NLS

,. .. 1,,1 J.t . P l u

"''''''

c~A NHOUHUTS·

n rL [ . NLS,l,

' ' ' 0 Su,...,., of

f nUl l
f lt lll

1t7 0 Pro

I Ace . .. l

' Acc ...1

(Ace ... l
f Ace.,,1

' ,U 'h'lI!

1t71 Su MV, 01
It , ! ProJtct Activi t

( 1, 111
f Abl'tr. chl
f Ablt,.. ct . l
f Abet ,..chl

.. ..." HNOUliUf$.II£SEAR CH. • lS I •• l-OCT - H

,.et

fInO }

lL l IAC h'
IL U AC h'
llL lA C h'

'r' •.,."

ACe . . .

N'f8l JtFC l U , TEL Htr

A st ud, of opt 111.1
NWlJ / ltFC

It"

Dwh

I Ace ...1 So,.. L' 9- 1 ."et
l .ce... l
I Ace ...1

""
'9"\. ThN
.. u ltlpl . Ac e . . .
51ft .. control In

A .,..dt .d

FIGURE 16. The user calls the comman~ Assimilate
P1ex by entering three characters on the keysei.
At the same time he is rolling t he mouse which
moves the arrow to the area (mi~d1e right) where
he wants to put the assimilated material.

FIGUR E 17. 8y hol ding down the left hand two
butto ns on top of the mouse, he command s the
system to assimilate only items that pass the
content pattern he specified above. The le t ter i
toward the upper right and the larger letters on
the upper left are feedback from this command.

online Team Environment
57

SRI-ARC 8 JUNE 1972
Team Augmentation
Basic NLS

1304l

c~AHHOUIiUYS'Tl

TLE.HLS,2.
("701 ,"0 SUllllllary of
("701 "70 ProJ.at
(U7,1 "7, SUIIIIII ... yof
(U71) ,,,, ProJ.at Aatlvlty
(Abnraat,1 lLLIAC l~
(Abnraat,1 lLLIAC I~
(Abnraat.1 ILLIAC I~
(ACC... I prllll.,..y Ace...
(Acc...1 HWB/RFC 2". TELHET
(ACC..,I A study of Opt I ilia I
(Aeeu.1 HlfG/RFC,,,, Dat a
(ACeu.1 50111. L.gal and
(ace ••• 1 Dulgn. ThN
(Ace...l Multlpl. Ace . . .
(Aee...1 Syn'lII control In
(Ace..,1 A 'r.tt.d

c~AHHOUIiUYS.ftES£AftC".NLS,2.

J-OCT-72
2-0CT-72 •• 21
SU."'J of R...... ch
SU."'J of ft ...... ch
lLLIAC I~ ft ...... ch
ILLIAC I~ h,. ... ch
ILLIAC I~ ft ...... ch

c~AHHOU"UYS'TlTLE.NLS,2.

("70 I "70
(,'711 "7,
(Abnraahl
(Abnraat,1
(Abl$raat,1

FIGURE 18. Assimilate has created a new file of
papers on Research. Such steps normally take from
1 to 5 minutes depending on the system load; they
were slower in these examPles for photographic
reasons.

1. The current ARC programming language, L10, is
more powerful than the several languages it
replaces, MOL and the SPL's. L10 permits special
purpose constructio"s anYWhere in its code. It is
a higher level language and provides greater
compiler optimization.

2. An effort has been made to modularize further
the functions within the !ystem to ease
development by a team of programmers. This
functional Moaularity will be increased with the
introduction Of the Mo~ular Programming System,
see--,4.d.2f).

Discussions of the user features of the systems and
SUbsystems making u~ NLS may be found in the fOlloWing
locations:

4c.1lblc

DNLS: See DNLS user guide. (10703.)

4dlblcl

TNLS: See TNLS User guide. (7470,)

4<11blc2

Online Team Environment

SRI-ARC 8 JUNE 1972 13041
Team AUgmentation
Basic NLS

DEX: see DEX user guide (9934,) and below (see
--,4dld).

4dlblc3

Journal: NIC Journal user Guide (7635.) and see
--,4a) and --,Sf2a) of this report.

4d1b1c4

Identification: See TNLS user guide (7470,) and see
--,4a4) in this report.

4dlblcS

Catalog: see --,4a6b2) and --,5g3).

4dlblc6

Sorter-Merger: See ---,4dlel).

kdlblc7

Baseline: See --,ke).

4dlblC~

NLS-DDT: see

4dlblc9

--,~dleua6).

NLS file structure

4dlb2

Introduction

4dlb2a

The format and structure of NLS files were determined
by certain design considerations.
4dlb2al
It is desirable to have virtually no limit on the
size Of a file. This means it is not practical to
have an entire file in core When viewing or
editing it.
The time required for most operations on a file
should be independent of the file length. That
is. small operations on a large file Should take
roughly the same time as the same operations on a
small file. The user and the system shOUld not be
penalized for lar~e files.
In executin~ a Single editing function there may
be a large number of structural operations.
A random file structure staisfies these
co~siderations.
Each file is diVided into logical
blOCKS that may be accessed in random order. There
are several types of blockS. eaCh with its own
structure.

online Team Environment
$9

4dlb2a2

SRI-ARC 8 JUNE 1972
Tea.m A11grnenta tion
dasic NLS

13041

An NLS file is made up of a header and up to a fixed
number (currentlY 465) of 512-word file bloc~s.
4dlb2a3
File Header

4dlo2b

File header contents:

4alb2bl

File creation date
Version word (changed when NLS file'structure
changes)
Identification of last user to update or output
the file.
File owner.
Left name delimiter default.
Hi~ht name delimiter default.
Number of structure pages used.
Number of data pages used.
status table -- one word per ring block or aata
block pa~e. Contains the follow1n~:
Whether oage has been modified by a user.
Free space count (for data block)
pr~-garbage collection count,
post-garba~e COllection count.
Free list pointer (fer ring blOCK)
Marker table.
structure Blbcks -- ring elements

4dlb2c

Tnpse blocks contain fixed size ring elements with a

free list connecting those not in use.

Ring

ele~ent

contents:

4~lb2cl

adlb2c2

pOinter to first eUbstaternent.
pointer to successor statement.
Pointer to the SDS that contains text for this
statement.
DEX work area.
Head of plex flag.
Tail Of plex flag.
Name flag.
Name hash.
statement identifier and free list link.
Data Block -- statement data blOCKS

online Team

Environ~ent

4dlb2d

SRI-ARC 8 JUNE 1972 13041
Team Augmentation
Basic NLS

Data blockS are composed of variable sized blocks
called Statement Data, Blocks (SDB's) Which contain
the text of NLS statements. New SDB's are allocated
in the free space at the end of a data block. SDB's
no longer in use (because of editing changes) are
marked for garbage collection when the free space is
exhausted.

4dl~2dl

statement Data AloCk (SDB) header contents:

4dlb2d2

No-longer-used SDS flag.
Length Of SDB.
Length of string 1n SDB.
Left name delimiter.
Ri~ht name ~elimiter.
pointer to ring element.
Length of name.
Last write time.
Last write ident.
string Identifiers and Text Pointers
A string identifier (STID) is a data structure used
within NLS to identifY strings (possiblY within NLS
statements).

4dlb2e

4dlb2el

If the strin~ is in an NLS statement, the STID
contains a file identifier and a rin« element
identifier.
The presence of a file identifier within the STID
all editing functions to be carried out between
files.
Text pointers are used with the string analysis and
construction !~atures of L10. They consist of an
STID and a character count.
LOcking meChaniSM -. Partial COPies
The NLS file system un~er TENEX provides a locking
Which protects against inadvertant
overwrite when several people are working on the same
file. Once a user starts modifY1ng a file, it is
"locked" bY him against changes by other users until
he deems his Changes consistent and complete and
mech~n1srn.

online Team Environment
61

hdlb2e2
4dlb2f

SRI-ARC 8 JUNE 1972
Team Augmentation
Basic NLS

13041

issues one of the commands: Update File, out~ut File,
or Unlock File Which "unlock" th~ file. Note, a user
can leave a file locked indefinitely -- thiS
protection is not limited to one console session.
4dlb2fl

When a file is locked (is bein~ mOdified), the
user who has modification rights sees all of the
changes that he is Making. However, others who
read the file will see it in its original,
unaltered state. If they try to moaify it, they
will be told that it is locked by a particular
user. Thus the users can negQtiate for
mOdification rights to the file.
This feature is implemente~ throu~h the use of flars
in the status table in the File Header and through
the partial copy mechanism.
4dlb2f2
All modifications to a tile are contained in a
partial copy file. These inclUde modified ring
elements and SDBts.
core

Manage~ent

of File

hdlb2g

S~ace

When space for more data is needed, the following
steps are taken in order until enough is found to
satisfY the reQuest:
1. Core-resident pages are Checked for SUfficient
free space.

2. Other pages are Checked for free space.
one has sufficient space, it is brought in.

3. If garbage collection on any page in the file
will yield a page with sufficient free space, then
tne p~~e which will give the most free space is
brOught into core ana garbage collected.

Otherwise a new page is created.

)

Online Team Environment
62

SRI-ARC 8 JUNE 1972 l)Ohl
Team Augmentation
Basic NLS

Logical structure

4dlb3

Introduction

4dlb)a

Interaction support

~dlb3b

Terminal interaction support

4dlb)bl

Display interaction support
The disPlay interaction support routines take
input from display users, support various L10
display input constructions Which allow the
creation of simple interaction statements, and
control the co~mand feedbaCk line, name area,
view spec area, and bug selection areas of the
display screen.
Typewriter interaction support
The typewriter interaction support routines are
primitives for interacting with a typewriter
terminal user. They inclUde input, command
feedback, literal collection, and error
feedback routines.
Sequential file input support
Sequential file input support routines take input
from DEX sequential files or a control file and
pass it to the DEX SUbsystem processor or the
control file driver system, respectively.
Subsystem control

4dlb3c

Command specification

4dlb3cl

The command specification routines receive
from the input interaction level or
sequential file input and process it as follows:

infor~ation

1. Command mnemonic inpu~ from the user is
parsed Using tests 1mplementeo as a large set
of nested case statements Which check
successive command characters.

Online Team Environment
63

SRI-ARC 8 JUNE 1972
Team Augmentation
Basic NLS

13041

2. OperanOs for commands are interpreted where
necessary.

3. Control is transferred to the appropriate
execution routine.

4. Control is transferred to the Portrayal
Generator for formatting and display.
5.

The user may repeatedly
a given tYPe with different
specifying more oarameters.
tYDes a character wnicrt can
specification, the input is
command.

execute commands ot
parameters by
When the user
not be a parameter
assumed to be a new

At any time prior to execution. the user may abort
an individual parameter specification and enter a
corrected operand without destroyin~ operands
previously entered in mUlti-parameter commands.
It is. however. possible to abort an entire
command at any time be£ore it is executed.
Su~syste~

support

4~lb3c2

These routines support the parsing of particular
SUbsystems and provide the COde necessary to
tranSlate the high level functions of each
SUbsystem into calls on the file manipulation and
portrayal generation routines of NLS. They also
have code necessary to implement any additional
facilities needed by tne SUbsystem.
portrayal

hdlb3d

~enerator

Display control

4dlb)dl

The display controller is composed of
1) a fast formatter and data structures that
allow ~LS to mOdify portions of tne display
ima~e in response to user modification of the
files being d1splaye~. and

user controls, SUCh as the DNLS jump

Online Team Environment
6h

SRI-ARC 8 JUNE 1972

13041

Team Augmentation
Basic NLS

commands, over what is portrayed and how much
is shown.
This formatter can maintain ima~es in several
"disPlaY areas" at one time, UPdating tnem as
necessary. Each area may display information'from
several files.
Typewriter terminal print control

4dl03d2

This is a formatter that is oriented toward
printing parts of a file onto a typewriter
terminal.
Hardcopy formatters

4dlb)d3

These include a relativelY simple system,
QUickprint, and a more complicated formatting
program,. the Output Processor.
QUickprint formats the text for printing as it
appears through the display or typewriter
terminal formatters.
The OutPut processor can fee~ to a variety of
different devices~ inclUding printers and
microfilm, and contrOlS the formatting of the
document according to directives embedded
within the text. For details. refer to the
"Output processor User Guide".(.11076,21.
Sequence generator

4dlb3dlJ.

SUcceeding callS on tne sequence generator create
a sequence of statements Which satisfY system or
user filters startin~ at a place in the file
specified by the user.
An example of the system filters it observes in
deciding whetner the identifier of a statement
should be part Of a sequence lS the level
truncation views~ec Which permits the diSPlay
of only those statements above partiCUlar
levels in the NLS hierarchical file structurp..

These

s~quences

online

of statement

T~am

i~entif1ers

Environment
6S

are used

SRI-ARC 8 JUNE 1972
Team Augmentation
. Basic NLS

l)Ohl

bY formatters for terminal or hard-copy portrayal,
oy compilers, or by processors Which manipulate
files, such as the sorter.
see--,4dle4) for a discussion of tne sequence
~enerator with user programs.
User filters and re£ormatters

4dlb3dS

The user may write and incorporate additional
filters which the sequence generator will use as a
final acceptance test. These user-SUPPlied
filters may reformat the text of the file for
special apPlications or views.
user sequence

~enerators

4dlh3d6

The user can write his own sequence ~enerators
which can make use of any NL5 routines.

E1iting

l!dlb3e

File manipulation

al~orithms

1I.dlb,3el

These algorithms carry out tne file manipulation
commands of NLS. They decide what is to be done
by the textual and structural editing routines and
in what order. utility routines actuallY
manipulate the NLS files.
So~e commands make use of textual ed1tin~
routines exclusively (e.g., "Insert Text");
some use onlY structural editin~ routines
(e.g.,"Move statement"); others use a
combination of the two (e.~., "Insert
statement").

These algorithms can move and copy text froM one
file to another tnrou~h cross-file editing ••

Structure editing

hdlb3e2

These routines inVOlve tne manipulation Of ring
structure alone and do not alter the contents of
the statement data blocks which contain the text.

online Team Environment
66

SRI-ARC 8 JUNE 1972

1)041

Team Augmentation
Basic NLS

Text editing

4dlb3e3

These routines edit the text of NLS statements.
Content analysis features of L10 are use~ to
determine where changes shoul~ take place) the
string manipulation and SDB manipulation machinery
then ch&nRe the contents Of the file.
special

processors

pur~ose

4dlb3t

Inserting and outputting sequential files

~~lb3fl

These processors create NLS files from sequential
files and vice versa.
compilers

4dlb)f2

currently four compilers are available trom NLS.
In addition we are now studyin~ ways of making
available through NtS the assemblers of the TENEX
operating system.
The tour compilers now available are:
L10. a procedure-oriented, block structure~
developed by ARC for use on the

lan~uage

PDP-~O,

A subset is available as the content analyzer.
(9246,10) and see --,4dle4d) in this report.

IMOL, a procedure-oriented, block structure~
language Which prOduces COde for the IMLAC
com~uter-~isplay.

Tree-Meta, a compiler-compiler used bY ARC
staff to develop other languages, such as L10
and IMOL. (See the Tree-Meta Report (10869,,)
and -·,4d2e ) of this report.)
MPL. the MOdular Programming Language, an
eXDerimental new language to be use~ to rewrite
NLS. (See --,4d2f)
Text is passed to these compilers through the

Online Team Environment
67

SRI-ARC a JUNE 1972
Team Augmentation
Baslc ~LS

l)Ohl

seQuence generator (and thus can be filtered and
reformatted enroute to these various processors).
utility routines
NLS

40103g

file system

4dlb3g1

These routines imclement and maniPulate the data
structures in Tenex files whicn NLS uses. Unlike,
other routines discussed above. they are cognizant
of and deal with the data structures and the TENEX
timeSharing system environment.
They are reSPonsible for:
Opening and closing files.
Managing the portion of core set aside for file
pa~es.

writing on and reading from files.
Manipulating ring elements and SDB's.
Moving within the NLS file structure by
fOllowin~ ring element oointers.
st~tement

NLS

strin~

name loOkup.

system

4dl03g2

supports string maniPUlation construcions in the
L~O l~nguage ana aeals with tne NLSStatement Dat~
Block and Ring Block structure.
Miscellaneous support routines
BasiC L10

lan~uage

4dlb)g3

support routines.

Call mechanisms.
Display support routines
Information
Manipulatin~

writ1n~

on the screen.

information on tne screen.

Online Team Environment
68

4~lb3~4

SRI-ARC 8 JUNE 1972 130hl
Team Au,-mentation
Basic NLS

Basic input routines

4dlb3g5

Basic typewriter terminal output routines

4dlb3g6

NLS -- New features

hdlc

The following fe~tures, common to both DNLS and TNLS, are
new on the PDP-10:

4dlcl

Name Delimiters

~dlc2

A user maY specify the characters to be used for left
and ri~ht name delimiters for statements within any
structural entity in an NLS file. The system defaults
are left and right parentheses.
JUMP to Word/Content

hdlc2a
4dlc)

The user was provided with tne capability of Ju~p1ng to
the first or next occurrence Of a specified word or te~t
hdlc3a

str~n~.

Null

4dlc4

Fil~

A new command, NUll File, has been added to TNLS and
DNLS. Given a file name, it will create an empty NLS
file with that name. Upon completion of the command the
user is left with the OM (Control Marker -- TNLS) I
display start (DNLS) at the origin of this new file.
4dlc4a
output Assembler

4dlc5

Sequential files acceptable to the DEC assembler may be
created from NLS files using this command.
output Compiler

4dlc6

The capability to drive TREE-META produceO compilers
(inclUding the L10 langua~e compiler) directly from NLS
files is available.
output

4dlc5a

s~quential

4dlc6a
4~lc7

The user may produc~ a seqUential file that corresponds
to his NLS file. Spaces are used to indicate the level
of a etatement.

online Team Environment
69

4dlc7a

SRI-ARC 8 JUNE 1972
Team Augmentation
Basic NLS

13041

Insert Sequential

4dlc8

The Insert sequential File command converts sequential
files into NLS for~at. This also allows the user to
convert XDS-9hO files to TENEX-NLS format.
output Quickprint

4dlc8a
hdlc9

since users often want quick nard copy of their files,
the output ouicKPrint command was added. UnliKe the
output Processor, this formatter does not maKe use of
embedded formatting directives. The command offers the
user a oefault file name and a aefault of 1 for the
number Of copies to print; these may be superseded bY
trte user. After the document is formatted it will be
automatically spooled for printing. Viewspecs in effect
at the time the command is given control the format and
content of tne printed text.
update File .- File LOCking

~dlc9a

~dlclO

The NLS file system under TENEX provides a locking
mechaniSM, whicn orotects against inadvertant overwrite
when several people are working on the same file. once
a user starts mOdifYing a file, it is "locked" bY him
aga1nst chan~es by other users until ne dee~s his
changes consistent and complete and issues one nf the
commands: Update File, OutPut File, or UnlOCK File which
"unlock II the file. Note, a user can lea.ve a file locked
inaefinltely -- this prot~ction is not limited to one
console session.
4dlclOa
when a file is locked (is being mOdified), the user
who has mo~ification rights sees all of tne changes
that he is ~aking. However. others who read the file
will see it in its original, unaltered state. If
they try to mOdify it, they will be told that it is
loc~ed by a particular user.
Thus the users can
ne~otiate for modification rights to the file.
udlclOal
the users are also allowed to enter "Browse MOde", which
several users to simultaneously mOdify a file.
When they leave browse mode, one of them ~ay elect to
keep his chan~es if no one has the file locked, in whicn
~ase he locks the file until an update or output command
is executed bY him.
4alclOb
~llows

online Team Environment
70

SRI-ARC 8 JUNE 1972 1)041
Team Augmentation
Basic NLS

Goto Exec

4d1cll

The user may start a new copy of the TENEX EXECUTIVE
below NLS in the jOb's process structure and execute
arbitrary EXEC level commands, including runnin« other
SUbsystems. Then, by issuing the EXEC quit command, tne
user is returned to NLS, exactlY as he was before
issuing the Goto Exec command.
4dlclla
Execute Logout

4dlc12

The n~w Execute Logout command is equivalent to 1ssuin«
the EXecute Quit command in NLS and following it with a
LOGOUT command in the EXEC.
hdlc12a
The following features in DNLS are new on the PDP-10:

4dlc13

SPlit screen and Cross File Editing

4dlclh

Display screen SPlitting and Formatting
FIGURE 19.

hdlc14a

(OpPosite) overall NLS logical structure.
4dlc14al

Goto Display Area Control

4dlclha2

Horizontal Split
This splits the displaY area in Which the BUG
oceurred horizontally (into an upper and lower
se~ment) at the bugged location moving the
image of tne original diSPlay area to the upper
or lower segment depending on Whether tne
cursor is above or below the bugged position
when the final CA is input.
No displaY area will be created which is
smaller than 2 lines bY 20 columns (us1n~ the
character size of the original display area).
vertical SPlit
This splits the displaY area in which the BUG
occurred vertically (into a left and right
seg~ent) at the hugged location moving the

Online Team Environment
71

SEQUENTIAL
FILE INPUT

SPECIAL
PURPOSE
PROCESSORS

TB-8754-2

FIGURE 19

OVERALL NLS ORGANIZATION

SRI-ARC c JUNE 1972
Team Augmentation
Basic NLS

130hl

image of the ori«inal disPlay area to the left
or rignt segment depend1n~ on wnether tne
cursor 1! to the left orri«ht of tne buggea
Position wnen the final CA is input.
Move

Boun~ary

The selected boundary (first BUG) is moved to
the new ~osition (second BUG). A bOundary will
not be moved past a boundary of a neighbor. A
boundary is move~ for all display areas for
which it is a boundary. Any resulting display
area Which is smaller than 2 lines by 20
COlumns will be deleted.
Format DiSPlay Area
Character Size
Tne current character size of the diSPlay ar~a
that currently contains the cursor is
displayed, and the user may type a number (0,
1, 2, 3) for a neW character size. Different
display areas may simultaneously have different
character sizes.
Clear DisplaY Area
Th~ bugged diSPlaY area is cleared, i.e., the
ima~e is erased, the return and file return

rings are released, and the association of a
file with that display area is removed. The
disolay area itself is not deleted.
cross File

Edit1n~

in DNLS

hdlcl~b

One may freelY edit ana jump usin~ several display
areas. The position of the cursor is used to resolve
amb1~uiti~s.
hdlc14bl
For example, if one executes & Jump command, the
position of t~e cursor when the final command
accept is enterea determines in which display area
the new ima~e is to appear.
~lso,

on~

changes viewspecs using the leftmost

Online ream Environment
72

SRI-ARC 8 JUNE 1972 1)041
Team Aucmentation
Basic NLS

two buttons of the mouse, the viewspecs ot the
display area containing the cursor when the
buttons go down are useO as the initial values and
are disPlayed in the views pee area. Wnen the
buttons are released, the disPlay area containin~
the cursor receives the new viewspecs.
5ubstltute commanrc Change

4dlc15

SUbstitute in DNLS (and soon in TNLS) has been ex~anOed
to allow words, visibles, etc., to be SUbstituted in a
structural entity.
4dlc15a
All of the old basic NLS SUbstitute commands are still
available and work as Qefore. In addition, the
commands, SUbstitute [text entity} in (strueture entity)
are now available. Text entity may be Character, Word,
ViSible, etc., and Structure entity may be Statement,
Branch, Groue, or Plex.
4dlclSo
During the suostitution, the delimiters of the
candidates for SUbstitution are ooserved. For example.
if the user issues Substitute Word ••• "the" for "an" in
the statement "DO you want an igloo instead of another
l inclUdes a
formal descriPtion Of tne Tree Meta langua~e taKen from
a lonrer Tree Meta report being completed.
Ud2e3d

Online Team Environment
92

SRI-ARC 8 JUNE 1972

13041

Team Aurmentation
Basic NLS

Modular

Pro,rammin~

4~2f

GoalS

4d2fl

The MOdular programming System (MPS) is a set of tools
for the development an~ continued evolution of large
software systems in an interactive environment. All
such large software systems share certain
characteristics:

402fla

(al) they are the work of a group of people whose
mernbersh1c will change over time;

4d2flal

(a2) tney are necessarily constructed from a number
of separately developed programs;

4d2fla2

(a3) they evolve and

~row throughout their lifetimes
(and there is evidence that theY also "age" (10481). 4d2fla3

The MPS oroject aims to decrease the effort required to
build and evolve such systems and to increase the
reliability of the resultant prOducts. As a specific
test of its capabilities, MPS will be use~ in the
rewritin~ and restructuring of the NLS system developed
at Stanford Research Institute.
Desirable Characteristics

4d2flo
4d2!2

pOint8 al, &2, a3 are axiomatic statements &oout the
dynamics of all l&rge software systems. The followin~
discussion uses these and a few other axioms to
establish desirable characteristics for MPS. They are
intended only to lend plausibility to the set of
capabilities Which the MPS project is investigating.
Furthermore I the "lo,ical conclusions" onlY represent
desi~n Choices to satisfy the axioms; other cho1c~s
coUld certainlY be made Which would not be inconsistent
with the axiom set, but that is another research
project. HopefullY there is a minimum of hidden meanin~
in the following discussion: each axiom and consequence
is intended to be taken strictly at face value.

~d2f2a

We first add two more axioms to the above set:

4d2f20

(ah)
Large software systems must be able to take
advantage of available hardware for efficiency.

online Team Environment
93

4d2f2bl

SRI-ARC 8 JUNE 1972

Team Augmentation
Basic t.JLS

(as)

13041

bugs are not known before they occur.

pro~ram

4d2f2b2

(a4a) al-a4 implY that software components, nereafter
calleo modules, should be separately compilable and
debuv.~able.
Therefore there must be a way of linking or
binding separate components together to provide an
environment (data and pro«rams) within Which a mOdUle
can be debu~~ed.
hd2f2c
(a6) In an interactive pro~ramm1ng environment. Users
must be able to develOp and use debuRging toolS
applicaole to programs in the same programming system
(6035,)

C10lL78,).

a4a, as, and

then imply that

(a6a) the environment of a program must be
dynamicallY alterable;

4d2.f2d
~d2f2e

4d2f2el

(a6b) a nro~ram Should not have to be altered When
its environment changes in ways which dO not affect
the semantic intent Of the program -- this is called
pro~ramming generality.
4d2f2e2
(a3a) a3 su~~ests that a desirable characteristic for
tools for build1n« large systems should oe that the
energy to chan~e part of the system Should oe more a
function of the comOlexitv of the chan~e than Of the
size of the system.

4d2f2f

(a3b) A new system alwaY$ has parts Which are
functionally similar to previously developed systems.
The new system may therefore oe regarde6 as a change
(though perhaPS sUbstantial) to an older system. a3a
then points out the nece~sity for bein~ able to reuse
components WhiCh ~ave been made reliable through uSage.
This increases th@ initial reliAbility of tne neW system
and aecreases its cost.
4d2f2g
(a3c) One waY of constructing useful components is to
builo them from combinations of already existin~ mOdules
(a)b).
Hence tnere must be a way of bUndling useful
conf1rurations to~ether as seemingly atomic modules se
they can be readilY reused.
hd2f2n
MPS Capabilities

hd2f3

online Team Environment
94

SRI-ARC b JUNE 1972

Team

1]041

Au~mentation

basic NLS

TO satisfY tnese objectives, MPS has concentrated on
providing the following c~pabi11ties:

~d2f3a

Control mechanisms ~hioh enable mOdules to be linked
~ogether with a minimu~ of built in assumptions about
how ~ach interorets control transfer over the link
between them.
4d2f3al
Simpl~ function call and return mechanisms alone
do not satisfy this requirement.

Data definition facilities that:

4d2f3a.2

clarifY the soecif1cation of the data structures
which, together with control, completely specify
the interfaces between modules;
are potentially economical in space and accessin~
speed witnout being dependent on a particular
m9·chine;

are an aid in developing and describing pro~ram
components and the structure of algorithms.
Facilities for dynamicallY binding the virtual
Objects required bY a mOdule for execution to real
Objects.

4d2f3a3

For eXample, for binding a procedure call to a
real procedure. a "typed" pointer to a ·jata
structure of tne correct type, etc. The set of
bindin~s for a module's virtual objects at a given
moment comprises th~ environment for tnat module.
Complete accessibility to the MPS "virtua.l machine"
(which is a set of primitive MPS programs) and to MPS
programs as data structures.
4d2f3a4
This enables debugging and measuring tools to oe
built ~s standard MPS programs and along with
dynamic binding alloWS such tools to oe brought to
bear on MPS programs whenever necessary.
The ability to bundle 3 configura.tion of data and
program modules together as a mOdule which may be
save~ for later use just as a Simple, atomic mOdule. 4a2f3a5

Online TeaM Environment
9.5

SRI-ARC e JUNB 1972
Team Au~mentation
Basic NLS

130hl

This allows syste~s to be partly initialized bY
p~rtially executing them and tnen bundling them up
for later use with the initialization computations
factored out;

It also allnws a configuration that has exhioited
a bug to be saved away for later perusal with the
state as it was when the bug was discovered;
Lastly. it allows standard mOdules to oe huilt by
confi!uring tnem from other modules in the spirit
of using alreadY aVailable components whenever
possible and provides some logical completeness to
the system.

Online

Tea~

~nvironment

SRI-ARO 8 JUNE 1972 13041
Team Au~mentat1on
Internal organization

INTERNAL ORGANIZATION

During the past year, several ARC organizational arrangements
were introauced, centering, in the early part of the per1o~,
mainlY on line activity structure and associated roles.
The creation of pusher (task leader) roles for tasks and
coordination roles for system arChitecture. methodolo«Y, and
personnel resources Place~ the responsibility for these
efforts more directly on selected individuals.
pUSher rOles Were carried out in the framework of the
developing Baseline Management System. Coord1natinr roles
were also carried out in this environment. The teChniques
for performing these roles still leave much to be desired.
our plans to record task requirements and designs will
aid this process.

In the Fall of 1971. we set up a four-man Executive Management
Committee (EMC) to carry out many of the day-to-day operat1n~
management taSkS. M~rnbership wae later changed to three.
The EMC has dooumented its meetings
as they occurred.

throu~n

Journal entries

PODAC is to deal with ARC peoPles' beliefs, interests, and
feelings, helping people and the organization to deal with
the goa18 and line activities that result.

4el

~ela

4elal
4elala

helb
4elbl

4elb2

During the past few months, a new, more broad overall
organizational structure has been in the process of formation.

~elc

This consists of three main activities that have been set
uP to cover our framework and goal settin~, line operation,
and personal and organizational development needs.

4elc1

These activities are called: FRAMAC, LINAC, and PODAC.

4elc2

FRAMAC is to discus! and define the ARC framework and
set long-ran~e goals and plans.

~elc2a

LINAC is to carry out activities within the framework
that Move us toward the goals, with more aetai!ed,
shorter-range Plan formulation.

4elc2b

Online Team Environment
97

SRI-ARC 8 JUNE 1972' 13041
Team Augmentation
Internal organization

PODAC is to deal with ARC peoples' beliefs, interests,
and feelings. helping people an~ tne organiza~ion to
deal with the goals and line activities that result.
These are

~ocuments

in more detail below and in
(10331,), (10034,), and (8651,) respectively.

(
4elc2c

d~scribed

FRAMAC

4elc2d
4e2

We have launched an activity within ARC
Activity (FRAMAC).

calle~

our Framework

FRAMAC's goals and ,eneral metnod ot approach arel
TO provide a continuing. puroosefullY run forum, for
develop1n~ the framework of concepts, strate~ies,
prinCiples, and goals within Which we will pursue our
planning, oromoting, growing, LINAC and PODAO activities,
and interaction with the world. We are holding a regular
sequence of meetings, where dialo~ is expected.Recor~s
are kept and Journalized. A COherent, explicitlY developed
Framework Section of the Handbook will ensue.

4e2a
ke2b

4e2bl

The first meetings' notes are recorded in (10458,',
(104S9,)~ and (10S53,).

he2bla

our First Stage (starting MaY 1972 and lasting several
montns) includes:

4e2b2

Piecing together and brine about a general
of Dr. Engelbart's personal frameworK, tne
history that brou~ht us to wnere we now are, an~ the
current state of our implicit framework (i.e. the
practices, principles, goals, etc. that we can se~ nave
affected our current state and direction).
4e2b2a
a)

understandin~

b) Bringing each Of ourFRAMAC participants to
understand reasonably well where each of the others
standS on wbat we consider to be the important faeets of
the framework, in terms not onlY of degree of nis
unaerstanding, but &150 of the degree and n&ture of his
interest. beliefS, and attitudes.
4e2b20

our Second stage will include:
A continuing process of framework analysis ana

Online Team Environment
98

~e2b3

SRI-ARC 8 JUNE 1972 13041
Team Augmentation
Internal Organization

development. The objective is to continually evolve
towar~ a "most useful framework," one that 1s kept
complete and uPdated as part of our HandbooK, and that
is referenced constantly 1n our planning, deSigning,
evaluating, and teachin~.

4e2b)a

we plan that in this stage we would jUdicioUslY
integrate concepts, considerations, viewpoints, and
analyses of others, via an organization and process Yet
to be decided upon. Durin~ tne Stage 1 process, Dr.
~nvelbart will fUrther develop oarts of his framework
and will describe those parts that bear upon the process
of further ARC Framework develo~ment.
4e2b3b
We clan on an approach here that is much as if we were running
a graduate ae~inar to impart where Dr. Engelbart is in his
thinking. An unbroken series of individual presentations
(lecture model) won't accompliSh what we want. We expect to
haVe both prepared and extemporaneous presentations, but in
limited cuts and modules from Dr. En~elbart's an~ others'
frameworks. interspersed with multi-way group dialog sessions
eaCh of whose content affects succeeding presentations. we
dontt Know where ~ost of the participants are in tneir
thinkin~ now, with respect to under$tandin~ most of the issues
involved, nor what kind of presentation it woUld take to
prOduce a given change in understanding on any given issue.

4e2c

we speaK of developing a "general unQerstand1n~" Of our
framework (which may involve a lot of work); but ~herealso
is the matter of the distribution amon~ the participants in
the nature and degree of their "beliefs and attitUdes"
(B&A) about the various facets of the framework.
It is
important for Dr. En~elbart at least to know what this BAA
distribution is; and it may prove important to the
succeeding FRAMAC stages to work at bringing about a closer
~rouping of ARC oeoPles' B&A relative to certain issues. ~e
expect that we will want to deal with this, but how much
~nergy to spend. and what part within FRAMAC and what part
in PODAC, will have to be decided as we progress.

4e2cl

About tne initial composition ot our FRAMAC group:
we had been visualiZing a small fRAMAC ~roup, considering
the type of dialog W~ hope for. But When we reviewed our
LINAC Planning~team compositton. we decided that there is a
sUch streng interaction "between our current planning

Online

Tea~

Environment
99

he2d

SRI-ARC 8 JUNE 1972

1)041

Team Augmentation
Internal organizatio"

p,xercise and our Framework that we couldn't seem to find a
logical way to cut the group membership smaller. The
initial FRAMAC ~roup numbers nineteen ARC people plus two
other SRI management people.
LINAC

4e2~1
~e3

We have launche~ an activity within ARC called our Line
Activity (LINAC).
LINAC serves several basic

nee~s:

Modularizin« our way of doing things .- something that
the size and complexity of our activities require.

ne3a
~e3al

4e)ala

E5tablishin~ interdependence relationships tnat will
~ive us v,luable experience for tne !u~ure problems of
mana~1ng a considerably larger anO more varied activity

within an increasinglY complex operational and technical
environment.

~e3alb

Establish1n~ the activity frameworK within which we can
pursue our new-contract commitments to ARPA (as per our
proposal of 29 JUlY 1971 .- 7404,)

4e1alc

In LINAC's organ1zat10n. our external projects are the
driving forces -- wh~re a pr~ject is an exolicit activity
involvin~ resource interchan~e with outside organizations.
The other specific activities within ARC are to serve the
orojects' ~oals. and will have all Of their resources
allocated. alon~ a contractin~ Chain, from the projects.

ue3a2

Along with this (internal) contracting system will come
specific development and application of conventions,
procedures and aidS for handlinr. estimates, resource
allocations, buagets. reserves. account1n« and
resource-control measures as required to operate the
organizatl0n.

~e3a2a

~e expect that many of our internal activities will
emerge from multi-party negotiations and proceed under
contracts involving several bUyers.

4e3a2b

some of our actiVities will be funded bY what amounts to
a taxation upon all or some. of the projects. Such

Online Team Environment
100

SRI-ARC 8 JUNE 1972

Team
Internal

13041

Au~mentatlon
Or~anlzation

taxation measures will be established and monitored with
due representation by the concerned parties.
4e3a2c
ARC planning and task activities are currently conducted in
the following LINAC organization:

ue3b

oPERATIONS
~e3bl

AOministrat1on
computer Service operations • Hardware
computer Service operations • SOftware
computer Service Operations - Operators
people S~rvice operations
User Interface
nEVElOPMFNT THRUSTS
Development Coordination
Delivery and Marketing
Dialo, Support System (DSS)
Documentation Production and support System (DPeS)
Baseline Record System (BRS)
System Developers Handbook system (SDHS)
software Engineering Augmentation System (SEAS)
General Development (not inclUded in abov~ thrusts)
PROJECTS
ARPA/RADC Project: Team Augmentation portion
Administration
ARPA/RADC Project: Network Information Center Portion
(NIC)

Administration
computer Service operations
Peop~e Service Opera~1ons
Net Interface (Station Agent and Net particication)
NIC Development
ARPA/RADC Project: Mini-console
Administration
System Development
ARPA/RADC Project: MPS Cooperation (Xerox)
Administration
Modular pro~ramming System Development (MPS)
ONR project: System Developer's Intelligence System
(SDIS)

Administration

online Team

~nvironment

101

4~3b3

SRI-ARC 8'JUNE'1972 13041
Team Augmentation
Internal Organization

RADC Project: Baseline Management
Support

Sy~tem

Development

Ad~inistrat1on

SRI OVERFEAD ACTIVITIES
During the earlY stages of the new LINAC, the following
actions are takin~ place:

4e)b4
~e3c

Each of the main activities is developint the framework of
a plan, with a reasonable amount of informal

intercommunication and coordination between plans.

4e)cl

!.ight people Who carry key ARC planning roles will meet
regularly to serve as a "Plannin~ and Executive-Review
committee" (PERC).

4e3c2

one important function for PERC during this time will be
to develop recommendations for refinements to the LINAC
system Of roles and processes.
ue3c2a
Anoth~r function will oe to participate in and reView
the operational decisions that must be made to
coordinate and manage the efforts Of the projects and
developmental thrusts.

Within the three parallel pushes of FRAMAC. LINAC, an~ PODAC.
our persistent eMQhasis will be toward "coordihated-system"
aspects of both our way of workin~ and of the augmentation
system(s) we dp.velop.
PODAC

4e3c2b

4e3d
4e4

In January 1972, AHC established a regular channel for
Personal ana Organzational Development named PODAC. Our
Planning for PODAC was integrated with planning for LINAC and
FRAMAC discussed above.
Est~blishm~nt of PODAC arose from the conviction that we,
who tell the world that we are learning hoW to show other
teams how to pursue ,oals MOre effectively, must constantlY
examine ourselves (the "example" that we work With), both
as an or~anizaton and as indiViduals, to understand how we
are dOing, and hOW we can imcrove.

ar~

convinced that unless we have a strong, constant,

online Team Environment
102

4e4a

4e4al

SRI-ARC 8 JUNE 1972 l)Ohl
Team Augmentat10n
Internal Organization

ind pervasive attitUde that we want to keep developin,
ourselves, and unless we consciously keep trYin~ to do
so, then we are fooling ourselves about seriously
pioneerin~ this augmentation system development.

4e4ala

TO work on this, we need a flow of information having to
dO with ~oals, attitudes, ambitions and feelings as they
relate to the common pursuits, and purposeful discussion
about strengths, weaknesses, and means for improvement.

~e4alb

to pstablish PODAC. we divided tne staff into four groups of
eight or nine people each.

4e4b

The ~roups, called POD's, are balanced in age, sex,
prOfessional trainin~, length of association with ARC, work
roles, etc.

4e4bl

POD'S are named Cedar, Fir, Oak, and RedwoOd.

4e4b2

EaCh group meets weekly for two hours.

he4b3

Each such group apPOints its own representative to a
central committee, PQDCOM, that helps to co-ordinate and
~uide the PODAO.

hehb4

PODAO does not eXist to vote on What ARC will dO. PODAC has no
line-management responsibilities or authority. It is
"orthogonal" to the management structure that commits
resources, sets targets, hires, reViews, and is held
accountable.

he4c

Instead, it provides an or~anized mechanism for
interactions among all parties toward affecting the
understandi~g, beliefs, and attitudes of each other, as a
means of affecting the deciSions and actions w1thl" ARC,
toward what each tninks is the best set of goals,
organizat~on. products, behavior.

4e4cl

It is a forum for the expression of concerns, beliefs,
ideas, feelines, and dissension existing within any
person or group in ARC about the way tnin~s are being
done (or not bein2 done), about our goals, etc.

~ellcla

It is a way to keep everyone informed about tne prOblems
and opportunities facin~ ARC and its penple ana its
~oals.

4e~clh

Online Team Environment
103

SRI-ARC 8 JUNE 1972 1)041
Team Augmentation
Internal organization

PODAC has been active for three months at the end of this
contract period. It is not yet easy to evaluate our
accomplishments.
Meetings of the groups described

varie~

4e4d

considerablY in
4e4dl

conten~.

on o·ne hand many members feel tha t people now
communicate somewhat more easilY among themselves within
the POD's an~ feel that they had some fruitful
discussions of the goals and strategy of our research
and of personal effectiveness at work.

~e4dla

on the otter hand many some people have felt
indifferent, hostile. or anxious when confronted with
the mandatorY but undefined oarticipation, and have
withdrawn or participate onlY very passively.

~e4dlo

Very little agreement on large issues or other action
has yet resulted.

4e4dlc

PODAC has invited speakers on organizational and Personal·
neYelopment. instituted a small library in the fiel~,
instituted augmented procedures for cataloging the library,
and formed several special interest sUb~roups.

REFERENCES

4e~d2

(5139.)D.C. En~elbart and staff of ARC (SRI-ARC), computer
Augmented Mana,ement-System Research and Development of
Augmentation Facility·-Final Report Augmentation Research
Center, Stanfor Research Institute, MenlO park, Califorinia
94025. RADC-TR-70-~2. AD 709,211. APril 1970. 268p.

4!1

(6035.) R. A. Krutar. Conversational Systems programming - Or
Plagiarism Made Easy. computer Science Department,
Carne~ie-Mellon University, Pittsburgh, Pennsylvania 15213. 3
March 1971. 23p.

4f~

(69l2.)Walter L. Bass (SRI-ARC). Output Processor Brief user
Guiae. AugMentation Research Center, Menlo Park. California
94025. 27 April 1971. SP.

hf3

Pro~ram

(740~.) Proposal for Researcn (to RADC/ARPA ISU 7l-94J. Network
Information Center and Augmentation system Development. SRI NO.
ISU 71-94. Augmentation Research Center. Stanford Research

Online Team EnVironment
lOll.

SRI-4RC 8

JUN~ 1972
130hl
Team Au«mentat1on
References

Institute. Menlo park. California 94025. 29 July 1971. Separately
paged. (Entered in SRI-ARC Journal 18 october 1971.)

-4f4

(7~70.) Network Information Center, Augmentation Research Center,
Stanford Research Institute. Menlo Park, California 94025. TNLS
User Guide: Pr~face, Syntax and contents. 1 September 1971.
Separately paged.

NIC Journal System User Guide. section 2, Journal SYstem.
Research center, ~etwor~ Information center,
Stanford Research Institute. Menlo Park, California 94025. 1
OctOber 1971. l3n.

4£6

(7638,) NrC Journal System User Guide, Section 3, Identification
System. Augmentation Research Center, Network Information Center,
Stanford Research Institute. Menlo Park, California 9402;. 1
OctOber 1971. 160.

4£7

(1639.) NIC Journal System User Guide, Section 4. Number System.
Augmentation R~search center, Network Information center,
Stanford R~search Institute, Menlo PrK, California 94025. 1
OctOber 1971. SP.

4f8

(8277.) D. C. En~elbart (SRI-ARC). Network Information Center and
Computer Au~mented Team Interaction, Interim Technical Report.
Augmentation Research Center, Stanford Research Institute, Menlo
Park, california 94025. Rome Air Development Center, ARPA.
RADC-TR-71-175, AD 737 131. ]0 June 1971. l04p.

4£9

(7637.)

Au~mentation

(86S1.) D. c. En~elbart (SRI-ARC). To Launch PODAC. Augmentation
Research center, sta~ford Research Institute, Menlo Park,
California 94u25. 25 JanuarY 1972. 6p.

hflO

(9241.) Harvey G. Lehtman (SRI-A~C). DEX-2 Proposea Desi~n.
Research Center, StanforJ Research Institute, Henlo
Park, california 94025. 22 february 1972. 24p.

4fll

(9246.) Au~mentation Research Center, Stanford wes~arch
Institute§ Menlo parK. Californi~ 94025. L-10 programming Guide
(a user guide). h April 1972.1000.

uf12

Au~mentation

(9697.) D. C. Enrelbart, W. K. English, J. F. Rulifson (SRI-AHC).
DevelOnment of a ~ult1disPlay, Time-Shared Computer F'~cility ana
CompUter-Augmen~e6 Mana~em~nt-Sy!tem ResearCh. Augmentation
Research center, stanford Pe!earch Institute, Menlo ParK,

online Team Environment
105

SRI-ARC 8 JUNE 1972
Team Augmentation
References

13041

California 94025. Rome Air Development Center, ARPA. AD 843 577.
April 1968. leop.

4fl3

(9934,) Augmentation Research Center, Stanford Research
Institute, Menlo parK. California 94025. Deferred Execution (DEX)
User Guide. 16 June 1972. 66p.

4f14

(10034.) D.C. En~elbart (SRI-ARC). ro Launch LINAC. Augmentation
Research center, stanford Research Institute, Menlo parK,
California 94025. 7 April 1972. 6P.

4£1)

(11076.)SRI-ARC,OUTPUT PROCESSOR USER' GUIDE -Introduction,Augmentat1on Research Center, Stanfor~ Research
Institute. Menlo ParK, California 94025. 6 September 1972. Sp.

4f16

(10331.) D. C. Enge1bart (SRI-ARC), To Launcn FRAMAC.
Augmentation Research Oenter, Stanford Research Institute, Menlo
Park, california 9h02S. 4 May 1972. 3p.

4£17

(10457.) James C. Norton (SRI-AHC). Initial FRAMAC Meeting Notes.
Augmentation ResearCh Center, Stanford Research Institute, Menlo
Park, California 94025. 23 May 1972. 14p.

hf18

(10459.) James C. Norton (SRI-ARC). Second FRAMAC Meeting Notes Centering on th~ concept of Frameworks. Augmentation ResearCh
Center. Stanford Research Institute, Menlo Park, California
94025. 1 June 1972. 390.

4f19

(10~78.)

James G. Mitchell, A. J. perlis, H. Van Zoeren. LCC: A
for conVersational computing. In: J. Reinfelds, M.
Klerer. EdS. Interactive Systems for Experimental APplied
Mathematics. Academic Press, New York. 1968. p.203-214.
Langua~e

(10~79.)

ReView.

James G. Mitchell. LCC. In: Computer Science Research
university, 1969. p.21-29.

Carnegi~-Mel1on

4f20
4f21

(10uSl,) L. A. Belady, M. M. Lehman. programmin~ System Dynamics
-- Or the Meta-DYnamics of Systems in Maintenance ana Growth. IaM
Research Document RC 3546. T. J. w~tson Research. center,
International Business Machines Corporation, YorKtown Heights,
New York. 17 September 1971.

4f22

(lO~S3J) RichardW. watson (SRI~ARC). FRAMAC Notes, May 19
l1972J. Augmentation Research Center, Stanford Research
Institute, Menlo Park, California 94025. 19 May 1912. 2P.

4f23

Online Team Environment
l06

SRI-ARC 8 JUNE 1972 13041
Team Augmentation
References

(10703,) Augmentatio~ ResearCh Center, Stanford Research
Institute, Menlo Park, California 94025. DNLS Preliminary
Reference Guide. 21 June 1972. SeparatelY paged.

4f24

(10869.) D. I. Andrews, H. G. Lehtman. W. H. Paxton (SRI-AKC).
Tree Meta - A Metacompiler for the Augmentation Research Center.
In process. Unpa~ed.

hf25

online

Tea~

Environment

107

SRI-ARC 8 JUNE 1972

13041

Network Information Center
Develooment an~ Operations
IntroCiuction

online Team Environment
108

SRI-ARC 8 JUNE 1972 130~1
Network Information Center
Development and Operations
Introduction

NETWORK INFORMATION CENTER
by Hichard W Watson, Jeanne B North, James g White,
John T Melvin, W~lter L Rass~ James C Norton,
cindY Pa~e, Dirk H van NouhUys, and the Staff Of ARC

Sa.

INTRODUCTION
The ARPA computer Network (ARPAN~T) has been eatablisned to
provide both a new experimental tyoe of comMunication facility
and a base for resource sharing.
The ARPANET community can oe viewed as a collection of resources,
peoPle, hardware. sOftware, data, and special services w~ich can
be brought together for short or long periods in different
conli~urat1ons to work coo~erativelY on a given problem or task.

5a2

In this context trte development of the ARPANET can be viewe~
as a multileveled experiment in learning how to bring together
and make available these distributed resources.
At ~he lowest level are the problems of creating a basic
communication facility which allOWS different types and
confi~urations of computer hardware to communicate.

5a2b

At intermediate levels are the developments of protocols which
al16w classes of computer pro~rams to communicate with each
oth~r and permit data to be shared.

t;a2c

At hi«her levelS still are the processes Which assist people
to ~ind the geographically dlstrioute~ facilities they need to
solve or studY a oroblem and WhiCh allow distribute~ peOPle to
wor~ together effectivelY.

5a.2d

The Network l~formation center (NIC) is one part of the AHPANET
interested in the higher levels Of problems. A
service such as the NT,C helps to create and sustain the sense of
community needed in an experiment such as that of the ARPAN~T.
The NIC is more than a classical informat10n center. as that ter~
has COme to oe used, in that it ~rovides a wider range of
serviceS than just biblio~raPhic and "library" type servicfl's.
experi~ent

The Network Information center (NIC) is an experiment in settin~
up and running a ~eneral purpose information service serving the
ARPANET community (botn those indlviduals and ~roups with direct

online

T~am

Environment

109

SRI-ARC & JUNE 1972 l]Ohl
Network Information Oenter
Develooment and Operations
Introduction

access to the network. an~ those associated with work goin~ on in
the network but without direct access) witn both online and
offline services. The services offered and under development by
the NIC have as their ·initial basic objectives:

Sa~

TO help people with problem! find the resources -- people,
systems, anO information -- available withn TH~ NETWORK
COMYtUNITY WHICH MEET THEIR NEE.DS.

5a~a

2) TO help members of a geographically distributed group
collaborate with each other.

Sa4b

THE NIC PUBLIC

To orovide reliable, useful effective information services to
meet t~e basic needs of a growing, diverse ARPANET community will
offer considerable challence.

5bl

One of the prohlems in the design of an information service is to
determine the main classes of clientele which exist for this
service and to deter~ine their needs.

502

The initial clientele for NIC services are those peoPle
oeveloping and building the network. The next group is
comnosed of tnose people whose research and development
interests are intimately connecteo with network resources or
who would be experimental users of various networK resources.
After this initial period the classes of clientele will grow.
as the network becomes a well shaken down operational entity.
to include a wide ran~e Of peoole who w111 use the network or
be interested in its development.

5b2a

our initial analysis showed us that there w~re four main needs
which the NIC could att~mot to meet, Reference and General
Network Information, COllaboration support. Document Hanalin~
and Creation. and Training. Although trainin~ programs must
eventually exist for all services available on the networK.
our initial emohasis is training in the Use of NIC services.

Sb20

Online Team Environment
. llO

SRI-ARC 8 JUNE 1972 1)041
Network Information Center
Development and Operations
The NIO public

Some users of the Network Information Center's services may be:

5b3

students
Researchers
university
inaustry
government
System Developers
university
industry
~over~ment

Teachers
Managers
university
industry
governm~nt

Comouter Center Directors
Libraries and ~ther InforMation Services
The General PUblic
The Media
PRES~NT

NIC SERVICES

The initial NIC services now available to meet the above goals
and pr~sent clientele are the following:
Online:

Scl
Scla

(1) Access to the tyoewriter version (TNLS) of the
Augmentation Research Center's Online System (N1S) for
communique creation, access, linking between users. and for
experimental use for any other information storage ana
maniPulation puroose suitable for NLS and useful to Networ~
"art1cipants.

Scl~l

(2)
Access to Journal, Number~ ana Identifioation Systems
which allow messages and documents to be transmitted to
NetworK participants.

5cla2

Documents or ~essages entered in tne Journal SYstem
online for later viewin~ via NLS.

5cla2a

(k)

are

m~intained

(b) Documents are now distributed oy:

onlin~

Team Environment
111

5cla2b

SRI-ARC 8 JUN~ 1972 1)041
Network Inform~tion Center
DeveloDment and oper&tions
Present NIC Services

i) placin~ the message or a link to the document in
tne receiver's "initial file".

5c1a2bl

ii) sending hardcopy

Scla2b2

throu~h

the U.S. mail.

Documents will shortlY be distributed through the
Network when sites nave implemented the appropriate File
Transfer Protocols
5cla2c
(c) A unique number is assi~ned each entry at the time
of su~m1ssion. Numbers can also be preassigned to allow
related documents to be interlinked at the time of their
preparation.
5cla2d
(6) A cataloR entry is prepared at the time of
submission and later this entry is used to update a
catalog kept both online and in hardcopy form.

5cla2e

(e) Special interest groups can be created to facilitate
indicating to the sYsteM particular distribution lists
for dialog items. Dialog items can be placed in
sUbcollections aSSOCiated with the dialog groups for
special index prOduction.
5cla2f

(3) Access to a number of online information oases througn
a special Locator file using NLS link mechanisms.

501a3

(a) Links to the NIC functional dOCUments, including the
printed catalog Of the NIO document collection, the ARPA
Network Resource NoteboOK, NIO user documentation, a
Directory or Network Participants, and Network protOCOls Scla3a
(b) links to other files created by sites with
inforroation of potential Network-wide interest.
Offline:

Scla3b
5clb

(1) A Network Information Center station set up at each
with:

~ite

(a) A station Agent to

ai~

use of the NIC

,clbl

5clbla

(b) A Liaison to provide technical information aoout his
site.
5clblb

Online

Tea~

Environment

112

SRI-ARC 8 JUNE 1972

13041

Network Information Genter
Development and Operations
Present NIC Services

(2) TechMiques for g~tnering. producing and
Functional Documents such as:

mainta1nin~

Sclblc

NIC
Sclb2

(a) Current catalog of the NIC Collection

5clo2a

(0) ARPA Network

5clb2b

Notebook

~esource

Sclb2c

(d) NIe user Guide

Sclb2d

(3) Support of Network dialog existing in hardcopy
duplication, distribution, and catalogin~.

throu~n

5clo3

(4) General Network referral and handling of document
requests

5c1b4

(5) Buil~in~ Of a cOllection of documents potentially
valuable to the Network Community. Initial concentration
has been on obta1ninr documents of possible value to the
Network builders.

5clb~

(6) Crude selective

5clb6

(7)

Trainin~

~istribution

to Station collections.

in Use of NIe services ana facilities.

In the sections to follow each of the above services and its
supoorting technology and organization will be discussed in
more detail.
RELATIoN OF THE NETWORK INFORMATION
RES~ARCH

CENT~R

~ENTER

TO THE

5clb7

Sclc

AUGMENTATIO~

(A~C)

The NIC is presentlY a pro1ect intimatelY imbedded within ARC.
ARC is an orga~ization with mult1ple sponsorship whicn has as its
goal the development 01 hardware and software computer tools,
teChniQues, procedures, and training to aio man in his
intellectual work.
The project has followe~ a research and development strategy
of "bootstrapping". that is, of US1n~ the tools anrj techniques
it has been developing in its own work, both as an aid to its

online Team Environment
113

5dl

SRI-ARC 6 JUN~ 1972 13041
Network Information Center
Development and operations
Relat16n of th~ NIC to the ARC

work and management and as a test "pilot plant" facility to
tryout ideas and techniques.

Sdla

As useful as this strategy is. there are limits to the type of
feedback it can Yield. The NIC is one of what we nope will be
many projects set up to offer services to outside users. The
goal is to providp a useful service and to obtain feedback on tne
needs of a wid~r class of outside users. We want to meet these
needs with an 1ntegrat~d. modular !ystem consisting of computer
tools. people assistance. procedures. and training. ~e also hope
to learn more about the problems of transferring augmentation
services to a wide range of users.

Sd2

The NIn consists of some personnel primarilY concerned with its
~eveloriment an~ o~eration. but also draws heavilY on the Skills
and work of most of the other members of ARC. AS the NIC matures
we are planning that it will grow into a well-defined
semiautonomous cost center with ~ore peoPle specificallY oriented
toward its tas~s. We want to clearlY define the NIe's goals an~
needs. Where these overlap with those of other ARC activities~ we
wiSh to work closelY on their realization and where theY do not
overlap to obtain the resources nee~ssary to pursue them
separately.

Sd3

The long-run. future relationshiP oetween the NIC and ARC
depen~sJ we would ~uess, on the future operation of the
ARPANET. The ARPAN~T maY eventually oe run by a commercial
utility. If this happens the NIC could be transferred to that
utility, become an independent enterprise, become a separate
enterprise within SRI, or remain within ARC. The NIC is bein~
aeveloped to be more independent, so that its tecnnology.
procedures, and serVices can oe moved ii required.

Sd3a

The Au~mentation Research Center during its approximately 10
years of existence has been primarily a research and development
organization providin~ service to itself rather than to outSide
client~.
Therefore. alon~ with develoDment of NIC services hae
had to come a Change in ARC's outlOOk, alterations in resource
allocation, and changes in many of its practices, to enable it to
Offer a servic~ and to maintain at the same ti~e a vigorous R&D
pro«ram.

Sd4

OPERATIONS
Computer service operations (eSO)

5el

online Team Environment
114

SRI-ARC ~ JUNE 1972 13041
NetworK Information center
Development and Operations
Operations

In the area of co~puter
capabilit1es were added
efficiency of the TEN EX
number of chan~es which
these measurements were

services, extensive measurement
to the system to measure tne
operating SysteM and NLS (Is,). A
appeared necessary ~s a result of
ma~e ano others are under stUdY.

Our hardware configuration contained a number of old,
one-of-a-kind pieces of equipment brou~ht over to tne PDP-10
system from the previous XDS-Y40 system. These pieces of
equipment have proven difficult to maintain and stUdies were
launched on now to replace or upgrade this equipment.

5ela

5elb

A neW b~~ network interface and a new DEC RP02 disc system
were installed in the spring of 1972, replacini oldp.r
unreliable eqUipment.

5elb~

up~rading of our di8Play system and its speCial
core oox has be~un to provide te~porary relief until a
replacement system can be planned.

5elb2

additional 32k words of core has been added recently.

5elb3

stUdies leadin~ to recommendations to add·another channel.
disc controller. and set of disc drives have been
completed. These additions will provide lnore file storage
capability and backuo swapping capability.

Selb4

The reliability imerov~ments resulting from these measures
and others under stUdY should begin to be manifest in the
summer of 1972.

~elb5

~ardware

Along with the above hardware improvements. improved practice~
and conventions have been evolved to handle new versions of
software releases, botn TEN~X and NLS, and their cheCKout
bef6re bein~ brought up for normal use. These conventions
specify both frequency and time Of daY at which ne~ systems
can be brou,ht up, and also specifY documentation standardS.

aspects of eso support has oeen
integration and maintenance of those progr~ms
necessary fer communicat10n with the ARPANET and nosts
connected to 1t. The basic NetworK Control Program ~nd T~LNET
Protocols are obt~ined as part of TENEX support from BBN.
When we had a non-standard hardware interface to tne networ~
and dur1ng early protocol development, considerable effort was

one of

the i~portant
implementatio~.

online Team Environment
115

Se1c

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Develoriment and Operations
Operations

required in protocol implementation to create operati",
network programs. Less effort il now required, out tnis effort
continues. We have also participated actively in working with
the Network workin~ Group on protocol design and specification
(proto qx,).

Seld

Se2

People Services Operations (PSO)
During the past Year ARC has develoDed several service
functions that are now beComing operational for ARC users and
NIC clientele.

Se2&

These functions (from activities such as RINS, NIC, Baseline
Record. and Journal) and the forthcoming use of Deferred
Execution (DEX) techniques have created new needs for people
services support.

5e2b

As a result, we concentrated some of our effort on
reor~anizing these activities to allow more effective and
effiCient handlin~ of routine and other tasks and to allOW for
easier expansion of the group size to meet needs of an
increas~ng amount of throughput. Tne three aims were:

5e2c

TO increase

throu~hPut

to meet existing demands.

5e2cl

TO become capable of expanding rapidlY (in tnrougnput
~uant1tY) to ~eet fluctuating service ~emands.

5e2c2

TO work at minimiz1n~ costs while maximizing responsiveness
to customer's needs and values.

Se2c3

This section describes in some detail the activities and taSKS
inVolved in settin~ up or running a pso. we go into thiS
detail because many people reading this report witn a
traditional computer service background may not appreciate the
comrilexity of running an information service. computer
teChnology. while important, is not SUffiCient in and of
its~lf to ~aKe possible such a service. Such a !ervice is only
possi~le with ~ balanced set of computer tools. p~ople suoport
services, and the methOdology. procedures, and training WhiCh
me11 them together into an effective higher level system.

Se2d

Therefore in order to create such a balanced system We
launched a new approach to ARC'S "peoPle services operations".
(se~ -- 7b3h,la)

5e2e

online Team

~nvironment

116

SHI-ARC 8 JUNE 1972

13041

Network Information Center
Development and Ooerations
Ooerations

The main thrusts were:

5e2el

organization
Physical Location and Configuration
procedure Establishment ana Documentation
TranscriPtion Activities
Terminals
personnel
Trainin~

5e2f

or~~nization

A group with skills in handling paperwork and messages. and
in using TNLS and DEX, was explicitly identified as PSQ,
and a group of advisors with skills in administration,
documentation, and training was assignea to assist in
~etting PSO into formal operation.

PhYsical Location and Configuraion

office and workrooM areas were expandea and relocated, to
~ive the growin~ support operations more efficient location
and arrangement. New tables, shelves, cabinets, and files
were acquired and their arrange~ent worked out,

Online Team Environment
117

5e2fl

5e2g

~e2gl

SRI-ARC B JUNE 1972 13041
Network Information Center
Develooment and Operations
Operations

FIGURE 21. PeoPle Service Organization worKroom.
5e2g1a
procedure

Establishment and Documentation

procedures were devised and documented for:

5e2h
5e2hl

Use of TNLS (see -- 7470,) and DEX (see -. 9934,),

5e2hla

The handling of transcription and other service
requests.

5e2hlb

All related NIC activities

clerical and secretarial.

Transcription Activities
Types of work to be handled:
Handwritten drafts
Tape recordings
Dictation notes
offline documents
online documents to be edited

Online Team Environment
118

5e2hlc
Se2i
Se2il

SRI-ARC 8 JUNE 1972 l30~1
Network Information Center
Development ind Operations
Operations

TeChniques for transcribing material into online files were
developed:

Se212

Deferred Execution (DEX) covered at greater lenrth see
--,4dl)

5e2i2a

This process makes use of terminal and magnetic tape
recordin~ equipment for initial input of data with
actual entry into computer files deferre~ until
perio~s of low system use (thereby resulting in less
expensive Use of the system for the processing Of
this work.) This system has been used to place
online many documents of importance to the ARPANET
community origirially prepared off11rie.
Se2i2al
Where and how long to store entered tapes for backup,
the conventions for hierarchical statement entry, and
when tne transcriber should try to put hierarchical
structure into documents are still under deVelopment.
5e2i2a2
5e2i2b

TNLS

TNtS is used largely for routine editing of online
documents, and for entering high-priority items
durin~ off-peak load hours.
DNLS

Se212bl
5e2i~c

Display NL5 is used for difficult editing of online
documents and for so~e highlY formatted documents.
peceiving processes

~e2i2cl

5e213

we set uo a central receiving station.

5e2i3a

one person. witn an alternate, nandles users' questions
regarding job status, time and cost estimates, etc.

~e2i3b

priority determination process
A requestor specifies his preference for priority:
Immediate service (1-4 nours)
Normal service (u-12 hours)
Deferred service (a weeK or two)

online Team Environment
119

~@2i4

Se214a

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development and O~erat1ons
Operations

Temporary

stora~e

A log system
been set uP.

usin~

unassi~ned

work

Se21S

appropriate work request forms has
5e215a

we have a central stora,e Place. organized for control
of work bY ~rior1ty.
Assignment process for transcription work

Se2iSb
5e2i6

A work scheduler assigns incoming work to group members,
balancin~ priority request witn members' capabilit1es
and workloa~.
Se216a
Later, priorities may be established
scheme.

a bidding
5e2i6b

we plan to enlarge this effort to allow assignment to an
0001 of wor~ers trained in DEX. both SRI ~eople
and contra~t manpower.
5e2i6c

outsid~

output processes

Se2i~

we have rtev~lope~ conventions for nam1n~ of temporary
input files (special and separate for the catalog
process) with proviSion for special instructions from
the author.

5e2i7a

we have developed procedures for delivery of
work to the requestor.

5e2~7b

co~pleted

Terminals

5e2j

we have ~ade a thorough stUdy of available teletype
terminals and ma~netic tape devices, and after experimental
use of several l nave leased nine TI terminals and six
Term1cettee. for use with DEX.
Personn~l

5e2jl
~e2K

we have aOded several new staff members with contributions
to make to NIC. Two writers who can also teach were active
in pso d~velop~ent. Three new staff members were added to
th~ docu~ent preparation, transcr1~tion and distribution
efforts.

Online Team Environment
120

5e2kl

SRI-ARC 8 JUNE 1972 l)Ohl
Network Information center
Development an~ Operations
Operations

Trainin(

Se21

classes in TNLS and DEX were held for ARO and network
people. Manuals were prepared. A more deta11ed discussion
training is ~iven later, see--.5gl0).

A detailed list of the types of tasks tnis PSO group and
associated information handling people perform to support the
NIC id given below because it is important tor people to
undprstand the ran~e of aetivities that are required even with
automated aidS to support a service such as the NIC.

pLANNING AND

SCH~DULI~G

5~211

Se2m
.5e2ml

Goal settinlt

service design
Site station aid planning
Function~l document desi~n
NIC Collection design
Station collection plan
Reference service desi~n
Ca.talog design
Procedure establishment

,Se2mla
Se2mlb

Disc'Jssion

Proc~aure writing
Experimentation
NIC !acil~tY design
work flow scheduling
NICtime and cost studies

GENERAL SUPPORT

5e2mle
,Se2Mlf

5e2mlg
~e2m2

Dictation
Phone
Orders and financial records
Timeca.rds
Vlsitor arran~ements
NIC travel arrangements
NIC facility upkeep
STATION PHONE ACTIVITY

5e2m3

ohone answer
calls

sta~ion
out~oin~

NIC

Online Team Environment
121

SRI-ARC 8 JUNE 1972 13041
Network Information Center
DeveloDment and operations
Operations

MAIL SINGLE NIC PIECES

5e2m4

Incoming mail processing
Single mailings
ACQUISITION OF NETWORK INFORMATION

5e2m5

N~twork resources
Network personnel
Network pUblication references

CHOIC~,

ANALYSIS, OF INFORMATION

5e2m6

Analysis for bulletins
Analysis for functional documents
selection Of pUblications
Aostracting
ACQUISITION OF PUBLICATIONS
Checkin~ hOldings
Order form preparation
'Receipt, record changing

OFFLINE CATALOGING wnRK
codin,
Checking of codinR. revision
proofing and revision
Recoding of old material
catalog offline records
Old catalog offline work
FILE-BUILDING ONLINE

Input of new citations
Input of old citations
Editing of new citations
Editing of old citations
Bulletin creation
Bulletin editing
catalog creation
catalo( editing
catalog file manipUlation
Functional 10euments input

Online Team Environment
122

5e2m8

SRI-ARO 8 JUNE 1972 13041
Network Information center
Development and Operations
Ocerations

Mailing list input
Letter online input
other online text input
other text input, DEX
Identf11e maintenance
,Se2mlO

PHYSICAL PROCESSING
keadyin~ of Journal printout
Readying of other work
Colla.tin~

Stamping. Punch1nr
xeroxinl of documents
Line printpr output
outside repro contact
Se2mll

DISTRIBUTION

Mailing list maintenance
Labels, envelope preparation
Pickup and delivery
STORAGE

A~D

MAINTENANCE

Se2m12

NIC Master collection
Extra cooie!
Supplies
VISUAL AIDS

Chartmaking
TRAINING

Instruction
Develcpment of training aids
REFEk~NCE

WORK

,5e2l1l15

Locating citations for ~et
Locating documents for Net
Literature search
Let us now look At each of the services provided a~O see what has
been involved in making them available beyond the changes

Online Team Environment
123

SRI-ARC a JUNE 1972 1]041
Network Information Center
Development and operations
Operations

described above. whY they were made availaole. and some future
Plans.

Se3

There are two major areas of changes to AkC caused by oroviding
NIC services that deserve mentioning: Planning and providing more
reliable and efficient compu~er services, and planning and
·providin, more varied and extensive clerical and other services
provided bY and for ~eople.

5e4

ONLINE SERVICES
ACC~SS

TO NLS

5fl

The ARC ONline SYstem (NLS) is an evolving system whicn we
view as an integrated set of tools for dOing general
int~llectual work (,4dl,).
To this end NLS nas, at this time,
Dower!ul document creation. editing, production, and studyin!
capabilities. dialog supnort functions for online
communication both !imultaneous and distributea in time,
biblio~raphic catalog-making ca~~bilities, programmin~ aids
and facilities. some basic inf.ormation retrieval abilities,
and some, as Yet, rUdimentary management and other planning
aids.

5!la

subset of these capabilities. felt to be of prime value to
initial NIC use centered around document creation, editing,
pro1uction, and studyinE as well as dialog support, has been
thoroughly documented for NIC clientele.

5flb

we knew that Most systems on the network su~porteo typewriter
terminals rather than displays so that ~uring tne conversion
frOm the XDS-9~O to the PDP-10, a typewriter version of the
system was designed and implemented --,4dla3a).

5flc

In thinking about the prOblems whiCh Could exist in
all the Varieties Of typewriter terminalS on the
network, we (to Keep A~C'S thougnts clearlY separate from
the net's) felt that it woula be better to nave most Of
these differences handl~d oy a standard networK protocol.
Therefore. we worked actively with the Network working
~roup (~wG) in establishin, a networ~ virtual terminal
~rotocol (T~LNET) see--. 6 bl).
ThiS protOCOl has succeeded
in allowinv access to TNLS from different systems and
terminals.
~upporting

Online Team Bnv1ronment
124

Sflcl

SRI-ARC 8 JUNE 1972 130u1
Network Information Center
Development and Operations
Online Services

NLS. as it has historic~llY develope~. is orienteo" in its
command lan~uage design f~r expert users.
This orientation towar~ hirhlY trained, experienced users
is not completelY suitable for the clientele of the NIC,
comprised of sone who use the system often enough to become
~xperts and others who want to use the system infrequentlY.
Therefore, thou~ht has recently gone into studying what
changes are needed in the NLS command language syntax to
provide 2 range of modes from novice to expert, and what
add1tion~1 help and tutorial capabilities need to be built
into the system. These changes will be implemented in the
coming monthS.
At the present time anyone With access to a typewriter
terminal connected to the network and with an entry in our
ide"tification file ,see--.4a4} (entries can be made in this
f1l~ directly by network users) Can have access to NLS.
we generally find betw~en 1 and 3 Users from the network
using TNLS ~uring priMe hours. The h1~hest number ~oserved
has been 7 simultaneous network users.
The numoer of
log ins a day from the networ~ has been avera~ing around hO
- SO, with a"variation between )0 and over 100. We expect
the numoer to increase significantly both as the networK
trows an~ as our hardware reliability i~proves, as
discussed earlier.

A system for allowin~ access to the display version of NLS
(DNtS) fro~ the n~twork using IMLAC display terminals eQu1p~ed
with a keyset and mouse has beeM developed jointly with thP
Xerox palo Alto Research Cent~r and tested with users from
UCLA-NMC and BHN-TENEX.
we expect to continue experimen~al use of DNLS over the
network and eventuallY to offer DNLS as a re~ular servic~.
~e are currently studyin, how to provide DNLS service from
low-cost alpha-numeric displaYS eQuippe~ with keyset and
mouse.
Documents are presentlY crea~ed by a user at a keyooard device
connected to TNLS via the network. We are worKin~ to allow
entrY of documents into Nts which w~re initially oreparea in
other host computers. At least one site, MIT-DMCij. has been
enterin~ doeu~ents in NLS bY preparing locallY a file of NLS

Online Team Environment
12~

Sfld

5fldl

Sfle

5flel

5fl!

Sflfl

SRI-ARC 8 JUNE 1972 13041
Ne~work Information Center
Development and operations
Online Services

comMandS and document text and transmittin~ it into NLS as a
simulated teletYPe. The sche~es under studY will simplify
this process.
AIDS TO COLLABORATION
We

5flg
Sf2

~nvision
wide variety
~eo~raphical1Y distributed

of collaboration aids to help
people work closelY together. One
such system being developed and offered as a NIO service is
the Dialog Support System (DSS). The first steps in the
creation of a PSS have been taken in the implementation Of
JoUrnal, Numb~r, and Identification systems.

Sf2a

As discussed in more detail above, the Journal is a system for
capturing recorded dialog items (in the form of documents and
mes~ages) and for ~istributing these items online, offline,
and throu,h the network to the appropriate recipients.

Sf2b

~hen an item is sUbmitted to the Journal, a unique number is
associated With it. either Obtained at the time of sUbmission
or oreviously from the Number system. This unique nu~ber is
used for cataloging purposes and as the name of the item for
later referenc~ and retrieval.

5f2c

once SUbmitted. the ite~s become read-only; statements in a
Journal item can be uniquelY an~ precisely referenced in
future documents with assurance that the reference will remain
meaningfUl.

5f2d

At the time of sUbmission, or any time later. documents can be
distributed to one or more individuals, either singlY or as
members of groups bY indicating to the system a list of unioue
1dentifications called IDENTS.

5f2e

New identifications can be created at the time of
sUbmission or at other times by use of the I~entification
system.

The IDENTS are usually a person's or group's initials. The
IDE~Ts are automatically assigned bY the Identification System
when a person's or group's name is entered into an
1dentification file by use of the system.
when one is sending an item to a group, one need only use
the grOUp's IDENT and the sY8tem will deliver to the the

online

Tea~

Environment

126

Sf2el

5f2£

SRI-ARC 8 JUNE 1972

1)041

Network Information center
Development an~ Operations
Online Services

membership of the group. One can also indicate distribution
to only the coordinator of the group.

5£2fl

If one aoes not reme~ber a person's or group's IDENT at the
time of SUbmission. a query iapability allows it to b~
retrieved.

Sf2g

The Identification System has provisions for COllecting other
relevant information such as a phone number, network site
affiliation, and preferred method of document delivery (online
as a citation in the receiver's Initial File. offline bY
hardCOPY throU~h the mail, or both).

Sf2h

The information in the identification file is used bY the
Journal System during document sUbmission and delivery. Tne
information in the identification file is also used to
automatically prepare directories of indivi~uals and ~ialog
~roups as described later.

5£2i

SAMPLE MESSAGE SENDING SESSION

5f2j

The following is a demonstration of how a message is SUbmitted
to the Journal by a Network user (includin« login, NLS access,
and lo~out procedure). Material in square braCKets is fed back
by the systpm. Material in parentheses is commentary. The
symbols *, @. &, && are system heraldS and are not shown in
orackets.
~Lo~1n

SF DOE SP DDD SP 1 OR
(A user named DOE
lo~s in to the system - nis ID is DDD)

(JOB lION TTY14

3-AUG-71

17:11)

t1!;nls OR

(The user accesses the

NLS system)
{ID:} DUD OR

{device:} N(et-tty]
(liN" signifies that tne user
ODD is connected through the Network with local
echoin~)
*e(xecu~e]

(SUb~it)

jlournal}

(access Journal system)

m(essa~e}

Online

T~aM

Environment

127

5f2k

SRI-ARC 8 JUNE 1972 13041
Network Inform;tion Center
Development 'and Operations
On'll.ne Services

THIS IS A SAMPLE MESSAGE CA
(Contents of message; note
"CA" means Command Accept)
(number) CA [33331
(typing CA after reouest for number
causes system to assign DDD a unique catalo,
number (333)J for the message)
CA
(causes the system to crompt the user
for the correet information reqUired to send th~
item through tne Journal)

&&i(n~errogateJ

&&{title:J

A SAMPLE

SESSION CA

JOUR~AL

&&[d1strioution:J XXX (for your action) YYY (for your
information) CA (XXX and YYY identifY otner persons known
to tne system; the text in parentheses are comments
~irected to them.)
&&(status) CA
•
•

(the SYstem prints back all information entered
the user)

•
&&[~o?)

n(o) (the User does not want to "go" now but wants
to add more information not requested by the
Interro~ate proceoure)

&&k[eywords:J test sample CA
(keywordS provide inout to
an index to all messages)
&&c(omments:l isntt this funl
&&g[01}

(tells the system to begin
Journal process. Note that as the author command
is not Used, DDD is assumea).

y(~sJ

(JOURNAL SYSTEM IN PROGRESS)
(the system is processing
the new Journal entry)

(the system nas created a link to
the new Journal entry)

(Journal,JRN1,J333:~w)

Online

Environment
l28

Tea~

SRI-ARC 8 JUNE 1912 13041
Network Information Center
Development and Operations
Online Services

*e{xecutej q[u1tJ CA
(the user has been returned to the
NLS command level as signified by the system
typing the herald character "*" the user then
types th~ Execute Quit command to return to the
EXEC)
~lo~out

(the user logs out)

EXAMPLES OF ONLINE JOURNAL DELIVERY

5f21

when Journal items are delivered to a person, theY are
delivered (as citations for documents, or tne actual text
tor messages) in a file called his "initial" file as it has
as a name the person's IDENT or initials. The citation
contains the IDENT(s) of the author(s), the date and time
catalog number; the title on a second line; and an NLS
"link" or the message on the third or additional lines (see
discussion belo~ on linkS).
(WATSON)RWW.NLS;372
*Print Branch .11wl
(Journal) Journal Documents (most recent first)
nCE 31-MAY-72 10:01 10614
comment on user-feature change coordination, and (105d7,)
Location: (JJOURNAL, 10614, l:w)

LPD 30-MAY-72 10:39 10591
Message: CAN YOU SEND ME A COpy OF THE LATEST LIST or
HOSTS?
RA~ TOMLINSON SAYS THE Nee ISSUES AN RFC ON THIS SUBJECT
PERIODICALLY.
Delivery of hardcopy of computer-processed documents is not
Yet as smocth as we desire and taKes longer than desired
bec,use of the chain of events that must presentlY take Place
in this process. The pre~ent chain of events is:
creatio~

of an

6n magnetiC

ta~e~

ima~e

Sf2m

of the documents for each receiver
Sf2ml

2)
TranEfer Of the tape to SRI's computer center for batch
printing.

Online Team Environment
l29

5f2m2

SRI-ARC 8 JUNE 1972

13041

Network Information Center
Development and Operations
Online Services

3) Document printing.

5!2m3

Bursting.

Sf2rn4

5) stapling.

5f2m5

6) Checking for correct content and addresses.

5!2m6

7) Mailing.

5t2m7

The documents are printed with a cover mailing address sheet.
We are presentlY workin~ to improve the reliability and
Scheduling Of the above chain of events.

Sf.2n

We expect in the next few months to be automatically
oe11vering documents through the network for printing at the
aestination sites or for delivery to online files.

5f20

This will require ratification of at least an experimental
file transfer protocol bY tne Network WorKing Group and
implementation of this protocol. SUch a protocol is
nresently under development.

5£201

we expect, as mentioned earlier, to allow documents prepared
on local host text editors to be entered into the NIC Journal
and be auto~atic~llY cataloged and delivered by tnis system.

Sf2p

To uniquely identifY hosts. and NIC stations associated with
the network we worked with the NWG to set up a standard
identifying syntax and asked each host and NIC station to nam~
~he~selves accord1n~ to the established rUles see--,6cl)?

5f2q

This was a small but imoortant step to help establish
uniform communication rules useful to different processes
of the ARPANET experiment such as virious NIC services.
These ho~t IDENTS are dialog groups. Thus to send an item
to everyone at ARC one uses the IDENT "SRI-ARC" in the
~istribution list at the time of Journal suomission.
At the time of sUbmission of a Journal item a catalog entry is
created with all the relevant information such as number,
autnor(s), title. date-time, documents obsolete~ or ucaated cy
this documert, person WhO actually did the ~ubmiss1on,
KeYwords if any, distribution, affiliation of author(s), and
SUbcollections.

Online Team Environment
130

5!2ql

5f2r

SRI~ARC 8 JUNE 1972
13041
Network Information Center
Development and Operations
Online Services

~ach dialog group or affiliation is a sUbcollection name as
well. and all items sent to that ~roup are automaticallY
oart of that subcoll~ction.

5f2rl

All the above information can be explicitly entered at
SUbmission time. It is from this catalog information that
indices and listings are made perioaically as described later.

5f2s

Users can find dialog items of interest by use of the cataloE
listings and indices.

5f2t

Thus. bY use of the Journal and the catalog of Journal items.
oeorilecan find and participate in dialog distributed over
time and bein~ carried on bY people geographically separated
frOm one another. see the discussion in tne next section for a
samole query of tne catalog.

5!2U

One of the features of NLS is a link mecnanism. An NLS link
is a syntactic entity Which references a statement in the
current docume~t, or in any other document. The link can also
contrOl the initial view of t1e referenced item.

5f2v

has Mechanisms whicn allow one to "pOint" at a link and
have the system fetch and aisPlaY the item referenced.

5f2vl

~LS

~hus.

usin~

items can

links, networks of related documents and dialog

created.

5f2v2

The sys~em saVes the last Reveral documents (and positions
within theM) eXamined, and thUS one can move ahead to an
item ana then, when the appropriate command is givfI!n,
return to previous pOSitions automatically.

Sf2v3

LinKS are essenti~lly forward references.
time one cannot automatically access tnose
oointin~ to a ~iven document (i.e., if one
he cannot now aSK wh~t documents reference

~f2v4

At tne present
documents
is in a document
it).

plans to implement this "bacl1~5,) and
those used in NAS panel andAFIPS workShop meetings.
These programs, descrioed belOW, are the result of much
thinking and experimentation to produce catalo~s and
indices of maximum usefulness, ~iven the present printin,
~onstraints.

Examples of the

11stin~s

and indices now produced are:

online Team Environment
145

S~3el

5g3e2
5~3e3

SRI-ARC b JUNE 1972 13041
Network Information Center
Develoriment and Operations
Offline Services

Catalog listing by number:
The Va11d1ty of Basing Computer Selections on Benchmark
Resultl.

6551

Edward O. Joslin and JoHn J. Aiken (U.S. Air Force
systems Command, Electronic Data ProcesI1nc Equipment
Office. Hanscom F1eld, Bedford. MaslaChusetts).
Computers and Automat10n, Vol. lS, NO.1. p.22-23.
January 1966.

Author Index:
Tit.le

Date

The Validity ot BAsin, Computer Selections on Benchmark Relulta

Jan 66

NUI'I~er

6557

Tit.leword Index:
Title

Date

The validity of Basin, Computer Selections on Benchmark Resultl

Jan 66

NUMber

NUmber

6551

TiUevord
val1.d1t,y

Index:

Author

Title

Joslin

The validity Of Basing Computer Selectionl on

Date
~enchmark

Resulta

PROBLEMS ENCOUNTEREu IN BUILDING A
NIC CATALOG

REFER~NC1

Jan 66

Number

6557

DATA BASE AND

Sg3f

The steps 1nvolved in building an online data base ~nd
machine produced catalog have shown us that successful
operation of such a system requires well-trained
staff, reliable computer system operation, carefullY
wO~Ked out and documented orocedures, carefUl proofin~
and just plain luck. Experience has shown that a full
blown augmentation SUbsystem such as our bibliographic
reference system contains a full mixture Of co~puter

online Team Environment
146

SkI-ARC 8 JUNE 1972 1)041
NetworK Information Center
Development and Operations
Offline Services

toolS. p~ople. nrocedures, and trainin, and tnat
integration and development of such a system is a
non-trivial process.
5~3fl

we have found even with our small collection of less
than 2000 items that the period between issues of new
catalo~s tends to oe about once a quarter. Our goal
when the new Catalog production Processor is fully
inte~rated into the present system is to produce a
catalog every 4-6 weeks, with weekly announcement
hUlletins Of new additions to the collection.
5~3f2
The problems of the printed Catalog are not unique to
this document; they occur alEo in tne prepar!tion of
th~ Directories and will occur in some form in other
fUnctional documents, but the diversity of the data
elements and tne complexity of the formattin~ are
~reater with tne Catalog than with other documents.
5g3f2a
NIC has had the experience, common to other
information centers. that oiblio~raphic orocessing
entails more effort and more sources of delay and
difficulty than can be specifically antiCipated.
5g3f2b
NIC staff involved' in "'roduc1n~ the last two catalogs
have kept a diary of problems as encountered
(summarized below). In the reading of this diarY the
impression of the staff is reinforced that problems of
various kinds seem to occur seriallY: as soon as one
problem is corrected, another is in line to apoear.
!)g3f2c

It is true tnat we could have issued typed versions of
the NIC catalog, the Resource NotebooK. the User
Guide, and the Directories in less time than it h~s
taKen to produce them as online files ca~ablp of b~ing
machine-uPdatab1e and printable on demand. But the
trade-of! alwaYS had to be made between service ~o the
Net~orY bY getting out the inforMation, and the
benefit to be gained from experimentation with machine
methOds, eventually leading to a better croduet.
5~3f2d

DESIGN PROBLEMS

5g3f3

In designin~ tne printed catalo~. no exist1n~ catalo~
was taken as a model. Each alternative forMat whieh

Online Team Environment
lh7

SRI-ARC b JUNE 1972 130hl
Network Information Center
Development and Operations
Offline Services

offered ~~vantag~s to the user and Wh~ch Was adaptable
to our printer was considered. Selp.ction of data
~lements for tne pr1nted catalo~ and for online
searchin~ was evolutionary, and extensive pro~ramming
was necessary to accommodate chan~~s in elements and
format.
Sg)f3a
The online catalog is tied to the printer format and
is less readable than is desirable; we plan to put
effort into design of an online version Which is
better ~dapted to ~isplay and teletype printout.
Sg3f3b
MACHINE VHOBLEMS
5~3fll
The occasi~nal unreliability of the system seemed to
adversely affect the Catalo~ operat1on more tnan other
worK at the site. Many times files containin~ progr.ams
or citatiqns were lost in dumps or for other reasons •
.,g3f4a
For some reason yet undetermined, large, neav1lv
manipulated files have gone ba~. A great number of
files had to be reconstructea from earlier versions.
5g31'JJ.b

An off-hours schedule is required because of tne load
placed on the system bY catalo~ prOduction, ana
consequently time was often lost in wai~in~ for
machine availability in off-periods. The process nas
been slow, consu~ing several hours of an evening,
during Which the operator had to keep an eye on tne
terminal. A late run sometimes had to be aborted
becaUse it ran into ~he dump time.
Sg3f4c
Delays were caused bY or1nter malfunction. Sometimes
several days were lost because tne prin~out for the
re'Oroducible master could not be obta.ined until the
printer was cureO of some ab~rrant behavior.
Sg)f4d
Limitatinns of the line printer caused some
co~prornise3 w1tn an 1deal design. ~e have experimented
with various formats to aChieve clari~y if not bpauty.
Sg3fIJ.e
PROGRAM PkOdLEMS
5~3f5

The complexity ~f tne present catalog production
process of calling files and using programs led to

online Team Environment
148

SRI-ARC 8 JUNE 1972 130~1
Network Information Center
Development and operations
Offline Services

time-consuming mistakes. (The new catalog production
processor Should help greatly here).
5g3fSa
The continual imrrovement in analyzer and formatter
pro~rams required ~ebugging and close ~xamination of
results.
5g~fSb
The continual evolution of NLS in general often has
resulted in a new version on which some sUbsystem use~
in making a catalog would no longer run or run
correctly. The process of catalog makin( with its
lar~e files, diversity of operations and long run
times has proven a useful NLS bu~ finaing tool. 5g3fSc
The programs for formatting the listings and indices
were primitive at the beginning, and have been Changed
as the possibilities of the medium were explored. Each
change in programs has meant the usual debug~ing. It
has also meant extensive eXamination Of tne effects of
each change on the citations resulting from the new
manipulation of the data elements.
5g3f5d
The heretofore unreache~ limitations on the size of
NLS files and fieldS have been brought out by the
unusually large size and the unusually heavy macn1ne
operations required for formatting lon~ biblio~raPhic
citations.
5g)f5e

INPUT TEXT PROBLEMS
The most oovious problem, an~ the most common. is
at the manual coding stage or at the
typewriter input stage or by accident in making
editing changes.
5~3f6a

rnispellin~,

Misunderstandings between staff members on file naming
and other·cataloging conventions often oecurred durin~
periOds of new prOcedure development and staff
training, all of Which introduced delays or ba~ data
or bad files. Most of th~se types of problems nave
been cured bY brief weekly meetin~s of people involved
with the various Phases of catalog production.
catalogers, coders, programmers" etc.
Sg3f60
The selection of information

Online Team Environment
149

fro~

the document. in the

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development an~ Operations
Offline Services

cOding process, is vital to the retrievabi1ity of the
1nformation in the document~ and errors in jUdgment in
this selection Must be caught to make the citation
useful.
5g3f6c
Th~ diversity of data, in type and length, of document
citations causes it to be impossible to predict
exactly what a formatting change will dO to some
citations. Trial and error are needed to help tailor
input to the requirements of consistency necessary to
produce an informative citation for the complete
listing and for the on-line indices.
Sg]f6d
REPRODUC~ION

PROHLEMS

5~3f7

To reduc~ t~e bUlk of the Catalo~ listings and
indices, the second issue of the catalog waS formatted
to squeeze as much information on a line and page ~s
practical. Tne aDpearance of the final prOduct is then
dependent to some degree on type of offset syste~ used
and the prOficiency and care of tne reprOduction
department in Photoreducing the masters. In some
cases, the product nas not been what we desired,
because of the quality of our printout, or, ~ore
often, because of unnecessarily great reduction or
incorrect Photoprocess. on two occasions we have had
to send tne order back to be rerun.
sg3f7a
Photo reprOduction is done centrally at SRI unless the
delay would be insupportable; we regularly send the
Catalog outside for repro, at an increased price and a
still unsatisfactory schedule.
5g3f7b
COLLATION PROBLEMS
Errors in collation occur with predictable reRularity
but in unpredictable places in the document, of
course. NIC is forced to do much of its own collation,
and to cheCk tne collation done outside, with
resultant delay.
5g3f8a
CONOLUSION

5~3f9

Familiarity with other centers bUilding
maehine-prcduced catalogs, (see References Section 2c)

Online ream Environment
150

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development and Operations
Offline Services

has convinced us that the above types of problems are
part of the present state of the art of the
information business and that any installation
planning to do these types of operations Should plan
on a shakedown perio~ to work them out. If their
system, like ours, is constantly evolvin~ as part of
planned research and ~evelopment, this shakedown
period may always exist.
Sg3f9a

SOME FUTURE PLANS
At the present time, dialog items submitted online to
the Journal and mailed to us for distribution offline.
and more formal oocuments such as reports, are
intermixed in our catalog. As the collection ~rows
these classes of items will be separated to maintain
ease of catalog browsing offline and online.
5~3gl
We will also probably Droduce the catalog in bOOK form
as now, and machine-prOduced cardS can be dis~ributed
to the stations with each item to aid station Agents
in maintaining an up-to-date catalog of their local
collections.
5~3g2
Plans exist to consider in the next year or two
distribution of items to site collections on
microfilm.
The Directory of

N~twork

Participants

5~3g3

5g4

The Directory of Network Participants is automa~1callY
pro~uced from information in the identification file
described earlier. The Directory contains several
views of the information in this file. There are three
main categories of records in this file: individuals,
dialog groups, a~d affiliations. Affiliations ~re
or~an1zations and are special cases of dialoR ~roups.
The Directory contains a comprehensive online listing
of IDENTS and names of all items in the file, brief
and extendeo listings of individuals. dialog ~rcups.
and affiliations, a listing of prlnciPle investi~ators
associated with each network site and ARPA contract.
liaison, station agents, and special mailing lists
(the latter are special cases of dialo~ ~roups).
Examples of Directory formats are given.
5g4a

online Team Environment
151

~ JUNE 1972
13041
Network Information Center
Development ana Operations
Offline Services
SRI~ARC

COMPREHENSIVE LIST OF IDENTS:

DF
DGB
DHL
Don I.
DL
DLH
DLM
DLS
DL52
DM

David Farber (UC1)
Daniel G. Bobrow(BBN-TENEX)
Duncan H. Lawrie(ILL)DIA
Andrews(SRI-ARC)
Don Limut1 (SRI-ARC)
Dan L. Murphy (BBN-TENEX)
Donal L. McNally (Tinker)·
Duane L. Stone (RADC)
Daniel L. Slotnick (ILL)
Donald McCracken (CMU)

BRIEF LIST OF AFFILIATIONS:

BBN-TENEX

CASE

B. B. and N. - TENEX Group
Bolt 8eranek and Newman Inc.
50 Moulton Street
cambr1~ge, Massachusetts 021)8
case Western Reserve University
10900 Euclid Avenue

Room 306. Crawford Hall
Cleveland, Ohio 4~l06
COA

CCCTF

computer Corporation of Amer1ca
565 Technology Square
cambr1dRe, Massachusetts 02139
canadian Computer Communications Task Force
100 Metcalfe street

4th Floor
ottawa 2. CANADA

Online Team Environment
152

SRI-ARC 8 JUNE 1972 13041
Networ~ Information Center
Development and Operations
Offline Services

CHIU

university of Chicago
Institute for Computer Research
university of Chicago
chicago, IllinOis 60637

LINC-67

M.I.T. Lincoln Lab • 67 Group
244 Wood street
Lexington, Massachusetts 02173

EXTENDED LIST OF AFFILIATIONS:
BBN-TENEX

B. B. and N. • TENEX Group
Bolt Beranek and Newman Inc.
50 Moulton Street
Cambridge. Massachusetts 021)8

DGB

Daniel G. Boborow

(617)891-1850 ext 330 ..

SeB

stephen C. Sutterfield
steven c. Chipman
pooert E. Ka.hn
Jotln MakhoUl
Mac MCKinley

(617)891-18.50
(617)891-1850
(617)891·1850
(617)891·1850
(617)891-1bSO

suc

REK2

JM
MM

ext
ext
ext
ext
ext

online Team Environment
1.53

419
358 ..
340
234
3.51 ..

principal
Investillator
Station Agent
taison

SRI-ARC 8 JUNE 1972 130~1
Networ~ Information Center
Development an~ Operations
Offline Services

EXTENDED LIST OF GROUPS:
jg4e

BBN-TENEX

Dan L. Murpny (DLM)
BOlt Beranek and Newman Inc.
computer Science Division
50 Moulton street
Cambrid~e, Massachusetts 02138

(611) h91-18S0 ext 351

CASE.,

patrick w. Foulk (PWF)
Case Western Reserve university
Computin~ and Information Sciences
10900 Euclid Avenue
Cleveland, Ohio 44106

(216) 36b-2936

CCA

Richard A. Winter (RAW)
Computer Corp~ration of America
565 Technology Square
Cambridge, Massachusetts 02139

(617) 191-3670

BRIEF LIST OF INDIVIDUALS:
Murphy. Dan L. (DLM)
Naficy. Hamid (HN)
NaYlor. William E. (WEN)
Nelson. Lou C. (LON)
Newell, Allen (AN)
North. Jeanne B. (JBN)
Norton. James C. (JON)
O'Sullivan, Thomas (TO)

F:H3N .. TENEX

UCLA-NMC
UCLA-NMC
UCLA-NMC
CHU
SRI-ARC
SRI-ARC
RAY

(617)491-1850 ext 351

(213)825-2377
(213)625-2012 ext 2368
(213)625-4733 or

825-~368

(412)621-6200 ext 151
(415)326-6200 ext 4119

(415)]26-6200 ext 2124

(617)762-6700 ext 2120

online Team Environment
lSh

8 JUNE 1972 13041
Network Information center
Development and Operations
Offline Services
SRI·A~C

EXTENDED LIST OF INDIVIDUALS:
Dan L. Murphy (DLM)
BBN-TENEX
Bolt Beranek and Newman Inc.
Computer Science Division
SO Moulton Street
Cambridge. Massachusetts 02138

(617)4Ql-ld50 ext 351

MUrOny

Hamid Naficy (HN)
UCLA-NMC
UCLA - Network Measurement Center
Computer Science Department
3732 Boelter Hall
Los An~e1es. California 90024

(213)825-2377

Nalicy

William E. Naylor (WEN)
UCLA-NMC
UCLA - Network Measurement Center
Computer science Department
3732 Boelter Hall
Los An,eles. California 90024

(213)825-2012 ext 2368

Naylor

We plan in the future to expand the information in the Directory to
inclUde additional information of value to tne ARPANET community such as
individuals' research interests, description of functions of each dialog
group. etc.
5g4h
ARPA NetworK Resource NoteboOk
For people to be able to effectively utilize the resources of the
network, they must know what resources are available. The initial
service to ~eet this need is th~ ARPA Network Resource Notebook. Tnis
Functional Docu~ent was launched in 1971 jointly by BBN an~ NIC. BBN
aesigned the initial information format, collected initial entries
from each si~eJ and did additional editorial worK to insure
uniformity. Kesponsioility for distribution and maintenance was
handled by the NIC. We also transcribed the material and made it
available online.
SgSa
As the number of sites ,rew it became clear that it Should have its
inf6rmation content expanded, with more specialized sections on
specific classes of resource, and that it needed an index.
5~5b

Online Team Environment

155

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development and operations
Offline Services

An index w~s orepared at the NIC and as we wanted to develop more
automatic alds to produc1n~ special views of the resource
information, ana as BBN felt they had fulfilled their initial
Ob1i~ation. future editorial responsibility for the Resource NotebooK
nas passed to the NIC.
S~5c
ARPA

N~twork

Current Network protocols

5«6

Successful intercomputer communication over the ARPA~ET depends on
the deve1op~ent and implementation of various classes of
communication orotacols. To ma,Ke this information widely available
and eas11y usable in a form peo~le could tell was up to date. the
various protocols were collected to~ether as one Functional Document
and are maintained as SUCh by the NIC. This has proven to be a
simole. but useful service.
5g6a
NetworK Information oenter User Guide
To enable users to learn and Use NLS. the Journal and other online
NIC services, an extensive User Guide was prepare a covering that
sUbset of TNLS fUnctions felt to be initially useful to network
userS. Because NLS is a constantly evolving system and such a
aocument as the User Guide WOUld be expensive to constantlY chan~e
and reproduce. we keep up-to-date a document we call Folklore which
contains sections corresponding to sections in tne User Guide WhlCh
note changes to the system. errors in the User Guide, heloful
sU~Festions, usage. warnin~s, etc. This document is distributpd
periodicallY and is available online.
Sg7a
wr1tin~ a Primer containing a hi~nlY restricted
but Which is sUfficient for people to create ~nd
stu1Y documents and use the Journal capabilities.
Sg7b

We are presentlY
SUh~et

T~LS.

A number of changes to the NLS command language are under study. When

these have teen settled on. a new version of the User
written.
Support Of vl!linp. Network

GU~de

will be
5g7c

Dialo~

At the oresent time the NIC sup~orts several dialog groups, the main
one~ being tne NetworK WorKing Group (NWG) of 68 memOers and its
sUb~roups~ the Speech Understanding Research Group (SUR; of 20
members, and the Co~puter H~sed Instruction Group (Col) of 25

members. These ~roups can use our online facilities or mail us a copy
of ~ ~ocument and indicate that they want it distributed to a named

Online Team Environment
156

SRI-ARC 8 JUNE 1972 13041
Network Information center
Development and Operations
Offline Services

Iroup. We duplicate, catalog, and distribute the ~ocument to the
appropriate group of individuals and station collections. This mo~e
of offline and online operation has been a well received and used
service to aid crea.tion of a sense of community in the particular
distributed groups and as an aid to their collaborative functioning.
Sg8a

Requests for Network Information

519

People interested in the ARPANET, from organizaaons not directly
connected with the network, from organizations connected with the
network but not fAmiliar with the functioning of the netWork. and
oeorile in various media services, frequently contact us for s~ec1f1c
documents or general background information about the network. we
SUPplY information ~oth verbally over the telePhone and in ~erson,
and send appropriate intrOductorY or other material as required to
meet these requests. We frequently refer people to someone within the
network community for additional or more detailed information When
appropriate.
5g9a
We ~eel as part of the NIC service it woUld be deSirable to prOduce
at NIC more descriptive information about actiVities in the ARPANET
community. Eecause of staff and buaget limitations we have not been
able to take on this role as yet and have depende~ on people within
the community to write this type of documentation. Not nearly enough
has been written, however, and we hope in the coming year to try to
some degree to fill this networ~ documentation gap.
5g9b

TRAINING

SglO

To launch the online use of NIC services, we have run at SRI 6
tWO-day traininV courses in tne use of NLS and the Journal and we ran
one course at MIT-DMCG using their computer and the ARPANET to
contact our system for training. These courses have been attended bY
one or more people from the sites with online access to NIC services
and by people interested in the network and desiring a feel for
network usage and baCkground on present network operation. The size
of each class has generally run around 12 peoole, althougn over 20
attended the class given at MIT.
5gl0a

online Team Environment
157

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development and Operations
Offline Services

FIGURE 22. Instructors (right in each group) work With students
during practice period in NIC TNLS training course. Class
alternates between brief lectures and practice periods. NIC
provides a terminal for each student or for every two students
dependinv. on class size.

These people haVe returned to their sites to use our system and help
others at their site learn to use it as well.
5gl0b
We have been constantlY evaluating how best to teach the use of NLS
and have been ~etting useful feedback on areas of improvement needed
in TNLS to make it easier to learn and use.
5g1oc
To provide a useful service to a distributed community requires more
active on-site user instruction and help than we have yet been able
to provide. We hope in the cOMing year to be able to free resources
to provide more of this kind of assistance.
5gl0d
AS part of this teachinE! process a series of "workbooks" which take a
person through commonlY used TNLS operations has been prepared. 5~10e
We expect to continue evolution of our teaching aids an~ NLS features
to make the system responsive to both the needs of inexperienced and
eXPerienced users. We hope also to add those features Which COUld
make NLS more self-instructive.
5~lOf

Online Team Environment
158

SRI-ARC 8 JUNE 1912 l]Ohl
NetworK Information center
Development and Operations
Experience Using the ARPANET

EXPERIFNCE USING THE ARPANET

Experi~nce USing the ARPANET nas proven Quite satisfactorY at this stage
of its develop~ent. The ARPANET reallY onlY came alive 1n mid-OctOber
1971 even thougn the central communications network had been operational
over a year earlier. becaUse it was only then that more than one or two
nosts were operational on the network with the needed protocols.
5hl

The ARPANET, the network interfaces, local hosts, and network software
comprise a very large. SOPhisticated system in which there are many
Places where breakdowns can occur. The central network facility has
been Quite reliable, with MOSt of the breaKdowns and bugs in local hosts
and network softWare. With the many possible places of breakdown. early
network users and servers have had to be patient and understanding of
their own local system and those serving tnem on the network.
Reliability of hosts on the network seems to be constantlY improving.
5h2
Response to users over the network seems to ~enerallY be quite iOOd in
spite of havin,. two computer systems with their layers of networ~
protocol software 1n the loop.
5h3

It is clear that there is much yet to be learned about handling network
protocols in local. operating systems and in network hardware
development.
Sh~

are, however, Quite pleased with directions of networK develonment
and ar~ convinceo that this type of technology is here to stay and will
have a si~nificant impact on the development of this project (AkC), the
nature of the or~anization of research and development generally. and
information technolo~y.
5hS
5i

CONCLUSION

The Network Information center is, we believe. an example of a new type
of information service Which has significant future potential and, eve~
thoU~h it is pres~ntlY in an experimental and'development phase. is
prOViding usefUl online and offline serVices to the ARPANET community.
Now t.hat a basic operational serVice is in eXistence, future attention
will be turneQ not onlY to further evolution
the range of services
Offered. and the quality of eaCh service, but. also te an analysis of the
costs of each service. The cost of information services is a tooic of
much discussion in the literature but one on which there is little
concrete data (see Reference Section 2b). We hope in future reports to
be able to describe in some detail the costs of various NIG services and

Online Team Environment
159

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development and Operations
Conclusion

compare th~m with the reported costs of similar activities at other
centers or performed bY other means.

511

We also hone to stUdy the way various NIC services are being use~ bY NIC
clientele and to evaluate the utility of each service in more ~etai1.
5i2
REF~KENCES

(5l~S.) Current Catalog of the NIC Collection. ARPA Network Information
Center. Stanford Research Institute, Menlo Park. California. (current
version datea 1 february 1972.) Separately pa~ed.
Sj1

(5~1?) Jim White (UCS~). NWG/RFO 7~, Specifications for NetworK Use of
the UOSS on-Line System. ARPA Network Information center, Stanford
Research Institute, Menlo park, California 94025. 16 October 1970. lp.

5j2
(5621.) R. Anderson. E. Harslem, J. Heafner (RAND). NwG/RFC 83,
Lan~ua~e-j~achine for Data ReConfiguration. ARPA Network Information
Center, Stanford Research Institute, Menlo Park. California 94025. 18
December 1970. 120.
5j3
(57~O.) John T. MelVin, Richard w. Watson (SRI-ARC). NWG/RFC 97. A First
Cut At a proposed Te1net Protocol. ARPA Network Information center,
Stanford k~search Institute, Menlo Park. California 94025. 15 FebrUary
1971. 10.
5j4

(S772.l John heafner, Eric Harslem (WAND). Working Note on Data
Langua~e/Service. ARPA Network Information Center,
Stanford Researcn Institute. Menlo ParK, California 94025. 2~ February
1971. ?3p.
5j5
Heconfi~uratio~

(5775.) James r. White (UCSB). NWG/RFC lOS, Network SpeCifications for
Remote JOh Entry and Hemote Job Retrieval at UCS8. A~PA Network
Information Center, StanforO ResearCh Institute, Menlo Park. California
94025. 22 March 1971. 80.
5jo
(6025.) Pe~gy Karp. BibliographY of Literature on Computer Networking.
MITHE corooration. McLean, Virginia. December 1970. 87p.
5j7
(67~O.) ARPA Network Resource Notebook. ARPA Network Information Center,
Stanford Research Institute, Menlo Park, California. (Current version
dated 22 Nove~ter 1971.) Separately paged.
5jb

(6808.) UCSb SysteM 360/75, UCS~ computer Center. University of.
California at Santa Barbara. computer Sciences Department, Santa

Online Team Environment
160

SRI-ARC 8 JUNE 1972 130hl
Network Information Center
Development and ODerations
References

Barbara. california. In ARPA Network Resource NoteboOK (6740,), p.3.
April 1971.
5j9
(7104.) ARPA Network Current Network Protocols. AHPA Network Information
Center. Stanfor~ Research Institute, Menlo Park. California 94025.
(Current versicn dated 12 August 1971.) Separately paged.
5jlO
(7120.) Jeanne North (SRI-ARC). Functional Documents and Their Revision.
Augmentation Research Center, Stanford Research Institute, Menlo ParK,
California 9h025. 23 June 1971. 1p.
5jl1
(7135.) Peter Deutsch (PARO). N~GIRFC 190, DEC PDP-10 -- IMLAC
Communication System. ARPA Network Information Center, Stanford Research
Institute. Menlo Park. California 94025. 13 July 1971. 15p.
Sj12
(7136.) Charles Irby (SRI-ARC). NWG/RFC 191, Graphics Implementation and
Conceptualization at ARC. ARPA Network Information center, Stanford
Research Institute, Menlo parK, California 94025. 13 July 1971. hp. Sj13
(7137.) Richard W. Watson (SRI-ARC). NWG/RFC 192, some Factors Which a
Network Graphics ProtOCol Must Consider. ARPA Network Information
Oenter. Stanford Research Institute, Menlo Park. California 94025. 12
July 1971. 22p.
$j14
(7l~1.) Richard W. Watson (SRI-ARC). NWG/RFC 196, A Hail Box Protocol.
ARPA Network Information Center, Stanford Research Institute, Menlo
Park, california 94025. 20 JUlY 1971. 4p.
5j15

(7h70.) TNLS User Guide: Preface, Syntax and Contents. ARPA Network
Information Center, Stanford ResearCh Institute. Menlo Park, California
94025. (Current version dated 1 Se~tember 1971.) Separately pa"ed. 5j16
(7612.) Richard w. Watson (SRI-ARC). NWG/RFC 221, A Mail ~ox Protocol.
Version 2. ARPA Network Information center, Stanford Research Institute.
~en1o park, California 94025. 2S August 1971. 5p.
5j17
(7834.) James C. Norton (SRI-ARC). Outline for Establishing People
Support Team (PSST) at ARC. Augmentation Pesearch Oenter, Stanford
Research Institute, Menlo Park, California 9a025. 2 November 1971. IIp.
5j18

(8056.) Abhay Shushan (MIT-DMCG), ~Ob Braden (UCLA-CON). ~ric Harslem.
John Heafner (~AND). Alex McKenzie (BBN-NET), John Melvin (SRI-ARC), BoO
SUnaberg (HARV), DiCk Watson (SHI-ARC), Jim ~hite (UOSS). NWQ/P.FC 278,
Revision of the Mail Box Protocol. ARPA Network Information center,

online Team Environment
161

SRI-ARC 8 JUNE 1972 13041
Network Information Center
Development an~ Operations
References

Stanford Research Institute, Menlo Park, California 94025. 17 Novemoer
1971. hp.
Sj19
(8158,) Richard watson (SRI-APe). Summary of 19'11 Activities, AHPA
Contractors' Meeting, 9-10 December 1971. ARPA Network InforMation
Center. Stanford Research Institute, Menlo Park, California 94025. 9
December 1971. Pa~es not given.
Sj20
(8289,) Richard w. Watson (SRI-AHC). Reply To JBL on Output Device
Teletype. ARPA Net~or~ Information Center, Stanford Nesearcn Institute,
Menlo park, Oalifornia 94025. 20 December 1971. Pages not ~iven.
Sj21
(8295,) Richard W. Watson (SRI-ARC). N~G/kFO 289. ~hat ~e Hope Is An
Official List Of Host Names. ARPA Network Information Center, Stanforo
Research Institute, ~enlo Park, California 9~025. ~l December 1971. 3p.

5j22
(9474,) Donald E. WalKer (SRI). Interactive BibliograPhic Search: The

User/Computer Interface, Proceedin~s of a WorkshOP. ArIPS Press.
Montvale, New Jersey. 1971. 311p.

5j23

(9868,) J. B. North (SRI-ARC). Codes Used in the Master cataloe.
Augmentation Research center, ~tanford Research Institu~e, Menlo Park,
Ca.lifornia 94025. January 1972. 6p.
5j24
(9934.) DEX User Guide. Au~mentation Research Center, Sta,nford Research
Menlo Park. California 94025. 19 June 1972. 61P.
Sj2S

Inst1tute~

online Team Environment
162

SHI-ARC 8 JUNE 1972 13041
Network Participation
Introduction

NETWORK PARTICIPATION
Richard W Watson John T Melvin
Charles H IrbY and James E White
INTRODUCTION

6
6a

the prime period of this report, general network participation
other than direct Network Information Center activities has been active.
6al
Our networK participation activity has been in two main areas, protocol
development throu~h work in several protocol design committees and
general network coordination throurh membership on tne Short lived
Network working Group Steerin~ Committee and its successor, the Network
Facilitators Group.
6a2
Durin~

PROTOCOL

D~VELOPMENT

We helped launCh the Telnet Protocol design committee at the February
1971 Network working-Group (NWGJ meeting with the document "A First cut
at a Proposed Telnet protocol." Rre 97. NIC 57hO and participated
activelY in the desirn of the protocol. The Te!net Protocol allows user
typewriter terminals of various types and attached to the users host to
communicate with serving hosts through definition of a standard Network
Virtual Terminal system. The Telnet protocol is describeo in "ARPA
Network current Network protocolS", NIO 7104. Dick Watson and John
Melvin were active in this area.
6bl
At the May 1971 NWG meeting we helped launch the design committee set up
to studY the problem of general network data and file tranSfer. Two
initial protocols were designed at that meeting. one for data transfer
and another for file tranSfer. Although it was felt at the tiMe that
further worK and experimentation waS needed on this data and file
transf~r problem, the resulting protocol~ were felt to Oe adequate to
gain initial experience. These ProtocolS are documented in "ARPA
Network current Network Protocols" NIC 7l0~.
6b2
BecaUSe most sites were preo~cup1ed with implementing their Network
ContrOl Programs (NCP)and Telnet Protocols, implementation at a few
Sites. includin~ SRI-AQC, of the D,ta and File TranSfer protocolS did
not start until early 1972. At this time early implementation
experipnce and furth~r experience in using the network indicated that
the design of the Data and File Transfer protocols should be
reconsidered. A meeting ot the design committee was held at MIT in
April 1972 Whi~h resulted in a new design. The results of this work are
presently being documented by Abhay Shushan of MIT~DMOG.
6b3

online Team Environment
163

SRI-ARC 6 JUNE 1972 13041
Network Participation
Protocol Development

One of the services of the NIC is to facilitate networK dialo~ bY use of
the Di~loe Support SYstem (DSS) of SRI-ARC's Online System (NLS). To
Oeliver documents and ~essages entered into the DSS throu~h the network
to orinter files at remote sites is simplified if a protocol built on
the file Transfer protocol is supported hy each site. A protocol called
the "M~11bOX" Protocol was propose~ in RFC 196, NIC 7141 and revised in
RFe 221. NIC ~612 and RFC 278. 8056. The new File Transfer protocol
being developed maY include a "mailbox" capability (i.e., a capability
to deliver printer files to remote sites) and therefore ~ne future of
the MailOox Protocol is not cert~in at this pOint. UiCK Watson. John
Melvin and Jim White have been active in the ahove areaS.
6b4
In July 1971. the first meeting of the Network Graphics Group (NGG) was
held t6 discuss requirements for a protocol to handle interactive
graPhics over the network. One of our goals in the ~rap~ics area is to
support the display version of NLS over the network. ~e have been
worKin~ with L.P. Deutsch of xerox, Palo Alto Research Center in this
area, as xerox wishes to use NLS from an IMLAC display. The initial
work here was described by Deutsch in "DEC PDP-10--IMLAC Communication
System," ~FC 190, NIC 7135 and oy Irby in "Graphics Implementation and
Conceptualization at ARC", RFC 191, NIC 7136 At the same time "Some
Factors Which a Network GraPhics Protocol Must Consider." RFC 192, NIC
7137, was published by Watson.
6b5

Further meetin~s of the NGG have oeen held, with the most recent in
April 1972, at which we particip~~ed in the design of an in1tial
experimental interactive graphics protocol.

6b6

We hav~ been eXperimenting with running the display verSion of NLS over
the network from two sites, ~BN an1 UCLA~NMC. The results are
encour~ging from BtiN, which has ~ 9600-oaud interface to their IMLAC and
a resi1ent NOP. The UCLA-NMC system runs its Telnet ana its NCP as user
prokra~s.
They have a 1200 baud connection to their IMLAC. WheIl loaded,
response is considerably slower than experienced locallY at SRI or
experienced by B9~. When both ~he UCLA-NMC and 5HI-ARC maehines are
11~htly loaded, respcnse at UCLA is barely satisfactory.
6b7
Charles Irby nas been active in the network graphics area.

6b8

ThroU~h JiM White. Who joined SRI-ARC in early April, we have been
participatillg in the design of a Network kemote Jnb Entry Protocol. The
most recent ~esign meetin~ was h~ld in April 1792.
6b9

Some work has bepn aon~ bY the NWG on considering the reQuirement for a
Network Data Management protocol that WoUld support mana~ement of
distributed data. We have maintained contact with the peOPle worKing in

Online Team Environment
164

SRI-ARC 8 JUNE 1972 lJ041
NetworK Participation
Protocol Development

this area, but other than defining some of our needs for reportin~ to
this grOUP we have not been active participants as yet. We expect to
work more actively in this area.
6blO
Plans for the future call for continued active participation in the
protocol design areas mentioned abov~ and for implementation of those
protocols for experimental and normal usage, as appropriate.
6hll
6c

NETWORK COORDINATION

A Network Working Group steering Committee was setup at the May 1971
NWG meeting of which John Melvin was a member. This group Planned the
October 1971 NWG meeting and then was replaced bY a Network FaCilitators
Group consisting of nine members geographically distributed. This group
has as its purpose to helP give detailed technical information and
personal aSsistance to people desiring to ~et on the network or make
technical contact with the network community. This group has also
served a trouble shooting role in ~eneral network coordination. John
Melvin and Jim White are members of ~his group. John left SRI to work
at RAND in April 1972.
6cl
REFERENCES

(57hO.) John T. Melvin, Richard w. Watson (SRI-ARC). NWG/RFC 97. A First
Cut At a proposed Telnet Protocol. ARPA Network Information center,
Stanford Research Institute. Menlo Park, California 94025. 15 February
1971. lP.
601
(710h.) ARPA N~twork current Network protOCOls. ARPA Network Information
Center. Stanford Research Institute, Menlo Park, California 94025.
(Current version dated 12 August 1971.) Separately pagea.
6d2
(7135,) Peter DeutSCh (PARO). NWG/MFC 190, DEC PDP-10 -- IMLAC
Communication System. ARPA N~tworK Informatinn Center, Stanford Research
Institute. Menlo park. California 94025. 13 July 1971. l$p.
6~3

(7136,) Charles IrbY (SRI-ARC). N~G/RFC 191, Graonics Implementation and
Conceptualization at ARC. ARPA Network Information Center. Stanford
Research Institute. Menlo park, California 94025. 13 July 1971. 4p. 604
(7137.) Richard W. Watson (SRI-ARC). NWG/RFC192, Some Factors ~hich a
Network Graphics protocol Must Consider. ARPA NetworK In!or~ation
Center. Stanford Research Institute, Menlo Park. California 9~025. 12
July 1971. 22p.
6d5

(71hl,) Richard W. Watson (SRI-ARC). NWG/WFC 196, A Mail Box Protocol.

Online Team Environment
165

SRI-ARC 8 JUNE 1972 13041
Network Participation
References

ARPA Network Information Center, Stanford Research Institute, Menlo
Park, california 94025. 20 JUlY 1971. 4p.

6d6

(7612.) Richard w. Watson (SRI-APe). NWG/RFC 221, A Mail Box Protocol,
Version 2. ARPA Network Information Center, Stanford Research Institute,
Menlo park, California 94025. 25 August 1971. Sp.
6d7
(8056.) Abhay 8hushan (MIT-DMCG), Bob Braden (UCLA-CON), Eric Harslem, .
John Heafner (RAND), Alex MCKenzie (BBN-NET), John Melvin (SRI-ARC), Bob
Sundberg (HARV), Dick Watson (S~I-ARC), Jim White (UCSB). NWG/RFC 278,
ReVision of the Mail BOX Protocol. ARPA Network Information Center,
Stanford Research Institute, Menlo Par~, California 94025. 17 November
1971. hP.

6d8

Online Team Environment
166

SRI-ARC 8 JUNE 1972 l30hl
Computer Facility
Hardware

COMPUTER FACILITY
by Donald C Wallace, James C Norton,
John T Melvin, Donald I Andrews, Charles H Iroy,
~dwin K Van De Reit, an~ Kenneth EVictor

7
7a

HARDWARE
Introduction:

7a1

At the end of the first year of this contract, we transferred our
comouter operations from an XDS-9hO to a PDP-10 computer. The
transfer effort is ~escribeO 1n our interim report for the first year
(8277,).
7ala
activity dUrin( the past year has focu5e~ on additional
tuning of the new configuration, maintenance. trouble8hootin~ and
operation of the facility, and some upgrading of critical parts of
the system.
1alb

Hardw~re

FIGURE 23.
Present

(O~pos1te)

ARC computer system.

7albl

7a2

configuration

The present AHC computer facility configuration is as follOWS:

7a2a

Digital Equipment Corporation (DEC) equipment is the heart of our
facility, providing the co~puter, core memory, and mass storage
devices (discs, magnetic tape units).
7a2a1

7a2ala

PDP-10

Tne KA10 Central processor has a 36-bit word leng~h and an
l8-b1t a~dress field. It controls computer cycles, executes
machine-language instructions, and han~les priority
interrupts. It interfaees with the outside world through its
1/0 Sus and Memory aus.
7a2alal
processor

7a2alb

Memory - 8 MAlO's (2 ME10's being added in June 1972)

7a2alc

These are ferrite core memories and are used wi~n the KA10
processor. The memory alloWS for storage of 37-bit wordS ()6
bits and parity) and has a 1 us MA10/ME10 cycle time. Each
memory box has a stora~e capacity of 16,3dh words.
7a2alcl

Online Team Environment
167

Memory Bus

I/O Bus

KA 10
PROCESSOR

BBN
PAGER

DEC
TAPE
CONTROL

MA10
MEMORY
16 K

2 Units
ME 10

ME 10
MEMORY
16 K

MAG TAPE ~---"r------...,

I--

CONTROL

@ @

TM lOA

•
•
•

t--

8 Units
MAlO

IMP
t-INTERFACE

I--

t---

IMP

MODEMS

BRYANT
DRUM
CONTROL
,:::.

1.5 x 10 6 Words

1
I

AFPA
NETWORK

IlDRUM
BRYANTJ
DC 10
LINE
I-SCANNER

PATCH
PANEL

TTYS

L-_-y-_---'

DF 10
DATA
CHANNEL

RP 10
DISK PACK
SYNCHRONIZER

I
~

RP 02

_ _~J

DISK PACKS:

J...!,

20 x 10

MODEMS

Total Words

DATA
PHONES

r-------,
I

~-----+_:~~I

I/O

XCORE
INTERFACE

CONTROL

I
I

XEROX
IMLAC

XCORE
MEMORY
32 K

I--

~_-----rl_~

XCORE
MUlTIPlEXER

ANDREWS

I~_.-_J~____...,

TTY

DUVALL

I
~----------~~
I

I
IMlAC

5" C.R.T.

T.V. Camera

--c:rJ c:t?-----

""'-

DISPLAY
GENERATOR
1

i""-

I'-"

I--

---

DISPLAY
GENERATOR

r---

t- r--i""-

I-I--

TEST
BOX

I--

INPUT
DEVICES
CONTROL

---

HSDS
CONTROLLER
PRINTER
CONTROLLER

I
I

DISPLAY
CONTROL

Mouse

T.V. Monitor

REAL
TIME
CLOCK

DISPLAY
CONTROL
1

I
I
I

-------'"'

Extended I/O Control

I--

I~I--~---~

I
SPECIAL
'L REMOTE TERMINALS

i""-

I
I
I
I
I
I
I
I
I
t

Lc::::J c::tJ-

----

r0-

Keyset

k'" o",h,,<>rrl
.~-'-~~~.~

lICAMERA llCONTROL IIAND
lPATCH llPANEL Il-

12 Stations

t--

"'-

C2::J

1' . .

AID
CONVERTER

i""-

LINE
PRINTER

I
HSDS
(MODEM)
TA-8754-1

FIGURE 23

AUGMENTATION RESEARCH CENTER-COMPUTER SYSTEM CONFIGURATION

SRI-ARC
Comput~r

JU~E 1972
Facility

13041

Hardware

Memory Interface DF-10

7a2ald

The DF10 Data Channel is a high-speed trapsfer device (10t6
words/sec). In the ARC configuration, it accomplishes direct
data transfer between the (RP02's) and memory.
7a2aldl
once enabled. data transfers independently of the pro~ram
in pro~ress, therebY releasing the central processor for
other operations.
7a2aldla
7a2ale

Disc Packs - kP-02's
our RP02's each provi~e storage for 5.196,800 36-bit
access time is 62.5 ms. The transfer rate is
ms/word. The ARC system has four online RP02 t s for a
storaRe of about 20 x 10t6 words. An a~ditional RP02
available to back up the disc system.
Avera~e

Disc Pack Controller - RP10

words.

total
is
7a2alel
7a2alf

The RP10 provides the interface logic between· the DF10 Data
Channel and the RP02 Disc P~Ck Driver.
7a2a1fl
DEC tape Units
These are special magnetic tape units used for loading
programs into the core memory. They are usually used for
bringing up the ARC system.
7a2algl
Mag Tape Units anct Controller

?a2alh

These units enaole mass storage Of information onto ma~netic
tape and are used in performing disc dumps and for file
arChival processes.
7a2alhl
7a2al1

Line Scanner

The DOlO Data Line Scanner provides ~ timesharin~ two-way
interfage between the PDP-10 central processor and a maximum
of 6~ teletype-like stations. The current configuration
handles 24 stations.
7a2alil
Bol~. Beran~k, and Newman, Inc. (BBN) has provided mUch of the
special hardware and softwar@ that modifies the standard PDP-10
system to make it compatible with ARC and Network requirements.

7a2a2

Online Team Environment
168

SRI-ARC 8 JUNE 1972

1)041

Oomputer Facility
Hardware

PaginJ Sox

7a2a2a

This ~evii~ interfaces the PDP~lU central processor to the
core memories. It facilitates tne swapp1ng Of page! (512
36-oit words) between the core memories and either the dru~
or the disc.
7a2a2al
Interface Message

Proce~sor

(IMP) and IMP Interface

7a2a2b

The IMP is the interface between the AHC NetworK Information
Ce~tpr and the ARPA Net~ork. It connects to the PDP-10 via
the IIO Bu! and connects to the rest of tne Network via
~elephone lines.
7a2a2bl

Bryant Drum and Interface

7a2a3

The Bryant drum is a mass storage device with a capacity of
1,566,'720 words and an average access time of 16ms. Once
enabled, data transfer with the core memories proceeds
independentlY of the pro"rams in progress, thereby releasing
the central processor for other operations. The drum is the
primary transfer (swappin~) device to the core memories. 7a2a3a
Bryant Disk

7a2ah

Tnis mass storage device nas a capacity of 23 x 1016 36-bit
words. At present it is used as baCkUp for tne DEC RP02's wnile
further uses for it are being considered.
7a2a~a

IIO Control Box

7a2a5

This deVice is used to extend the PDP-10 IIO Bus. It also
provides manual control over the periPheral devices it
interfaces.
7a2a5a
External Core (Xcore)

'7a2a6

Tnis is a 32k 24-bit memorY. It is now used for stora,e of
display and keYboard information and other non-critical
information transferred at slower rates.
'7a2a6a
xcore Multiplexer

7a2a7

This attaches 8 ports to Xcore. (The main core MA10/ME10's have
4 ports as part of their structure).
7a2a7a

online Team Environment
169

SRI-ARC 8 JUNE 1972
Comput~r Facility
Hardware

13041

xc ore Interface Box

7a2a8

This device provide~ for the proper timin~ and voltage
interface between the PDP-10 memory and the Acore Multiplexer.
7a2a8a
peal Time Clock
7a2a9
This cl~ck provides the reference for all times recorded bY the
system.
7&2a9a
TTY Pa.tct Panel

7a2alO

This connecting panel allows some of the many TT¥ and Modem
inputs to be connected to the 24 channels available on the line
scanner.
7a2alOa
nataphones

742&11

There are 8 DataPhones

an~

Modems connected to the system.
7a2a11&

Display Controllers J Tasker Display Generators, and Closed Circuit
TV

7a.2&12

These devices enable local users to view &ny of the 12
television monitors (located at the display consoles). These
monitors display infor~ation stored by the system in xcore.
7&2a12&

Data Products Line Printer

7a2a.13

This device provides for hardcopy printout of user and
files.
Test box

syst~m

7a2a13a
'7a2a14

This unit occupies A part of Xc ore and is used as a
tool.

trouble~hooting

Input uevices controller (IDC)

7a2a14a
7a2a15

This equipment handles information from the displa~ consoles
(12 KeyboardS, keysets, and mice) and stores it in Xc ore to
a~ait processin~.
7a2alSa
A/JJ

converter

7a2a16

Online Team Environment
170

SRI-ARC 8

JUN~

1972

1)041

Comouter Facility
Hardware

This converts analog mouse coordinates to digital coordinates
to be stored in Xcore via IDe.
7a2a16a
Display Consoles (12, Plus spares)
These each are

co~posed

of:

Mouse
Keyset
Keyboard
Video Disolays

7a2a17
7a2a17a

7&2&17a1

console Patch Panel
This enables video output from the display system to be
interchanged among the various diSPlay consoles within the AHC
work area and is also useful in trOUbleShooting.
7a2a18a
?a2b

Illustration to be used:
ARC PDP-10 system Configuration Layout
PrOblemS We Have Been Facing

?a2bl
?a3

7a)a

ARC Service problems

one of ARC's key Objectives is to provide reliaole service to 1~s
augmentation system users at as reasonable a cost level as we can
within the context of. cur part-developmental, part-service
environment.
7~3al
We have provided Many ARC and Network users with NLS service
the cast year. In this period. ARC and NetworK users
in many instancesexcerienced system access ability and
user-response at what we consider to be undesirable levels.
7a3ala
The main cause of such lowereO service levels has oeen problems
with our hardware. althou~h some SOftWare problems have also
been encountered.
7a]alb

durin~
h~ve

we have been concentrating on the various hardware problems that
have cau~ed lower-than-desir~d service levels.
7a3a2

one source of trouble has been the external core (Xcore)
configuration through Which we have run the Network Interface,
the ARC displays. tne line printer, ana other devices.
7a3a2a

online learn Environment
171

SRI-ARC ~ JUNE 1972
Computer Facility
Haraware

13041

Sens1tive cable connections that have broken with handling
durin~ maintenance and trouble-Shooting worK, ~any cards
that have failed, and basic internal xcore groundin~ design
flaws were the main causes of xc ore failures.
1aja2al

New cables have been made and are oeing installed. A
different grounding scheme has been implemented and
appears to have reduced the nOise levels previouslY
exoerienced in Xcore.
7a3a2ala
A new BbN Network Interface nas been installed that does not
connect to the system through our Xcore. In tne future. Xc ore
trouble will not bring down our Network connection (at least
not as in the past).
7a]a20
The DEC PDP-10 has had several failures in the past few months.
DEC responds qUicklY and effectively to such occurences.
713a3
Any timesharing syste~ is susceptible to such failures. The
fact that we have onlY one machine puts us in a position of
being more vulnerable to service interruption than that
experienced by large commercial utilities, where there are many
~achines. When one machine ~oes down. another is Switched in,
frequentlY without the Users seeing much effect.
7aJa3a

we plan to discuss with c~mmercia1 utilities the POSSibility' of
their providing all or part of another machine for the NIC
portion of our NLS service in an effort to:
7aJa)o
1. aecome more reliable and

7a3a3bl

2. To provide more COMPuter service to NIC users.

7a3a3b2

We woUld have to secure additional fundin, for such an
arrangement.

7a3a3c

The br~ant drUm nas failed several times recentlY, even with
freauent maintenance by Aryant. Xhe UNIVAC drums have been used as
baCKup, but have been unreliable at times.
7a3a4
The UNIVAC drums are too ~xpensive to keep as bac~up and don't
speed the system signi£icantlY when used with the brYant drums
s1ruultaneoUslY. we have terminated the lease of the UNIVACS for
cost reasons.
7a3a4a
we have

trie~

swapping Off a single DEC 6iskpack to see if we

Online Team Environment
172

SRI-ARC 8 JUNE 1972 l;O~l
Computer Facility
Hardware

can backup the Bryant equipment satisfactorily with that
7a3ahD

arran~ement.

Th~ number of users supportable is considerablY reduced, but
service to a limited number (4 or 5 users) is satisfactory.
7a3a4bl
With the added 32k DEC memory (coming in June 1972). there
will be less swapping, so that swappin~ off the diskpacks is
expected to support more users than during early trials.
7a.3a4b2
In addition. we plan to develop software that will swap Off
sever~l of the paCKS. not just one. We also are contemplating
adding another diskpack controller.
7ala~c

If swepping oif the diskP~CkS doesn't appear to be the best w~y
to provide backup for the Bryant drum, we may have to add
another Bryant drum.
7a3a4d

The TaSKer display system is now five years old and is requiring
an increasing level of maintenance and trouoleshooting.
7~3a5
Since it provides the primary display facility to ARC liNLS
users, its early replacement appears necessary, both to provide
more reliable service and to up~rade the ouality.of the
displays to current state-of-the-art perfor~anc~ levels. 7a3aSa
we have been actively trying to secure more of our equ1pment from
commercial sources, while puttin~ effort into making hardware that
is unique-to-ARC more reliahle through upgrading efforts.
'7a3a6
The xeore configuration and some interface hardware are still
one-of-a-k1nd prototype eouipment, and in some ways do not nave
the sOlid commercially-produced characteristics we now need.
7a.3a6a
The Bryant disc is not being used now. since it was the source
of serious reliability crobleMS (craShing the system
!requp.ntlY) last ye~r. Its functions are now bein~ performed bY
~ne n~w DEC diskPacks.
7a3a60
The Bryant disc is several years old
overnaul if it is to b~ further
system. We hav~ been lOOking for ways
th~t dO not put it in the ~ainline of

maj~r

now an~ is due for a
utiliZed in the ARC
to use its capaCity
our system o~eration.
7a3a6bl

online Team Environment
173

SRI-ARC 8 JUN1 1972
Computer Facility
System SOftware

13041

SYSTEM SOFTWARE

Imlac support for DNLS

7bl

A orogram written (by Peter Deutsch of Xerox Palo Alto Research

Center .- XFARC) for an IMLAC display and processor and some
modification to the d1splay sup~ort monitor calls allowed us to offer
uisclay NLS suoport over Phone lines and through tne ARPA Networ~.
To dat~ DNLS has been experimentally used by a remote ARC employee
(about 100 miles away', phone line connect1on), by XPA~C personnel
(also phone line), at the Network Measurement Center at UCLA (A~PA
NET). and at BBN (ARPANET)
7bla

TENEX

7b2

In our inital use of BBN-TENEX the main concern was to just "maKe it
work". In getting TENEX to run on our unique harOware configuration
we ~ade many extensive modififat1ons and additions. In the ensuin~
year and a half Of experience with TENEX and its evolution we have
learned much. with the responib11ity Of providing reliable computer
resources for the NIC many heretofore overlooked requirements in
runnin~ our facilities have become considerably more critical.
702a

Lt has beco~e increasingly important to run as unmodified a version
from BHN's distributed version as possible. MOdifications are only
madp When tnere is a real user need and B~N cannot or will not make
the appropr~ate mod or addition. When we dO make adoitions or mods
to TEN1X we first attempt to implement them in a Mann~r that would be
of ~eneral use to TENEX users and secondly we notify 8BN of the
chante in the hope that it will become a part of standard TENEX with
a. subsequent release.
7b20
The followin~ is an overview Of many of the changes we have made here
at SRI-AHC to HBN distributed TENEX.
7b2c
Further ~etails.
for the asKing.

includin~

implementation details. are aVailable
7b2cl

OPERATlONAL PROCEDURE CHANGES

704::U

CHANG£S TO START-UP AND HESTArtT PROCEDURES OF THE MONITO}'?
DTBOOT

7b2dl
7b2dla

We have switcheJ from using TENOMP (for load1n~ tne monitor
from DECTAP) to usinl DTBOOT, a DEC-provided replacment for

Online Team Environment
174

SRI-ARC 8 JUNE 1972

13041

Comeuter Facility
System Software

TENDMP that is much easier to use and a Detter
TENDMP.

than
7b2dlal

pro~ram

Novice startup procedures

7b2dlo

We have chan~ed the starting address of the monitor from 100
(which goes immediately to DDT) to SYSG01.
7b2dlbl
Thus the procedure necessary for a novice to
system is easier and is as follows:

up the
7b2dlbla

brin~

readin DTBOOT
type CR.

one of the by-products of

usin~

built in default file names.

nTaOOT is that it has

We have renamed the resident monitor to be SYSTEM.SAV
SYSTEM.SAV is the default name for loading for DTBOOT
7b2dlc

DDT Flushin«

Several new flags were added to the monitor to control tne
use of memory for DDT. BasicallY three ootions are available
to the system pro~raMmer.
7b2dlcl
The system may be run:

7b2dlcla

Without DDT or the monitor symbol table.
With DDT, but no symbols
~th

both DDT and the monitor symbol table

Monitor routines are also provided to dynamically alter
tne state of DDT monitor core usage.
7b2dlclo
The rationale behind this new facility is that tne
monitor symbol table uses 12k of meMory that would
normallY ce available for user pro2ram ex~cution. Tnis
new feature alloWS the system operator to spl~ct the
optimal use of memory given system load. reliability and
use.
7b2dlclc

Online Team Environment
175

SRI-ARC 8 JUNE 1972
Comguter Facility
System SOftware

13041

System Startup procedure

7b2dld

We have modified the system such that if CHECKDSK does not
run successfullY, then nothing else. e.g. AUTO-STARTUP joos,
is allowed to run (exc~Pt for the operator's console and one
special dial-up line) until the digc has been fixed and
CHECKDSK hiS been run successfully.
7b2dldl
If CHECKDSK does not run successfullY, then a message is
broadcast to all currentlY connected users telling them
that the disc needs fixing.
7b2dldla
we allow a dial-up line access in this case, so that a
system programmer can fix the disc from nome if
neccessary.
7b2dldlb
We made this modifioation with the primitive inter-joo
communication described below.
7b2dldlc

Auto-start-up jobs

7b2dle

we have changed the manner in Which auto-start-up jobs get
started so that they now run under the EXEC rather than
under the MINI-EXEC
7b2dlel
COMPILING AND LOADING OF A NEW MONITOR

7b2d2

we no longer add coae to existing files when we get new monitor
releases. Instead we have defined additional files that are
assembled with each group of files an~. where pOSSible. WE have
made our additions in these new files with JRSTs an~ CALLs to
~he new code.
7b2d2a

We have also broken the MON assembly into swappable and
resident code similar to the SWPMON assemblY.
7b2d2al

Thus we can add COde that is logically related to code in
the MON assemblY but not resident.
7b2d2ala
we have made several changes in tne compile-and-load sequence
7b2d2b

These changes give ua more information at each step in
putting together a new monitor.
7b2d2bl
~e have changed both the FAIL assembly (ASSFIL) and the
MACRO assemblies (MACALL) so that, where pOSSible, we are

online Team Environment
176

SRI-ARC 8

JUN~ 1972
13041
Computer Facili~y
System Software

notified when the swappable cOde overlaps the resident
code at compile time rather than at load time.
7b2d2bla

When an overlap does occur, we are told about it
immediately.
In addition we are told what has to be changed in
order to get rid of the overlap.
TO ~et notice of overlaps we had to break out COde
from PARAMS, FPARAMS, and some other routines and
localize it in one routine.

The MON assembly now tells us trte lower bound for
loading MFLIN, etc.

In addition the driver file MACALL, after the
assemblies are done. executes the SUbsystem TEeo and
~ypes out the current load address of MfLIN
This number can then be immediatelY compared with the
output from the MON assembly and check~d for val~dity.
We save ~oing through a load only to diseover that
overlaps do occur.
We have changed the

loadin~

se~uence

as follows: 7b2a2blo

We have removed the bounds checKing that used to oe
done by ~oing into DDT.
A neW program was written that is assembled with and
called by POSTLD.
This pro~ram does the checkin~ that USed to be done in
DDT plus some additional checkin,.
In addition it outputs this information in a nicely
formatted way that can ~e kept as current
do~umentation for this version of the mon1tor.
This proRram also gives us the current values of
certain critical cells.

have adOed another nrogram that is also assembled
POSTLD.

~e
~ith

online Team Environment

177

SRI-ARC 8 JUNE 1972
Computer Facility
System Software

13041

POSTLD calls this program.
This pro~ram types out the file names and current
versions of the source files that went into ~enerating
this version of the monitor.
This information also provides useful documentation on
the current monitor.
In addition to typing out current file names and
version numbers it sets up cells in tne Monitor which
contain the current version number of each of the
files.

Thus we can go into MDDT and determine which source
files were used to generate this monitor.
PRI~ITIVE

INTER-JOE COMMUNICATION

7b2e

we have implemented a very primitive inter-job communication
faci11ty.
7b2el
It involves a
other bits.

syste~-wide

cell with each bit

in~eoendent

of the
'7b2ela

Each bit is directly settable, resettable, and testaole.
7b2ela1
A process must kno~ the password for any bit to set. reset,
or test it.
7b2e1a2
ADV!SE

7b2£

have implemented an advise facility similar to that of tne

9~O.

702£1

Its implementation is similar to the implementation of links,
except that lines are checked to see if theY are input linked
at the time characters are put into the big buffer.
7b2fla

If lines are input linked, then characters are Placed into
the big buffer with the line number of tne advisee. 7b2flal

HANDLING OUR DISPLAYS

7c2g

(see also PFO 190 (7135,) and HFC 191 (7136,))

Online Team Environment
118

7b2g1

SRI-AHC 8 JUNE 1972

13041

Computer Facility
System Software

we have made many changes to the teletype routines to accommodate
6ur displays.
7b2g2
Basically, we

def1ne~

an escape sequence:

This escape sequence declares that the following n (where n
is part of the escape sequence) characters are to be
interpreted differently from normal TTY input.
7b2~2al
There exists a mapping from the special sequence to
normal TTY input.
'7b2g2ala
~hen our displays are in TTY mode (as opPosed to
display mOde) thiS mapping applies.

If we are in ~isplay mode, then the characters of the
special sequence include: what keYboard character was
strUCk. what combination of tne mouse buttons and keyset
buttons were struck. what the current position of the
mouse is, and, optionallY, the time of the character
input.
7b2g2alb
This escape sequence enables us to support other
displaYs (including IMLACS over the NET) with no
to either NLS or TENEX as long as these ~remote"
input the proper escape sequence.

types of
change
displays
1b2g2alc

we have made the necessary changes to the rest of TENEX to
accom~adate this sequence, e.g. STI, and ad~ed additional jsies
to be able to define what type of terminal (TTY, local diSPlay,
remote diSPlay) is associated with each line.
7b2g2b
FAST TERMINAL HANDLING

7b2n

we have added a jsys to say that paddin~ (sending additional
rUbouts) is required for tnis terminal when a OR or LF is output.
7b2nl
This means that the user will not lose tne characters at the
left margin on fast terminals.
7b2hla

ewe understand that version 1.29 takes care of padding.
ret rid of any inconsistencies in our code.)
SCHEDULER

We will

7b2h2
7b2i

C~ANGES

online Team Environment
179

SRI-ARC 8 JUNE 1972
Computer Facility
System Software

13041

we have chan~ed several scheduler parameters to get the kind of
response we want.
7b211
primarily, we have tuned the system to give very good service
hi~hlY interactive processes and very poor service to rr.ore
computebound processes. We toned it by adjusting ~BASE, T~ASE,
and TFACTR.
7b2ila
to

we have also chan~ed our working set parameters in an attempt
"to reduce I/O wait ti~e by ~etting more processes in the
balance set.
702110
In addition, we have our own version of NEWS!, which, to~ether
with other code, ~ives preferential treatment ~o disPlay
terminals. This is a departure from the Bil&N idea of lIN
service to all users. We give our disolay users a lar£er share
of the machine.
7b2i1c

a bit of code has been added at ARC to

statistics.
7b2i2
This ~e~surement code is oart of a SUbsystem (SUPERWATCH)
written at AHC to get a profile of the system performance at
any time.
7b212a

~uite

~ather

Documentation on this system is available (see below).
7b212a1
In ad~ition to finding how the CPU's time is spent, w~at
important scheduler variables are, and how our disc and drums
are behavin~. we can sample the program counter and/or the
conterts of memory.
7b2i2b
The program counter (PC) sampler 1s very valuable. The PC
is sampled when the two clocks are synchronized every 50ma,
in the clock interrUPt. Either user or system mo~e is
sampled. A specified SUbsystem may be sampled in user mode.
The information is cOllected as a "count of samples ~ithin
specified ranges, with One count for out-of-range in each
direction. The ranges are specified as a lower bound and
word count per range. The wor~ count is roUnded to a power
of two. so that a SUB, L5M, AOS sequence does tne joo.
7b2i2bl

The saMPling of memory (user pages) is done bY a process
clOck on 500ms intervalS.

It giVes us a prOfile of

pa~es

me~ory

7b2i2b2

USP.

are categorized as private unmodified, private

Online Team Environment
180

SRI-ARC 8 JUNE 1972 l)Okl
Computer Facility
System SOftware

modified, shared but not referenced. shared and
referenced bY one process, snared and referenced by more
than one process.
7b2i2b2a
Based on the information gather~d by the measurement code, the
scheduler generat~s a number we call the response index. It is
an exponential avera~e of the length of time processes on Queue
z~ro wait on the go list cefore bein~ broUgnt into the balance
set.
7b2i2c
lt indicates the kind of service being provi1ed to
interactive users.

7b2i2Cl

If the response index Joes over a threshold, the EXEC
prevents new logins.
7b2i2c2

since our scheduler has been biased against computebound jObs, we

added a JSYS to set some scheduler parameters (T8ASE, TFACTR).
This allows us to dYnamically alter the scheduling characterists
of our system.
7b2i3
A speCial subsystem allows tne operator to set tne oarameters

compile time" or "normal II.

•

-;b2i)a

compilations during regUlar hours do not disrupt serVice to
interactive users (and in general, don't get done).
In~eractive service during compile time is poor, and
compilations get done quiCkly.
7b213b
MISCELLANEOUS CHANGES

7b2j

GTJFN

7b2jl

If a version number of -h is
haDpens:

specifie~

followin~

to GTJFN then the
7b2jla

If tlhe file exists then the user is returned a JFN for the
version number of the file.
7b2jlal

hi~hest

If the file does not exist then a file is created for the
user and he is returned a JFN for tnis new file.
7b2jla2
7b2j2

nELNF'

This is a new jays that we have adaed.

online Team Environment
181

lb2j2a

SRI-ARC B JUNK 1972
Computer Facility
System Software

130ul

It will delete all but the n (where n is a passed parameter)
hiFhest versions of a file.
7b2j2al
Superwatch.

703

Abstract

703a

superwatcn is an information gathering and formatting
rtesigned to help fin1 out what is ~oing on witnin our
tiMesnarin~ system.

Dro~ram
TEN~X

7b)al

It is d~signea to put a very small load on the system while
collecting inforMation from it~ so that it will not alter'the
operation of the system si~ni£1cantly.
7b3a2
'7b3b

Introductior.
The system monitoring is done in

s~veral

steps:

7bJbl

Information is collected within the timesharing monitor in a
crude form, usuallY as meters. A meter is a counter tnat is
continually incremented, and represents a count of events or
the sum of Quantities.
703bla
The difference oetween two meter readings, and the time
interval between the readin~s, can be used to compute an
avera~e rate over the interval.
7b]blal
A user mo(1e program collects tne crude data from tne system at
specified intervals. This information is written directly on a
file. This process must ~ut very little load on the system.
7b,3b1 b
At the end of the collection period, the file is printed in
whatever form the user desires.
7b3blc
Monitor meters
The T~NEX system, as it came to us, contained several meters, but
we found tnem inadequate in answering our qu~stions aoout the
~ystern.
703c1
~e

added several types of information collection to the system.
7b3c2

we added meters to the monitor. especiallY with respect to hoW
time Was spent in scheduling and other system overhead
functions.
7b3c2a

online Team Environment
l82

SRI-ARC 8 JUNE 1972 13041
Computer Facility
System Software

we added sa~pling cOde to a clock interrupt routine to measure
sever;l thin~s, especially with respect to tne balance set and
memory utilization. The s~mplin~ is don~ at a 50ma. rate.
703c2b

perha?s tne singly most useful thing is the PC sampler. which
runs ~ff th~ same clock interrupt. Given ranges of pro~ram
address~s, the PC sampler counts the number of times tne
program counter was within each range at the clock interrupt.
From a large number of such counts one can infer the percenta~e
of tiM~ spent executing in each range. The PC sampler can be
!ocuspd on a specified SUbsystem or the system itself (system
mode execution).
703c2c
A device called a fault record works in a manner similar to the
FC sar,pler and records pa«e faults. I~ records either fault
location or fault address for a specified subsystem. The user
gets a picture of where page faults occur in the program in
QUeation. It is generally used to refine prograM organization.
7b3c2d

The User Program -

Superwa~ch

Subsystem

7b3d

The SUbs~stem h~s commands for COllecting crude data from the
Monitor and writing it on a file, and for reading such files and
formatti~g the output in a Variety of ways.
7b)dl

The collection
SMaller amount
The other must
since it takes

can be done in one Of two modes. one collects a
of data, runs faster, and uses less file space.
COllect ~ata from the monitor at a Slower rate
more time.
'7b3dla

The primary parameter specifed by the user is the interval
betWeen collections or samples. The program simply dismisses
itself for the specified interval oetween samples.
7b3dlb
The

COde has been written so that virtually no
is lost if the system crashes, or if the program is
the user.
7b)dlc

c~llection
infor~ation
ter~inated by

After collection is finiShed, the !tatistics are Obtained ~y
formatting the file.
printouts for an entire file, or just a
portion (given two times of day) can b~ obtained with a variety of
orint comman~s.
7b3d2
The objects of the printouts are parameters. The set of
parameters is a superset of the set of meters or items
collect~d from the monitor.
7b3d2a

online

Environment
183

T~am

SRI-ARC 8 JUNE 1972
Computer Facility
System So!twar~

130hl

are functions of several meters. The value
~re computed by a procedure which has
available to it all ~ata collecte~ from the monitor at the
time interval in Qu~stion.
7bjd2al

M~ny

parameter~

of some parameters

Generally. the user specifies a set of p.rameters he wiShes
to see.
7b)d2a2
Tte simplest format is a list of the values of each reaue8te~
paraMet~r at each interval.
An average over the entire test is
included.
7b302b
FaUlt record and PC results are printed in table forM ~iv1nr
address ran~es. counts and percentages for each range.
7b]d2C
For a specified parameter, a line printer h1sto~r&m can be
printed, for either the distribution of that parameter
(distribution of the values at each interval), or the
parameter's value as a function of time.
7b)a2d

A special command allows a real time display (nistograms) of
specified parameters in real time. This is actually a
collection command rather than a print command. other
collection commands allow the user to request a real time
printout. Tne formatting is done at the time of cOllection,
and the user can see the results imme~iatelY.
7b3d2e
TYPical use

7b3e

we usually use the subsystem in one of several ways:

7b)el

We often run it with a collection interval of about 1 to 5
seconds for 10 minutes to an hour durin~ peaK loads to study
uerforrnance.
7b3ela
Another mode 1S to run it all day with a collection interval of
15 m1nut~s. This gives a profile Of the eystem usage, type of
load, and overall performance for the entire day. A jOb wnich
runs tne sUDsyste~ in this mode is &utoMat1cally started up
when the ti~e sharin~ system is started.
7b3elb
Tne slow type sampling with a lS min. interval is also used to
collect PC and Fault record statistics.
The sampling is
~enerally done over a periOd of about 3 to 5 nours.
7b3elc

Online Team Environment
l84

SRI-ARC 8 JUNE 1972

1]041

Computer Facility
System SOftware

The re-al tiMe display moce is useful for
~appenin~

When the system is

behavin~

finctin~

out wha.t is

strangelY.

1b]eld

~here are several parameters which we nave found to be very
useful:

It is essential to l(now wtiere the CPU ,time is going.
terMS of percent of real CPU tiMe:
idle time
tir.e spent

deal in
7b3e2a
7b3e2al

runnin~

user programs

7C13e2a2

time scheduling;
time spent

\'ie

7b3e2

7b3e2a3

waitin~

on drum and/or disc

time in system overhea1 (e.g. network.
etc. )

~arbage

collection.
7b3e2a5

Disc and Drum behavior and usage:

703e20

percent of time busy

7b3e201

queue lene:ths

"7b3e2b2

time to

tr~ns£er

a page,

includin~

Queue wait time

number of reads. writes

Memory utilization:

703e2o3
7b3e2b4
7b;e2c

numoer of jObs hOlding space in memory

7b3e2cl

amount of memory reijerved for above jObs

7b3e2c2

actual nunber of pages held by above jObs

numoer of free pa,ps
numo~r

pa~es

7b3e2c4

retained due to sharing

usage bv SUbsystem

7b)e2c5
'lb~e2d

percent of real timg used

Online Team Environment
185

7o.3e2dl

SRI-ARC 8 JUNE 1972
Computer Facility
System Software

co~pute

13041

time between page faults

7b3e2~2

There are many other parameters (over 100). They nearlY all are
of value just to know that various aspects of the system are
functioning well.
7b3e3

A FeW Discoveries

7b3f

Reveral times our Bryant Disc has malfunetioned in SUCh a way that
it tOOK the maximum length Of ti~e to do a seek. AS a result,
disc transfers were very slow (about 260ms. per pa~e) and the
system response very poor. It was not apparent that the aisc was
the cUlprit since no errors were being reported. But a
statistical printout showe(l the long disc pa~e times. as well as a
long disc queue length, and excessive I/O wait and low utilization
~ecaUse of the oisc.
7b3fl
we also discovered a performance problem in tne time Sharing
system. When many jobs were Sharing the samp. suosystem, the
system was over-reserving ~emory for those jObS. we presented the
prOblem to BB&N. and the next version of TENEX from SB&N had a
mO{iiiied memory Management package in it which handled shared
oages in a more satisfactory way.
7b3f2
The p~ sampler has uncovere~ two expensive parts Of the scheduler
which may have been corrected in the newest release from BB&N
CTENEX 1.29 which we have not used yet). Also, the PC s&mcler has
been a guide for reorganiz1n~ the code in NLS, in order to ~roup
frequently used code to reduce the working set size.
7b3f3
we Keep track of the overhead time spent handling tne Network. It
is in the range of 0.5% to 1% of the real CPU time p~r NET u~er to
maintain it.
7b3f4
one of our subsystems makes particularly heavy use of the disc
(BSYS).
when running on the Bryant disc, we found that system
~erformarJce was very poor wn~n BSYS was running and using the disc
heavily. A statistical printout showed that it was due to very
high 1/0 wait time Oecause of a long disc queue. This was a
factor (in addition to re11&b11ity) for getting tne disc packS.
When runnin~ BSYS with the disc pack system, the disc use is
increased, but the IIO wait time is not si~nificantly increase1.
The page tranSfer time on the Bryant disc is about 160ms •• and on
the paCK~ 1t is about 35ms.
703£5
occasionally~

we have problems with one 16K memory bOX.

Online Team Environment
186

The

S~I-A~C

8 JUNE 1972

1)041

Comnuter Facility
System SOftware

stanaard procedure is to run without it, with 16K less memory for
swapping sPace. The result is a very clear degradation in
service, with more time spent in Ilo wait and with fewer jobs in
meMory at one time. Also, we occasionally run with the system DDT
(debugging system) and symbols resident in memory. This reduces
user swarpin~ space bY about 10K, and the result is evident in a
statistical printout. This prompted us to think that we would
«aJ.n in system performance by increasing the amount of memory.
~nother 32K will be delivered soon, and we snall see just how mucn
it increases our performance.
7b3f6
GenerallY, an information
TO verify that the

system like ours is valuable:
7b3f7
is working as designed.
7bJf7a

~ather1ng

syste~

TO identifY the caUse of poor serVice at the time it is
happenin~ (e.~. a bug, hardware malfunction, or just
overloading).

7b3f7b

TO identifY the "weak link" in the system confi«uration (drum,
disc, memory or CPU capacity).
7o)f7c
TO evalUate changes in the system or hardware configuration.
703f7d
R~F~RE~CES IV - Computer Facility
7c
(7135,) Peter Deutsch (PARO). NWG/kFC190, DEC PDP-10 -- IMLAC
Syetem. ARPA Network Information Center, Stanford Research
Institute. Mpnlo Par~. Californ1a 94025. 13 July 1971. lSp.
7c1

Com~unicat1on

(7136,) Charles lrhy (SRI-ARC). NWG/RFC 191, Graphics Implementation and
conCeptUalization at ARC. ARPA Networ~ Information center, Stanford
Research Institute, ~'enl0 park, California 94025. 13 July 1971. ho. 7c2
(8277,) D. c. ~;nRelbart (SRI-ARC). Network Information Center and
Augmented Team Interaction, Interim Technical R~port.
Autmentat10n F~search Center, Stanford Res~arch Institute, Menlo Park,
California 91~02S. kome Air Development center, A~PA. ~ADC-Tk-71-175, AD
737 131. 30 June 1971. l04p.
7c3
Comput~r

online Team Environment
187

SRI-ARC 8 JUNE 1972
Pla.ns
Ooa.ls

1304l

Online Team Environment
188

SRI-ARC 8 JUNE 1972

13041
Plans
Goa.ls

PLANS
by James C Norton, Richard W Watsona~
and Douglas C Engelbart

GOALS

ARC plans to reSOlve a set of interdependent ~oals by conducting
research and providin~ service under a new "Base-project" contract that
concentra~es primarily upon the goals of:
dal
Aavancin~ the techniques available to AKC and Network system bui11ers
and users for augmentin« the development Future Plans of
computer-oase~ information systems.
6ala

Ma.king tne Network Information center into both
(1) an

8alb

useful service to the Network community and
8a.lbl
(2) an 1~portant part of the Network Experiment (in its
1iatributed, colla.borative operations and in its Network-utility
role).
8alb2
i~creasingly

Moving useful augmentation techniques and services out into the
ARPA-Network Community.

8alc

In the discussion that folloWS, and in our proposal to RADC/ARPA
(7hUh.), we outline the types of a.ctivitv that seem to us best to meet
these eoals.
8a2
SERVICE TO USERS

A central point of our prooosed approach is that we need to become
prepared to negotiate and provide ~n extensive amount and ran~e of
serviceS to distributed users. our position sterns frOM the following
reasoning:
8bl
Our planned NIC services involve a stea~ilY expanding set of explicit
"reference Rona d1alo;;: support" services (see -- 7lJ.06,). This is
consiaered ty us to be the central commitment of a "Networi
1I
Informat~on center.
We plan to be readY to expand the operational
capacity of these services as needs and Possibilities emerge.
801a
Aside from these NIC-explicit services, there are other services
that our ~eneral set of tools and metho~s can prOVide and that are
interest to other parties. Over the years that the Network has

online Team Environment
189

SRI-ARC 0 JUNE 1972
Plans
Service to Users

l30kl

been evolving, there have been many discussions about the
riotential value ARC's toolS m.i~ht have for different Network
individuals and groups. HecentlY there has been a distinct
increase in interest and expectation in this regard.
8blal
In ~eneral, we enjoy this snow of interest in our prOducts, and in
oarticular we want very much to collaborate with and support some
this experimentation (as in the -goal set cited above).
~bla2

Howpver, it is quite obvious to us that significant value will not be
obtained from extra-NIC experiments with our computer services, or
from interaction with our staff, unless these be done in a
nondissipative way. with individuals or groups
8blb
(a) Whom we can adequately support with computer and personnel
. resources, and
Oblbl

(b) That show promise of following through, by oein~ able to
acquire adequate resources and being able to integrate our
services si~nificantlY into the work that theY will be doing.

8blb2
Furthermore, it is also obvious to us that there will oe considerably
Mor~ payoff (to our and ARPA'S roals) from the ~xternal use of our
finite resources, if these are individuals or groups interested in
bootstrapping -- that is those who
8blc
(C) will pursUe activities tnat either add to the techniques and
capabilities SubsequentlY available to other particioants. or who
will help other peoPle learn about and obtain this kind of
8blel
service.

on another tack, if the concept Of a distributed community making use
of "network utilities" is to materialize, then certainlY there must
eVOlve a bo~y of teChniques and conventions involving
Bold
(a) Service Delivery--where these utilities can deliver
responsive, interactive transactions, over a complex repertoire of
service functions, with both a hi~h degree of reliablity and a
high aegree of aVailability, and
Boldl
(0) Service Marketing--where a customer can negotiate with a
utility for the quantity and type 01 service that suits his needS
~na where there is a ne~otiation environment at
service-transaction time tnat enables the customer to get the
serv1ce When he needs it, out with a resource-utilization
framework that is balanced be~ween efficiency and demand capacity.
8bld2

online Team Environment
190

SRI-ARC 8 JUNE 1972

13041

Plans
Service to Users

Therefore. we Plan to conc~ntrate our efforts within a four-pronged
project wherein coordinated advances can be made in:

8b2

(1) Developing service functions that will be of maximal value in our
above-mentioned goal structure,
8b2a

(2) Developin~ the knowhow ana capability for deliverin~
significantly useful service to the Network, as a utility,

8b~b

(3) Developing the knownow anO capability for marketing a utility
service to the Network,
8b2c

and

wn~rein

we become ever better at

(4) Operating a utility service.

8e3

8h3a.

Dependin, on funding ava11ab11ity ana other arrangements to oe
negotiated we maY find ways to provide additional service capacity
through Placement of the comouter-based portion of our
augmentation system on a computer or computers operated for us a
commercial timesharing utility.
8b3al
8c

BASIC PROJECT WORK

We are planning that under our new base contract, ARC's "utility" would
initially serve two, bUlk-commodity customerS--ARC worKerS and NIC
customers.
8cl
Until we learn how to market an~ deliver service better, we would
rather concentrate heavily upon developin~ our marketing and delivery
capabilities, as contrasted with expending a large amoun~ of ener,y
in trying to meet the beyond-bas1c-NIC services that mi"ht be wanted
by "customers."
8cla
And as we learn how to deliver and market different types and
QUantit1es Of serVice, we feel that there will be a logical
pro~ression of service types and of customer types to be effe~tivelY
and beneficiallY ~romoted and served in our ~row1ng ~utility market."
8clb
~e outline below What seems to be a natural succession of "service
~ystems" that mi~ht be thus marketed, and we WOUld propose
concentrating our service-function development efforts on ~ettinE
prototypes of these service systems shaken down within ARC'S
internal domain in readiness for marketin, tnem when the time is
right.
~clol

online Team Environment
191

SRI-ARC 8 JUNE 1972
Plans
Basic project Work

l30hl

~e will hope to develop a market for our services that leans strongly
toward-B CU$tomers interested in bootstrapping.
oclc

If we make unexpected progress in ~evelop1ng ~e11very and marketing
capability, and if it appears tnat additional ARPA fUnding could
profitably be allocated for "buyin~" more service for some typ~s of
utility customers, We assume that the utility service provided under the
contract would be extended beyond that initiallY negotiated.
8c2
count on putting a
development of
delivery/marketing techniques and principles and that any expansion
of ARC'S service-delivery capacity be supported by means of explicit
additional negotiations with customers (and perhaps with the
customers' sponsors).
8c2a
~asicallY. we expect that the Base Project will
si~nificant and constant effort into continuous

Our Base project work will focus on:
(1)

Developin~

8c,3

Service Functions for:

(a) External Users (via the Network)
NIC reference and dialog support functions (aiscussed further
in -- 7406 J )
Bc3ala

Our planned major points of emphasis are as follows: 8c3alal
continue to work With Network Working Groups,
particularly 1n those areas vital to the NIC such as
graphics. file transfer, distributed data management, and
accounting.
dC3alala

Expand our ability to provide basic reference and dialog
support for the increas1n~ numbers of network users and
~roups who will be eoming on th~ NtT.
8c)alalO
ReOrga.nize our harctlAlare a.nd SOftware sy.stem
smooth expansion as the need arises.

",0

enable
BC3alalc

Get our resource accounting of both people and ~achine
resources in Shape so as to be able to know What each
operation and serVice is costing.
~c3alald
new dialog support functions are developed and tested
on the research side of tne house, move them into
operation in the NIC.
8c3alale

online Team Env1ronment
'192

SRI-AMC 8

l)Ohl
Plans
Basic proJect Work
JUN~

1972

provi~e improved queryin~ capabilities for the online
reference files sucn as the:
8c3alalf

NIC c~talo~
Network Resource Notebook
The Current Network Protocols
Hecords of site status
Documentation of site facilities and services
Networkwide and personal f11es of people interested in
various research topics
possiblY provide a facility to ask questions for online
uPdating of site status or other files that are changing
over a short period of time.
8c3alalg
continue to improve making information aVailaole by
preparing weeklY notices of new additions to th~ NIC
collection.
8c3alalh
prepare specialized bibliographies for sUbjects of wi~e
interest.
8c3alali
The arove services as well as evolvin~ the NIC
cOllection require considerable effort to:
Monitor current literature to select, collect.
abstract, and catalog
Design and pro~ram to produce such listings from
input items

catalo~

prepare and distribute
Devise improved

w~YS

to handle hardcoPY at sites:
8c3alalj

AS the number of users grows and the number of
available services increases, the size of the
cOllections at local sites will increase.
AlloW inrtividuals and groups the capabilities of NIC to
create and manage their own private collections of
information with catalo~s and capabilities for entering
and proofin~ items and queryin~ the catalogs.
8c3alalK
This item requires basic bibliographic tOOlS beyond
those used for prOducing the standard NIC catalog.

Online Team Environment
193

SRI-ARC 8 JUNE 1972
Plans
BaSic project Work

130~1

It places more requirements for training and close
liaison with users.
Since th~se users will have online iteros, POSSiblY
scattered in files on other hosts, it would be
desirable to provide ways for retrieving them tnrough
their catalogs in NIC.
Learning to use all the varied systems on the network is
not going to be possible by sending all pntential users
to each remote site for training or by always bringin~
instructors to the user's site.
Bc)alall
(b) Internal Users (evolving toward external use), such as:
prototype Dialog support System
(discussed further in -- 7407,)

8c3a2
tiC3a2a

our DSS ~evelopment will be coordinated ~ith our other
developments toward serving teams of people inVolved in
developin~ complex computer-based systems.
Hence we will
concentrate upon makin~ a prototype DSS tnat really supoorts
the dp.velopers and users of the systems tnat ARC is
developinr, and ooerating--such as: NLS, NIC, DSS, BRS and,
DPes.
Bc3a2al
Tne ARC Handbook is the prototype "super document" (see
-- 5220,5b) that our collaborative dialog will
concentrate upon for ARC's internal, prototype
develocrnent of DSS.
8c3a2ala
AS features of DSS are seen to be useful to the NIC

system of serVices, theY will be so provided. This will
provide us with earlY experience in tne use Of DSS
featUres among a larger, distributed community. 8c3a2alb
For instance, we expect to use imoroved link and/or
advise features in simUltaneous online conference
dialog and other working cOllaboration when and where
consistent within ARC and NIC goals.
It is assumed th~t there may be special DSS featur~s
for this distributed-cornnlunity serVice; we
expect to do thi8 sort of work with~n tne
"functional-development" part of our actiVity. ~ome
discussion of the "distributed-dialog" features is to
re~uired

Online Team Environment
194

SRI-ARC 8 JUNE lQ72

Basic project

130al
Plans
~orK

be found in a 7 Dec 1969 memo.
(see
5220,5e)

Examples of
consi~ered

fun~tion~

are:

under develoPMent or beinr

8c3a2alc

Sets--the ability to find those items in the dialog
universe relevant to one's interest and view them in
many ways.
BacKlinks--to find out which other items are
referencing each item.
Ability to build sub catalogs of dialogs--related to
sets.
Dialog with files distributed in many hosts throughout
the network--There are many problems that would have
to be sOlved such as assuring that files did not get
deleted and keeping track of where things are in our
catalo~, to help reduce the load on NlC.
Action items--ways to enter a dialog item reQuiring
action by a certain date and having the system remind
the sender to follow up or check to see Whether the
receiver responded.
New Journal entry techniques--making the process much
easier for users, inclUding pre-specification in NLS
files of entry details.
prototype DOCUmentation PrOduction and Control system (DPOS)
(discussed further in -- 7408, )
oc3a2b
We plan to further develop within ARC Q separate Place,
terminal configuration and staff -- for a DPCS system
expressly to support prOduction and control of
information-systems' documentation -- wnere the support work
for developing and controlling ARC'S documentation will all
be done.
8c3a~bl

If we need more throu~hPut to shake down the system,
and/or if through NIC's activity or through special
arran~ements with Network groups there is reasonable
sense to dO so, we would consider our supportin~ of
other-group (NetworK) documentation and control. ThiS

online Team Environment
195

SRI.-ARC 8 JUNE 1972

13041

Plan8
BaSic project Work

activity would serve as a test bed for the successive
stages of DPC system developments we want to go through.
Bc,;a2bla
In support of this aoproach. we would like to ~rovide
ourselves locally with a hardcopy printout system capaole of
makin~ good-Quality mixed-text/graphic drafts.
8c)a2b2

We may coordinate this system with parallel use of a high
Quality COM system for final production of documents and
micrOfiche. We expect to use a commercial service bureau
for this initiallY. but want to have our local facility'
be capable of producing completelY accurate
representations of the final output.
8c3a2b2a
The earliest form of a DPCS would have the authors wor~1n~
offline to a large extent, using Deferred Execution (DEX)
processes.
dc3a2b3
The features crovided by DEX will allow clerical peoPle
to fOllOW complex mark-up notations made bY authors as
drafts are developed.
bc3a2bJa
Spooled-input typewriters,
equipment would be used.

usin~

ma~netic

tape recording
Bc3a2b30

Subsequent evolution of a DPeS would be towardS prov1din~
fe~tures such as: automatic concordance-type indexing,
cro~s-reference control, glossary control and production,
and towardS extendea representations, new forms of portrayal
for use in documenting complex systems, an extended facility
for composing and modifying the exotic representatj.ons, and
hi~h-qualitY font/formatting.
8c3a2b4
prototype SOftware-Engineering Augmentation Syste~
(discussp.d further in (7h09,) and -- 7411, )

New or changed features
Source level

oein~

considered are:

Bc3a2c
8c.32,2cl

incremental compilation
tjc3a.2cla
A orimitive system is being implemented now with a
more advanced version to come following MPL
imnlementation.
debuggin~

a~d

Documentation aids

8c,;a2clb

Online Team Environment
. 196

SRI-ARC 8 JUNE 1972

1)Oh1

Plans
Basic project Work

Documentation for different levels -- user guide
level, system architecture level, etc.
Automatic documentation -- reformatter programs to
make embedded aocumentation more clear and in su~mary
form.
Co~ing

8c3a2clc

aids

possiblY produce parsers automaticallY from use-level
of commands -- that would require fairlY
strict rul~s for documentation.

doeu~entation

Use of back-linking for cross-reference and annotative
docu~entation.
8c3a2cld
Develop cross-reference facility for modules (and
possiblY inter-modular if bacK-links are not
SUfficient).
Use set facilities for viewing and
different levels.

worKin~

on code at
dc3a2cle

For example. a user mi~ht construct a set that
contains all procedures that are pertinent to a
particular DNLS command, or a set of all procedures
that do command ears1ng for DEX and so forth.
Further develop our compiler system

8c~a2clf

Allow ~asy generation of interpreters as well as
compilers.
MOdularize compilers.
possibly generalize trees to netwoKS IN TREE META.
Develop program verification capabilities

Bc3a2clg

Development of heuristic pro~rams to determine that
do wh~t the writer has indicated they do.
Allow statement of programmer asumptions at various
pOints in a progra~. The verification faciliti~s might
test those assumptions ana specifY if they can be
false.
pro~rams

online

~eam

Environment

197

SRI-ARC

& JUNE

1972

Plans
Basic project Work

1)041

Develop trace facility in the Baseline program
To help immprov~ estimating and
activity.
Develop

catalo~s

~nd

Index procedures

~ive

a history of our

inaices for system files
by

8c3a2clh

Bc3a2cli

function.

once a remote site has established a DNLS station that can
work with our system througn the Network, it WOUld be
directlY feas~~le for sOftware en~ineers, workin~ on oth~r
computers with other languages than ours, to use our DNLS
syste~ to considerable advantage as a workShop ~n which to
co~pose. mOdify. and studY their (integrated) source code
and documentation. an~ to participate in computer-aided.
collaborative dialog over this material.
8c3a2c2
With straigntforwar~ utilization of our compiler-compiler
techniques operacle through DNLS. they can easilY build
special-purpose lan~uages that match to other computers,
to other purposes, at binary or assemblY-language levels.
8c3a2c2a
We hope to encoura~~ some experimentation in this
direction, and intena to round out the prototypical set
of conventicns. aids, principles, etc. within our
application areas that will make suen aPPlication
relatively direct. The extent of such eXper1mentation
will of course be limited to what we can mana~e to
support, ooth with computer service and with peoole
interaction.
8c3a2c2b

More Advancea Use of the Software Tools at ARC

Bc3a2c3

We have described above how the software engineer at
another location might use ~LS for writin~ nis proRrams.
8c3a2c3a
It will also be po~sible for the remote prorrammer to use
other software augmentation tools Q~velop~d ner~.
8c3a2c30
For instance, t~e TREE META compil~r writ1ng sys~em
coUld be ~odif1ed to prOduce code for another 'macnine
(thiS wa~ in fact done as part of tne ~ransfer of NLS
fro~ the XDS-9hO to the PDP-10). It could tnen be used
to develop experimental compilers that WOUld run on a
PDP-10 (or throu~h further modifications an~

unline Team Environment
198

SRI-ARC 8 JUNE 1972

lJO~l

Plans
Basic project Work

bootstrapping, on another machine) and produce files
that coUld be sent over the Net for loading.
The feasibility of such an undertakin~ will oegreatly
increased with the development of the Modular Pro~ramming
SYstem described in (7411,).
8c3a2c)c
The compiler-compiler will be co~posed of mOdules, so
that the code production can be more easily replaced
without requirinp, a detailed undprstanding of large
sections of a comPlex orogram a
when it is operational, the MOdular Programm~ng System
itself will be a very powerfUl tool and of interest to
other orogrammers.
8c3a2c3d
In addition, it will open up new ways for the remote
programmer to access and use the other tools at ARC.
oc3a2c3e
It will become poss10le for the programmer to create G
personal version Of NLS bY the replacement ana
addition\o1 modUles so as to better match hiS needs.
prototype System-DeVeloper's HandbOOk System
We will design the next stage HandbOOK, including the

specification of content categories to~ether with techniques
and procedures f~r maintenance of the Handoook.
8c3a2dl

we plan to implement this design
periOd.

durin~

the next contract
6c3a2dla

Indices and Tables of Contents for tne HandbOOK are
planned to be designed and 1mplementeO.
8c;a2dlb
~e expect to complete the collection of the basic exist1n~
Handbook-relevant documents that already eXlst, both in
hardCoPY and online files. we will also add new
HandbOOK-relevant docu~ents as they are produced, retiring
Obsoleted documents as appropriate.
8c3a2d2

We exnect the HandbOOk system to aid in stimUlating the
prOdUction of documents that are needed, but ~issing from
our information base.
dC3a2d2a

online Team Environment
199

SRI-ARC 0 JUNE 1972
Plans
Basic project work

13041

prototype 8~seline Recor~ System
(discussea further in -- 7~lO.)
We plan to improve the data collection procedures and

storage mechanisms of the present Baseline

System.
BcJa2el
our present Baseline aata storage techniques will
probablY be changed to use a more generalized systeM
common to the Baseline system, Catalo~ system, and other
ARC data handling systems.
dc)a2ela
Recor~

ARC users will be more effectively oriented toward the need
·for and trained in a more organized task definition and
selection process.
8c3a2e2

Better views of the Baseline Record will be prOduced for use
by ARC, with more useful user-created view capabilities
provided.
8c3a2e3
HardCoPY and online Baseline Records will be more complete
and made a part of the daily workin~ life of ARC
researchers.
8c3a2eh
We plan to develop better methods for keeping
u~-to-date, both online and in nardCOPY.·

the Record
8c3a2eS

The ARC resource accounting system, as it develops, will be
integrated with and used by the Haseline Record sYstem.
8c3a2e6
(2) Developing Service-Delivery Principles and practlces for:
8c]o
(a) Computer serVices, including considerations sUch as:

DNLS
Remote Hardcopy Delivery
Keliabilitv
~esource allocation, accounting, bil11n~
The questions of scale, efficiency, reliability
service-capacity expansion plan
~emote

(b)

8c3bl

oc3bla
~C3blb

Bc301c
'8c]bld
oc301e
bC]blf

NrC-service (information, people help)

8c3b2
8c3b3

(~s

operational prototype of DPCS,
Bc3b4

online Team Environment
200

SRI-ARC 8 JUNE 1972

13041
Plans
Basic project Work

(3) Developin,

Service-~arketing

principles and practices:

8c3c

(a) Learning how to ne~otiate with prospective customers for
delivering various kinds of service to theM. including questions
sUCh as:
8c3el

what basis are the

a~reement~

maOe?

bc3cla

HoW is financing accomplished?
HOW

is the account1nR performed?

are the scheduling and billing of service delivery
accomplished?

HOW

are conflicts resolved (marKet conventions. arbitration)?
8c3cle
wnat ,uarantees can practically be made regarding,
accessibility, reliability, dOcumentation accuracy and
completeness. and the like?
dclclf
HOW

HoW are user training and helping provided?

(h) Providing operational Marketing and Delivering of Services:

Bc3clg
8c3d

Developing the framework, as the marketin~ and delivery systems
begin to take shape, in whiCh the current service resources are
marketed within the ARC and NIC customer market.
bc3dl
studying the POSSibilities of evolving the various "prototype"
services into marketable items, negotiatin~ the resources for
this, extending our service marKet-wall in an orderly orocess
involving ~ number of ~ultiparty agreements.
dc3d2
8d

REF~RE~CES

(5220.) Douglas c. En~elbart (SRI-ARC). ARPA Memo #2. Au~mentat1on
Research center, stanford Research Institute, Menlo park, California
9~025. 7 December 1969. 15p.
6dl

(7404.) Proposal for Research {to HADC/ARPA ISU 71-94J. Network
Information CeMter and AUgmentation system Develop~ent. SRI NO. ISU
7l-9~. AugMentation Research center, Stanford Research Inst1tute. Menlo
Park, california 94025. 29 JUly 1971. Separately pa~ed. (EntereJ in
SRI-ARC Journal lR Octob~r 1971.)
Bd2

online Team Environment
201

SRI-ARC b JUNE 1972
Plans
References

13041

(7h06,) Appendix B: NIC Development - Function and operational Delivery.
In: Proposal for Research [to RADD/ARPA ISU 71-941. Network Information
Center and Augmentation System Development, (7hOk,). SRI No. ISU 71-94.
Augmentation Research Center, Stanfor~ Research Institute, Menlo Park,
California 94025. 29 July 1971. IIp. (Entered in SRI-ARC Journal 15
October 1971.)
~d3
(7407.) AppenOix C: Dialog support System. In: proposal for Research [to
RADC/ARPA ISU 71-94}. Network Information Center and Augmentation system
Develooment, (7404,). SRI NO. ISU 71-94. Augmentation Research Center,
Stanford Research Institute, Menlo Park, California 94025. 29 July 1971.
7p. (Entered in SRI-ARC Journal 15 October 1971.)
8d4
(7k08,) Appendix D: Documentation production and Control System. In:
PrOPosal for ResearCh {to HADe/ARPA ISU 71-94J. Network Information
Center and Augmentation Syst~m Development, (7i04,). SRI ~o. ISU 71-94.
Augmentation Research Center, Stanford Research Institute, Menlo Park,
California 94025. 29 July 1971. 3p. (Entered in SRI-ARC Journal October
1971. but not presentlY online.)
8dS
(7409,) Appendix E: software-Engineering Augmentation System. In:
PrOPOsal for ResearCh {to RADC/ARPA ISU 71-94}. Network Information
Center and Aug~entation system Dev~lopment, (7404,). SRI No. ISU 71-94 •
. Augmentation ResearCh Center, Stanford Research Institute, Menlo Park,
California 94025. 29 July 1971. ap. (Entered in SRI-ARC Journal 18
October 1971.)
8d6
(7410,) APpendix F: Descriptive Notes About PBMS, a project Baseline
Management System. In: Prooolal for Research [to RADC/ARPA ISU 71-94}.
Network Information Center and Aug~entat1on System Development, (?40h,).
SRI No. ISU 71-9h. Au~mentation Research Center, Stanford ResearCh
Institute. Menlo park. California 94025. 29 July 1971. 3~. (Entered in
SRI-ARC Journal 18 October 1971.)
8d?

(7411.) Appendix G: Collaborative SYstem-Evolution system. In: proposal
for Research ito RADC/ARPA ISU 71-94}. Network Informat~on Center and
Augmentation system Deve1ooroent, (7404,). SRI No. ISU 71-9~.
Augmentation ResearCh Center, Stanford Resea~ch Institute, Menlo Park.
California 94025. 29 July 1971. 5p.
add

online Team Environment
202

SRI-ARC 8 JUNE 1972 130hl
Glossary

GtOSSAR~

APR

Acronym for the Arithmetic processor Of the PDP-10.

ARC

Acronym for

Augm~ntation

Research Center.

ARPA -- See DARPA

Arithmetic Processor -- Xhe central processing unit of the PDP-10.

Augmentation -- In this report, extension, imorovelnent, or amplification
of human intellectual an~ organizational capabilities bY means of
close interaction with com~uter aids and by use of special procedural
and organization techniques desi~ned to support and exploit this
interaction.
ge
BB&N -- Bolt Beranek and Newman. A commercial research and development
organiZation under contract to ARPA for services to the ARPA Network,
and under other contracts that lead to frequent interaction with ARC.
9£
9g
BRS -- Acrony~ for Baseline Record System
Baseline Record System -- part of a developin~ management system used at
the center. It records tasks and peOPle aSSigned to tasks, and allows
retrieVal of information about taSkS bY people or peOPle by taSks. 9h
Bootstrapping -- A name for the research strategy of the ARC. BY
"bootstrapping" we mean taking advantage Of the feedback in recursive
development of systems. That is, we try to test ways ofaugmentin~
intelli~ence bY their usefUlness in developing new systems to augment
intelligence, through the use of the new system features by (mainly)
the develooers of the system.
9i
Branch -- In t~e NtS hierarchy of statements, a statement snd all
sUbstatements that depend on it.

aug -- The cursor visible on an NtS Display Which is controlle~ by the
hand-held mOUse and which may serVe as an address in NLS commands. 9k
Center -- The same as ARC.

COMPiler -- A computer lan~ua~e that is used to translate from one set
of symbols to another, particularly to maChine lan~uage.
9m
Consol~

used here, specifically a user's control conSOle for tne

Online Team Environment
203

SRI-ARC 8 JUNE 1972
GlossarY

13041

ARC's Online SYstem (NLS). The consoles presentlY 1n use at AHC
consist of a display scr~en. a KeYboard, a "mouse", and a "keyset". 9n
current Statement -- In NLS. normally the last statement moaified.
executed, or reproduced bY the user and, hence, the statement tnat
starts the sequenc~ Of the sequence generator Which generates the
disPlay ima~e. Usually the statement at the top of the screen is the
current statement, but content analysis or screen SPlittinl may
diSPlace or Obscure it.
90
current statement POinter -- The internal symbol fixed on the current
statement by NLS.
9p
DARPA' .- Acronym for the Defense Advanced Research projects Agency of
the nepartment of Defense.
9q

DDT -- Acronym for Dynamic Debug~ing Tool, a program useful for
establishing at wha~ point in another program a prOblem occured.,

DEC .- Acronym for Di~ital Equipment Corporation, tne manufacturer of
tne center's PUP-10 computer an~ PP02 disc memory.
95
DSS -- Acronym for Dialog support

syste~

Dialog support SYstem (DSS) -- The system of files, programs. and
procedures at ARC for storing, sorting, and recover~ng the interchange
of thOUghts, plans, memos. technical documents, etc. that accomoany
our system development.
9U
Displav Start

State~ent

-. The same as "current statement"

Executable Text -- In NLS, as it operated on the XDS-940, a program or
suoroutine t~at was written by users in characters as all or part of a
statement and that can be carried out by a simple command from the
us~r.
9w
FRAMAC -. From Framework Activity. An or~anized activity aMong members
of the center WhO are involvea in planning to define long and short
term goalS.
9x
Field ooerations .- In pro«rammin~ NLS, manipulations that involve the
capacity of the PDP-lO's s6ftw&re to handle part8 of words.
9Y
File -. 10 NLS, thiS refers to a unified collection of information held
in computer storage for use with the Online System. A file ~ay
contain text (English or program code), numerical information.

Online

Tea~

Environment

204

SRI-ARC 8 JUNE 1972 130hl
Glossary

~raPhics,

or any combination of these. conceptuallY, a file
rou~hly to a nard-co~y document.

corr~sponas

Frozen stateme~ts -- In using NL~, statements shown stationary on tne
disPlay while other part! of the file are in view and viewed, composed
or Modified.
9a@
HLP -- Acronym for

Hi~h~r

9aa

Level Processes

HandboOK .- A complete reference work of all systems and activity at the
Center at a 2iven time.
9ab

Higher Level Processes -- A Phrase once used for what we now call User
Programs.
9ac
IMLAC .- The manUfacturer of a disolaY console used experimentally with
NLS.
9ad
IMP -- Acronym for Interface Me5sa~e Processors. Hardware devices that
code and decode messages for transmission between tne comDuters on tne
ARPA Net~ork.
9ae
Ident .- a two-to-six-letter code. 2iven to people or grnups for
reco~n1tion by the Journal Ident system.

9af

Intellect -- The hum~n competence to make, sort. exchange, ana applY
knowledge to decision making.
9ag
Journal -- The open en~ed information storage and retrieval
forms the core of the Dialog Sup~ort syste~.

sys~em

that
9an

-. lit.: "jump to system" The machine instruction used in Tenex to
invoke a monitor supplied service; i.e. a jump to a subroutinp.
9ai

JS~S

Keyset -- A device with five keys like piano keys for entering
cnar~cters into NLS at a display console. Each key controls a bit in
5-bit ASCII code.
9aj
L-10 -. The alrol-like

lan~u~ge

in which our online

sys~em

is written.
9ak

Level-clipping -- With reference to NLS Viewspecs. the practice of
controlling how deeply into the outline structure of a file you see in
any ~iven vi~w.
9al
LINAC .- From line Activity. The line management structure Of

Online TeaM Environment
205

th~

SRI-ARCS JUNE 1972
GlossarY

13041

Cent~r, a matrix Of projects and functional organization, as
differentiated from PODAC and FRAMAC.

9am

LINKS -- In NLS, a routine to search the dlsc for any statement and set
viewspecs. links maY be part of file text and may be used as an
address 1n TNLS commands without regard to what file tne user has
loaded. Links have tne form (ddd,fff,n:x) where the field dad comta1ns
a TENEX directory name; the field fff contains a TENEX file name; tne
filed n contains an~ NLS statement name or nu~ber and the filed x
cont~ins NLS viewspecs.
Fields are frequently left to default 1n
practice.
9an
-. In ~lle NLS hierarchY, the list of a given statement is tne set
of statements that are in the plex of the source of ~h~ ~iven
stat~ment and are on the same level witn it.
9~o

L1s~

for Modular programming System .- A reorganization of NLS
eoce into modules that may be exoorted separately and whiCh pass
control only through defined ports.
9ap

MPS -- Acrony~

MarKers -- A symoo11c name that the user may attach to a particular
character in a file. It is not displayed or printed, but is visible to
routines that search for it.
9aq
Monitor -- A prograM wnich remains in me~ory at all times and controls
the coming and ,oin~ of data and other programs in tne maChine.
9ar
Mouse .- A round-topped, handsized device normally operated bY the
user's right hand when usin~ the Online System from a ~isPlay console.
The mouse rolls freely on any flat surface, eausing a cursor spot on
tne display screen to move correspondingly.
9as
NGG -- Acronym for Network Grapnics Group

9at

NIC -- Acronym for Network Information Center, one of ARC's key roles in
t.he ARPA Computer Network. The NIC is a computer-assisted reference
and communication service for information pertaining to the Network.
9au
NLS
Acronym for the ARC Online system.
9av

NwG

Acronym for Network Working Group

9aw

Network WorKin, Group -- A group of users of the ARPA Network organized
to d~velop Network functions.
9ax
Online System -- Tris is ARC's prinCipal and central computer-based

Online Team Environment
206

SkI~ARC

8 JUNE 1972 13041
Glossary

in the area of computer aids to the human intellect. As
prespntlY constituted. it is a time-Shared multi-console system lor
the composition, studY, and modification of files (see definition of
"fil~").
Ma~y details of the system are described in the bOdY of this
report.
9ay
develop~ent

Output Processor -- The SUbsystem of the portrayal generator that
processes NLS files into sequential files suitea to drive de',iees tnat
produce hard copy.
9az
PDP-10 -- The computer used at the Center from the winter of 1970 until
the ~resent. The asynchronous arithmetic Processor has a l-microsecond
Cycl~ and us~s 36-bit words paged in a bB&N pag1ng oox 1n~o ~12-word
pa~e~.

POD -- With~n PaPAO. a group of about 8 employees of the Center that
meets weeKly for purposes of personal and or~anizational development.
9ba

PODAC .- Acronym for the continuinr, organized ~ersonal ~n~
OrF.anizational Development Activities within the Center.

90b

Plex -. In the NLS hierarChY, the
comm~n source.

9bc

s~t

of all statements that have a

Pointer -- An Old name for marker.

9bd

Portrayal uenerator -- The class of NLS code that
formatted for view bY a human.

crea~e5

sometning
9be

Protocol -- Amon~ users of the AKP~ computer Network, a document
deScribing conventions for carrying out some activity over the

9bf

Netw~rk.

RADL -- Acronyr for
RFC

Acrcny~

~ome

Air Development Center.

for Request for Comments

9bg
9bh

Requpst for Comments --a series of memoranda between Network Li~ison
personell nU~bered and distributed at the Network Information Center.
They are no longer restricted to requests for co~ments.
9bi
SRI -- Acronym for

Stanfor~

Pesearch Institute

STID -. ACronyr for statement 1uentifier. A nu~ber unique to each
statement itl a file and that remains with the data regardless of
dOCument structure change.

online Team Environment
207

9bJ

9bk

SRI-APe 8 JUNE 1972
GlossarY

13041

Sequence Generator -. A routine that, when given the number that
iaentifies a statement internally (the STID), will searc~ through the
file and find all the sUbsequent statements tnat observe the current
view~oecs.

9bl

Server Telnet -- see Te1net

90m

Sublist -- In the .NLS hierarchY, the first sublist of a statement is the
set of statements immediatelY below it, the secona SUbli8t is all
statements one level belnw them. T tile nth sub1ist of statement "s"
is the set of statements that ar~ in the first SUblist of the
statements in the (n-l)th sublist of "sUe
9bn
Statement -- The basic structural unit of a file. A statement consists
Of an arbitrary strin~ of text, plus graphic information. A file
consists of ~ number of statements arranged in an explicit
hier~rchical structure.
9bo
SuoerWatch -- A grouo of programs that measures the loads on
P1eCeS of hardware and on subsystems of TENEX and NLS.

differe~t

9bp

TENEX -- The timesharing system that supports NLS on the PDP-10. NLS
runs as a subsystem of TENEX and draws extensivelY on TENEX's file
handlin~.

9bq

TNLS -. Acrony~ for Tyoewriter online system. The system used at AkC for
typewr1ter type terminals from early 1971 on. It differs from TODAS
internally in usin~ core NLS with aaaptive routines that are called
automaticallY When the user names his terminal in logg1n~ in, ana
externally in a number of additional, powerful editing commands.
9br
TODAS -- Acronym for Typewriter Oriented DOCUmentation Aid System. The
versj.on of NLS used from typewriter-like terminals prior to 1971. 90S
Telnet -- In the ARPA Network. the software that allows a user at one
Site access to a time-sharing system at another site. User Telnet is
the software at the user's si~e; Server Telnet is the software at the
remote site.
9Dt
Textpointer -- In NLS. as used on the PDP-10, the

fix~t10n by NLS on a
Space between two characters which allows the users to be sure eoiting
will begin with the fOllowing character.
9bu

Tree Meta -- Tre ARC compiler-compiler system. used to compile all the
langua~es at ARC.
90V

Online Team Environment
208

SRI-AWC 8 JUNE 1972 13041
Glossary

User Programs

proc~sses in wnieh the basic user features of our
(particularly NLS and TNLS) are used as oU1ldin~-b1ocks
in the construction of programs for carrying out specific. perhaps
rath~r complicated tasKs.
90W

onli~e

User

syste~s

T~lnet

-- See Telnet

9bx

ViewspeCs -- A feature of NLS whereby a user may mask part of his files.
such as the hierarchical numberin~. or statements below a certain
outline 1evpl. in order to better view the unmasked portion.
9by
XDS -- Xerox Data Syst~ms, manufacturer of the XDS-940 Computer. used at
the center until January of 1971.
9bz

online Team Environment
209

SRI-ARC 6 JUNE 1972

Appendices
HandbooK conter:ts

13041

online Team Environment
210

SRI-ARC 8 JUNE 1972

13041

Aooenaices
HandbooK Contents

APP}i: NDI CES

APP1NDIX I

CO~TiNTS

OF ARC

HA~DBOOK

Section 1.

USr:R l)OClH1ENTS

lla

Volume I
NLS

CATNUM

GENERAL

~LS

CUWR~UT STATUS
NE~ NLS PISES FROM

THE PIT

9213

current Folklore Branch of NLS status
witn new System Changes

858~

An Oktober Fest Including Goto Program
La.te July NLS

745~

7/ 9

7391

1~LS

~id-June

Changes in NLS

7329

FILii'S

proposal for New File Commann
Loaa Locked File Command

7d29

ADDpESSING
Link Delimiter Change

6214

tDITING
VIEWS

viewspecs, a Brief Table

738'7

viewspecs

7389

t.RROR

t--q~SSAGES
Concernin~

Note

Section 1.

NLS Error

Me~sages

7290

USEH DOCUMENTS
llb

Volume II

TNLS SPECIFIC

~ATNUM

GENERAL

online Team Environment
211

SRI-ARC ~ JUNE 1972
Appendices

13041

conte~ts

Handbock

~IC

TNLS User Guide

7470

FILf,S
ADDpESSES
TEXT: CREATING AND VIEWING
TEXT EDITING
MISCELLANEOUS

Section 1.

USER DOCUMENTS

Volume III

DNLS SPECIFIC

llc
CATNUt-ol

Multiple Display Areas in DNLS

7290

User Features of NLS and TODAS
(no CATNUM)
Introductory Notes
Keyset and V1ewspecs
NLS Commands
NtS Vector package
viewchan,e System
Links and Returns
NLS Cont~nt Analyzer
Keyword InforMation-Retrieval system
Miscellaneous Useful Information
Definitions
calculator package

Sectio,", 1.

USER DOCUlv!ENTS
11d

Volume IV

'rENEX

CAI'NuH

kesnonse to Login Message

9310

Chan~e

Another ProPosal for Handling Old Versions of NLS Files

8930

Further Co~~ents About Only
Files Around

8922

EXFr,

1.32.0~

Keepin~

one Version of NLS

features

9222

EXEC LOGIN command to start NLa automatically:
auto-lo~out

of inactive jObs

8953

8693

Online Team Environment
212

SRI-AkC 8 JUNE 1972

13041

Appendices
HandbooK Contents

EXECUTIVE MANUAL - PDP-10
(no CA'INUH)
Introduction
Bxecutive Langua~e Structure
systeM Access
TENEX File System
nevice Handling
SUbs~ster. Control
pro~ram Control and Debuggin~
Queries
Terminal Characteristics Commands
Index
~NDMSij - A new SUbsystem

6970

TLINK - A new SUbsystem

6976

Know Your Disc Space

7337

Lin~/Advise

~efuse

Default

7705

Insert from Teco File or Whatever Specs

7376

Proposal for a Simple ArChive system and
Directory Size Limitation

8062

Online_Team_Environment_Jun72 Online Team Environment Jun72

Online_Team_Environment_Jun72 Online_Team_Environment_Jun72

Navigation menu

Versions of this User Manual:

Views

Navigation