178
NATIONAL SOFTWARE WORKS TOOL INTEGRATION STUDIES
General Systems Group, Inc.
Contractor: General Systems Group, Inc.Contract Number: F30602-79-C-0106Effective Date of Contract: 12 December 1978Contract Expiration Date: 15 May 1981Short Title of Work: National Software Works Tool
Integration StudiesProgram Code Number: 9P10Period of Work Covered: Dec 78 - Apr 81
Principal Investigator: Normand RasmussenPhone: 603 893-1000
Project Engineer: Patricia BaskingerPhone: 315 330-7007
Approved for public release; distribution unlimited.
This research was supported by the Defense AdvancedResearch Projects Agency of the Department of Defenseand was monitored by Patricia Baskinger (RADC/ISCP),Griffiss AFB NY 13441 under Contract F30602-79-C-0106.
TABLE OF CONTENTS Paoe
1.0 Preface 7• . . 7
2.0 Introduction 0 * a * 0 9
2.1 History . . . . . . . * 122.2 Policy . . . . a . . . e e . . . . . . . 15
3.0 NSW Project Organization * * & e a * * * * & * 17
3.1 Organizational Structure . e * . . . 183.2 NSW Contractors.. . . . . . . . . .20
4.0 NSW System Architecture . e o e . e 9 . o o * * o 22
4.1 The ARPANET . o . . o . q . * .o .o o 234.2 NSW - A Network Operating System . . . • 284.3 Host Families . . . . . . . . . . . . . . 294.4 NSW Software Architecture . . . . . . . . 30
4.4.1 KSW Software Components . . . . 344o4.2 DMC Responsibilities o 9 . • . 364.4.3 Participation of Hosts
in NSW Systems * - . . . . o384.4.4 Levels of Host Fasily
Participation. . . . . . . . .404o4.5 The NSW User System
Configuration o . . . . . . . .42
5.0 NSW System Development . . . • . . . . . . . . 45
5,1 NSW System Configurations . . * . . . . . 485.2 NSW Testing Hierarchy . . e. . 9 . . . * 595.3 NSW System Release and Assessment . * . . 515.4 QualitV Assurance Testing . o . . . a . . 57!,5 STR Processing o . . , . . , . • , . • . b5.b Configuration Management . a . , . . . 655,7 NSW Release History . . . . a . . . . . 76
6.0 NSW User Interface • • . a • . . . . . • . • • • 74
6.1 Overview a o . • • . • o • . . . • . • .75
b1.1 Prolect Management * e . . . 766.1.2 NSW File System . . . . . . . . 856.1.3 NSW Tools e 9 e e 9 * * 9 * * a 98601.4 NSW Command Language . , * . e 95
Ij, I M" I ll Wl•r
I..
7 1!: V 7 t "*nP M : ... .1
6.2 NSW User System Status (May 1981) . . . . 96
6.2.1 NSW Command banguage Status * . 976.2.2 WSW File System . . . . go .9
6.2.3 WSW Tools . . . . . * 0 0 1026.2.4 User Docymentatlon . 113b.2.5 Future Directions
and Problee Areas . ... 16,2.6 NSW Availabil~ity . . . . . . .117
7.0 NSW System Operations . 0 . . . . *Its.. .1
7.1 Overview oi NSWOPS Responsibilities o 1197.2 Status Of N4SW Operations o . . o . 120
8.8 AF1LC Technology Demonstration . . . . 9 e o a 9 125
9.0 Notes and References . .* 9 .& .e * * 9 * * .126
Appendix A: GSG Bibliography . . . . . . . 9 . . .130Appendix 8: Generic Confiquration Items o * 9 a e & .133Appendix C: An Overview of the NSW Help Facility ,*.153Appendix D: Sample "Weetly Usage Report" 9 e 9 161
2
List of Figures Page
3-1 N45W Organizational Structure. . . . . . . . 21
4-1 ARPANET Geographic Kap ... * .......... 26I
4-2 ARPANET Logical Map . o . . 27
4-3 Component Covmunication Via MSG . 32
4-4 15ws Star-Shaped Control Structure o 33
4-5 The NSw User System Configuration a a e . . * . . e 44
5-1 Stages of NS* SystemI Development o a * a 47
5-2 NSO System Configurations * a 9 e 49
5-3 148w System Development Life Cycle o * * * * 9 56
5-4 STR Resolution: Organizational Interactions. 9 & * . o 64
6-1 Project Node A and Tool/File Rights o a 0 0 0 a * o e .79
6-2 Node A Creates modes or C and D * o * e o 0 a 9 0 0 0 669
6-3 Node 0 Creates Nodes DA. DE ani DC 9 o . o * 81
6-4 Node A Deletes Node B o * o o * 9 o e 9 e 9 * 9 9 9 * .82
6-5 Node A Revokes Node Creation R1ght troi Node D * * . a 83
6-6 Node A Assigns File Riont B&A to Node DO * o o o * 9 * 84
6-7 Movement and Translation of xSo File During EXPORT * * 87
6-0 Assigning a oorKspace to An XED Tool Instance 9 o e 9S
6-9 File Movement and Translation Resultina from iCED Read .91
6-10 Creation of New Fie in worKSOaC* 92
6-11 Modification of HSW File In the aortsoace o 9 o 93
3
6-12 Delivery ot XED OUtput Files into Naw rilespace *. 94
4
IT
List of Tables page
6-1 Hlost Family file Types 0 . . a . 9 0 0 0 0 ioo
6-2 NSW Tools by Host Family 0 104
6-3 Tool Statistics by NSW Host and Tool Type e . e o 1@5
6-4 Alphabetic L6isting of NSW Tools by Host e o a * o * 106
6-5 NSW Tools by Generic Tool Type and Hoot a o * o o * 109
1.6 Preface
The General Systems Group (GSG) has been Involved In theNational Software works (NSW) Prolect since 1976. During theperiod 1976 - 1981, GSG has been awarded four (4) NSW contracts.GSG's participation in the NSW project and responsibilities,vis-a-vis assessment and operation of the NSW system, have grownappreciably during each successive contract period.
GSG has, in the past, advocated and successfullydemonstrated the viability of an independent testing andoperations organizations for the NSW system. based on thesesuccesses, GSG was asked to recommend a Plan for managing the
development, operation and maintenance of the mSw software system(1]. GSG's recommendation became an Integral Part of the ONSWManagement Plan* (2], prepared and distributed by the sponsororganizations (RADC and ARPA). Implementation of this plan hasbeen a major goal during the present contract Period covered bythis report, This report concentrates heavily on the role GSGhas played in imolementing and evolving the system developmentapproach called out by the ONSW Management Plann. GSG iscontractually resoonsible for fulfilling the following two (2)roles:
- Product Development Contractor (PDC)
- NSw System Operations (NSWOPS)
These organizations, staffed by GSG Personnel, are respectivelyresponsible for two of the four stages of the NSW system'lelopment process (see section 5.0)p namely:
- Productization and Quality Assurance (PDC), and
- Production operation of the NSW system (NSWOPS).
This report attempts to meet a number of goalssimultaneously. Discussing GSG's NSW activities and documentinoour project contributions during the contract period are onegoal. However, this report Is also Intended to serve thefollowing purposes as well:
- Review the NSW project organizational structure#including roles, responsibilities and contractorassignments
Describe the NSW system development process
II I - "
Survey NSW's system architecture and user functionality
E stablish the current operational status ot NSW;Indicate the major chronology of events.
-Serve as an introductory NSW tutorial for new users.
44' I
2.0 Introduction
The National Software works (NSW) is a pioneering R & Dproject, lointly sponsored by the Defense Advanced ResearchProjects Agency (DARPA) and the Air Force. The NSW system is anetwork operating system which attempts to achieve Integratedresource sharing in a heterogeneous computer networkingenvironment.
A computer network Is a collection of autonomous computers.called "hosts* , interconnected by a common communicationssubsystem. Hosts may be geographically dispersed (i.e.. tens.hundreds or even thousands ot miles apart), and of widelydifferent make and/or manufacture. Computers ot different Imanufacture are usually software incompatible. That is. programswhich run on one computer will not be readily portable to anotherfor execution. Also, the syntax and interpretation of storeddata (programs and the data on which they operate) varyconsiderably. Such Incompatibilities manifest themselves asdifferences In:
- Hardware architecture and/or
M Operatinq system, includinq
Program execution environment
File system, and
Command language
The communications subsystem ot a network provides a mediumfor the exchange of information between host computers. Thecommunications subsystem serves as the foundation on which moresophisticated conversations (often called Oprotocols*), betweenhost computer entities (i.e.. executing Programs) may beimplemented. Protocols have been developed to provide a widevariety of network services and functions, including:
* User access to other network hosts (and their
resources)
- Movement of files from one host computer to another
- NetworK electronic mail
NSW is a protocol-oriented systev, augmenting and extendinq thefunctions provided by existing network protocols*
r 9
r9
Single host computers are often viewed abstractly as acollection of computing resources which may be parceled out toComputing OtasKs*. In the course of a ItasK'sO lifetime, manydifferent computing system resources may be required to completea given computational "tasKO: the following are representativeexamples:
Storage and retrieval of files- Program execution (of proqrams stored as files)
a Use of special peripherals (e.g.. printers, tapedrives, emulators, etc.)
Single host operating systems provide a uniform Interface foraccessing, and controls for mediating access to, computer system *resources. If more than one host entity (e.g., program or user)can access and/or use a given resource (e.g.. tile, printer*etc.),that resource is said to be "shared". Many advantagesaccrue from resource sharinq. includinq:
- Greater utilization through multiplexing (e.g.,printers)
Reuse without duplication (e.g.. one copy of a compileraccessed bY all users)
- Communication (e.g.. between users)
- Lower cost
Similarly, computer network can make (selected) resources of allnetwork host computers available to the network (user) community;i.e. resource sharing can occur across, as well as within theconfines of host computers.
NOW, the pioneering nature of NSW becomes apparent. NSW hassucceeded In achieving a uniformity at the network level whichhad, In the past, only been accomplished within a single-hostenvironment. To achieve uniformity and transparency of.operation, NSW provides:
- A single standard command language
- A global, distributed tile system
- Uniform access to and control of network resources(a.e.. programs called OtoolsO as well as files)
iM
"!
Y im m lom | a E I r ,n n ml ~ ln mun-
Mintegrated Project management facilities
- Centralized accounting
All of th~e above has been achieved Inl a *heterogeneous'networking envirdnment of diverse and incompatible hostcomputers,
2.1 History
Evolution of the NSW concept and development of the WSWsystem has occurred In several, sometimes overlapping# phases.The five (5) phases of NSW development 13) are briefly summarizedbelow:
1. Feasibility Demonstration (July 1974 through November1975): This phase Included formulation of the osic NSWarchitecture, ad noc implementation of the malorsoftware *components" (see Section 4.4.l) anddemonstration of the following:
- Use of IBM 369 batch tools
- Use of TENEX Interactive tools
- Transparent file movement and translation, and
- Rudimentary project management capabilities
2. Detailed Component Design (June 1975 through March197b); During this Period external and functionalspecifications were completed for the following malorcomponents: MSG (the NSW interprocess communicationfacility), works Manager, Foreman and File Package. Aminimal Front End (component) specification was alsoprepared during this period.
3. Prototype Implementation (January 1976 through November1977): This phase was primarily devoted toimplementation of NSW components for varying hostenvironments. During this period:
- TENEX, IBM and Multics MSG implementations werecompleted and demonstrated
initial Implementation of all TENEX components(Works Manager, Foreman and File Package) werecompleted and demonstrated
Implementation of the Multics Foreman and FilePackaqe components progressed to the Point that aOrudimentary Multics interactive tool' [4) could bedemonstrated
- Development of the IBM Foreman and File Packagecomponents was started
12
- Preparation of the "Interim Reliability Plan" wasInitiated
4. Reliability and Performance enhancement (January, 1977
through December 1988): This phase concentrated on$
- Completion of the "Interim Reliability Plan' andImplementation of specified reliability scenarios
W Addressing Performance problems visible In theexisting (primarily TENEX/TOPS2-23) componentimplementations through:
" Development of performance measurement routines(completed In February of 1978)
* Instrumentation of all (TENEX) components (completedIn May of 1978)
d Completion of the Foreman and File PacKagecomponents for the IBM and Multica hosts.
5. Productization (January 1979 through April 1961): TheNSw Productization phase, covered by this report, ischaracterized by the Introduction and implementation ofa Plan for managino the development and operation of theNSW system 5. This plan formalized procedures for:
- Release integration and hand-oft
- Quality assurance
- Software Trouble Reoort (STR) processing
- Configuration management
- Production operation
This phase can also oe characterized as a period ofunprecedented use and hardening of the WSW softare.Many problems and deficiencies in the areas ofoperability# reliability, performance, user/operatorinterfaces, etc were successfully addressed. (Thus, theOProductization' phase is also considered to be acontinuation of Phase 4t 'Reliability and PerformanceEnnancementO). Also, In preoarationfor Phase 6(OTechnology Demonstration and Transfer Feasibility")#much of the planning for the AFrLC TechnologyDemonstration was completed during this periods Duringtne next, Technology Demonstration, Phase selected AFCsites Will make use of and assess NSW and networKingtechnology relative to current and future AFLC needs.
13
MINE,",
4A;
Phase 6 development activities will be based on currentplanning activities aimed at determining the NSWfeatures and Performance Paramleters required for thePlanned Technology DtoonStration.
14
2.2 Policy Statements
The major near-term goals of theo NSW project are summariZedbelow using excerpts from Policy statements Issued during thecontract Period covered by this report:
Project Evaluation Policy (November 24v 1979) (6Js
-"Our Immediate goal Should be to overcome knownPerformance obstacles and rectify known designand feature deficiencies to provide a systemcapable of supporting a technologydemonstration within the MELC serve as arepository and testbed for JOVIAL, and ADAProgramming tools, and be good by the WSWdevelopment community and by selected membersof the ARPh community."
*"The Initial task should be a reevaluation ofthe tunctional performance characteristicsdesired in the system"*
*"Out Performance qoal should be to Provide allof the critical Performance characteristicsreauired by the above postulated userCommunity# and# within our resourcelimitations# those desirable characteristicswhich will enhance user satisfaction."
-"Our Implementation goal should be to have anyredesiqnlre-implementation occur as a series ofstaged releases evolving from Release 4.1."
Product Policy (November 24P 1979) [7):
= uin general# . Proper attention shall begiven to operability, (and) maintainability, inaddition to functional performance"
a "The system ultimately provided shall permittool execution which approximates the nativeenvironment werormanco. as well as In selectedcases provide an appropriate executionenvironment."
AmL Demonstration Policy (November 24. 1979) Elio
,-...is
- "The intent 15 that the AFLC Demonstration havea high project priority*
"The goal Is to demonstrate selected aspects of
NSW functionality. The effort will be executedin three phases, the first two ot which provideintroduction to networKing and the NSW, andconfigure the necessary tool support for phasethree. During the third phase, the functionaldemonstration of the NSW will occur using aselected AFLC tasK."
"The demonstration will have functionality asIts goal and help to define the ultimateproduct characteristics for the AFGCapplication."
NSW Support Strategy (December 26. 1979) (9i:
a (A]*. , strategy for the use, support andmodification of NSW release 4.1" requestingcoordinated action on the part of PDC and ACC(see Section 3.1) to:
" Develop "a plan for the use and supportof the current release 4.1"
" Participate "in regularly scheduledmeetings of the 'wOrking group* that hasbeen set-up to coordinate the details ofthe AF6C Technology Demonstratione.
Ensure "a smooth transition of their[ACC and PDCJ planning activities" to"assure @ . a smooth transition fromNSW version 4.1"
w16
;4*b
3. NSW Prolect Organization
During the prototyplng and feaslbllity desonstratlon Phases.of WSw development (Prior to January of 1979) the absence ofProject structure and discipline had been the norm. However, thedesire to harden, ruggedlzed and enrich (i.e., Op.roductliei) theNSW system, combined with the increasing number of geographicallydistributed contractors. established the need for formal Projectmanagement discipline. RADC resoonded to this need by DreDarinathe ONSW Management Plan", whicn:
1. Establishes . , . an overall approach tormanaging the development and operation ot theNational Software WorKs (NSW)[ L10], and
2. Identifles *responsibilities ot particlpatinaorganizations, types of services to be provided,and directions tor future growth" rill)
1-
3.1 Organizational Structure
The roles of the six (6) primary NSW organizationalentities, discussed in the ONSW Management Plan*, are summarizedbelow:
" Policy Group (PG): hargely staffed by Individuals fromthe sponsor organizations (RADC and ARPA). PGresponsibilities Include resolution of "top level issueswhich Impact NSW's Present service stance and futurerange of applicability" (123. Speciftc PGresponsibilities include:
- Strategic planning
- Resource allocation, and
- Organizational conflict resolution
" Architecture Control Contractor (ACC): ACC isresponsible for:
- *Ensuring Ethel continued specification-levelintegrity of the NSW architecture" (131
Interpreting the strategy for and orchestrating
the development of NSwv and
- Integrating the various software componentsdelivered by the Development MaintenanceContractors (DMC's) into an NSW product which isboth operable and usable.
* Product Development Contractor (POC): "Focusing onthose steps which can be taken* . e e to bring aboutnear term, measurable improvements In eitner thefeature, performance or reliability domains" 1143, PDCIs largely responsible for wMaKtin NSW a palpable.usable. Land) acceptable product* (l3.
* NsW System Operations (NSWOPS)3 NSWOPS' role Is toProvide the NSW user community with "reliable,dependable and efficient computational services andcomprehensive, correct and responsive informationservicese (163.
* Development/Maintenance Contractors (DMC's)t Theindividual DMC's are responsible for implementationandlor maintenance of one or more NSW softwarecomponents (see Section 4.4.1). DOC activities are
is
: - -
• -nmmmnlmmmmmmmm~mlE*mu.
directed by Specifications and/or guidelines establishedand maintained bY ACC,
*Tool Manager (Tm): The NSW Tool Manager Is responsiblefor managing and supporting the selection, acquisition,Installation and maintenance of (nee) NSW tools (seeSection 6,1.3 for a discussion of NSW tools).
19
3.2 NSW Contractors
Summarized below are the sponsors and/or contractors (andprincipal contact) responsible for each of the N4SW organizationalroles discussed In Section 3.1:
ft Policy Group (PG)
RADC/lSCP: Dick Metzger, and Al Barnum
ARPA/IPTO: Larry Druftel Ift Architecture Control Contractor (ACC)
Massachusetts Computer Associates (COMPASS):Charley Muntz
- Product Development Contractor (PDC)
General Systems Group# Inc*: Doug Payne
NSW System Operations (NSWOPS)
General Systems Group. Inc.: Doug Payne
W SW Tool manager (TM)
IIT Research Institute CIITRI): Loraine Duval
-NSW Development/Maintenance Contractors (DOCs)
*Massachusetts Computer Associates (COMPASS):Charley Muntz
bolt, Beranek and Newman. Inc. (BBt4)3 Rick Schantz
UCLA/Campus Computing Network CCCN): Neil Ludlam
Honeywell Information Systems (HIS): John Ata
Specific component responsibilities ot each DNC aredetailed In Section 4.4.2.
Although no formal reporting structure has been established,rigure 3-1 (which is based on existing Protocols andorganizational Interactions) provides a realistic approximationOf NSw'S organizational structure (dashed lines Indicatesigniticant organizational Interactions which Span theorganizational hierarchy).
29
PG
(RADC/ARPA)
COASS(PDC TM
\(GSG) (G ITR
NSW Organizational Structure
Figure 3-1
21
'vi
4.0 NSW System Architecture
The (SUb)sections which follow present a "bottoM-Up"overview ot NSW system concepts and architecture, Separatesections are devoted to the following topics:
The ARPA NetworK
NSWd host families
NSW software components
Participation of hosts in NSW svstems configuration
22
4.1 The ARPANET
NSW has been implemented In the ARPA Network (ARPANET)environment. A brief description of the ARPANET follows:
"The ARPANET is an operational, computerized, packetswitchinq DOD digital network which provides acapability for terminals or geographically separatedcomputers, called hosts, to communicate with eachother. The host computers often differ from oneanother In type, speed, word length, operating system,and other characteristics. Each terminal or hostcomputer is Connected into the network through a smalllocal node computer called an IMP or TIP. The completenetwork is formed by Interconnecting the IMPs throughwLdeband communication lines (normally 59,000 bits persecond) supplied by common carriers.
Each node is programmed to recLeve and forward messagesto neighboring nodes in the network. During a typicaloperation, a host passes a message to Its node; themessage is Passed from node to node through the networkuntil it finally arrives at the destination IMP, whichIn turn passes It along to the destination host. Thisprocess normally takes less than 250 milliseconds.
Hosts communicate with each other via regular messages.A regular message may vary In length from 96 to 8159bits, the first 96 of which are control bits called theleader. The leader is also used for sending contrilmessages between the host and Its IMP or TIP (node).The remainder of the message is the data or text.
For each regular message, the host specifies adestination, consLstino of node, host, and handlingtype. These three parameters uniquely specify aconnection between source and destination hosts. Thehandling type gives the connection specificcharacteristics, such as priority or non-prLorLtytransmission. Additional leader space has beenreserved for a fourth parameter, to be used In futureinternetworK addressing. For each connection, messagesare delivered to the destination In the same order thatthey were transmitted by the source.
1
For each regular message, the host also specifies a12-bit Identifier, the message-ID. The sessaqe-ID,together with the destination of the message# is usedas the *name* of the message. The node uses this nameto inform the host of the disposition of the message.
23
Ai
Therefore, if the host retrains from re-using aparticular message-ID value (to a given destination)until the node has responded about that message-ID,messages will remain uniquely identified and the hostcan retransmit them in the event of a failure withinthe network.
After receiving a regular message from a host connectedto it, a node breaks the message into several packets(currently the maximum data bits Per packet is 1008)and passes these through the networK in the directionof the destination. Eventually, when all packetsarrive at the destination, they are reassembled to formthe original message which is passed to the destinationhost. The destination node returns a positiveacknowledgement for receipt of the message to thesource host. This acknowledgement is called a Readyfor Next message (RFNM) and identifies the messagebeing acknowledged by name. In some relatively rarecases, nowever, the message may not be delivered due toa node failure, line disruption. etc., in such cases anIncomplete Transmission message will be returned to thesource host instead of a RFNN. In this case themessage which was incompletely transmitted Is alsoidentified by name.
If a response from the destination node (either RFNM orIncomplete Transmission) is not delivered to theoriginating host, this condition will be detected by
the source node, which will automatically inquire ofthe destination node whether the original message wascorrectly received and repeat the inquiry until aresponse is received from the destination node. Thisinquiry mechanism Is timeout-driven, and each timeoutperiod may vary between 30 and 45 seconds In length.
When a message arrives at its destination node, theleader Is modified to Indicate the source host, but themessage-ID field Is passed through unchanged. Thus, Inaddition to providing message Identification between ahost and its local node, the message-ID can provide ameans for hosts to identify messages betweenthemselves.
Users of the ARPANCT may access local or distant SERVERcomputer (hosts) over the network. They may alsoexchange messages, create realtime links between users.transfer files from one computer to another, and submitbatch Jobs to distant computers. ror a more completedescription of these processes, see the ARPANETProtocol Handbook available from the (NetworkInformation Center) NIC or the National Technical
24
ta- -='
. .... .
/ aam> i__
i l ~ i l~ mim
Information System MNIS), Springfield, VA, 22161 asAD AS5259490 E173
The ARPANET communications Subsystem configuration (ioe,, IMP$and TIPS -- sOe above) is shown in F'igure 4-1 [181; Figure 4-2 Isan ARPANET schematic which includes host identifiers 11.
25
11!______ Im
I ~~" ii ~i~26
fAf44
-J-
0 27
4.2 NSW - A Network Operating System
The National Software works (NSW.) Is an operating system.Because it has been Implemented in a networking environment, NSW IIs often called a OnetworK operating systel e. Much lIKe a single
host operating system, NSW manages network resources, providingIts users with uniform access to files* programs (called *tools*)and hardware resources available from network nosts which"participate" in the NSW system. However* the NSW networkoperatinq system differs from slngle-host operating systems In
many significant and important ways:
- NSW operates In the networking environment, where
dispersed computers may be required to complete a
user's request.
- NSW Is an operating system which, Itself, has beenbuilt "on top" of existing single host operatingsystems.
NSW has been built to operate on a set of DISSIM1LARcomputer systems, and to provide users with uniform,controlled access to the resources of thesedissimilar computer systems.
-~ 28
4.3 Host Families
NSW software components (see Section 4,4.1) must beImplemented for an ARPANET host computer system In order for thathost to *participate" In a configuration of the NSW networkoperating system, Generally speakingo the level at which a hostcan participate In an NSW configuration Is determined by thenumber of different NSW software components implementel for thathost* Since the operability of NSW component Implementations islargely independent of hardware configuration anad/or operatingsystem version/release, we often speak of -"host families" whenreferring to NSW component implementation$. That Ise NSWsoftware components may be Implemented once# for a "host famIlvrthen the software components can be installed on each host (ofthat family) Participating In the NSW System configuration.
The NSw host families and the current set ot constituentARPANET hosts Ci.e., Participating famly vembers) are Itemizedbelow:
-TENEX/TOPS-20
ISM1 DECSYstem-20 (199T) running ?OPS-20version 3A,
ISIC: DECSystem-29 (KAlS) runnino TOPS-2S version3A.
RADC-20: DECSystem-20 (2049T) running TOPS-29version 4.
IBMIOS
UCLA-CCN: 3033 running MYS (Note: CCN iscurrently converting from OS/VS1 toMYS)
- Multics
HADC-Naltics: N6186 running MultIcs
M Unix
RADC-UNIXI PDP-11/45 running Unix (future FrontEnd Host - see Section 4.4.3)
ROSZNS-UNIX3 PDP-11/'45 running Unix (futurefront End Host **see Section4,4o3)
29
sku~
I4
4.4 NSW Software Architecture
The NSW functionality has been Logically decomposed andgrouped into a set of software "componentswo Host-Independentspecifications exist for each malor NSW component. Thesespecifications are used as the basis for realizing componentimplementations for different host families.
NSW components communicate with one another through aninterProcess communication facility called MSG (Figure 4-3).MSG# combined with existing ARPANET "protocols", serves as thefoundation for implementing higher level, NSw protocols.Protocol interactions between components are often grouped IntoONSW scenarios*; each NSw scenario reliably Implements one (ormore) NSW operating system function(s).
For an ARPAN.T host to "Participate" In an NSW systemconfiguration, host (family) Implementations of the interprocesscommunication facility (MSG) and at least one other NS* componentmust exist. The level at which a most (family) can Participatein an NSW system Is constrained by the set of NSR componentsimplemented for that host (family). NSw software components (seeSection 4.4.1) are each associated with a set of NSw operatingsystem services. The level at which a particular network hostparticipates In NSw system configuration Is determined by the setof implemented services (executing components) the host providesfor the NSW user community.
An NSw system "configuration" consists of a set of ARPANEThosts participating at various levels according to the NSWoperating system services they provide (operating system servicesare implemented by the NSW software components - see above). AnARPANET host may participate In more than one NSW systemconfiguration.
NSw resource management and control, includingauthentication, access control, synchronization and accountingare logically centralized In a set of "core system* softwarecomponents. The 'core system" components ran on the "core systemhosta; there Is one "core system host" per NSw systemcontiuration. Thus* the "core system host" enloys the highestlevel of participation in an NSW system configuration. Non-"coresystem" components, run primarily on non-"core system" networkhosts out may (and frequently do) run on the "core system host"as well. A single "core system" host means that the cost forother non-"core system" hosts to participate In an NSb systemconfiguration (in terms of systev resources) Is relatively low.That is, only the "core system host" Pays the Price to providethe expensive "core system" services mentioned abov.
3
A central set of "core SYstema comPonents also means thatNSW logically taK*5 the shaPe Of a "Star* (Figure 4-4). Thisstar-lke Control structure does not Preclude directcommunication between non-Ocor* system" components (as indicatedby the dashed lines of Figure 4-4), However, such interactionsare Usually coordinated in advance with the "core system".*
31
MO N N 01
COMPONENT I. COMPONENT 2-
Protocol HOST A MSG (NSW interproceSS communication)HOS+ B MSG
Layers HOST A \ 0S (Host operating system) HOSF B 0/S
HOST A \NCP (Network Control Program - HO$T B NCPnetwork interface)
6.PANET COMM4UNICATIONS SUBSYSTEM /
Component Communication Via ?4SG
Figure 4-3
32
ARPANET Non-
Non- ( Core"'
..Core",-
Core System
/Components
NonNon-"Core.
ONon-
NSW'S Star Shaped Control StrUcture
33
''a4 -
4.4.1 NSW Software Components
Logically speaKing, the NSW System consists of eleven (11)functional software packages called "componentsm. Thesecomponents consist of generic (i.e., implementation independent)groups of NSW functionality which may be realized for one or moreof the NSW host families (by NSW Development/MalntenanceContractors (DMC's) -- see Section 3.1). A brief description ofeach generic NSW component is given below:
- MSG: The interprocess communication facility usedby all components to communicate with and requestservices of one another is called MSG.
- "Core System" Components:
works Manager (WM): The works Manager Is NSW'Ssystem resource manager and control point,providing centralized authentication, accesscontrol, synchronization, and accounting. rheWorks manager maintains several criticaldatabases, including:
- A central file catalog
- A central tool (executable program) catalog
- Project organizations (see Section 6.1.1)
- User ids, passwords, and rights
* ChecKpointer (CHKPTR): The Checkpointermaintains WorKs Manager database integritythrough periodic back-up.
* works Manager Operator (wmO): The W4O directsand coordinates the execution of *batch Jobs"with non-"core system" Batch Job PacKagecomponents (see below).
Fault Logqer (FG): The Fault Logger is thecentral operator-visible collection point forOtaults* (abnormal and/or error conditions)reported by other NSw components.
" Operator Utility (OPRUTI): OPRUTb is one of manyoperator utilities; it provides NSN operatorswith a number of high-level "core system"component manipulation and clean-up ope.itlos.OPRUTL, has been elevated to component status
34I
tI
because some operator functions communicate with
the "core system* coloonents though MSG.
- Non-*Core System" Components"
Foreman (FM)s The Foreman component oversees theexecution of Interactive tools (executableprograms). One important function of the ForemanIs to Intercept operating system calls (e.g.,file references) and direct the% to NSW or thelocal operating system, as appropriate.
File Package (FLPKG): The File Package componentmanages a host-resident Portion of NSW t1lespace.File Packages resident on different NSW hostsInteract with each other to transfer files Ibetween different (host-resident) portions of NSWfile space. The File Package is also responsiblefor translating tiles as they are moved betweenhosts which belong to different host families.
Batch Job Package (BJP): Under direction of theWorks Manager Operator the Batch Job Package mapsuser-Initiated "batch lobs" into, tne local hostexecution environment and oversees theirexecution.
Front End (FE): The NSW Front End implements andInterprets the NSW command language. AlternativeFront End Implementations may realizesyntactically and sevantically different commandlanguages (see, for example, Section 6.2.1). Arequest Initiated by the Front End always beginsan NSW "scenario", involving interactions with atleast one other NSW component. Based onuser-supplied commands and parameters, the FrontEnd requests services Implemented by other NSWcomponents (usually the "core system" WorksManager).
Dispatcher (DSPCHR): Contacting a standard hostsocket causes the Dispatcher to place the(prospective) NSW user in contact with a spawnedFront End instance.
35
i 'i
4.4.2 DMC Responsibilities
The tour (4) NSW component Development/MalntenanceContractors (see Section 3.2) are each responsible for severalhost family component implementations These responsibilitiesare summarized below by host fa%1ly.
TOPS-20
MSG - BBN
*Core System" Components:
Works Manager - COMPASS
- Checkpointer - COMPASS
- works manager Operator - COMPASS
- Fault bogger - BBN
- Operator Utility - COMPASS
Non-*Core System" Components%
- Foreman - BBN
- F'ile Package - COMPASS
- Front End - COMPASS
- Dispatcher O BMN
IBM
MSG - UCLA/CCN
*Core System* Components:
** none 9*
Non-*Core System" Components$
- Foreman - UCLA/CCN
M File Packagea UCbA/CCN
36
~ .frJ
- Batch Job Package - UCLA/CCN
MulticI
MSG - HIS
*Core System* Components:
* none *
Non-*Core System" ComPonent$%
- Foreman - HIS
- File Package - HIS
Unix
MSG - BBN
"Core System" Components:
*$ none **
Non-*Core System" Components:
- Front End - SBN
37
4.4.3 Participation of Hosts In NSW Configurations
The level at which an ARPANET host 'ay participate In an NSWsystem configuration Is determined by the collection of softwarecomponents Implemented for the associated host family. (Note:An implementation of MSG Is required for any level ofpartlcipation.) The five (5) disjoint levels at which a host mayparticipate in an NSW configuration (or, alternatively the fivesets of operating services a host may otter by participating inan NSW system configuration) are each described below:
Core System Host (CSH): Only one host per NSWconfiguration can serve as the 'core-svstem host" byproviding the following NSW functions: authentication,access control, synchronization and accounting. Hostfamily implementations of the following "Core system"components are required:
works Manager
ChecKPointer
* Works Manager Operator (required only If the NSWconfiguration Includes one or more Batch Job Packagecomponents).
. Fault Logger (required only if the NSW configurationIncludes one or more components which report"faults" to the Fault Logger).
* Operator Utility (as required by host familyimplementations of the works Manager andChecKpointer).
File Bearing Host (FBH): Any host tor which a (hostfamily) Implementation of the File Package componentexists can oversee a portion of NSW filespace residenton that host by providing support for:
" File transfer and translation between host-residentportions of NSW filespace
* The movement of files between N3W filespeco and thelocal host file system.
The Datacomputer (now defunct) Is an example of anARPANET host which might wish to participate in an NSWsystem configuration only as a File Bearing Host (i.e..not as a Tool Bearing Host -- see below).
3m
!A
(Interactive) Tool Bearing Host (TBH): Any host forwhich a host family Implementation ot the Foremancomponent exists can provide support for the executiono0 interactive *tools* (executable Programs). However,the Foreman cannot, without a file Package component#support tools which reference NSW tiles. Thus*participation as a File Bearing Host is almost alwaysconsidered a prerequisite to participation as a ToolBearing Host.
Batch Job Host (BJH): Any host for which a host tamilvimplementation of the Batch Job Package componentexists can Participate in an NSW system configurationas the executor of NSW batch job processing on thathost. Of course, Such Participation assumes a Ocoresystem" configuration which includes a works ManagerOperator component (see above). Also# Decause certaininformation required for batch processing istransmitted from the Works Manager Operator to theBatch Job Package through the NSO file system, supportfor NSW files (loe., a host-resident File Packagecomponent) Is also required*
Front Sn Host (FEH)9 A Front End Host acts as a useraccess point for an NSW system configuration. Any hostfor which a host family implementation of the Front Endcomponent exists can be an NSW access point Providinguser interface (i.e., NSw command language) support.
39
:: , .. . . ...
4.4.4 Levels ot Host Family Participation
Usinq the "levels of participation* discussed In Section4.403, we can suvmarize the levels of participation possible foreach NSW host family Identified in Section 4.3:
TOPS-20 (fOPS-20 host can participate In an NSW
configuration as one or more ot the following)$
- Core System Host (CSH)
- File Bearing Host (FBH)
- Tool Bearing Host (TBH)
- Front End Host (FEH)
IbM:
- File Bearing Host (FBH)
- Tool Bearing Host (TBH)
M Batch Job Host (BJH)
Multicst
- File Bearing Host (FBH)
T o01 Bearing Host (TBH)
Unix:
M Front End Host (FEH)
One or more "levels of participation" have been asslqned toeach host family listed above. An ARPANET host which belongs to
(i.e., Is ComPatible with) one of the NSW host families CAN
participate at any of the levels listed above for that family.For example# any ARPANET DECSystem-20 running TOPS-20 canparticipate In an NSW system confiquration as a:
Core System Host (CSH)
- File Bearing Host (FBH)
- Tool Bearing Host (TBH)
40
'4
-Front End Hiost (FEH)
or any combination of the above. The RADC-20 ARPANIT host# aDECSystem-29 running TOPS-2S. Provides a specific example.Currently the RADC-20 participates In several N~w configurations.In the NSW User System configuration (see Sections 4.4.5 and5.1). the RADC-20 Participate* as g Tool Searing Host and a FileSearing Host, but not as a Core System Host or a Front Enld Host,
41
4.4.5 NSW User System Configuration
The production NSW~ configuration available to NSW users IsCalled the ONSW User System"# The User System configuration(Figure 4-5) Consists of ARPANET hosts participating at variouslevels (see Section 4,4.3). The level(s) Of host participationIn the User System configuration are summarized below (by ARPANEThost):
USC/ISIE (TOPS-20)
w Core System Host
- Tool (and File) Bearing Host
- Front End Host
USC/ISIC (TOPS-20)
- Tool (and File) Bearing Host
- Front End Host
RADC-20 (TOPS-2a)
- Tool (and File) Bearing Host
UC6A-CCN (soon to be running MYS)
- Tool (and File) Bearing Host
w batch Job Host
RADC-MUL.TICSI-Tool (and File) Bearing Host
Note the following:
* UsC-ISIh9 is the only core system host In the UserSystem configuration,
* RADC-20 could be# but Is not* a Front End Host (eventhough a Front End component Implementation exists fortne TOPS-20 host family)*
*UCLA-CCN Is the only Batch Job Host (te IBM hostfamily Is the only family for which a batch Job PacKagehas been Implevented).
42
, A
*UCL.A/CCN and RADC-MULTICS could rnot be front End Ho*sts(Front End components have not beenl implemented toreither the IBM Or NUltICS host tam1iOS)o
*The User system configuration inciijdes no Unix hosts(the Unix Front 9nd has not yet been released torintearation Into the User System contl~uration)o
434
W4%43
H
InI
o Cl, E-
-4
44
41
U)
(12
>.4 E- (n 2>
En I E-4 U)
444
5.6 NSW System Development
At the highest level, NSW sVste* development can be viewedas a sequence at stages, each of which Is Performed andcontrolled by a different NSW organization. The tour (4) stagesat the NSW system development life cycle are briefly describedbelow (see Flqure 5-1):
1. Component Development and Maintenance: The NSWDevelopment/maintenance Contractors (DMC's -- seeSection 3.1) are responsible tar developing andmaintaining host family Implementations of specificNSW software components* when a new componentversion is considered ready for release, theresponsible DMC delivers it to the NSW Architecture
Control Contractor (ACC) for integration.
2. System Integrations It is ACC*S lob to Integratecomponents received from the various DMC's into anoperable NSW system and to verify that the componentsinteract Properly with one anotner. The DMC's workwith ACC to isolate and correct probleis; comoonentswhich do not "pass muster" are returned to theappropriate DMC for additional Work. Since the DMC'soperate asynchronously from one another, NSW systemIntegration Is. defacto, an Incremental process.That Is. at most a few components are introduced intoa stable N4w system configuration at a time.However, incremental integration has the advantage ofmaking ACC's Integration testina (and problemIsolation) task somewhat easier. $hen ACC isconfident that the integrated NSw system Is ready forproduction operation, its constituent components arePackaged into a system release which Is thendelivered to the NSw Product Development Contractor(PVC) for Quality Assurance.
3. Quality Assurance (O/A): It Is PDC's tIsK to verify,throuqn Independent testing, that NSW system releasesare ready for
Production operation by NSh System Operations(NS*PS), and
- Use by the NSW user community.
Upon comoletion of U/A, PDC provides th* N45W Policy
Group (PG) with recommendations rejarding productionoperation of the release, Including any correctiveaction which may be required to make tne release
45
operable/usable. Based on recommendations from PDC asoell as input from ACC, and NSwOPS, PG VaKes one of twodeterminat ions:
- Return the release to ACC (and the DMC'5)for further worK, or
M Deliver the release to NSWOPS forInstallation and production operation,
4. Installation and Production Operation: NSWOPSoperates the national NSW User system configurationon behalf Of the NSW user community. When a newrelease (or notification thereof) Is received fromPVLC, NSWOPS:
W Schedules an Installation date
= broadcasts a summary of the release (Includingrelease date) to the NSW user community# and
M (On the designated date) Installs and beginsoperation of the new release.
Note (see Figure 5-1) that each stage of the NSW system
development Process Provides a feedbacK loop to the Immediately
the form of bugs, deficiencies and/or desired features may becommunicated to PDC, ACC and ultimately the DMC's for analysis,Prioritization and action.
46
V.V.
.7
4)i
L!1iI®1.-4 U)
, U , E,
00) 0 0
"00
I 0 @1
Iow
00)
IE4
7J
4) ()n.U
1.- 4.) U
0z 0
41
c 0)
447
5.1 NSW System Configurations
To maximize efficiency, It iust be Possible for each step ofthe NSW system development process to proceed Independently ofall others. In particular, It must be possible for:
W NSwOPS to operate the current release while newreleases are at various stages of development.
- PUC to perform O/A on a new release (nil) while ACC Isintegrating a future release (n+2) and NSWOPS isoperating the currently Installed release (n).
- ACC to integrate a release (n+l) while PDC isperforming G/A on a recent release (n) and DMC's arepreparing components for future Integration (releasenil or greater).
- DMC's to prepare new component version(s) independentof ACC integration activities.
Four (4) distinct NSW system confiqurations were establishedto provide the necessary organizational autonomy which wouldallow each step of NSW system development to proceedIndependently of all others (Figure 5-2):
1. The NSW "Debug" System configuration, controlled byACC, Is used by the DMC's to prepare new componentversions.
2. The NSW "Development" System configuration iscontrolled, operated, and used by ACC to Integratecomponents Into system releases which can then bedelivered to POC for /A.
3. The NSw "Candidate" System configuration, operated byNSWOPS#, Is controlled and used by PDC for G/A.
4. The NSw "User" System configuration is controlled andoperated by NSWOPS on behalf of the NSw usercommunity.
t &9
to)o 41 41 0
1.4 4 44 toa, 0 2
ML 0
14 .. 140 54
44
V0 0
N
U .4
4J 01
0. 4U0 14 M
0 04 tp '4
CA
41
>1 a
vI 4
41a4
4494 0
5.2 NSW Testing Hierarchy
NSW System software Is separately tested during each stageof the system development Process (see Section 5.3). Tests for agiven stage are most often applied to one or more NSw componentswhich have been installed In the associated NS* systemconfiguration (see Section 5.1). Devised and applied tests areoriented toward the system development activities of each stage(e.g., 0/A) and reflect progress along the development continuumleading to production operation of new NSw system releases.Collectively, tests applied during develooment stages one (1)through four (4) form a hierarchy In wnich Individual componentsare tested first (this is called "unit" testing), then individualcomponents are integrated into a full hSw system configuration,which receives two separate batteries of tests: Integration andQ/A. The testinq activities associated with each stage of theNSw system development process are summarized below:
1. Unit Testing: Each NSW software componentimplementation is referred to as a unit. These testsare (often) applied to components installed in theNSW Debug System configuration. Unit tests aredevased and applied by the DMC with iiplementationresponsioility to:
- Components In Isolation to verity correctoperation of internal functions, and/or
- Small collections of components to verity thatthe component interacts properly with other NSWcomponents.
Components which have "passedu unit testing aredelivered to ACC for inteqrationo
2. Integration testing: It Is ACC's responsibility to:
M Integrate NSW components received from DMC'sinto an operational NSW system.
- Verity the system, specification andinter-component integrity of complete componentconfigurations (i.e.. full NSW systemconfigurations), and
- PacKage and deliver NSW releases to PDC for 0/A
I integration tests are devised and applied to components(recei% : from the DMC's) whicn have been installed Inthe NSW Development System. Due to the asynchronous
i5
-.) _ i
--- m m m re m= mmmmm n m i t~i • m• -m m
nature of component deliveries from the DMC's, NSWsystem integration Is largely an incremental process.However, Incremental integration does have itsadvantages: If the Installation of new components inthe Development System can be spaced (in time)sufficiently apart from one another, the Job ofisolating problems (when they do occur) becomessignificantly easier. ACC has, for this reason,adopted the Incremental integration and testingapproach. Incremental Integration does requirecontinuous operation and Support of the NSW DevelopmentSystem which has the additional advantage of providingNSW developers (DMC's) with access to afully-integrated, operational NSW system prior to 0/Aand release for production operation. Wnen theIntegration Process has been completed, ACC packagesthe current set of components, databases anddocumentation for delivery to PDC who will perform Q/A.
3. Quality Assurance (W/A) Testing: PDC is responsiblefor independent validation and verification of thenew NSW systems released to ACC. During the O/Atesting, NSW systems delivered by ACC are installedand operated bY NSWOPS In the NSW Candidate Systemconfiguration. PDC prepares and applies independentsystem-level tests to each major new NSW systemrelease. The results of these tests are communicatedto the development community (ACC) and, along withrecommendations for action, to PG for determinationof release disposition. (A more detailed discussionof GSG's quality assurance may be found in Section5.4.)
4. Production Operation: NSWOPS Installs and operatesnew NSW system releases for the NSW user community inthe NSW User System configuration; these releases aredelivered to NSWOPS by PDC (as directed by PG). Inaddition, NSWUPS Is responsible for the timelyresolution of user questions and problems (sometimescalled Software Trouble Reports (STRs) -- see Section5.5). Thus, NSWOPS must view and review the NSWsyste.., from both the operational and userperspectives. To Provide an NSW system which ismaximally operable and trouble-tree, the testingefforts of stages one (1) through three (3) of thesystem development Process concentrate on removing asmany (major) proolems and deficiencies as possible.Loosely speaking, the testing an NSW system receivesduring production operation Is "use* , which isundoubtally the most important Kind of testing and animportant source of feedoack for PDC, ACC and theDMC's as well, User (and operator) acceptability Is
51
47 7-
A;X
the ultimate test. (ror a detailed discussion ofGSGI& System operation responsibilities andactivities see Section 7,0.)
52
5.3 NSw System Release and Assessment Procedure
When system Integration (ani testin4I) thas been completed,ACC Packages and delivers the new NSW system to PDC for QualityAssurance (Q/A). Due to the autonomous operational requirementsot the IBM and MIutICs NSW hosts, this DELIVERY takes thefollowing form organizationally:
ACC: Delivers all TOPS-20 components to PDC/NSWOPS
NSWOPS: Installs and operates NSW TOPS-26 componentconfigurations (including the *core system'"co*Ponents -- see Section 4.4) on the USC-lSIE#USC-ISlC and RADC-20 hosts
DMC-CCN: Installs and operates an NSW IBM componentconfiguration on the UCA-CCN host
DMC-IiS: Installs and operates an NSW Multicscomponent configuration on the RADC-Multicshost.
When a new system has been deliverel for O/A by ACC, arelease assessment and transition procedure developed by PDC (andACC) takes effect. rMIS Procedure covers the last two stages ofthe NSW system development process:
Stage 3t Quality Assurance by PDC
Stage 4: Production operation bY NSWOPS
As contractor for both the POC and NSWOPS orcanizations. GSGIs responsible for these two stages of the NSW system developmentprocess. Note that the Procedure outlined below Is Presentedfrom the PDC/NS*OPS Perspective (ie., that of POC receivingreleases for Q/A from ACC and that of NSWOPS receiving releasesfrom POC for Production operation). The stae of the NSW systemrelease and assessment orocodure arts
1. ACC: Integrate NSW components received from theDMC's into an operational NSW systeu; performIntegration testing.
2. ACC: when system integration has been completed:
Identify and obtain specific versions, for each"generic configuration Item' (see Section 5.6and Appendix C) of the. new MSW system, and
Deliver the NSW System and rOPS-23 Host F'amily*packets*m (ot configuration Items *see Section5.b) to PDC/NSWOPS*
39 NSWOPS: Install selected contiquration items fromthe ONSw System" and TOPS-20 *Host Festiva Dac~tts inthe NSW Candidate System configuration; coordinateinstallation of the IBM Host Family and Multic# HostFamily Packets with DMC-CCN and DMC-HIS respectively*
4. ACC: Verify that the new NSW system has beenInstalled Properly In the NSW Candidate Systemconfiguration; coordinate verification activitieswith DMC-CCN and DMC-HlS
Candidate System configuration (including the Ocoresystemw) for POC during Quality Assurance; direct andcoordinate operational activities with DMC-CCN andOMC-HlS.
6. PDC: Direct the application of quality assurancetests to the new NSW system release (see Section 5.4for details); report results and releaserecommendations to PG and ACC.
7. PG; Based on 0/A test results andinput from PDC#NSWOPS and ACCe select one of the followino coursesof action:
a. Return the release to ACC for Waor modification(ioe.. return step 1). or
b. fix maior Problems and release to NSWOPS; let*:
i. ACCg Direct DMCs to correct selected bugsand deliver new components for Candidatesystem installation ASAP.
2. POC: When new components have beenreceived from ACC and/or selected DMCsvverify (if possibLe) that all salorproblems have been corrected and nosignificant# new oroblems have beenintroduce
3. Proceed with Step 8
*c, Release to NSNOPS (i*e.. proceed with Step 8)
54
J, * ~
Be NSWOPSt As directed by PG. prepare for. Install andoperate the new NSw system release on weaif of theNSw user Community; direct and Coordinateinstallato/Ooeration activities witn DMC-CC andVACI4IS,
Delivery of a new NSw system release to PDC for Q/A is asignificant event In the lite cycle ot an NSw system (see Figure5-3). it signals:
- Completion of a malor amount of the worK associatedwith a given release, and
- b3eginninq of worK *In earnest" on the next major ftS*system release
A further reason Is that, as a result of PDC 0/A activities, ItIs most often the Case that PG elects to nave ON~LY major Problemscorrected (oPtion b of Step 7 above) before releasino the systemto MSWOPS for Production operation.
55-
C,
~1I-4U
oI~ U0/
/4.)
0*o o
-4 ~40:1. 0'0 *.*4
0 ~ r~.aS4..)In
NO In~ 0 (i~0 (fl 4) ~Z Z In 0
"-4In 0
56S
I
5.4 Quality Assurance Testino
PDC (GSG) nas responsibility for assuring the quality ofreleases submitted by ACC. This role is as close as any on theNSW Prolect to "independent validation and verification', afamiliar DoD term. PDC's 0/A tests represent the most extensiveand complete testing a new NSw system receives before it isreleased to NSWUPS for production operation. PDC's O/A testinaactivities have evolved Into the following logical sequence ofsteps:
1. Prepare and distribute a "Test Plan" for the new hSwsystem release (see for example, the "NSW S.0 TestPlan" (281) which identifies:
a. The current set of "generic configuration Items"(see Section 5.b)
b. Tne status of all outstandina STR's (see Section5.5) Including specific tests Prepared for eachSTR addressed by the new system release
c. The NSW host and software componentcontlqurations to be used for the release
d. The tests to be applied (see below), and
e. A scnedule for completing testing activities.
2. Update existing 0/A test procedures, scripts etc., anddevise new tests as necessary (concurrent aith Step 1).
3. Apply O/A tests (POC and NSWOPS) to the new release(L.e., the "Test Plan" is carried out under PDC'sdirection.)
4. Prepare and distribute a "Test Summary" of the O/Atesting activities (see for example, the *NSW 5.a TestSummary' 1211). which Includes:
a. An overview of O/A test results and recommendations
b. A summary of sionificant events, which occurredduring the test period, which impacted 0/A testing
C. A summary of the results for each type of testing(e.g., regression, STR-speciftc, etc. -- seebelow).
57
e~ ~ , .. *
I. .
d. An annotated list at new STR's uncovered during O/Atesting.
The *Test SummaryO Is distributed by POC to PG and ACC. Onthe basis at the "Test Summary* and Input from PDC, ACC andNSwOPS, PG determines the future disposition of the new NSWsystem, as discussed In Section 5.3.
The Q/A tests applied to each new NSW systeu are ot severaldifferent types, each designed to test different Integrationlevels ot WSW functionality. These tests are not exhaustive, butthey do represent a significant assessment at the WSWfunctionality provided the user. with tne exception atSTR-specific tests, G/A testing methodologies have been preparedtot each type at testing# as described below:
1. STI-Specitic Testing: Prior to receipt at a new NSWsystem from ACC, POC prepares tests for each SoftwareTrouble Report (STR -- see Section 5.5) which will beaddressed by the new release. rhese tests are usedto verity that problems nave been corrected and thatno new problems or side-etfects nave Peon Introducedin the Process. Also, STR-specitic tests are used toassess new and/or Improved NS, functionality. Thesetests are documented in the "rest Plan" which isdistriouted prior to the oeginninq of the O/A testingperiod (i.e., Prior to receipt of a new release fromACC).
2. Regression Testing: A methodology has been devisedtot regression testing new NS, releases. It a systemfunction or feature, which worKed properly In thepreceedinq release, no longer functions correctly Inthe new release, a "regression* Is said to haveoccurred. Regression tests are designed to uncoverthese differences. However# the NSW regression testsare more general In that they have been designed touncover as many differences as possible betweensuccessive NSW releases, including:
- Improvements
- Regressions, and
- Problems which persist from one release toanother
Regression tests consist of a number at distinct testscripts. These scripts are composed at WSW comeandsequences which are applied to the user intertace(exercising user-visible WSW functionality). Bothapplication of regression test scripts (to the user
.MM
intertace) dad collection of NS, svstev responses havebeen automated. The steos of tne NSW regressiontesting Procedure are summarized below:
1. Update regression tests as necessary to reflectdifferences between the successive releases*
2. Use automated means to apply test scripts to thenew NSW system and collect responses.
3. Comoare (automatically) the responses for eachtest script to those retained from thePreceedinq release, and sumiarize theincremental differences.
4. Analyze the differences (obtained in step 3) toidentify improvements, regressions end problemsexhibited by both the new and immediatelypreceedinQ releases.
5. Prepare and submit new STR*s to ACC for eachregression identitied.
This procedure Is simple, yet Powerful (Identifyingmalor differences between successive releases) andefficient (highly automated).
3. File Transformation Testing: File transformationsare the vehicle which NSW provides for data residingon one NSW host to be converted into a form which maybe used by a "tool" (see Section 6.1.3) residing onan NSW host of a different "family* (see Section4.3). File transformations allow the output of onetool to be used bY another tool of a differenttamily. Thusp NSW file transformations are the keyto success of tool Interactions between NSW hostfamilies (e.g.. the use of a tool followed bY the useot a tool which resides on a host which belongs to adifterent (incompatible) family). Conversion of anEBCDIC character file residing on an IBM host to anASCII character file during movement to a TOPS-20host Is a simple example of an NSW filetransformation. File transformations embody recordstructure, format effectors, as well asword/character encodings. because the NSW concept ishighly dependent on these transformations* a*methodology and Plan for Testing FileTransformation' (223 was developed. Due to thenature of the differences between NSW host families,the distributed nature of the WSW file system (andits protocols), and the data translation approach
59
-kip"
adopted, NSW file transformations are Perhaps one ofthe most difficult packages of NSW systemtunctionality to test. The file transformationtesting methodology is aoplied to new NSW systemreleases to verify the fidelity of thisfunctionality. A simplified version of the basicprocedure Is outlined below:
a. Update the "methodology and Plan for Testing NSWtile Transformations" as necessary to reflectIncremental cnanqes from the. preceeding release.
b. Prepare and/or modify tile transformation testcase files, as necessary; import these filesinto the NSW Candidate System.
c. Use automated means to force filetransformations by moving test case files fromone NSW host to another (these hosts may or maynot belong to different host families).
d. Analyze resultant files to determine whethir thefile transformations under test have beensuccessfully completed.
e. Prepare and submit STR's to ACC for eachidentified file transformation anomaly orproblem.
4. Interactive Tool Testing: Tool testing is concernedwith verifying the proper operation of "tools'(executable Programs) Installed in the NSWenvironment. Interactive tools are the mostprevalent type of NSW tool (see Sections 6.1.3 and6.2.3). Although tool testing Is viewed largely as aTool Manager responsibility (see Section 3.1). It Isan drea which GSG addressed during the NSW systemdevelopment orocess. Tool operability is one of themost Imoortant concerns of NSw user community.oecause tool availability Is the user's reason forusing the NSW system. Therefore* GSG developed the"Interactive Tool Testing Methodoloqy* 1231 andapplied it to a number of NSW tools delivered withNSw release S.*. The results of these tests aresummarized In the "Summary of Interactive Tool TestsiNSW Release 5.*" 124). These tests will be appliedas necessary to (selected sets of) the toolsdelivered with all future NSW releases.
"4/ A I
0li
5.5 STR Processing
When NSW users, contractors, etc uncover Suspected Problemswith the NSW software, a Software Trouble Report (STA) Isprepared to document the problem, In addition, STR's are used toreport system deficiencies. An STR Includes some or all of thefollowing Information:
- Originator (e.q., name of user or contractor)
- Description ot the Problem, deficiency or improvement
- Date and time of submission
- Type of Problem (component, tool or docauentation)
- Release number
- Urgency
- Etc.
STR's are a critical Part of the NSW system developmentprocess, particularly configuration management (see Section b.6)of successive NSw releases. Because of the Pervasive use ofSTR's for reporting bugs, deficiencies and new feature requests,NSw system releases have largely become STR-4irected. [hat is,the NSO system modifications Integrated and packaged Into asystem consist largely of components delivered by DMC*s Whichaddress a given set of STR's (including deficiencies andimprovements).
GSG, as Product Development Contractor (PDC), developed theprocedures and Protocols for the original STR accounting system.At that time, STR's were Known as "NSW standard trnsactions' (orNST's) and the accounting system was known as the ONST System".The NST System ,as designed to oe zeneral and nLghly tlexible.NST's were envisioned as a convenient means for documentingand/or tracKLng many communications ("transactions") other thanNSW system software bu'ga includinis
- Deficiencies
- Improvements
* inquiries (questions)
61
- Operations procedures
* Regularly generated reports
- Etc,
Eventually, the large number of NST's and the Informal,unregulated protocol for interaction between NSw organizationsbecame a major burden to users of the NSW System. Consequently,a tool for monitoring STR's, called MONSTR was developed byMassachusetts Computer Associates for use by all NSW contractors,and (eventually) NSW users. NONSTR serves as a STH repositoryand implements a more rigid, table-driven protocol for themovement of STR's between NSW organizations on the road toresolution. besides implementinq the protoc9l for resolution ofSTR's, MONSTR provides a number of other facilities Including:
- Archiving of terminated STR's
- Generation of STR reports by STR attribute (e.g.* bySTR Identifier, priority, responsible organization.etc.)
- Etc.
To understand the role STR's play in the NSW systemdevelopment process, consider the following example (Figure 5-4):
1. An NSW user creates an STR, which reports a suspectedNSW software Problem to NSWOPS.
2. After reviewing the useris STR, NSWOPS decides thatthe problem is legitimate (i.e., neither usermisunderstanding nor error), but decides to requestadditional Information (e.,, a typescript) from theuser*
3. The NSW user responds by supplying NSWOPS with theinformation (typescript) requested.
4. NSwOPS assigns a priority for resolution of the STRand dispatches the STR to ACC. (Note: ror thisexample we shall assume that the problem Isinterfering dramatically with use of the NSW systemand that a high priority has been assigned to itsresolution).
5. ACC reviews the STR and dispatches It to theappropriate DMC for corrective action (Notes It moreInformation were required or the STh were notactually a software problem, It would be returned tohSWOPS),
62
6. The DMC selected bY ACC addresses the Problem bypreparing a new component version which Is deliveredto ACC tor integration and testing; the STR isreturned to ACC with an analysis of tne problem and adescription of the fix.
7. ACC integrates and tests the new component in a fullNSW system configuration. If the new componentproperly addresses the STR, it is passed on to NSWOPSalong with the STR (which includes a user-orienteddescription of the problem and no, it was rectified).Otherwise, the component is returned to theappropriate DMC for additional worK.
8. NSWUPS installs the component (POC may elect toperform O/A), notifies the user that the problem hasbeen corrected, and "terminates* the STR.
The above example describes the means by which a high Priorityproblem, substantially impacting use of the NSW system, would beresolved. Note, however, that STR's are normally addressed andintegrated into valor NSW system releases, shich are, from theuser's Point-of-view, spaced many months apart.
63
• - -.. .w i-n Y..7
4 x
4J4 -4
04-0
t.
41 0
$40
U) S.4 0 E- 0
C.))
0c 0
z. w 0.IG
-4 > 4 414 i EU OlC o 0 M - 14
4.1
Un M 1.4 0to 0 0$ 41
U' - Eu E-4CI0
., S4I- 4.0#al 044i4J'
1.44 0V 4 )
0 E4 1 : 0 41 4i
oj 4) 4ijf
(a 00 4) 04)
$4.e 0 c 4 9
64
-. * cn JK 3 -n W
5.6 Confiquration Management
Software configuration manaqevent (CM) Is a discipline forinstalling software changes which allows the evolution of asoftware system to be tracKed and controlled. By tracKInq andcontroltlnq software changes. CM becomes an integral part of aformalized systev software life cvcle Planning and developmentprocess. Such formal development discipline becomes extremelyimportant for projects with characteristics similar or identicalto those of NSWr namely:
- A larqe number of geographically distributedcontractors, who are
- worKing autonomously on a large number of constituentsoftware components, which must, ultimately, be
- Inteqrated Into a workable software product.
Software CM is an integral Part of the alan for developing,maintaining and operatiiig tne NSW system ("The NSW ManagementPlan" 12J) The NSW proltct hat. coXlectively been working toward aCM implementation coal since the beginning of the contract periodcovered by this report. GZ'Ga POC organization received amajority of the charter and tesponsibilltv for developinq NSWcontiquration manaqement procedures.
Software CM Is generally viewed as a continually evolvinq,three-step process:
1. Configuration identification
2. Configuration control
3. Configuration auditing
The CM approach adopted for the NSw project results from acollective effort on the part of both PVC and ACC. Withsuggestions and Input from ACC (Massachusetts ComputerAssociates), GSG has prepared a NNSW Software Management andControl Plan" (26) which deals with each of the above Cmactivities in detail. A brief characterization of each CMactivity as It pertains to the NSW system followsl
* CONFIGURATION IDENTIFICATION: This is the process ofidentifying the objects, called "Items" (e.g@. programs.data files, etc.) which are to be controlled. Eachitem, without a specific version, is called a *genericconfiguration item*. When a release is packaged, aspecific version Is Identified for each generic
65
configuration item to be Included with the release;items which include version identification are simplycalled "configuration Items' (Clls). PDC and ACC agreed(with concurrence from PG) that only malor, aggregateItems ot the NSw system would be Placed underconfiguration control. These aggreqate Items Include:
NSW software component executables
- NSW *tool* executables
- NSW system database skeletons
- Host-independent functional specifications
M User documentation
" Host-dependent component documentation
- Operator documentation
Note: This list of aggregate Items does not, forexample, Include the constituent source andobJect modules for each componentexecutable (see below),
Configuration management of source and object Modules foreach software component (see Section 4.4.1) has beendelegated to the DMC responsible for the componentimplementation. After a consensus had been recChed onconfiguratidn item granularity, POC developed amethodology for identifying, through hierarchicaldecomposition, the "generic configuration Items" for theNSW system. The decomposition consists of collections ofgeneric Cl's called "Packets". The approach taken was tofirst identify generic Cl's which applied to more thanone host family (i.e., the entire NSW system)# then toidentify generic Cl's which apply to more than onesoftware component, tool, etc of a host family (ise., tothe entire host family), then to Identify the CI'S whichapply to individual host family component implementationsand tools, respectively. The CI packets produced by thisdecomposition are:
1, NSW System Packet (Cl's which apply to multiplehost families)
2. TOPS-20 Host Family PaCKetr containing thefollowing subpackets
66
4A - WIIE0
a. Generic TOPS-20 packet (C10s which apply tomore than one TOPS-20 component of tool)
b. TOPS-20 component pacKet(s) (one tor eachTOPS-20 component implementation)
c. TOPS-20 tool packet(s) (one for each TOPS-26tool)
3. IBM Host Family Packet
a. Generic IBM packet
b. IBM component pacKet(s)
c. IBM tool pacKet(s)
4, Multics Host Family Packet
a. Generic Multics packet
b. multics component pacKet(s)
c. Multics tool packet(s)
5. Unix Host Family Packet
a. Generic Unix Packet
b. Unix component packet(s)
(Note: There are currently no Unix-oased NSw tools)
Because ot autonomous operational requirements,configuration management ot the IOM and Multics HostFamily packets (with the exceotion ot contlqurationauditing -- see below) have oeen delegated to DMC-CCN andDMC-HIS, respectively. Generic contiuration Items forboth the "NSW System" and "TOPS-20 Host Family" Packetsare enumerated In Appendix 8 of this report.
NS. organizational and contractor responslollity forcontLquration management of the above packets (asinstalled in the various NSw contituratlons used for NShSystem development) is summarized oelow:
- Debug Systems ACC (COMPASS)
- Development System: ACC (COMPASS)
67
V. a -. . _ _ -. .
Candidate System: PDC (GSG)
User System: NSNOPS (GSG)
* CONFIGURATION CONTROL: Once configuration Items havebeen identified and CM Procedures I*pleventedp a largepart of the fi1xed cost" associated with configurationmanagement is done. The following dtsciplLnes are themajor constituents used to control (incremental) NSWsoftware changes:
1. Autonomous Component Development: DMC's areresponsible for development and maintenance ofIndividual NSW software components. &CC Is largelyresponsible for directing DMC's to sake softwarechanges and upgrades. DOC's modify and deliver Isoftware components which reflect the changes
requested by ACC or suggested oy the DMC's. ACCcompletely controls integration of new componentversions into fully operable NSW systemconfigurations.
2. Autonomous NSW System Configuration: Associating aseparate NSW system configuration with each majorstage of the NSW system development process* anddelegating control for each configuration to asingle NSW organization (see Section 5.1) Providesthe mechanism for controlling c€anges to the NSWsystem during the NSW system development process.
3. Release Packaging: When preparing a system releasefor delivery t, PDC, ACC is required to make allsoftware changes known to PDC and NSWOPS. Softwarechanges directed by ACC usually take one of twoforms:
- A fully specified enhancement which must beimplemented by at least one DMC, or
An STR which documents a problem, deficiency orimprovement (STRes are accessible to NSWcontractors through MONSTR -- see Section 5.5)o
Because ACC controls the Integration process*It is likely that most NSW software changes arecommunicated to ACC by the DMC*S, which can Inturn be communicated to PDC prior to deliveryof a new release for 0/A,
However, because of autonomous and asyfchronouscomponent development practices, It Is possiblefor DMC's to make changes to components which
, 68
Il a i ll .n
are never Known by ACC. Since PDC/NSWOPS mustrely on ACC for a complete and accurate Pictureo0 the Incremental software changes whichcomprise any given release, we Should note thatthis approach to configuration management isnot foolproof. However, experience indicatesthe level of formality and control which hasbeen achieved is sufficient to assure smoothevolution of the NSW systel.
CONFIGURATION AUDITING: Configuration auditing is theProcess oV which information is obtained on the currentstate or Past history of an installed set of NSwconfiguration Items. One of the vost Liportant aspectsof configuration auditing is the ability to identifydifferences between any two sets of NSW configurationitems (e.g.* system or component releases). Suchprocedures are extremely important in the NSW contextbecause of IBM and Multics host family autonomy (seeSection b.1). For example, auditing allows ACC, PDC andNSWOPS to determine what cnanges (if any) nave been madeIn the sets of IBM or Multica host (family)configuration items (installed in tne NSW Development,Candidate or User system configurations) withoutmaintaining control over the set of Installed Cl's.Contiguration auditing procedures have been implementedand are regularly exercised in each NSW systemconfiguration (i.e.. the Development, Candidate and UserSystems).
69 "
5.7 NSW Release History
Version 3.1 of the NSW system was installed In the NSW UserSystem contiguration Just Prior to the contract period covered bythis report. Two (2) major and one (1) inccemental release(s)occurred during the past contract period. The salient featuresof each release are outlined below:
NSw Version 4.0: A malor NS5W system release addressinqseveral STRes and also including a few sianifIcantt butlargely operator-vigible (i.e., user-invisible)enhancements *
W Released to POC for 0/A: May 2, 1979
W Major Improvements:
Support for TOPS-20 version i1B1
First release of the Fault 6.ogger component
New ChecKpointer and TOPS-2a Foreman components
Improved operator interface
more robust Multics TBH
separate descriptors for each tool executable
. Package logs (component compiling/linkingprescriptions)
WSTRs$ Addressed: Unknown
-Testing Completed by POC: Auaust 14P 1979
WSTR fixes failing 0/A: UnKnown
W New STR's Identified: 3004 (action suggested byPDC on 128)
W Major (New) Problemss
Database integrity
0Improved component resilience (especiallyTOP3-20 MSG)
7,
.NW
IProtocol violations
Resource consumption
User interface anomalies
Released to Nsw Users: Never; upgraded to NSW 4,.
NSw Version 4.1: An Incremental uparade of NSW release
4,0, addressing many of the oroblems mentioned above under%S version 4.0.
- Released to PDC for /AS Septesber L, 1979
- Major improvevents:
Database Integrity oroolems resolved
" Component resilience (new TOPS-20 MSG andForeman, and 18M Foreman component(s))
Several protocol violations rectified
* Resource consumption (unnecessary componentinstances and activations) Improved
* User Interface (error messages, controlcharacters and connection handling)slqnificantly upgraded
- SrHs Addressed: 69
- Testing Completed by POC: September 28, 1979
- STw Fixes Failinq O/A: 9
- New STRs Identitied: 49 (most of these werescheduled to be addressed bV NSW version 5.3 -- seebelow)
Major (new) problems:
Heliability scenario failures
TOPS-20 MSG link allocation Problems
Local TOPS-20 MSG failures
71"
forcibly terminated components
Front End failures4
Node size limitations
Released to NSW users: October 5, 1979
NSW Version 5oJ: A maJor, no#, largely srR-directed NSWsystem relase also concentrating on release transition andconfiguration management procedures.
"PDC *Test Plan*: July 30, 1960
" Released to PDC for Q/A: July 31, 198a
SuportforTOP-20version 4; s~ore resilient
TOPS-20 MSG
New TOPS-2a Foreman covponent (wor~spacecreation, archiving and reliability scenarios)
User Intertace improvements (restored tools,Foreivan workspace and file delivery prompts)
Multics T8H more robust
fSTR's addressed: 65
G /A testing Completed oy PDC: August 29, 198d
W PDC RTest Summary": Septemoer 1).. 1994
W N5WOPS "Interactive Tool rest Suivarv*: November14, 1980
ft TR tiles failina 0/A: 8
ftMow STil's identified: 67
M Pajor (now) problems:
TOPS-20 MSG and Front End failures (m.ost ot theproblems In this area were dialnosed andcorrected before' release of NSW 5.3 to users)
72
K NOON
- Released to NSW users: October 20, 1980
73
6,0 NSW User Interface
In the tirst of two maJor sections which followe we Providdathe reader With a user-oriented overview of NSA functions andcapabilities. This first section sets trio stagie for the Secondsection which summiarizes and discusses:
-The current status of the NSW User System
-Progress (during the contract Period covered by this4report) In evolving the NSA Concept# and
-Future directions dictated by known requirements,deficiencies and problem areasj
74
1 I.
6.1 Overviee of NSw Capabilities
The NSw system operates in a networtingj environment and isanalogous, in its functions and Capabilities, to a single-hostoperating system. In Particular, NSW irrilevents a standardcommand interpretor, Providing NSW users with uniform access to:
- Friles resident in NSW's Sistributed file system
- Tools available on NSW hosts In the NSW system
contiguration.
In addition, NSO Incorporates a built-in Project managesentfacility Which provides project managers with a vehicle fordelegating responsibilities and Implementing Informal protocolsamong Project members. An overview of NSw's project managementcapabilities, tile systes, tools and command language are eachcovered by the individual subsections whiCfl follow*
75
4,44'~
6.1.1 Project Management
The project management facilities of NSW are an integralpart of its design. Each new NSW user Is assigned a "Prolect* , a"node* and a "password*, which must be supplied during the NSWauthentication sequence (l.e., 6OGIN). Thus, a user wlshlng touse NSW facilities first logs In to the assigned node of his/herProject. The user's login node establishes a context for theduration of tne his/her NSW session.
NSW projects are collections of nodes. Much like theorganizational structure of many companies, the nodes ot aproject form a hierarchy (also called a "project tree"). Eachnode must have a "supervisory" parent and say nave zero (0) ormore sons. we say that a given node was "created" by its parentand that a node (with the appropriate "rignt" - see below) mayact as a "supervisory" parent by creating sons of its own.(Note: since a node establishes the context for a user's NSWsession, the terms "node" and "user" may, at times, be usedinterchangeably). Nodes establish a context by aztlng asplace-holders for tool and file access "rights". Associated witheach node is:
- A list of tools which may be accessed (used) bY thatnode, and
- A list of file "Keys" controlling access to named(groups of) NSW files.
A node may receive rights from any "supervisory" parent inthe tree ot which the node is a direct descendent. A node maygive any of its rights to any of one or more of Its sons (ortheir sons, etc.).
NSW provides built-in Project management tools for:
- Manipulating (creating and deleting) nodes (orsub-trees) of the Project tree
- Assigning rights to and removing rights from a son node
E Examlning nodes of the project tree and their tool/fileaccess rights
These project management tools are governed by tool rights aswell. For example, a user (node) ,isnino to create a (new) sonnode must nave received rights for the "create node" tool from a"supervisory" parent.
7b
)rk
......... ...
To Illustrate NSW Project Management capabilities, considerthe following example. Initially, there Is one node (node NAN)In the Project tree (see Figure 6-1) witn:
Tool rights tors
- All NSW project management tools:
Create-node
Delete-node
Examine-node
Assign-rights
Remove-rights
- A small set of program development and documentationtools:
Teco ka text editor)
PL/l (load and o Compiler)
Runott (a text/document processor)
File rights:
A and B
(Note: A and B are called "Keys" to tne NSwnamespace for tiles. NSW filenames consist of anumber of "components" separated by Periods ('.").For example, *A.PR0J.TLqA" is an NSw tilename withseparate components. Tne "Keys" A and B may be usedto access any NSW tile whose name begins,respectively# witn the component A or the componentb. Tne notion of NSA tile rignts has oeenSimplified somewhat tor tnis example? for additionalinformation, Please reter to tne NSA Users'Reference manual" L27)).
Using the create-node tool, node A Ceeates nodes 8, C and D,then, using the assign-rights tool, gives each now node therights shown In Figure b-2. The rights Assigned oy node A allowsonly node 0 to create ne nodes (node D Can not, however, deleteson nodes). Also, nodes B and C have a %ore restricted set ofIlie rights (i.e., "view' of hSw filespace) than node D. Infact, node D can access any tile which nodes b or C can create oraccess, but because node D has the more general file right "A".It can also create or access tiles which nodes 8 and C can't
77
*~-' ~ *4
- __ - ; 4 imm-=----------------*,.mam--mm-i,
(e.g.. tiles beginning with AM.). Continuing with our example.node D creates three new son nodes (DA. DOB and DC) assigning eachthe rights shown In Figure 6-3. Atter surveying the prolect treewith the "examine node" tool (which can not be showndiagramatically here), node A implements the following prolectmanagement decisions:
- Node B will not be needed; node A uses the"delete-node" tool to delete node B (Figure 6-4)
- Node A notices that node D has been overzealous increating new son nodeu; node A uses the "removerights" tool to revoke the "create-noe tool rignttrom node D (Figure 6-5)
W Node DB needs temporary access to some NSW fileswhich begin with B.A. Node D cannot access tilesbeqinnino with Be so s/ne requests assistance fromnode A. Node A temporarily assigns tile right B.A tonode Db (see Figure 6-6), out not to node D whodoesn't need it.
In this example, we nave examined the NSW Project managementcapabilities tor:
- Creating and deleting son nodes, and
- Assigning and removing tool and file rights.
we have also tried to provide feeling tor the managerial actionsWhich may oe implemented by project directors and team Memberswho use tne NSW prolect management tools.
78
O rools: create-node, delete-nodef
assign-rights, remove-rights,
exam~ine-node,
teco, PL/I, runoff}
[File Rights: A,B
Project Node A and Tool/File Rights
Figure 6-1
79
fTools: create-node, delete-node,
assign-rights, remove-right
examine-node,
teco, PL/1, runoff
A File rights: A, BJ
I. , D
C
&Tools: nore} {Tools: teco, PL/Ij &Tools: create-node,
V~ile Rights: A.b} LFile Rights: A.CJ assign-rights
examine node
teco, runoff
File Rights: A
Node A Creates Nodes B, C, D and Assigns Tool/File Rights
t Figure 6-280
Tools: create-node, delete-node, assign-
rights, remove-rights, examine-node,
A teco, PL/I, runoffJ
File rights A, B
BI{Tools: none iTools: teco, PL/I
(File Rights: A..D {File Rig ts: A.CJ
D <Tools: create-node
assign-rights,
examine-node,/// teco, ruof,
tecoT oo ile Rights: A)_
teco, 4teco,Tools: none iTools: runoff,1 jTools: runoff,)
File Rights: A.D.A)(File Rights: AD.B) File Rights: AD. CJ
Node D Creates Nodes DA, DB, DC and Assigns Tool/File Rights.
Figure 6-3
81
* ~ ~~ ---
A tTools: create-node, delete-node,
assign-rights, remove-rights,
examine-node, teco, PL/I, runoff)
File Rights: A, j
Tools: create-node,
Q - assign-rights,Tools: tCo, PL/I) examine-node,
File Rights: A.Cj teco, runoff)
(File Rights: A)
DA B
Tools: nonej {Tools: teco,runoff) I Tools, teco, runoff 5
LFile Rights: A.D.A 4 {File Rights: A,D,Bj tFile Rights: A.D.C
Node A Deletes Node B
Figure 6-4
82
• a! !i
A iToOls: create-node, delete-node,
- - assign-rights, remove-right,
examine-node, teco, PL/I, runofff l File Rights A, B !
-Tools: assign-rights,OC D
'Tools: teco, PL/I ." examine-node,
'File Rights: A.C runoff-'
/ File Rights: Alt
9 D teco, teco,LTools: nones ZTools: runoff! kTools: runoff j
j'ile Rights: A.D.A3 (File Rights: A.D.Bj IFile Rights: A.D.C)
Node A Revokes Node D's "Create-Node" Right
Figure 6-5
83
•~~~~~~~~~~~~~~ f--7. L5 -,, = . :.. %, -
A fTools: create-node, delete-node,
assign-rights, remove-right,
examine node, teco, PL/I, runoffj1lFile Rights: A, BJ
C D -Tools: assign-rights,
jTo~ls: teco, PL/I xamine--node, teco,
(File Righ. A.CJ runoff j
~File Rights: A3j
DB D4Tools: nonej fTools: teco, runoff: ."Tools: teco, runoff"
[File Right3: A.D.AjI/iFile Rights: A.D.B, -IA (File Rights: A.D.CJ
Node A Assigns File Right B.A to Ncd*c DB, But Not to Node D
Figure 6-6
84
T 19
6.1.2 The NSW File System
The NSW operating system provides its users with a uniformand coherent vie, of the NSW tile system. The NSP tile system isdistributeo across the set of network hosts participating in theNSW system configuration (i.e., those NSW Mosts participating asFile Bearing Hosts -- see Section 4.4.4); hosts Participating Inthe NSW file system provide support for:
- Movement ot tiles between unativeN host file systems
and NSW filespace
- Storage of, and access to tiles in NSW tilespace jMovement of files between NSW hosts (as necessary)
- Data translation durinq movement of a tile from one NtShost to another (as necessary)
In the name ot uniformity and coherence, NSW tries to makeas many aspects of tile access, movement and translationtransparent to tne NSw user.
The tollowlng example Illustrates the tile system functionslisted above, Includino the level of transparency achieved by theNSW system. For the purposes of this example, an NSO file named"A" (containing text) is stored on the UCLA-CCh NSW host. An hNSuser would like to create a copy of NS* tile A in local directory<B> on the HADC-20 NSw host under the name "A.TXT". (Tie act ofcopying a tile from NSW filespace into tie "native" host filesystem is called "exportinq a tile from NSw filespace".) NSWprovides a user command for "exporting" files, ,oich requiresonly that the user designate the name of the NSW tile to beexported, and where in the "native" file system It is to beplaced (i.e.# name, directory, Password, etc.). To the NSW user,the file export Is a single command, for wnich a positive ornegative acknowledgement is received*. However, to complete theexport operation, the underlying NSW macninery must proceed asfollows (see Figure b-7):
1. Move file A from the NSW tilespace on UCLA-CCN NSwnost to the NSW filespace on the RADC-2a NSW host.
2. Translate the tile as it is moved from UCLA-CCN toHADC-20 (tile translation Is required becauseUCLoA-CCN and RADC-20 beloni to two very different(i.e., incompatible) host families). As a minimum,character conversion (from FBCDIC to ASCII) isrequired.
95
0|'
3. Place a copy of the translated file in RADC*2Jdirectory <B>) under the name OA~rXT".
4. Notify the NSW user that the export operation hasbeen successfully completed,
Note that all of the Lie "motion" and translation activityremains invisible to the NSw user,
86
rimi
0000 f4 t0
c~. 0'U U)
CF)
87I
6.1.3 NSW Tools
The NSW operating system Provides support for tour (4)different tool types; each of these May be characterized brietlyas follows:
1. Management Tools: These tools are tightly coupled toand deeoly imbedded In the NSW software; they areused to manipulate sPecial NSW project managemententities called "nodes' and "rights" (see Section6.1.1) L281.
2. N54 Tools: These tools are Implemented using specialNSW operating system primitives specifically designedto support the construction of "NSW tools*. NO toolsof this type presently exist, See the 'NSW Toolbuilder's Guide" (29) for a discussion of the NSWPrimitives available to tool builders.
3. Batch Tools: These tools are characterized by"staged" execution. That is, the user must supplyall parameterso Includinq input/output filenames, Jobcontrol parameters, etc prior to tool execution;these tools are not user-interactive except duringthe period that runtime Parameters are collected. Alob number is assigned to each batch tool executionsthe user may query the status of a job andautomatically receives notification wnen the Job hasbeen cotoleted (or terminated).
4. Interactive Tools: These tools are characterized bYdirect user contact and interaction during execution.They differ from Management and NSW tools In thatthey are neither imbedded In the NSw software normake use of special NSW operating system primitives.Most interactive tools are copies of tools which havebeen built for and are regularly used in the *native"host (family) environment. Using a technique called*encapsulation", these "native" tools are regularlyInstalled in the NSW system without modification."Encapsulation" Is the technique used to mediate allInteractions between the tool ana Its executionenvironment (i.e.* operating system calls); thisIncludes (re)directing file references to either theNSW system or the 'native" host ooerating system.Each interactive tool instance Is executed In anassigned area called a "workspace"; the user modelfor Interactive tools is comPlicated somewhat by theuse of worKspaces for tool execution (see the examplebelow). Read operations cause NSW files to be moved
v 88$____ 1
into the worksPace for the duration ot the toolsession; new files or versions (of existing NSwfiles) are also Placed in the workspace during toolexecution. Upon termination of the tool session, theuser may elect to "deliver" new and/or uodified filesfrom the worKspace into NSw filespace.
To illustrate, consider tne manner in which the interactiveeditor XED (available on many TOPS-26 hosts, Including theRADC-26) is used to modify NSO tile "A" stored in hS* tilespaceat UCLA-CCN:
1. The NSW user invokes the XED tool.
2. NSW assigns a worKspace for the XED tool instance,starts execution of XED in the assigned worKspace,and places the NSW user in contact witn the XEDinstance (Figure 6-8).
3. The NSP user reads file A from NSW filespace (Figureb-9); it is translated and moved from UCLA-CCN toRAUC-20, then into tne assigned workspace, andaccessed by XED.
4. The NSw user modifies file A, creatin4 tile b storedin the worKspace (Fiqure b-1a).
5. The NbW user reads file A from tne worKspace, thenmodifies and creates a new version of tile A (A isused to distinguish between the original version oftile A and the new workspace version) in theworKspace (Figure b-li).
b. The NSw user terminates his/her XED session (i.e.,quits XED) and confirms delivery of tne Toditiedversion of tile A (A) and new tile 6 into NS$tliespace. Note: Because a nea version of tile AA° ) was delivered into NS* filespace, file A is no
longer stored at UCLA, but rather in the RADC-20portion of NSW filespace where it was delivered(Figure b-12).
7. NSW deallocates the worKspace assigned to the XEDinstance.
89
4O
CD
904
".4
41
C','
1-0)
z to
0 4n
911
4
'I
h.O.
92
oCOk
A 0i00
-4
WTI,
Q I......
I / S
U9
6.1.4 NSW Command Lhanguage
NSN provides a number of user commands* These Can becategorized and summarized as follows:
1, User Session Management:
Chanoe password
W Terminate user session (looout)
2. NSW File Manipulation
Move tile(s) between "native" host file system(s)and NSW tilespace
*Copy, delete and rename NSW files
6 ock (set a semaphore on) an NSW file
Chanae specificity (the "scope") of file Keyreterences
3. TEool Session Management:
I nstantiate (request use of) a tool Instance
Abort an active tool session
-Resusie an Interrupted (eeg., due to host crash)tool session
4. information and Status Query:
-Inquire about the status of a batch lob
-Display node attributes (e~.,# sons and rights) Otthe user's login node
6 ist names ot files (which may be accessed by thenode)
61Lst tile key "scopesm (see ONSW File Manipulation*commands above)
6,2 Current mSW User System Status (may 1931)
The subsectionls which follow summarize the evolution,progress (both user-visible and user-invisible) and currentStatus Of the NSW system for the period covered by this report.
The NSW software system has Improved dramatically in thelast two years, much of the progress Is of a form which Is notdirectly user-visible (Primarily because so many NSW services aretransparent to users). At the same time# the Progress Is sosubstantial trwt the absence of this proqress vould mean an NSWsystem for which NSW users would most definitely discern ('feel")a difference, During the contract Periol covered by this report,the NS* system has:
1. become easier to operate
2e Embodied greater economy of concept (and has becomeeasier to use)
3. Reduced resource consumption dramatically
4. Improvel In performuance and user responsiveness
5. ACnieved more reliable and robust operation
96
6.2.1 NSW Command Lanquage Status
The NSh user interface (including the NSW command languageand its Interpretation) is largely Implemented by the Front Endcoaponent (and Its interactions with other NSW components suchas the WorKs Manager). Perhaps the most significant achievementin this area has been the addition of a new (alternative)Unix-based Front End component. The Unix Front End Implements asomewhat richer user Interface and command set (including, forexample, "immediate command return mode* which allows NSW usersto initiate multiole, concurrently executing NSW commands -- seeSection b.1.4). However, the syntax for NSW commands lplementedby the Unix Front End differs visibly from that which was adoptedfor the TOPS-20 Front End. Plans nave been made for Installinothe Unix Front End on the AFLC *base system" configurations(PDP-11's runninq Unix) for the AFIC Technology Demonstration.This new component has not yet been released for O/A or Installedin the NSW User System configuration.
No new commands or user capabilities of the Kind mentionedabove (e.q.. "Immediate command return mode*) nave beenIncorporated into the TOPS-20 Front End implementation. Thecommand Language Implemented corresponds to the commands listedIn Section b.1.4. To provide the NSw user with the best userinterface possible, significant TOPS-20 Front End modificationswere made. These modifications addressed the following userconcerns:
- Component reliability*
- Tool connection management#
- Error reporting, and
- Consolidation of user interface (includlng controlcharacter functionality, consistent prompting, commandconsolidation, etc.).
.97
6.292 NSW File System
Improvements in the NSW file system largely depend Upon theevolution of the varlouS host family lmpleaentations o the rilePacKaqe component. Progress In this area can be summarized asfollows:
1. A new, more efficient Implementation of the TOPS-20File PacKage component was introduced.
2. The IBM and multics rile PacKaqe implementatlonsbecame sore dependable and reliable*
3. The following new file types (by host gamily) wereIncorporated Into the corresponding host familyimplementations of the rile Pactage:
TOPS-20 (2):
- iaX-TEXT
W IOX-SOSTXT
IBM ( )I
- 360-ASM-OBJ
- 360-MACR29-OBJ
- 360-COBOL-SEQ-SOURCE
- 360-ASM-SOURCE
- 360-PLMBO-OBJ
- 36-PLBO-SOURCE
- 360-OVEPRINT
- 360-ASMaO-SOURCE
Multics (2):
" MTX-TEXT
* MTXoLIBRARY
99
iVm mm -- •m --- m -- mmm- -m
Unix:
*$ none **
(Note: A Unix host family imPlementationof the File PacKaoe component does notpresently exist.)
4. NSW file transformations nave been cosprehensivelytested and malor problem areas identified
5. Protocol modifications nave been deslnel to ivDroveuser reliability, user error reporting, andperformance
Presently, the best (if not the only reasonaole) %easure ofNS* file system status is the nulber of file tves supoorted bVeach host family (see Table 6-1).
'IS
99i
4;
1 _4'
-TOPS-29 (3):
m IOX-SINARY
w IOX-TEXT
l 1X.SOSTEXT
- Rultics (2):
- MTX-TEXT
m DTX-LIBRARY
- IBM (33):
-36-TEXT
-360-ORIGINAL.BIN
-360-.NACRO20-SOURCE
360-ASM-OBJI
3bd-BINARY
-360r-MAC9020-08J
-3bO8OJECT
-3bO-COBOL-SECJ-SOURCE
3b@-COBOL-SOURCE
-360-ASM-SOURCE
ft 360-PLI-CC-SOURCE
m 369-PLICC-CARDS
Table 6-1
NSW File Types bY HOSt FaMILY
its-
Table 6-i (continued)
- 360-Pbl-CARDSI
- 360-JCL
- 360-ORIGINAL~
- 3bw-PL'480-OBJ
- 360uCI4S2M-OBJ
- 36&i-ovERPRLNrf
m 3bd-SPPCOOL.-SOURCE
- 3bk~-PLMOO-SOURCE
- 3bW-P~LISOURCE
-3bW-CmS2M-SOURCE
- 36-ASMSBOSOURCE
- 360-LOAD
w 36k,-FORTRAN-SOURCE
- 360-CARDS
w 366-LIST
- 360d-PRINT
m 36KEYPUNCH
Uinix:
4* not applicable *
Table b-I
NS% File Types by Host Familv
191
b.2.3 NSW Tools
Significant orooress has been achieved in establishing toolmanagement Procedures and improving the level of tool supportprovided by the NSW system.
The NSW Tool Manager has been largely responsible forprocedural advancements. The Tool Manager has Prepared a "ToolQuality Management and Control Plan" 1301 and a "ToolInstallation Guide" (311, which to~etfler adress the followingtool-related issues:
-iTool) selectionf
-Acceptance
-Installation and maintenance
-Configuration management
-New tool developmient
-Administration and legal oroblema
Improvementi in the level of tool suoport provided by theNSW system are Much lKe file system Improvements (see section i
te292J largely determined by evolution of the various host familyImplementations of thne Foreman and Batch Job Packcage componentst
TOPS-20 (Foreman)
ft Support for allocation and archiving of toolsessions
- Improved tool session management, including userprompts for worKspace file access
fSimplification of operator interface
W Improved reliability mechanisms
W Proposed Protocol modifications to Improveperformance
Multics (Foreman)
102
It.A
WI.-
- More reliable and resilient imolementation
- support for aborting and rerunning tool sessionsj
- support required for the NSW reliability scenarios
- Improved user interface and workspace management
- Support for Program execution
IBM (Foreivan, and Batch Job PaCKaqe)
- Improved operator support for batch lobs
- Full Interactive tool support (eXClUdinq NSW
reliability scenarios)IA measure of tool support status (and Progress as well) mav
be gleaned by:
W Identifying the new tools installed In the NSW systemduring the contract period covered by this report(Table b-2)
- Summarizing the number of tools installed on each hostby *NSW* tool type as defined in Section 6.1.3 (Tableb-3)
W Ltemizino NSW tools by name and User System Most (Table46-4) 132J
- ItemizinQ NSW tools by "c;eneric* tool type and UserSystem hiost (Table 6-5)033)
103
A T RiJ W:
TOPS-20~ (5):
CO NCONU.)A N CI
F MTBCP LPSAVESRCCUM
IBM (24):
A5MCOMPASMLINKCOBOLCUMPHESSCRE~A £ ICCHLATE.L
CREATEPOISPLAYFOR TCOM PFORc1LINKGETC
GL~TPLIBMVAINTMIERGELlbPLICOMPPLILiN(PLMSOPUTCPUTOPU TPTSOLDIT
MUIJTICS (5):
AL)AADA-LSTATPD LRUNHUN-ADA
rable 6-2
New NSW Tool by HoSt Family
104
q,.
Manaqement NSW Batch Interactive Total
ISIE 5 a d 20 25
ISIC a S a 21 21
RADC-2 16 lb
CCN a 3 2 32
RADC-MULTICS ( 6 5 13 13
TOTAL, 0 36 72 107
Table 6-3
Number ot NSW Tools by User System Host and ONSWO Tool Tvpe
l
. $
- -- ---.
GENERIC - HOST SPECIFIC ---
NAME: SUFF'IX
USC- USC- RADC- RADC- UCL6A-151E ISIC 2a muLaics CCN
ADA -RMAuA-LSTAT -14M(liorary-status)ALjM wRMYA81480 -UC 41ASMCOMP -UC *ASALINK -UC 4ASSIGNHIGHTS (none)tIASIC -RMBCPL -1E -IC -R2SODT -IC I1C -R2CMS2MI -UC *CoBOL -uC *CUMPRESS -UC 41CONCORDANCE -XECRLATEC -uc *CREATEL -C *CkLArENOIE (none)CRLATEO -UC *CI4EATEP -UC 41DEL.ETh:NODE (none)DESCRIBE -IE WIC WDISPLAY -UC
VMLOAD -1CEXAMINENODE (none)FMIBCPLI -XEFORTCOMP -UC *FO RT LI NK -tiC *FUR IRAN hR -UC *0FTP -IC -IC -R2GIETC -UC
reble 6-4
NSw Tools by Namie and User svste* HostIhote: batch tools are markeS withi an asterisK (0*0)3
Table b-4 (continued)zGENERIC HOST SPECIFIC --- -
NAME SUFFIX
USC- USC- RAOC- RADC- UCGA-ISIE ISIC 20 MUbTICS CCN
GIETO -UCGLTP -UCH4kLLP -RNH08TAT 1I -C wR2IUDT -1C -IC -R2JIGSAW -Ii: -IC wR261&8MAINT -UCAiNKER WIE -IC -R2MACRO -IE -IC RMACR020 -IC -UCMERGEblb 'UCMRUNOFF 'IE 1IC -RNI.TSTAT -lE -IC -R2
PI)LI-RNPL 1 RMPL.1 -UCP1,II3GO -UC *PLICOMP -UC *PLILINK -UC *PLI480 -UCPRIM -ICPSAVE -Ii:PUTC -UC *PUTO -IUc $PUT P MUC 0QLDX -RNHIMOVER1GHTS (none)
Table b-4
NSW Tools bV Name and User System Host(Note: batch tools are marked with an asterisk (0*0)1
I10
Table b-4 (continued):GENERIC - * HOST SPECIFIC - --
NAME SUirIX
RUN -RMRUN-ADA -RMRUNOFF -RNSMITE -RNSOS -IE -IC -R2
1 . I -IC -R2 -UcS8SPELL -lE -IC wR2-RTECO. -IE -IC 2TSOEDIT -UCUVK29 -IC
Table 6-4
NSW Tools by Name and User System Host
CNote: batch tools are marked with an asterisk (0*0)J
to
rYPE or GENE;RIC HOST SPECIFICTOOL NAME SUFFIX
USC- USC- RADC- RADC- UCLA1-ISIE ISIC 20 MULTICS Cch
ASSEMBLER:ALA -RMASMCOMP -UC
CMIE: MACRO -LE -IC -R2
AUA -RNBASIC -RMbCPL -II -IC -R2COBOL -UC.roRTCOMP -Uc*FOR TR AN -RNM -UC*PL 1 -NMP161 -UC*PLIBGO -UCPbLCOMP -UCSMITE -RMSPPCO006 -UC
CRO SS ASSEN86ER:ASM80 -UC*MACRDO2D -IC -UC
CROSS COMPILER:C1452M -UC *PLIM as -UC *
DEBUGGER:BOOT -IE -IC -R2LOUT -IC -IC -R2
Table b-5
WSW Tools by Generic Tool TYD* and User System Most(Note: Batch tools are marKed with an asterisk (0*0)
Table b-h (continuel)tTYPE OF GENERIC - HOST SPECIFIC -
TOOL, mAMF SUFFIX
EDITOR: lED X -RN
SOS *IE -IC -R2Tk.CO *IE -IC aR2TSUED1T -UCXID 1IE IC fR2
EXECUTION SUPPORTRUN RRUN-ADA -RNi
FIICE UTIITY:DISPLAY -UCFTP ftC _IC 2SI4CCOM ftIC -IC -R2
INTERPRETER:
PL.I BGO UC
.jIBRARY UTILITY:ADA -[STAT -RMCOMPRE.SS -UCCREATEC -UCCREATEL -UC *CREIAMh -UC *CREATEP -UC *GETC _UC *GErO -Uc. *GCTP _UC *616MAINT - UCMERGELIB _UC *PUIC -UC 9PUTO -uc *PUTP -UC 9
Table 6-5NSW Tools by Generic Tool TYPO and User System HostIhott: Batch Tools are marKed aith an asterisk (0*0)
Table b-b (Continued)tTYPE UF GEhNERIC . . . HOST SPECIFIC -
TOOL, NAME SUFFIX
LItNKI~R: SLN U
ASMTLINK -UC *
LlNMIR -XE WIC -R2PLILINK -UC *
NSw MANAGEMENT:ASSIGNRIGHTS (none)CREATENODE (none)DELETENODE (none)LXAMINENODE (none)REMOVEI4IGHrS (none)
PRIM EMULATOR:LMLDAU -IJIGSAW WXE ftic -R2PRIM -ticU1059 -ICUYK(20 -IC
PROGRAMMING AID):C014CORDANCL -XEf'MTBCPL -XEPUL -RMPSAVE -IE
p SPELLING CORRECTOR:SPELL -XE -tIC &R2 -RM
Table 6-5
IN5w Tools bv *Generic* rool Type and User System Host
Table 6-5 (continued)
TYPE or GENERIC - - - HOST SPEIFic - --TOtO NAME SUrrix
SYSTEM INro:DESCRIBE -It aIC -R2HEL6P -RMIIOSTAT MIE -IC -R2INETSTAT -It -IC -R2
TEXT PROCESSOR:oRuNorr -1E WIC aR2
Table 6-S
NSW Tools by "Generic" Tool Type and user SyStem Host
(Nott: Batch tools are marKed with an asteriSK (#w))
Ila
6.2.4 User Documentation
At different times in the prolect's history, various NSWuser oriented documents have been Prepared. Tmese Include:
- "The NSW Users' Reference Manual* (35]
- "The NSw Users' Guide" 0361o
- "Interim NSW Managers' Tools' (371
* The NSw Beginners' Guide" [38)
Currently, the only document that Is maintained updated Is theQNSW user's Reterence Manual". GSG updates this document foreach new system release. GSG was also tasked with preparation ofan ONSk. User Impact Bulletin" for each NSw systes release.
The "NSW User Impact Bulletin" [381 augments the ONSP Users'Reference Manual". The Bulletin was designed to oe a highlymodular compendium of notes:
identifying all user visible changes associated with anew system release. These changes can take many forms,includini new or changed command functionality,elimination at bugs found In earlier releases, improvederror messages, and new tools. implementation or nostfacilities.
- identitying all known user issues and limitations thatexist In the current release, and suggesting how torespond to each.
- augmenting existing NSW user documents as needed. Forexample, the UlB attempts to clarify, expand, andprovide additional bacKground on user features that maybe misunderstood or are counter-intuitive In theirapplication.
supplementing the NSw user documentation by supplyingInformation not otherwise avallaole. For example, theU1B comprises the only uniform documentation ofoperational differences between tools In the NSwenvironment and their behavior In the native hostenvironment (with the Possible exception of UCLA tooldocumentation -- sO* below).
Items which tall Into the above categories are typicallypresented as Incremental updates relative to tne last WSW systemrelease. Such items are generally removed from the *User Impact
113
BulletinO within the next two NSW system releases. However, someItems remain In the mUser Impact Bulletinm until they areincorporated Into more suitable user documentation (e.g., the"NSW Users' Reference Manual"). with the above requirements inmind, the "User Impact Bulletin" was designed so that incrementalmodifications Could be made easily and quickly.
"User Impact bulletins" have been prepared and distributedfor NSW releases 4.1 and 5.8 139,441. In addition, a "special"version of the "User Impact Bulletin" for NSW 4.1 (411,containing only those Items to be considered as candidates forInclusion in the NSW Users" Reference Manual", was Prepared forACC. Preparation and distribution of updates to the NSW 4.1'User Impact bulletin" (42J was testimony to viability ot theplan for quicK, incremental modification ot the 'User ImpactBulletin. After the "User Impact Bulletin" for NSW 4.1 had beencompleted, a plan for maintainina the *User Impact Bulletin" wasprepared and distributed to interested parties E431,
During development of the *User Impact Bulletln", GSGconducted a review of the existinq NSW user documentation (44).Based In part on this review, user documentation requiements wereidentified and documented. These requirements were then comparedto the current state of NSW user documentation, and specifictasks were proposed to address known deficiencies (45].
In tne separate area of NSW tool documentation (describinooperability of Individual tools ohich have been Installed in theNSW environment), UCLA nas provided documentation for tnefollowing IBM tools installed in NSW.
- "Usinq The UCbA Native banquaqe Processing Tool
its* (4b1
- "Using The DISPLAY ToOL" (471
- "Using The TSOEDIT Tool" E481
- "Using the UCLA PL/l 1ool Kit" L491
- "using The UCLA Interim Librarv Management ToolKit" 1501
114
71-Km m m m ~ lm I Il
b.2.5 Future Directions and Problem Areas
Probably the most ilportant development planning thatoccurred ourinq the contract Period covered by this report hasbeen:
- Formulation of the functional and performanceattributes required tor the AFLC TechnologyDemonstration,
- Recognition of NSW structural, performance and featuredeticiencies relative to Demonstration needs, and
- Preparation of a development plan for addressingTechnoloqy Demonstration support.
During the latter half of the contract period, an NSW AnalysisGroup (chaired bv Bob Thomas of BBN) was created. This internalgroup was assigned the following tasks:
- Identify NSw requirements (for the AFLC TechnologyDemonstration)
M Prepare a functional specification hlich conforms tothe identified requirements
- Develop an evolution plan for realizing the specifiedNSW functions
based on inout from NSW users and contractors, the AnalysisGroup identified and documented NSW requirements In a documentreferred to as the "NSW Concept Paper" 1511. GSG also proposedrequirements 1521 and reviewed the requiresents distributed bythe NSW Analysis Group (533. Subsequently, the Analysis Groupprepared a revised NSW Functional Specification (541. This Planwill serve as a quidelLne for NSW development activities durinathe Technology Demonstration period. A summary of NSW systemareas liKely to receive attention, and examples of Proposedimprovements follow:
- User Interface
User 1/0 commands (e.g., display contents of a fileon the user's terminal)
. User Information and status reporting commands (e.s..system status, file attributes, etc,.)
115
.~ .4--,Wt
" Improved error reporting (eog., report abnormalconditions to the NSW Fault Loqier)
-Simplified User model
* Single, unitorm namespace for tiles and tools(executable Programs)
-Tool Support
" Tool chaining (egg., compile. then linK, then loadand execute by invokinq one rather than three tools)
User "owned" worKSPaCeS
F ile System
User *owned" segments of N filespace
Improved file translation and typing
Additional tile access Method$ (e.g., direct access)
Reliable transfer of long files
40 Performance
Optimiized file motion and access Protocols
" siupport for *native" services (ise., tools andservers NfliCh operate in Port moutsidew of NSW, inthe Onative" host environment)
116f
x,4 ai M.
I,
6.2.6 NSW Availability
NSW System Operations (NSWOPS) Is responsiole for operatina
the NSW user System configuration on behalf of tne NSW usercommunity. A goal of GSG's NSW operations group has been toachieve maximum NSW availability during operator attended Periods(9 AM - 5 PM EST, Monday - Fridav). This means tnat NS svstemdowntime should correlate as closely as possible to the durationof NSw host outages (especially the "Core System' Host - seeSection 4.4.3).
To provide a measure of service provided oy NSvOPS to theNSO user community, aoqreqate statistics ot NSa availaoilitv forthe period Uctober 8, 1979 through Novemoer 10, 1981 aresummarized below:
file Period
Operator OperatorAttended Attended and
only Unattended
(M-F, 9-5) (P-F, All Day)
Average weeKly Uowntime
(nours& minutes) 3:38 44:02
NSW Availability (1) 91% 74%
Tne above figures are saved on "Core System" availabilitystatistics accumulated since October of 1979. (Note: NSK cancontinue to operate in tne tace ot some non-'Core System" hostoutaqes; however, the NSw system remains completely unavailableto users during OCore System" Host outaqes.)
117
, m i ll m l • • m u -
7.0 NSW System Operations
During 1978, an NSw Operations Office (NSWOPS) wasestablished at the Rome Air Development.Center, Grittiss AirForce Base, Rome, New York. Since that time, on-site GSG staffmembers have been expandinq and evolving the NSW OperationsCenter wh~ich is responsible for the NSw User System. NSWOPStasks and responsibilities are reviewed in the first sectionwhich follows. The second section discusses NSwOPS activitiesand contributions durinq the contract report covered by thisperiod.
Its
7.1 NSWOPS Responsibilities
The malor responsibilities of the NSW Operations aresummarized below:
1. Install and operate NSw system releases in the NSWUser System contiquration
2. Uevise and automate operational Procedures; aoPlvthese tautomated) procedures to the NSo User andCandidate Svstem configurations.
3. Provide technical support to the NSW user comqunityoassurin4 expeditious resolution of all user questionsand problems; develop an accounting system fortracKinq all user inquiries and Software Troublekeports (STR's).
4. Provide user information services including an NSW
HlLP facility and usage reporting for the NSNooeratlons datsoase.
5. Prepare NSw user documentation including a "UserImpact bulletin" summarizing pertinent informationtor use ot the NSW system and its tools# including:inprovevents, outstandino ougs, Ijiltations,anomolies and procedures for dealinq with and/orcircumventing these.
6. Implement configuration control and auditingProcedures In the NSW User System confliuration.Maintain the NSW Uocumentation Repository, placinQNSW documentation under configuration control
7. Support PDC Guality Assurance (J/A) activities byoperating tne NSW Candidate Systes and participatingin Q/A testinQ under PDC's direction.
A more detailed Jiscussion of NSwOPS activities and achievementsmay be tound in the Section (7.2) which follows.
t19
iN
T71
7.2 NSWOPS Activities and Accomplishments
The malor accomplishments and Contrioutions ot the NSWOperations Organlzatlon (NSWOPS), in each malor area ofresponsibility (see Section 7.1) are summarized below:
1. User System Operations
This task primarily concerns the application ot(automated) operational procedures (see 2 below) tooperation ot the NSW User System configuration.
Due to autonomous operational requirements of the IBMand Multics hosts, the scope of NSWOPS operationalactivities is limited to the set of TOPS-20 ARPANEThosts Participatinq in the User System configuration.Tthe IBM and Multics hosts operate primarily in an"autostart" model little if any operator interventionIs ever required (except, possibly to track-downbugs).
The set of Participating TOPS-20 hosts must, ofnecessity, Include the *Core System" Most. Most ofthe operational requirements imposed by the NSWsystem are focused on this "Core System' host, wherecontrol and synchronization are centralized and thecritical system databases (user, tile and toolcatalogs) are maintained.
NSWOPS strives to achieve maximum system availabilityfor the NSW user community. NSWOPS has been verysuccessful in mtotinq this self-imposed goa1 (seeSection 6.2.6 for details).
2. NSw Operations Procedures
NSWOPS is tasKed with development of Manual andautomated Procedures for operating NSW systemconfigurations. Due to the nature of the operatorinterface, procedures far operating NSW systems tendto be many, varied and complex. In spite of this*much has been achieved during the contract Period Inthe areas of Procedure development and automation.
NSW operators must, minimally, be concerned withProcedures for:
129"4[
- Installing new NSW system releases, and
- operating Installed releases
Development and documentation ot a "Kernel* set ofoperations procedures for release installation andoperation, a significant undertaKing, was completedduring the contract period covered by this report (55).In additions the followLnq procedures were partially orcompletely automated:
- Installation of new NSW system releases
- Recognition ot:
NSW failures
NSW ARPANET host outages
Restoration of host service
- Operator notification Of host failures andrestarts
- Host clean-up and restart
3. User Support and Technical Assistance
NSWOPS is logically (and has officially beendesignated) the Local point for resolution of userquestions and problems. In support of thisresponsibility, NSWOPS was tasked with thedevelopment of a Software Trouble Report accountinQsystem which could be used to track outstanding userquestions, bug reports and new feature requests (aswell as contractor-reported bugs and deficiencies).GSG desiqned and implemented a highly parametric andtlexible accounting system based on the existLnoARPANET mail facility. However, after:
- Considerable experience had been gained with themail-based system, and
- Volume had increased dramatically, and
- Requirements for controlled interaction betweenNSW users became apparent.
A protocol-oriented tool for MONitoring SIR's (MONSTR)was conceived, designed and Implemented byMassacnusetts Computer Assoclates (COMPASS). For moreon STR processing, see Section 5.5.
121
Rival I
4. user Information Services
NSWOPS serves as a conscientious, accurate source ofinformation about NSW system features status and use.NSWOPS has been responsible tor developing a numberof vehicles for communicating Information to NSWusers:
- Periodic usage reporting
W Automated status reporting
- An Integrated# user-oriented Information utility(HIELP facility)
M The *NSIU User Impact Bulletin" (see 5 below orSection 6.2.4)
"At the beginning of each weeK, NSWOPS prepares#Publishes and distributes a report detailingavailability and utilization of the NSw User System forthe preceeding weeK. A sample "NeeKLY Usage Report"appears in Appendix D,
System status reporting is an inteiral part ot theautomated host failure and restart recognition Process(see 2 aoove). Users may guery cuzrrent system statusinformation (maintained by this automated operatorUtility) through a special TOPS-2a command at RADC-20or the NSW HELP facility (see below),
NSWOPS was tasked with development of an NSik HELPfacility for the NSW user community* First, aspecification detailing:
M Information requirevents
M Functional requirements
- User interface
* was Prepared for review 1561. At this stage it becameapparent that ambitious re~ulremuents could be realizedthrough a faclity, of great generality and Power.which could also be conStruCtkd at a very reasonablecost. The Product of this effort Is a nioh-qualitY,Integrated Information Utility which:
-Provides a uniform interfacea to wile variety ofInformation
122
Allows Information to be added or exchangedwithout moditvin software
- Provides an easily extended topical Index, and
- Is user-oriented and friendly
This tacLiLtY, available as an WSW tool, Provides NSWusers with on-line, Interactive access to the followinqinformation:
- mNS* User Impact Bulletin"
- ONS* Users' Reference Manual"
- "lnterim NSW Manaqers' Tools*
- ONSw Documentation Summary*
- DESCRIBE Tool databases
- HELP-HM tool databases
- Current NSW system status (as described above)
In addition, the HELP Facility provides a netmailconduit between NS users and NSwOPS. It has beenprovided so that NSW users may send writtencommunications to NSWOPS from within NSw. Among otherthinqs, this provides NSW users oitn a mechanism,internal to NSw, tor initiating Inquiries and SoftwareTrouble Reports (see 3 above). we refer Interestedreaders to Appendix C which provides a thoroughoverview of the NSW HELP facility -- its goals,functions and Information.
5. User Documentation
The "User Impact Bulletin" Is NSWOPS" malorresponsibility in the area of user documentation. Inaddition, NSWOPS has shown a conscientious InterestIn understandinQ and respondinq to user documentationneeds, we refer the reader to Section 6.2.4 whereboth of these Items are discussed In detail.
6. Configuration Management
Configuration management Is an integral Part ofmanaging the NSW software developient process (seesection 5.6). NSWOPS Is responsible for Implementingconfiguration mana0ement procedures devised by PDC inthe NSW user System configuration. NSWOPS controls
123
changes to (i.e.* the introduction of newconfiguration Items into) tne NSW User Systemconfiguration and performs periodic audits to verityconformance with the baseline configuration (this ismost Important for the 169 and Aultics mostconfigurations which are not directly under NSWOPSoperational control). In addition, NSWOPS Isresponsible for controllina and auditing changes tothe NSW Documentation Reoository# which is the focalPoint for collection and dissemination of all NSWdocumentation. Procedures for maintaining the hSWDocumentation Repository nave oeen devised andpartially automated E571. These proceduresautomatically:
- Update an index of documentation repositorycontents, and
- Generate a formatted ONSw Documentation Summary*which Is publically available to interested NSWcontractors and/or users
The Uocumentation Repository index Is In a formatcompatible with and accessible through tne NSw HELPfacility (see 4 above).
7. 0/A Testing Support
NSwOPS supports PDC's 0/A testing activities in a
number of ways:
- Operation of the NSW Candidate System durinq O/Aassessment periods
- Assistance In preparation and/or modification oftest plans# methodololes and scripts
- Application of tests to new NSw system releases
- Assistance in preparation of test scenarios andreports
0/A assessment activities are very much a Joint effortbetween PDC and NSWOPS. It is, therefore, not easy todistinguish the specific responsibilities (other thanCandidate System ooeration) of one organizationalentity from the otner, We refer the reader to Section5.4 for a more detailed discussion of GSG's (PDC andnSwOPS) Ouality Assurance activities*
124
-"-M-W ,"
8.0 AFLC TechnoloQy Demonstration
GSG (PDC) has played a major role in the planning anddevelopment of the NSW AFLC Technology Demonstration. PDC hascontributed directly to the demonstration Planning activitiesthrouqn Participation in the QNSW Working Group* created for thatpurpose. At RAC's reauest, technology transfer (581 anddemonstration milestone (591 plans were Proposed for thedemonstration.
Early in the planning stages, the NSW WorKing Groupconcentrated on Identifying and developin4 application scenariosfor the technology demonstration. GSG proposed a procedure forthe Identification and development of these application scenarios
The following tour application areas mere identified by theparticipating AFLC sites as candidate demonstration scenarios:
1. Configuration Management
2. Emulation Support
3. NSw Tool Repository
4. ADA Training
Configuration Management was selected by the AFLC's as thedemonstration scenario which Should receive highest priority.GSG was assigned responsibility for coordinating and developinathe Configuration Management scenario. GSG responded bydeveloping a general multi-level approach to development of theCM scenario [61J, and by proposing a specific tool-based approachfor Implementing the scenario (621.
The future requires further refinement and development ofthe approach tor the Configuration Management scenario which willbe achieved by:
- working with Participating AFIC's to Identifyrequirements
- Preparing a suitable NIW-based CM capability
- Testing the N45-based CM capability Prior todemonstration, and
* supporting ArLC ass ot the CM capability during thedemonstration period.
125
9.0 Notes and References
11) ONSW Tool Integration Studies: Final Report", GSG,January 5, 1978, Chapter 5
23 ONSW Management Plan", RADC, February to 1979
(3J 'Final Report on the National Software works for theperiod October 1. 1977 through December 6, 1978',COMPASS, Pp. 9-12
(4 Ibid, 0. 11
15) Op. Cit. (2)
E61 "Policy Statement" net message. R. Metzger,November 24, 1979, pp. 1-2
[7M Ibid., P. 2
td) Ibid., P. 2
(9) "NSW SuDport Strateqy' net messaQe* R. Netzger#December 26, 1979
[1(l Op. Cit. (2), p. 1
[11J Ibid., o. 1
112 Ibid., Do. 2
(13) Ibid.. D. 7
114J Ibid.. D. 5
(151 Ibid.. D. 5
(161 Ibid.. a. 14
(17) 'ARPANET Directory*# NetworK Information Center,SRI, November 198, pp. 9-10
(181 Ibid., Inside of baCK cover
(19J Ibid., Inside of front cover
(291 NNSW 5*. Test Plan', GSG, August 14, 1988
126
''.
(213 ONSW 5.0 Test Summary", GSG. September 11, 1980
(22] OMetnodoloqy and Plan for Testing FileTransformations*, GSGv January 33, 1991
L23) "Interactive Tool Testing MethodoloaYO, GSG,Nove;.Der 14, 1980
(241 "Summary of Interactive Tool Tests: NSw Release5.0", GSG, Novemoar 14, 198
(253 Op. Cit. [2)
(2b] "NSW Software Manaqement and Control Plan", GSG,November 28, 1988
E27] "NSW Users' Reference manual System Release 5",COMPASS, August 1, 1983
(28) "Interim NSW Managers' Tools", COMPASS, Septeiber29, 1976
(29J "NSW Tool Builder*s Guide", COMPASS anJ BBN,February 18, 1977
(301 "Tool Quality Manaqement and Control Plan", IITHI,February, 1980
E31] "Tool Installation Guide, Part 2", 1lTRI, May, 1980
L321 "NSW User Impact Bulletin for System Release 5.0",GSG, March 25, 1981, pp. 73-74
(33J Ibid., PP. 75-77
(34) Op. Cit. 1273
[3b] "The NSW Users' Guide", COMPASS, December 30, 1976
1301 Op. Cit* (28]
(371 "NSW beginners' Guide", GSG, August 1, 1978
(383 Op. Cit. 1323, pp
(391 "NSW 4.1 User impact Bulletln" o, GSG, January 31,
(401 Op. Cit. 132J
127
(41) OUIS Entries for Inclusion In Revised User ReferenceManual", GSG, February 14. 1980
(42) "Updates to the NSW User Impact Bulletin for SystemRelease 4.1". GSG, May 1, 1980
[43] "NSW User Impact bulletin Maintenance Plan*, GSG,April 2. 1980
[44) "Review of User Documentation for System Release4.,0, GSG, September 19, 1979
[45) "Proposal to Upgrade NSW User Documentation", GSG,May 30, 1980
(460 "Using the UCLA Native Language Processing ToolKits*. UCLA* July# 1979
[47J "Using the DISPLAY Tool*, UCLA, 4arcn, 1980
(48] "Using the TSOEDIT Tool*, UCLA. March. 1960
(49) "Using the UCLA PL/I Tool Kit", UCLA, July, 1979
[501) "Using the UCLA Interli Library Management ToolKit", UCLA, July, 1979
(51] "NSW Concept Paper", NSW Analysis Group (BbN andCOMPASS), November 19, 1919
[52) "NSW Requirements: Initial Ideas eni Organization",
GSG,
[53J "A Review of the Conceptual NSW Design", GSG,[54) "NSw Functional Specification*, NSW Analysis Group
(BBN and COMPASS),
(551 "NSw operations Guide: System Release 4.1', GSG,October 31, 1986
[56) "NSW HELP Facility System Specitication", GSG@February 27, 1981
(57) "NSW Documentation [Reoository) Maintenance Manual",GSG, November 28, 1980
[50) "NSW Technology Transfer Plan", GSG, February, 1980
(59J "AFLC Technology Demonstration Milestone Plan', GSG,,ebruary, 1980
128
' -- Idm m mm imm ~ innl m mNoIw
(60] "A Scenario Development Procedure tor the AFLCTechnology Demonstration, GSG, Aprii, 1980
(61] "An NSW-Based Confiquration Management Scenario forthe AFLC Technoloqy Demonstratlon*, GSG, June 9,1980
E62] "An NSw-Based Confiquration management SupportEnvironment UsInq GIM/ilSO', GSG, June 9, 1980
I
It
I
129
~, ii
Appendix A: GSG Biolioqraphy
bListed belo (by author) are the major documents and reportsprepared by GSG during the contract period covered bY thisreport.
Bamberger, Frank, "Methodoloqv and Plan for Testing NSWFile Transformations", GSG, January 3a, 1901
Bamberger, Frank, "NSW Requirements: Initial Ideas andOrganization", GSG,
Samberqer, Frank, "NSW Global File Types andTransformations", GSG, July 10, 1988
Dinqman, John, *lnteractive Tool Testing MethodologY", GSG,November 14, 19V0
DIngman, J. and Gale, R., "NSW Operations Guide: SystemRelease 4.1", GSG, October 31, 1980
Dinqman, J. and Kneiss, P., *Summary o Interactive ToolTests: NSw Release 5.0", GSG, November 14, 1980
Gale, Ross, "NSW 5.8 Test Plan*, GSG, Auqust 14, 1988
Gale, Ross, ONSW Documentation Summary", GSG, November 28,1980
Gale, Rosso "A Scenario Development Procedure for the AFLCTechnology Demonstration*, GSG, April 1988
Gale, Ross, "A Review of the Release-SpecificDocumentation: System Release 4.10 , GSG, January 1980
Gale, Ross, "A Review of the MSG user Manual*, GSG, January1980
Gale Ross, "NSW System Release and Assessment Procedure:Draft Proposal*, GSG, January 198
Gale, Ross, "NSW 4.1 System Status and Test Summajy, GSG,February 12, 1980
Gale Ross, "PDC Comments", In "The NSw ApplicationExperiment: Final Report", TRW,
130
7- 1,7
Gale, Ro, Kneiss, P., Bamberoer, F. and Dingman, Jo, "NSW
5.0 Test SuvmaryO, GSG, September 11, 1980
Gale, Re, Payne, D., and Vincent, D., "An NSw-Based
Configuration Management Scenario for the AFLC Technology )Demonstrationm, GSG, June 9, 1980
Gale, R., Payne, D., and Vincent, D., 'An NSW-Based
Configuration Management Support Environment Using
GIM/1100", GSG, June 9, 1983
Gale, R. and Bamberger, F., ONSw Fault Logger Design
Review", GSG, March 1979
Gale, R. and Bamberger, F., "UNIX NSW Front End Design
Review", GSG, February 1979
Gale, H. and Bamberger F., "A Review of the Conceptual NSW
Design*, GSG
Gale, Ho, Kneiss, P., and Bamberger, F., "NSW User Impact
bulletin for System Release 5.00, GSG, March 25, 1981
Kneiss, Peter, ONSW Tools On-line Documentation", GSG,
April 2, 19890
Kneiss, Peter, "NSW User Impact Bulletin Maintenance Plan",
GSG, March 19, 1980
Kneiss, Peter, "Review of User Docuientation for System
Release 4.0", GSG, September 19, 1979
Kneiss, Peter, "Proposal to Uoqrade NSW User
Documentation", GSG, May 30, 1980
Kneiss, Peter, "A Representative Tool Kit Using NetworKinq
Technology - Current NSW Tools", GSG
Kneiss, Peter, OUIB Entries for Inclusion in Revised User
Reference Manual", GSG, February 14, 1980
Kneiss, P. and BaMberger, F., *NSw 4.1 User Impact
Bulletin", GSG, January 31, 1988
Knelss, P., Dlngman, J., and Salisbury, S., "NSW Regression
Tests for System Release 5.#", GSG, Septevoer 30, 1980
Kneiss, P., and Gale, R., "MO.NSTR Comments", GSG, June t,
19841
131
Kneiss, P., and Dingman, J., "NS* Help Facility System
Specification", GSG, February 27, 1961
Knelss, P., and Bamoerqer, F., *Updates to the NS User
Impact Bulletin tor System Release 4.1", GSG, may 1. 1980
Payne, Doug, "NS% Technology Transter Plan", GSG, February.
19890
Payne, Doug. "AFLC Technololy Demonstration %1lestone
Plan*, GSG, February, 1980
Slocum, Lee, "NS6 Software Management and Control Plan",
GSG. April 14, 1981
"NSP Documentation tiepositorv] Maintenance manual", GSG,
Novemoer 28, 1980
132
74_;
112 {
Appendix 8: Generic Configuration Items
This appendix is designed to complesent the discussion ofNS* "Configuration management" which appears in Section 5.6 ofthis report.
In the three (3) subsections which follow, this appendixsummarizes the decomposition methodology used to-identify"generic configuration Items" and enumerates the current set otgeneric Cl's for each of the following "Pacxets":
ft NSo System packet
- TOPS-20 Host Family packet. Due to theautonomous operational requirements of the IBMand Multics NSW hosts, the set of "packets"covered by this appendix excludes the HostFamily packets for these host families.
133
W.- rs
B.1 Generic Confluration Items (CIs)
The set of generic Cis for the NSW System consists ig thefollowing two (sets of) "pacKets":
1. The wNSw System PacKet", Identifying the Cis genericto the (entire) NSW system, consists of the Lollooinqthree Items:
(1) System databases list
(2) Operator aids list
(3) System documentdtion lists, one for each ofthe following sets of documentation:
(A) host-indePendent functionalspecifications
(B) Release documentation
(C) User documentation
(D) Operations documentation
11. (A set of] "Host F'amily Packets", identifyinq the CIStor each host family implementation of NSwfunctionality, consists of the tollowing three (setsot) pacKets:
1. A "Generic Host PacKet", identifying the CIscommon to one or more host components (see"Component Packets" below), consists of thefollowing four items:
(1) Databases list
(2) Utility executables list
(3) Doerator aids list
(4) Documentation List
2. CA set of) "Component PacKets", identifyinq theCis for eacn nost-specific component of NSWfunctionalitv, consists of the tollowinq fiveitems:
134
(1) Component executaoles list
(2) ComPonent databases list
(3) Utility executables list
(4) Operator aids list
(5) Docuientation list
3. [A set ot] "Tool Packets", identifyinq the Clsfor each NSW tool of the host family, consistsof the followinq tour Items:
(1) Tool executables list
(2) Tool databases list
(3) Operator aids list
(4) Documentation list
The qeneric Cis for the ONSW System" and the TOPS-20 HostFamily "packets" are enumerated In subsections 8.2 and 5.3 whichfollow.
1 35
B.2 NSW System POCKet
The NSW system PacKet contains the following (sets of)generic contiquration items:
(1) System Database(s): CONFIG.BAS (A) (UniversalConfiguration Latabase (UCD)l
(2) Operator Aid(s): none. lnone : no contiqurationItem(s) to be CONTROLLED)
(3) System Documentation:
(A) Functional specifications
(1) ONSW Functional Specification" (A)'A" a an up-to-date revision to be
supplied by the Architecture ControlContractor (WC) during releasetransition to the Product DevelopmentContractor (PDC)].
(2) "System/Subsvstem Specification" foreach of the tollooing aenericfunctional components:
- Batch Job PacKage (A)
Checkoointer (A)
Dispatcher (A)
- Front End (A)
- Fault Logger (4)
- Foreman (A)
- File PacKaqe (A)
- MSG (A)
- Operator Utility (A)
WorKs Manager (A)
136
iT.,
Works Manaqer Operator (A)
(3) "Universal ContLQaratLon Database(UCO) Speclfication" (A)
(B) ~elease Docuientation
(1) *Release-SpecLf1c Docuientation*Lcoverinq all host (family)implementations) (A)
(C) User Documentation
(1) Sw oeqlnners ° Guide" (P ) (*P* = anup-to-date revision to oe supplied byPOC; '*" z an up-to-date revision tobe supplied shortly alter releasetransition trom PDC to tne NSP usercommunity).
(2) "NS. Users' Reference Manual"(revisions tor ootn tne rENLX/TOPS-20and UNIX Front EndsJ (A)
(3) "NSP Users' Guide* (A)
(4) wlnteriv NSw Mansaeros roolse [untilincorporated in the "NSW User'sReference Manual"I (A)
(5) "User lioact Bulletin" (0) [°* S
up-to-date revision to be supplied byNS% Operations (NSwVPS)J
(D) Operations Documentation
(1) "NSw Installation Guide" (A)
(2) "NSw Operations Guide" (0+)
II
137
8.3 TOP5-20 host Family PaCKet
The TOPS-20 Host Falily PacKet includes the following(sets of) generic C1 paCKets:
1. rENILX/TOPS-20 Generic Host Pacicet:
(1) Database(s): none
(2) Utility Executable(s): LOGUTL.EXE (A)
(3) operator Aid(s): none
(4) Documentation: none
k. TENE2X/TOPS-20 Component Pacxet(s):
Checkpointer:
(1) Component Executable(s): CHKPTR.EXE (A)
(2) Dataoase(s): none,
(3) Utilities: none
(4) Operator Aid(s): none
(5) Documentation:
- Interface Conformance Report(s): (A)
w Proqram Maintenance Manual(s): (A+)
M operator manual(s): (A)
iDispatcner:
(1) Component Executable(s): DSPCHRd.XE (A) andNSWROOTeEXE (A)
(2) Dataoase(s): none
(3) Utilities: none
139
(4) Operator Aid(S): none I(5) Documentation:
- Interface Conformance Report(s): (A)
SProgram Maintenance Manual(s): (A+)
w Operator Manual(s): (A)
Front End:
(1) Component Executable(s): Fe.ExE (A),FETI4DI.EXE (A) and UNdTLNT*EXE (A)
(2) Database(s): none
(3) Utilities: none
(4) Operator Aid(s): none
(5) Documentation:
Interface Conformance Report(s): (A)
-Program maintenance Manual(s): (A+)
-Ooerator Manual(s): (A)
Fault L6oqer
(1) Component Executable(s): FIeEXE (A)
(2) DatabaseOs: none
(3) Utilities: FLTEST*EXE (A) and rTLOPER.EXE(A)
(4) Operator Aid(s): none
(5) Documentation:
MInterlace Conformance Report(s): (A)
wProqram Maintenance Manual(s): (A0)
M Operator Manual(s): (A)
file PacKale
(1) Component ExecUtable(s): FLPKG.EXE (A)
(2) Database(s): none
(3) Utilitless none
(4) Operator Ald(s): none
(5) Documentation:
- Interface Contormance Report(s): (A)
- Program Maintenance Nanual(s): (A+)
- Operator manual(s): (A)
Foreman
(I) Component Executable(s)s FOREMAN.EXE (A)
(2) Database(s): none
(3) Utilities: MKCOM.EX9 (A), LOGRED,EXE (A)
(4) Operator Aid(s): none
(5) Documentation:
- Interface Conformance Report(s): (A)
Program Maintenance Nanual(s): (A+)
- Operator Manual(s): (A)
MSG
(1) Component Executable(s): NSG.EXE (A)
(2) Database(s): MSG-GENERIC-NAMES (A)#MSG-NETWORKfCO.NFIGURATION (A)
(3) utilities: none
(4) Operator Aid(s): none
140
(s) Doeu'uentatioqs
.Interface Conformance RePOrt(s): (A)
*Program Maintenance Manual(s): (A+)
*Operator Manual(s): (A)
operator Utility:
(1) Component Executable(S): OPRUTL.9EXE (A)
(2) Database($): none
(3) Utilities: none
(4) Operator Aid(s): none
(5) Documentation:
w Interface Conformance Report(s): (A)
w Program Maintenance Manual(s): (A+)
MOperator Manual(s): (A)
worKS Manager:
(1) Component Executable(s): wm.ExE (A)
(2) Database(s): WM-ONLINE.TASLES (skeletoni(A), DBOTFol [sKeleton) (A)# DSFCE.I(skeleton) (A)
(3) Utilities: SIMWMTEXE (A). SIMWTEEXE (A),SIMIP4F.XE (A), DMPUL.EXE (A), DBJTATEXE(A), T8IjTRN*EXE (A) (Note: Databaseconversion procedures sholl be Included Inthe *NSW Installation Guide- (see OSystemDocumentation Packet")l
(4) Operator Aid(s): DO files for creating:
-The CheckPointer Control Entry in theWorkcs Manager Database
*Database skeletons for wMaONLINE*?ABL6ES.DBWTV.1 and DSU'CE.1
(5) Docamentation:
ft Interface Conformance Report(s): (A)
fProgram Maintenance Manual(s): (A+)
fOperator Manual(s): (A)
works Manager UPerator:
(1) Component Executable(s): NMO.EXE (A)
(2) Database(s): none
(3) Utilities: WMOUTL.EXE (A)
(4) Operator Aid(s): none
(5) Docuventation:
ft Interface Conformance Report(s): (A)
ft Program maintenance Manual(s): (A+)
- Operator Maenual(s): (A)
3. TENEX/TOPS-20 Tool PacKet(s):
bCPL:
(1) Tool Executable(s): BC?LEXE (T) 'T' x anup-to-date revision to be supplied ov theNSW Tool Manager)
(2) LUatdbase(s): to be identified
(3) Operator Aid(s): DO files for creating tooland global file descriptor entries In theworks Manager database
(4) Documentation:
M installation: to be identified
M NSW-Specitic: to be Identified
142
A'7
-Native Host: to be identified
BOUT:
(1) Tool Executable(s): SDOTEXE (T)I
(2) Database(s): to be identified
(3) Operator Aid(s): DO tiles for creatina tooland global file descriptor entries In theworKS Manager database
(4) Documentation:
Mlnstallation: to be identified
w NSN-SPeCitic: to be identified
wNative Host: to be Identified
CON CORDA NCE:
(1) Tool Executable(s): CONCOROANCLAE (T)
(2) Database(s): to be identified
(3) operator Aid(s): DO files tor creating tooland global tile descriptor entries In theworKs Manager database
(4) Documentation:
fInstallation: to o. identified
- NSW-Specifjc: to be Identified
fNative Host: to be Identified
DESCRIBE:
(1) Tool Executable(s): DESCRIBE.EXE (T)
(2) Database(s): to be Identitled
(3) Operator Aid(s): 00 tiles for creating tooland global file descriptor entries In theworK5 Manager database
143
~4ARM'
(4) Documentation:
- Installation: to be Identified
- NSW-Specific: to be identified
- Native Host: to be identified
ECLj:
(1) Tool Executable(s): ECLAE (T)
(2) Uataoase(s): to be identified
(3) Operator Aid(s): DO tiles for creating tooland global file descriptor entries In theworKs Manager database
(4) Documtentation:
- Installation: to be identified
- NSO-Specific: to be identified
- Native Host: to be identified
EML.OAD:
(1) Tool Executable(s): EMLOAD.EXE (T)
k.2) Database(s): to be Identifiedj
(3) Operator Aid(s): Uu files for creating tooland global file descriptor entries in theworics Manager database/
(4) Documentation:
- Installation: to be identified
- NSW-Specific: to oe identified
- Native Host: to be Identified
k'MTBCPL:
144
4 w
(1) Tool Executable(s): FMI'BCP6.EXE (T)
(2) Database(s): to be identified
(3) Operator Aid(s): DO tiles tor creating tooland global file descriptor entries In tfleWorKS Manager database
(4) Documentation:
w Installation: to be identitied
"NSw-Specitic: to be identified
w Native Host: to be identified
FTP:
(1.) Tool Executable(s): FrPExE (T)
(2) Database(s): to be identified
(3) Operator Aid(s): DO tiles tor creating tooland global file descriptor entries in thleuoTKs Manager database
(4) Documnentation:
- Installation: to be identified
- NSw-Specific: to be identified
- Native Host: to be Identified
HOSTAT:
(1) Tool Executable(s): HOSTAr.ExE (T),NETSTAT.EXE (T)
(2) Database(s): to be Identified
(3) Operator Aid(s): DO tiles for creating tooland global tile descriptor entries In theWorKs Manager database
(4) Documentation:
L45
'777
__ _ __ _ __ _ __ _I I I i• -
- Installation: to be Identified
- NSw-Specific: to be identified
- Native Host: to be identified
LOOT:
(1) Tool Executable(s): IDDT.EXE (T)
(2) Database(s): to be Identified
(3) Operator Aid(s): DO files for creating tooland global file descriptor entries In theworks Manager database
(4) Documentation:
- Installation: to be identified
- NSW-Specific: to be identified
- Native Host: to be Identified
JIGSAW:
(1) Tool Executable(s): JIGSAw.EXL (T)
(2) Database(s): to be identitied
(3) Operator Aid(s): O files for creatinQ tooland global tile descriotor entries in theworks Manager database
(4) Documentation:
- Installation: to be Identified
- NSo-Specific: to be identified
- Native Host: to be Identified
6INKER:
(1) Toul Executable(s): LINKER.EXE (T)
146
f4 V-
(2) Dataoase(s): to be Identified
(3) Operator Aid(s): DO files for creating tooland globial tile descriptor en~tries in th~eIworKs Manager database
(4) Docuientation:
w Installation: to be identified
m Nsw-Specific: to be Identified
- Native Host: to be identified
M4ACRO:
(1) 1ool Executable(s): MACHO.EXE ('I)
(2) Database(s): to be Identified
(3) operator Aid(s): DO files for creatinQ tooland global file descriptor entries in tfleoorKS manager database
(4) Locuventation:iw Installation: to be ioentitied
ft NSW-Specific: to be Identified
- iAative host: to oe Identified
MACP020:
(1) Tool Executaole(s): MACR020*EXE (T)
v.2) Database(s): to be Identified
(3) Operator Aid(s): DO tiles for creatinQ tooland global tile descriptor entries In tneworKs Manager dataoase
(4) Documentation:
-Installation: to be identified
-NSw-Specitic: to be identified
147
- Native Host: to be idtentlfied
MHUNOF'F:
(1) Tool Executaole(s): MRUNOFdEXE (T)
(2) Database(s): to be identified
(3) Operator Aid(s): DO tiles for creatino tooland global tile descriptor entries in theworKs Manager database
(4) Documentation:
- Installation: to oe Identified
- NSw-SpecifjC: to be identified
- Native Host: to oe identified
NETSTAT:
(1) Tool Executable(s): NETSTAT.EXE (T)
(2) Database(s): to be identified
(3) Operator Aid(s): DO files for creating tooland global file descriptor entries In theworKs Maflager database
(4) Documentation:
f Installation: to be identified
- NSw-Specific: to be identified
- Native Host: to be identified
PRIM:
(1) Tool Executable(s): PRIM.EXE CT),IO-SERVCR-rOR-PRI.CXE (T)s GPMLXUE (T),UDDT.EXE (T)
(2) Database(s): to bOe identified
(3) operator Aid(s): DO files for creating tooland global file descriptor entries In theworKs Manager database
140
' , V, as V
1I
(4) Docuventation:
- Installation: to boe identified
- NSW-Specific: to be identified
- Native Host: to oe identified
PSA YE:
(1) Tool Executaole(s): PSAVE.EXE (T)
(2) Database(s): to be identitied
(3) Operator Aid(s): DO files tor creatinq tooland global file descriotor entries In theworKS Manager database
(4) Documentation:
" Installation: to oe identitied
f NSW-Specitic: to be identitied
f Native Host: to be identified
SOS:
(1) ool Executaole(s): SDS.EXE (T), SOSHLP.EXE(T)
(2) Dataoase(s): to be Identified
(3) Operator Aid(S): DO files for creetinq tooland glooal tile descriptor entries in theworKs Manaqer database
(4) Uocumentation:
- Installation: to be Identified
- NS*-SpeclflcZ to be Identified
N Native Host: to oe identified
149
SPEL016
(1) Tool Executable($); SPULL.AXE (T)
(2) Uataoase(s): to be Identified
(3) Operator Aid(s): U0 files for creating tooland global tile descriptor entries In theWorks Manager database
(4) LUocuientation:
- Installation: to be identifiedfNSW-Specitic: to be Identified
SNative Host: to be Identified
814CCOM:
(1) Tool Executable($): SRCCOM.EXE.(T)
(2) Database(s): to be Identified
(3) Operator Aid(s): Do files for creating tooland global file descriptor entries in theWorks Manager database
(4) Documentation:
w Installation: ta be identified
- NSW-Speclfic: to be Identified
ft Native Host: to be Identified
TICO*.
(1) lool Executable(s): TCO.CEXEC Me) EXEC.EXE(T))
(3) Oerator Aid(s): DO files for creating tooland global file descriptor entries in theworks manager database
(4) Documentation:f
I nstallation: to be Identified
- NSW-SpecitiC: to 00 Identified
W Native Host: to be identified
(2) Database(s): to be Identified
UYK2(6:
(1) Tool tKxecutabje(s): UfK20.EXE (T),1O-SERVER-tOR-PRIM.XE (T), GPMeEXE (T),UDOTEXE; (T), PRIMEXE (T)
(3) Uperator Aid(s): DO files for creating tooland global file descriptor entries in theWor~s Manager database
(4) LUoCumentation:
- Installation: to be identified
- NSW-SpeCitic: to be identified
- Native Host: to be identified
Ul a5lb:
(1) Tool Executaolets): U1650,EXE (T),IOHSEVE-FOR-PRIM.EXt; Me) GPMAE CT)UDDTEXE (T), PRIM.AXE (T
(2) Database(s): to be Identified
(3) Operator Aid(s): DO files for creating tooland global tile descriptor entries In theworKs Manager database
(4) DocumBentation:
. Installation: to be Identified
w NSW-Specific: to be identified
w Native Host: to be Identified
XEDS
(1) Tool Executable(s)Z XEDoEXE(T)
(2) Database(s): to be Identitied
(3) operator Aid(s): DO tiles tor creatino tooland qlobal tile descriptor entries in theworks manager database
(4) Documentation:
" Installation: to be Identified
f hSo-Specific: to be Identitied
t Native Most: to be Identified
152
Appendix C: Overview of the NSW HELP Facility
LNote: The overview of goals, requirements and capabilities Ofthe NSW Help Facility (including execution examples) whichfollows was extracted from "The NSw HELP Facility SystemSpecification" by Peter Kneiss and John Dingman, dated February27, 1911.]
NS Help Facility
The NSW system consists of Many dissimilar hosts andinternal functions supported by a variety of developmentcontractors. Each tool purveyor, host operating systemdeveloper, and each NSW contractor documents a particuli-r concernIndependent of its integration in NSW. As a result, thedocumentation of the conglomerate of systems that Is seen ov theuser as one entity originates as a series of separatepublications. Because the documentation for various aspects ofNSw nas many origins, documentation standards cannot be Imposedto accomodate the HELP facility. Rather, tne HELP facility mustfunction as a delivery facility that would consolidate access tothe existing documentation. Thus, the following broad goals wereset when specifying the Information delivery system for the %So4ELP facility:
To standardize the user interface to conform with otherNSW components
To centralize information In one source Instead of manytools for many types of Information
To create a generalized Interface which is adaptable toa variety of Information files
To create a facility whose tiles and topic selectionstructure can be externally configured by an NSwoperator (I.e., to have few, it any parameters, topics,etc., compiled Into the software Itself).
153
In addition, there were two functions which the HELPfacility needed to provide to users:
Enable a user logged Into NSW to send a message to an NSWoperator (who is not necessarily logged in). This wouldallow HELP users to document bugs, va~e requests, or askprocedural questions without leaving NSw. In particular,these messages could oe entered during the times anoperator is not available by pnone.
Display the status o NS* hosts so users can be Informedwhen remote hosts are not resoondini, thus avoiding navinto wait for connection timeouts, and providing affirmationtnat long running tasks are actually continuing to execute.
The HELP facility currently installed In the User Systemsatisfies the above mentioned goAlso It aids users In selectinathe type ot Information needed from among a variety ofinformation tiles. At tne top level of the interface, the usermay also choose to send a message to Ups (rELOPS) or display themost recent status of NSw hosts (STATUS). the tool IS designedfor tlexibilitv In chanqinq the topical nao (e.b., to reflectchanges in h6a) and for adaptability in disolavin4 differentInformation tiles. The current version can provide a singleonline access point to the Information previously provided by theUSER IMPACT bULLETIN, the NSw OOCUMLNTATION SUMMARY, tne NSW USERo FENENCL MAhUAL, the NSW tools.DESCRIBE and HELP-RM, the RAC-20Command INFORMATION (about) NSW-STATUS, and the INTERIM NSWMANAGER'S TOOLS*
The following typescript illustrates some of the featuresof the HELP facility. A dollar-slin (S) indicates that an<escape> was entered. The user's lower case typein can usuallybe distinguished from HELP's uppercase retyping of the commandline. It should be noted that all of the *enus are functions otthe database rather than the program and can be changed byaltering the help files. The only compiled in commands areOTELOPS", "STATUS", and the display commands prompted for with"(H,P,S,E, or Y)=>".
J Our comments are offset In this manner
) The followinq typescript hypothesizes) that a naive user tries to use a tool) and encounters a problem. He attempts to "nuit"I NSW and encounters one of the few times that the1 syntax. Instead of tne help NSW usually
I Provides in response to an escape, heI receives an error message.
154
) ve show now the HELP facility would lead him outI of his quandary it the Front End response) Included a pointer to the HELP tool.
4Sw User System Version 5.0
Report problems to NSoUPSORADC-26, (315)330-6256.
Nbh: use qedx-rmS (Confirm): I
>>> Tue 17-Feb-81 08:10:47-PST: No rights for tool OLDX-RM>>> Tue 17 Feb 198t 0813:49-PST -- MCA.tvMITAK)3>> OEDX-RM not available
NSO: quit$ NO TOOLS EXIST
NSP: ?Options are:
COPYDELETELOGOUTNETUSE
SEMAPHORkRENAMEJObPASSwORUFASTOUTSHOWALTERMOVELOG0UITRESUMEtFor more information, type "use helpom
continue...!NSw:
I Takinq his cue from the NSw Front End'sI response to a question mark, the user invokes) the HELP tool and types *?"
I tor a list of HELP topics,
NSi: use helpS (Confirm): !(Connecting to 2HELP...l
NSW HELP FACILITYType ?<CR> tor list of topics
HELP>?
155
Topics/commands available are:
COMMANDS mdescribes and shows examples of NSW commands.
NEWS -allows users to read notices and newsentered by NSWO.PS concerning schedules,new tools, etc.
POINTERS -disolays NSW files which users may access foradditional Information*
QUIT - exits tool and returns to NSW command level,
STATUS - displays current status of NS'W hosts.
MEOPS - a device which enables NSW users to sendquestions. complaints, or comments to NSWOPS.
TOOLS - describes NSW tools, outstanding Problems.and tool rights*
Only enough of a command to make It unique must be entered.
Entering 0?0 Will Show Possible commands/subcommands.
Fields (between commands and subcommands) must be separated bV
a space.
For example:
"C ?<CR>* will list the Possible subcommands of 'COMMANDS.,
"to ?<CH>* will list the Possible subcommands of 'TOOLS.,
Use the tollowinq Characters to edit your Input:J
(DkL> delete last character
CTR16-W delete last word
CTRL6-U -delete line
CTHLk-H retype line
CTR6-V -quote next Character
)It migjht occur to a user who has been warnedIthat NSW is a multi-host system, that the host forIhis tool is down. The HELP tacility#s
Idisplay Of host status eliminates that PoS&iblity.I5
wA
IIHELP>status
NSw User system Status as ot: 13-Feb-81 1711-ESf
USC-1SlE LiorKs Manager Host) is UPUSC-ISIC (Tool Bearing Host) is UPRADC-MULTICS (Tool Bearing Host) iS UPUCLA-CCN (Tool bearing Host) will be down untilfurther notice due to system upgrading.
Im
It It occurs to the user to check tne commandI "QUIT" to see if It is intended to end NSwI sessions, the following viqnt ensue. (Thei typescript illustrates HELP's interpretationk ot escape and question mark.)
HELP>commandsSCOMMAND NAME (13 CHOICES)HELP>COMMANDS quit$QUIT (NSw COMMAND) (4 CHOLCES)
HELP>COMMANUS QUIT ?
QUIT (NSw COMMAND) (4 CHOICES)
DESCRIPTION (OF COMMAND)EXAMPLE (OF COMMAND USES)NOTESEXCEPTIONSHELP>COMMANDS QUIT description
COMMAND: QUIT (NSw Command) (10 lines) (NUR 5.1)
PURPOSE: End a Pending tool instance.
SYNTAX:user system user system usel
QUIT noolnane (name> action { * SUSPEND
4 ABORT4 TERMINATE
(End ot items.)
157
K--
I Me user, having seen the four topics) under the hSw QUIT comand, now) can use a minimum number of characters toI specify displaying "COMMAND QUIT NOTES".
HELP>c q nFUNCTIONAL NOTES: QUIT (NSW Comiand ) (27 lines) (NURM b.)
1. For <name> you should type the tool instance name. Typinq ?at this Point wi1l yield a list of Pending tool instances.
2. As explained in the NSW Users' manual:
(*4 SUSPEND causes the tool to cease activity; it the tool permits,it can be reactivated (see RESUME) -- Not yet implemented. *$]
ABORT Kills the tool Instance imnediately; in particular, tilesahlch nave been created nay not be delivered into NS% tliespace.
TERMINATE causes appropriate tools to enter their termination code;whether or not tiles are delivered depends on the characteristics oftne tool.
3. It SUSPEND or TERMINATE Is not meaningful for a particular toolthe user Is so notified.
(End ot items.]
I It an Information file contains multipletopics (as indicated ov the presence of torn
I feeds), HELP offers tne four display optionsi illustrated below.
HELP>c q exceptions
QUIT (NSw Command) (3 items) (Ulb 5.0]
(I1,PS, or ?)=>?h - Shoo ieaders of all itemsP<Ck> (or lust <CR>) - Print this ItemPn<CR> - Print item nuvber nS - SKIP to next ItemE (or Ctrl-X) - Return to HELP command level? - Print tnis text
(H,P,S,L, or ?)3>h
158
-- *in IM e 'm
£-Never use the QUIT command on a CCN Interactive tool
2 -It is Inadvisable to slew-away from a tool that has begun atermination sequence (i-e.. the tool's termination Commandhas been entered),
3 *The following sequence of messages may be generated whentrying to QUIT or RESUME a tool-Instance:
LEnd of items.)
(H.P,SPE, or ?)=>Pl
Never use the QUIT command on a CCH interactive tool, (e.g.,DISPbAY-UC). Instead you Should Use the tool's terminationcommand (eog., "END*), Frequently as a consequence of usingQUIT on a CCN Interactive tool, your rront End Is damaaedand NSW Is unable to clear the CCN system resources for thattool-instance. Since these resources are finite.tool-instances which QUIT falls to clean-up will accumulateuntil they e~haust thei available WSW resources at CC?4.LNST-62616 INST-592J
It is inadvisable to slew-away from a tool that has begun atermination sequence (i.e.. the tool's termination commandhas been entered).
(HPPSPE, or ?)z>sThe following sequence of messages may be generated whentrying to QUIT or RESUME a tool-instance:
(HPSC.or ?)*>a
)If the user went on to retrieve information aboutItool rights# or looked up the error message InIan error message dictionary# he should findIthat his real problem Is obtaining rights for
-Ithe tool. To do this no needs to communicateIwith the NSW operator.
159
- 7
HFLV~telups
lype Control-X to anort, "?<CR>" for nelo.
Please enter your name=>Peter Kneis
Enter your ProJect.Node name=>cgsqjadmin
E:nter your net address ((CR> if n~one)=>)K ne is s ~raddc -2
E~nter sucdect (one line summnary of Problet or topic)x>Grant rights to (UEDX-RM
Enter your message below on as many lines as needed, terminatinayour Input w~ith Control-Z or ESCkPE.
Please gjrant GSG;.ADM1N the righ~ts to QEDX-H!4.
ThanKs
Your message is beingj delivered to NSwUPS. A reply will be sent toyou soon. Tnank You.
HELP>QjuitS (Confirm UUIT):NSW:v
160
III
Appendix U: Sample "weekly Usege Report"
WEEKLY USAGE REPORT FOR THE NSW USER SYSTEM(VERSION S.h)
From MON MAN 09 1981 0003EST to MON MAR 16 1981 3006ESTo
I. Number at bogins:
MON TUE OED THU FRI SAT SUN *TOTAL*4 1k 2 1 7 0 0 30
11. Node Usage 5ummarVI
PHtIJECI' f r4OUL/OO[,S US:!
AC - ,7I 1 boins Totaling 04:53: 0iJELP: 2 Sessions Using 30:00:06 In 00:44:00
Pbl-A: 2 Sessions Using aS:90:a4 In 00:12:00UEDX-RM: 3 Sessions Using a8:03:e1 In 00:01:00RUN-Ro: 9 Sessions Using 3:00:36 in 00:48:80
AIbC + CNAIG 3 Logtns Totalina 31:36:60HEIP-RM: 1 Sessions Using 03:0:84 in 00:12:00
GSG 4 AItN 3 Loqlns Totalin; 35s42:09DESCRIbL-lE: I Sessions Using S 00:831 in 09:2:00FONTRAN-R: 1 Sessions Usinq M03e: 0 In 00:00:90
F'TP-IE: 1 Sessions Using 33:09:33 in 09:13:0HELP: I Sessions Using 43:0a:81 In 00:02:00
AkD-1E2 I Sessions Using :00:33 in 00:12:00
GSG 4 JRL 3 LoqIns Totaling 03:22:80HELP: 6 Sessions Using 8 :08:31 In 00:04:80
GSG + KNEISS 9 Logins rotallno a2:54:83SOS-R21 3 Sessions Using 3:083M4 In 00:42:0XEU-ICI I Sessions Usino 39:08:88 In 00801:0oXk.D-lE: 2 Sessions Using Md:08:0 In 0S101o90Xcv-P23 6 Sessions Using 8808:54 In 00:36800
C~ ~ M a M m M mb m a a a w w m a ft w a a M a w a a
161
.. .... .. ... ... ... ... .. .. .. . . .. ... .. ... . . . . . - - I~
RADC + ADMIN I Loqins Totaling S:276aNo tool usage
HADC + BASKINGER 1 Loqins Totaling a3:5b:aOHELP: 1 Sessions Using 40:0a:a! in 00:31:00
RUN-RM: 1 Sessions Using a:oao in 00:00:02
Ill. Tool usaqe Summary:
TOTAL# TOTAL TOTALTOOLNAME SESSIONS CPU CONNECT
OIESCHIukEaIE 1 0:k0S:31 6:2FORTRAN-RM I 04:0:aa664hFTP-IE I ad:0a:63 ab:13:J4HELP 10 j0:00:09 41:21:aeHELP-Hm 1 d4:0d:04 a:12:aPL1-R 2 d80 a:4 0312:a
RUN-RM 10 40:04:36 6h:48:aO
SOSaH2 3 JO0:4 a:2a
XLD-IC 1 a$0:0:aa j018
XE-L3 00:03:63 M1:2:30X9D*H2 6 40~:06:a4 0a:3b:3a
IV. NSW Up-time/Don-time (,MH only, TBHs excluded)
The followini conventions will be used in this section:
U-<Tl K> -- Time NS4 came up (all tlies are LST)D-<Tlf> -- Time NS* went down%umber In parentheses tollowin4 time Indicates reason i4S*
went down, using the followinq codes:
(1) -- ISIE scheduled downtime(2) -- Unknown ISIE system failure(3) - Known NSw failure(4) a- Unknown NSw failure(5) -- OtherA single asterisk printed under any day means the system was
unavailable the entire day. A double asterisk *eans tne syste%was up the entire day.
MON TUE WED THU F1I
;a:725 ;-1130(2) D-0527(2) U-0836D-1445(2) U-1229 U-696V Dm1809(2)U-1b35 D-1459(2): U-1516Uall
162
NMI='
D-21i 6(2)
SAT SLI N
Steve S81ISbury (NSWOPS@RADC-20)
163
addresses number lineOf copies number
Leon Mci~owell 6tRAbC/ISCP
RA'C/TSLL) 1 2GRIFFISS AFB NY 13441
.?A UC /DAP 2 .3R I FF ISS AFR NY 13441
DAL)W I N ISTRAToR 12 5J)EI TECH INF CTRATTNI LJTIC-Di.ACAh.cR0N STA BG 5ALEXANDiRIA VA 22314
HO ESC (XPZP) 1 12SAN ANTON 10 TX 78243
HO ESCA.)(x 1 13SAN ANTONIO TX 78243
HO USAF/XOKT 1 17WASHINGTON DC 20330
HU USAF/RiST I20'WASH[N(TrON LDC 20330
HO LJSAF/RL)PV I21VoAbHLr40TON DC 20330
DL-1
PENTAGON 2 26USbR&E, RM 3U-139ATINs TSCO
WASHINGTON )C 20301
0 29
H1Q AFSC/DLAE 1 30
ANLREWS AFH DC 20334
HO AFSC/XRK 1 37ANbREWS AFR DC 20334
0 3o
40 SAC/NRI (STINFO LIBRARY) 1 39OFFUTT AFB NE 68113
0 44
HO 3246 TW/TLTW 1 46cOlIN AFB FL 32542
AFAT TL/DLOOL 1 47EMLIN AFfi Ff. 32542
,S ARC/PM (STINFO) 4bPATRICK( AF FL 32V25
D1-2,%,L:" •
TAF IG/ IIPL 50LANGLEY AFB VA 23665
HO TAC/XPS (STINFO)] 1 51LANGLEY AFB VA 23665
HO TAC/XPJC 1 52ATTN: Lt TaylorLANGLEY AFB VA 23665
TAF IG/I ICJ 2 53A7fNs Capt John MorrisonLANGLEY AFH VA 23665
0 55
HO TAC/;r.CG 1 56LANULrY AFB VA 23665
iO rAC/JRF 1 58LANGLEY AFBI VA 23665
AFSC LIAISON OFFICE I 59LAGI1.Y RESEARCH CENTER (NASA)LANGLEY AFR VA 23665
AFV4L/-4TYEL ( C L. BAUM ) f 63KIRTLAN) AFR NA 87117
AFIL/SIJL 1 64AT1Nt TECHNICAL LIBRiARYKIkTLANU AFB NM 87117
VL-3
ASU/ENLUE I67A-MN9 CAPT T CLELANDv4IGHTPA'TcRSON AFI3 OH 45433
ASbl/NL.0E 1 68AIINI MR LARRY WEAVERARNIGHT-PAT[ERSON AFB OH 45433
kSLJ/XRL 80WIGHT-PA7TERSON AFB OH 45433
AFIT/LL)L - TECHNICAL LIBRARY I81f3UILL)ING 640, AREA BWRIGHT-'A1TERSON AFB OH 45433
A FHR L/OTN 190AILLIAMS AFB AZ 85224
A FHRL./OA I91B3ROOKS AFF3 TX 78235
AUL/I.Siz 67-342 I9MAXWELL. AF6 AL 36112
HO AFCC/DApL I9H3LUG P-40 NORTH. RM 9 9SCOTT AF13 IL 62225
HO AFCC/EejjjoSCOj'T AFB3 IL 6222510
DL-4
-1 04,04
AFPRL/LRT 1 101LOWRY AFB CO 80230
33(:0 TTw/TrGX 1 103KEEST.ER AFR MS 39534
DEFENSE INTELLIGENCE AGENCY 1 107ATrNI RSE-2 (LT COL SCHWARTZ)AfASHINGTON DC 20301
JEFENSE INTELLIGENCY AGENCY 1 1OAT'TN RSM-IWASHINGTON UC 20301
CODE 0123 TECHNICAL LIBRARY 1 10DEFENS, COMMUNICATIONSENINEER ING CENTERI dBO IIEHLE AVENUERtTON VA 22090
uIkECTOR IIIIDEFENSE NUCLEAR AGENCYATINs TILWASHINGTON DC 20305
CHIEF. C3 DIVISION 2 112DEVELOPMENT CENTER, MCDECATTN3 R S HARTMANOUANTICA VA 22134
.FLMC/LGY 116ATIN. MAJOR MORGANGUNTER AFS AL 36114
uIPECTOR 119liMb A VANCED TECHNOLOGY CENTERA'rNl ATC-P, CHARLES VICKPO BOX 1500HUNTSVILLE AL 35807
Dr-5
EOAR)/CM I 120TECHNICAL LIBRARY FL 2878BOX 14FPO NY 09510
COMANL)ING OFFICER 123NAVAL AVIONICS CENTERLIBRARY - CODE 765INLIANAPOLIS IN 46218
NAVAL TRAIN ING EQUIPMENT CENTER 124TECHNICAL INFORMATION CENTERORLAND) FL 32813
CO.,MAN UER 1 125NAVAL OCEAN SYSTEMS CENT,-HATTN8 TECHNICAL LIBRARY, COL,- 4473BSAN DIEGO CA 92152
SUI-ERINTENDENT (CODE 1424) 1 127
NAVAL POSTGRADUATE SCHOOL•AONTEr-Y CA 93940
CohMA Nj INU OFF ICER I 12dNAVAL R-SARCr LABORATORYCObL 2627,ASHINGTON DC 20375
riLLSTONE SCIENTIFIC INFORMATION CENTER 2 131ATTNl URSPI-RPRJUS ARMY MISSILE COMMANUREDSTONE ARSENAL AL 35809
,)OT/FAA TECHNICAL CENTER 1 134ARL-142 (ATTNt A k CIOFFI)ATLANrIC CITY NJ 0t405
NATIONAL CENTER FOR ATMOSPHERIC RIES-ARCH 1 135IE5A L IBARYPO BOX 30004OULDER Co 80307
1DL-6I
AIR FORCE ELEMENT (AFELM) 1 140THE RAND CORP1760 mA IN STREETSANTA MONICA CA 90406
.)R RAYNER K RL)SICH 1 142ELFCTRo MAGNETIC AhPPLNIS, INCC/C; 7031 PIERSON STREETARVAJE CC) 80004
AELC LIBRARY (TECH FILES) 1 143AR~NOWL AFS TN 37389
director 0 144National Security AqencyATTN: T1213/TULFort Meade YD) 20755
Jlrec tor 1 145National Security lkqencyATfNs W07Fort Meade M0) 20755k
Jirector I 14bNational Security AnencyAT'Ns Wl31Fort 4.eade ML) 20755
oirector I155National Security AtencyATTN a R03Fort Meade ML) 20755
oir ec torI16NAtinnAl Security AgencyATTNs RiFort Meade Md 20755
d~irector I 1!)7National SecurityA77N I R2For t meade ML) 2075
DL-7
director I 58NAtional Security AqencyATTNI R5Fort Meade MU 20755
director I5bNational Security AqencyATTN: R6Fort Meade MU 20755
director 1 160:Ntinnal Security AgencyATTN: W7
Fnrt Meade Md 20755
U irector 161Nitiona1 Security Aency
Fort Meade MU 20755
Colonel Larry Druffel
ARPA/ITTO 19 (,3
1400 Wilson BlvdArlington VA 22209
HO ESu/FAE, STOP 27 1 164,iANSCOM AF3 MA 01731
-SL/UCKd (STOP 53) 1 16$AT NS L.T Com-SHANSCOM AFH k4A 01731
HO ESd)/YSFA 172HA SCOM AFH MA 01731
S 174HANSCOM AFR mA 01731
DL-8''EEl I
p - " -
! . m m I m ii
LUXR.V5 *78HAI~ COM AFH MA 01731
MA L,/X 179HANSCOM4 APR MA 01131
:$ L/X, uT 0I18
IANSCOM AFH MA 017 31
=Sb/XaT I81,tAINSCOM AFR MA 01731
ESU/XR 184J-ANSCOM AF6 MA 01731
F ESL/UCt?- 3E 1 185HANSCOM AFH MA 01731
riQ 6SL)/YSM (STOP 18) 2 186HANSCOM AFB MA 01731
HO ESU/UCR-1S 1 187ranscom AFB MA 01731
HO t.SD/UCR- I I 88HANSCOM AFB MA 01731
'T"
-),-
H Sb/TOFE (Caot Cliff Gardner) 2 3-iANSCOM AFH WIA 01731
AHIC/[LO)tC (Caot Bill rdiski) 2 4A ?IGHT-PATTLRSON AFB Oil 45433
Wt?-ALC/MEFCUM (Palmer Craiq) 3 5R-OHIN6 AI-d GA 3109b
SM-AT-C/MME*CF (Van Johnson) 3 6MCc(.ILrILAN AFR CA 95652
OC-ALC/4MFC (Mike Parish) 3 7,rINKFII AFB3 OK 73145
DL-10
P ~ -.
