NBSIR 73-217

Use of Computer Networks in Support of

Interactive Graphics for Computer-Aided

Design and Engineering

Marshall D. Abrams

Jerome A. Hudson

Paul Meissner

Thomas N. Pyke, Jr. Robert M. Rosenthal Frank H. Ulmer

Computer Systems Section

Institute for Computer Sciences and Technology

National Bureau of Standards Washington, D. C. 20234

30 June 1972

Interim Report

Prepared for Contract IMo. 72-90013

U.S. Army Electronics Command

Fort Monmouth, N.J. 07703

NBSIR 73-217

USE OF COMPUTER NETWORKS IN SUPPORT OF

INTERACTIVE GRAPHICS FOR COMPUTER-AIDED

DESIGN AND ENGINEERING

Marshall D. Abrams

Jerome A. Hudson

Paul Melssner

Thoinas N. Pyke, Jr. Robert M. Rosenthal

Frank H. Ulmer

Computer Systems Section

Institute for Computer Sciences and Technology

National Bureau of Standards

Washington, D. C. 20234

30 June 1972

Interim Report

Prepared for Contract No. 72^90013

U.S. Army Electronics Command

Fort Monmouth, N. J. 07703

U. S. DEPARTMENT OF COMMERCE, Frederick B. Dent, Secretary

NATIONAL BUREAU OF STANDARDS, Richard W. Roberts, Director

CONTENTS

Page

1. INTRODUCTION I

1.1 Background 1

1.2 Scope of Project Activity 3

1.3 Relation to Other Current and Planned

Activity ^ 1.4 Guide to this Report 5

2. TEST BED NETWORK CONFIGURATION 7

2 . 1 Ob j ect ive 7

2.2 Hierarchical Configuration 7

2.3 Networking Challenges. . . .' 8

2.3.1 Use of an Experimental Network 8

2.3.2 The Test Bed Implementation 9

2.3.3 Reliability l4

2.3.4 Other Networking Challenges ....... 19

2.3.5 Planned Changes in Configuration. ... 21

3. CONCLUSIONS AND PLANS 24

REFERENCES 26

APPENDIX A: Rendering Service to the Remote

. Computer User. . , . , 27

APPENDIX B: ECOM-NBS Communications Protocol ... 39

1. INTRODUCTION

1.1 Background

The material presented in this report is a result of

work performed between 1 July 1971 and 30 June 1972 as part

of a long-term "Interactive Computer-Aided Techniques Study"

initiated in August 1970. This long-term effort of research,

development and consultation by the National Bureau of Standards is _n direct support of the Department of the Army

Program of Research and Development in Computer and Information Sci-nces and the programi in Computer Aided Design and

Engineering.

The intent of this cooperative arrangement between NBS

and the U.S. Ar.y, specifically the U.S. Army Electronics

Command (ECOM), Fz . Monmouth, N.J., is to provide both

general and specific assistance to ECOM in the initiation of

the use of interactive graphics as a new and important tool

in com.puter-aided design and engineering.

From year to year NBS and ECOM select the topics for that

year's activity based on the outline for the long-term effort,

taking into account current emphases of related programs at

ECOM and NBS. In general, appropriate NBS staff are available c -J a continuing basis to consult to ECOM and its parent

organi ^?,'c ion , the Army Materiel Command, in the methods of

applic J on of interactive computer-aided techniques to meet

Army recvirement s for research^ development, and engineering.

This c r;. suiting activity takes advantage of NBS experience in
the areas of hardware, software, overall systems planning,

and general applications support.

Other pursuits from which specific activities can be

selected include: the performance of research and development necessary to identify and test measures of adequacy,

suitability and performance of interactive computer-aided

techniques; the development and transfer to usable formats

of computer software which supports interactive CAD-E systems;

the documentation, dissemination and general support of government sponsored software for interactive graphics; and the

performance of exploratory studies involving the application

of devices such as flying spot optical scanners and graphical

displays to problems in interactive generation, maintenance,

and updating of computer-based engineering documentation.

This work is being conducted within the Institute for

Computer Sciences and Technology of the National Bureau of

Standards. Specifically, it is being performed within the

framework of a principal objective of this Institute: to

provide technical advisory and consultative services to other

government agencies as required to assist them in making

effective and efficient use of computer-based systems. The

technical area covered by this project, interactive graphics,

and also the use of computer networks in support of interactive

graphics, is a new type of application of computer systems that

supports flexible conversational interaction between user and

computer. DeveloprnxOnt and application of this type of inter-
active computer system is of particular importance within the

teleprocessing program of the NBS Institute for Computer

Sciences and Technology.

1.2 Scope of Project Activity

The primary emphasis during this project period has been

on investigating the feasibility of using computer networks

to support interactive graphics for computer-aided design

and engineering, utilizing design terminals in a laboratory

environment. Altenative means for providing remote computing

service in support of interactive graphics have been studied

and the project has taken full advantage of the location of

a node of the experimental ARPA Computer Network at the

National Bureau of Standards. This node has been used to set

up a test bed configuration in support of the interactive

graphics facilities at ECOM.

In the course of this project, several practical networking problems were identified and are discussed in this report.

Some interim solutions were found; a more comprehensive

approach to the general problem may be expected to emerge

from continued system development. System reliability can be

expected to increase as the ARPA Network and its hosts evolve

toward greater stability.

Also during this period a variety of consulting services

have been provided. These have included continual interaction

with ECOM during their implementation of an interactive

3
graphics laboratory. During several meetings attended by

ECOM and NBS personnel numerous ideas concerning the stateof-the-art of interactive graphics and related technologies

were discussed. NBS staff members are maintaining close

observation of other potentially related interactive graphics

efforts in the United States and elsewhere, especially those

in university environments, from which developments useful

to ECOM in its implementation of the "design terminal concept" may be extracted. Discussion of these observations

has taken place during the mutual visits by NBS and. ECOM

personnel. Also, during the year extensive NBS experience

in computer networking has been made available both to ECOM

and to its parent command, the Army Materiel Command. In

addition to informal discussions with ECOM personnel, a formal presentation was made to the AMC CAD-E council on 29

September 1971 concerning the ARPA Network and its potential

use by AMC in support of its CAD-E program.

1.3 Relation to Other Current and Planned Activity

The tasks conducted within this project during the

period covered by this report have been accompanied by other

intensive related activity at NBS. The work most closely

related to this project has been in the general area of performance measurement of interactive remote access computer

systems. In that area, emphasis has been on determining

criteria and developing and testing tools for measuring the

performance of computer systems as viewed by a typical interact4
ive user at a remote access terminal. Specific effort

has been devoted to two types of tools. One Is the ICST

"Dialogue Monitor" that collects basic data about system

performance, user behavior, and communication line utilization.

The second Is a "Terminal Environment Simulator" which will

permit measurement of performance of remote access systems

under controlled conditions.

The techniques being developed In this performance

measurement program should be directly applicable to the

performance measurement problems associated with Interactive

[21 graphics usage. As discussed In the conclusions and plans

section of this report, these performance measurement techniques will be applied during FY 73, along with Intensive

study of the development of meaningful performance criteria

and measurement techniques for Interactive graphics and

general graphics system configurations. Experience gained

In other projects within NBS In the design and Implementation

of dialog monitors, dialog monitor analysis routines, and

general studies of Interactive dialog monitoring and data

Interpretation are expected to be quite useful during the

next project period.

During the next project period, the planned effort In

support of ECOM will be concerned not only with providing

network access and remote computer services In support of

graphics, but will follow up studies that were begun last

5

o
year in support of ECOM in the area of performance criteria

and performance measures.

1.4 Guide to this Report

In part two of this report the test bed network configuration developed during this project period is described.

The general concept of a hierarchical configuration in support of graphics in a laboratory environment is developed

and a series of challenges met during the im.plementat ion

process are discussed.

The next part of the report summarizes NBS experience

in providing computer service to remote computer users through

computer networks.

Finally, significant conclusions of FY 72 work are

summarized and planned extensions of this work are presented.

NOTE: The identification of certain commercial equipment in this report is done in order to adequately identify

the network components discussed herein and in no sense does

it im.ply recommendation or endorsem.ent by the National Bureau

of Standards.

6
. 2. TEST BED NETWORK CONFIGURATION

2 , 1 Ob j active

A test bed network configuration was established during

FY 19 72 to provide access on an experimental basis to remote

computing facilities for use in conjunction with the in-house

interactive graphics facility at ECOM. The objective of this

configuration was to explore the capabilities of remote facilities for supporting in-house graphics applications and to

investigate the methods and problems associated with the use

of networks for the support of interactive computer applications of this type.

2.2 Hierarchical Configuration

The basic configuration embodied in the implementation is

that of access to a hierarchy of increasingly powerful computer

systems through a netvjork. The minicomputer-based design terminal which directly supports the designer is connected through

an appropriate comm.unication circuit to a network access computer that acts as a port to a nation-wide network containing

numerous and varied computer resources. Through this network

connection, access to a large computer system has been provided

on which a major applications program can be executed in support

of the interactive terminal user at ECOM.

Specifically, the Varian 620 computer incorporated in the

graphics terminal at ECOM has been connected using a dial-up

voice grade circuit to a PDP-11 minicomputer at NBS. For this

2000 bit per second communication channel, a synchronous

7
block oriented protocol was developed that would permit a

remote job entry type of communication with the remotely

accessible computer resources. This protocol is described

in Appendix B.

The N3S PDP-11 was then used to interface directly

through the NBS Terminal Interface message Processor (TIP)

to the experimental ARPA Network. This network, sponsored

by the Advanced Research Projects Agency (ARPA) of the

Department of Defense has attached to it a number of large

and quite flexible computer facilities. One of these, the

IBM 350/91 at the University of California at Los Angeles

(UCLA) J was chosen to be the support computer for this

implementation.

So that the planned interactive graphics activity could

receive adequate support for mechanical engineering design

tasks, an appropriate applications package, the NASTRAN

structural engineering package, was transferred by NBS from

NASA to the UCLA 3 6Q/91o With the help of the staff of that

installations this package was made operational and accessible

through the entire hierarchical configuration from the ECOM

design terminal.

2o3 Networking Challenges

2.3,1 Use of an Experimental Network

In the process of developing a working test bed network

configuration, the ARPA Network was selected to support this

experiment. It is the only general purpose, large-scale

8
network of its kind and also is accessible at NBS through

part of the NBS program to evaluate the capabilities and

limitations of this type of network. However, the nature

of this developing network is such that the comjnunicat ions

network, although operable, is not 100% reliable nor is it

totally stable. Numerous problems have occurred both in

the use of the communications network and in the use of

three major host computer systems connected to the network

in preparation of this test bed configuration.

2.3.2 The Test Bed Implementation

The initial implementation plan envisioned the utilization

of a new operating system for the PDP-11 being developed at

the University of Illinois. The remote job entry (RJE) protocol has, however, matured slowly in the APPA Network. In addition, the ARPA Network Terminal System (ANTS) operating system

for the PDP-11 was not successfully completed by the University

of Illinois during the period for which it was planned. This

software package would have permitted a relatively straightforward connection through the network from the PDP-11 at NBS

to the UCLA 3 60/ 91. In its absence, it V7as necessary for the

NBS project staff to develop a new connection mechanism through

the network for support of ECOM. This interim connection was

made possible through the flexibility of the ARPA Network and

a number of its general capabilities for transferring programs

and r:.aking host-to-host computer interconnections.

9
The configuration actually implemented involved the

development of a special program for the PDP-11 that interacts with the Varian 620 at ECOM through an agreed-upon

synchronous protocol. The PDP-11 then communicates with the

TIP by simulating a human user connected at one of its terminal ports operating at 2400 bits per second. A connection

is then made through the TIP to a PDP-10 computer located

at Bolt, Beranek, and Newman (BBN) in Cambridge, Massachusetts,

operating under the TENEX operating system. A program was

developed by the NBS project staff to satisfy the "user

remote job entry protocol" necessary to connect to the UCLA

IBM 360/91. This PDP-10 program is a substantial revision

of a program written by Eric Harslem for the PDP-10 at the

RAND Corporation, Santa Monica, California. That program,

designed for direct human use, did not lend itself easily to

use by another machine (which might be considered as an

"automaton") rather than a human user. The PDP-11, while

simulating a human user, may be viewed as an automaton in that

it cannot respond to exception conditions with the flexibility

of a human user. The Varian 620 computer at ECOM also appears

as an automaton and, therefore, depends on a well-behaved

network. Similar problems of this type may arise at ECOM in

the handling of output generated by the remote applications

programs .

'

For this implementation, the NASA Stress Analysis (NASTRAN)

program, available at UCLA was selected. Use of this program.

10
via the network was planned in stages. In the first stage,

the user at ECOM submits punched card input in remote job

entry mode. He then receives output via the network suitable

for either hard copy on a line printer or viewing on a CRT

display in alphanumeric mode. In the second stage, the user

manipulates a graphic image of his stress analysis problem,

which is then encoded for him by the Varian 620 in terms of

NASTRAN source data and is automatically transm.itted via the

network to the remote computer. In the third stage, the

designer is able to view the output graphically, including

appropriate plots and tabulated data.

A copy of the NASTRAN package intended to run under

OS/360 was kindly provided by NASA AMES Research Center,

Moffett Field, California. The UCLA IBM 36O/91 was selected

as the host computer for the experiment and the NASTRAN package was transmitted via magnetic tape to NBS and then to UCLA.

Figure 1 shows the experimental configuration, in which

the node labelled TENEX is at Bolt, Beranek, and Newman.

TENEX is the name of the operating system at BBN used to

support this configuration.

Figure 2 shows the eventual configuration planned for FY

1973. The BBN computer can be bypassed after the appropriate

protocol can be satisfied within the PDP-11 as will be seen

below. This changed configuration should greatly increase

the reliability of the link to the remote computer facility.

11
Fig. 1 Interim Configuration

12
^ Phone

^Line

Additional

Terminals

TIP - PDP-11

(Under

ANTS)

NBS

UCLA

Fig. 2 Eventual Configuration

13
The change to the eventual configuration will require

either the delivery of software from the University of Illinois or the availability of additional core which is now on

order for the NBS PDP-11. It will also require stability of

the UCLA remote job entry protocol in the network. There

are now plans to implement a new protocol, a so-called

"standard" remote job entry protocol within the ARPA Network.

It is not clear whether the PDP-11 can support both this new

standard protocol and the present UCLA protocol. In addition,

a variation of one or more of these protocols may be developed

in support of the AMC ARPA Network usage to interconnect Ft.

Belvoir and Aberdeen facilities.

2.3.3 Reliability

Data obtained by BBN on the ARPA Network [3] host "up

times" indicates that, during the period January to June

1972, both UCLA and BBN averaged 80% up-time.

The ARPA communications network itself is considerably

more reliable, but software problems were encountered with

the TIP. Some bugs remain in the BBN-provided TIP program

as of this writing which have an adverage effect on communications reliability. The communication path for the interim

configuration involves the following computers:

Locat ion Computer* Est . Up Time

(1) ECOM Varian 620 (80^ ?)

(2) NBS PDP-11 (80^ ?)

(3) BBN PDP-10 (80^ ?)

(4) UCLA IBM 360/91 (80^ ?)

*Interface Message Processors and Terminal Interface Message

Processors are not shown; their reliabilities are considerably higher.

14
The figures in parentheses are expected reliability figures

for operations during the next few months. Assuming perfect

performance for the ARPA network (contrary to our experience)

an overall probability for successful job submission to UCLA

can be estimated at (0.8)'^ = 0.41. Not reflected in this

figure is the fact that, particularly for BBN , the ups and

downs come at frequent intervals, often without warning, and

the destructiveness of a crash, particularly during a remote

job entry run can be considerable.

More interesting than the percentage "up time" , measured

essentially instantaneously, would be data on the time between

failures for host systems and for the Net itself. It is the

expected up time which determines how likely it is that a

terminal session of a given length will be successful. Since

turn-around times for NASTRAN runs may amount to hours , it is

highly likely that a system averaging hundreds of crashes in

a month will prevent successful job completion.

Adequate statistics of this sort are unavailable, except

for the knowledge that a figure of perhaps 10 0 failures per

month appears to be typical for BBN. Spread over prime time,

this would lead to a typical mean time between failures (mtbf)

of about two hours. Much depends of course on how these

failures are distributed, and such information remains unknown

at this vjriting.

15
Much also depends upon the severity of a failure. An

automaton is not so flexible as to deal properly with situations such as an operator's message saying: "Please sign

off and log back on in 5 minutes". This temporary stoppage

is not likely to be serious to a human user, but it would be

unmanageable to our automaton. Crashes of any sort then must

be considered significant.

Some conjecture can be mtade about the effect of coupling

several systems, each with its own mean time between failures,

making a few assumptions about the distribution of times

between failures. Suppose systems 1 and 2 are characterized

by distributions N-j^(t) and N2(t), where N^Ct) is the probability

that system i will fail at a time t measured from its last

failure. Each system is characterized by a probability F^Ct)

that it will fail at or before time t,

F. (t) -C^ N. (f )dt'

X Vol

Conversely, we would expect system i to operate without

failure at least for time t with probability P^(t), where

P. (t) = 1 - F. (t)

1 1

If systems 1 and 2 are connected, the probability P(t) that

both remain up for time t is , assuming 1 and 2 to be independent:

16
P(t) = P^(t) P^Ct)^

= [1 - F^(t)][l - F^Ct)],

= N^(t') dt'][j^ N^Ct') dt'].

Let us suppose P(t) has associated with it a total system distribution of

times between failures, N(t), such that

P(t) = N(t') dt'.

Differentiating, we have

N(t) = N^(t) N2(t')dt' + N^Ct) N^(t')dt'

If the distributions N.^ and are exponential, of the fom

N^(t) = (lA.) exp(-tA^),

where X is the mean time between failures, then the composite distribution,

N(t), is of the same form, with

A. X-^ X^^

A pair of statistically independent systems, each with mean times to

failure of two hours would together appear as a single system with a

mean time to failure of one hour; four systems would present a mean

of one-half hour; and so forth. The exponential distribution is an

excellent model for describing short , uniformly distributed interruptions in a telephone line, radio reception, etc. Needless to say,

a periodic polling of a noisy telephone line, in which only a short

contact was made (limited sampling), would not permit meaningful

measurement of X . Moreover merely reporting the number of times such

polling uncovered a failure is insufficient to describe the statistical

mechanism.

17
2

N(t)

0

Fig. 3. Probability distributions for systems

characterized by mean times between failures

of 1/2, 1, and 2 hours. Systems are assumed

to have exponential distribution functions

of the form N(t) = (1/A) exp(-t/X).

18
Clearly, the network and its hosts should be monitored

for the a cq ui s i t i on of mtbf data, so that estimates can be

confidently made for given combinations.

2.3.4 Other Networking Challenges

Another aspect of the networking situation v/hich deserves

mention is the frequent unavailability of relevant documentation. For example, it is usually impossible to obtain DEC syste

documentation from a TENEX host (requestors are enjoined to

write to the manufacturer). Many experimental systems (e.g.

:

UCLA's Remote Job Entry System) are incompletely documented,

and this adds to the frustration of users and system developers.

A related problem is the difficulty encountered when a

remote user tries to gain access to a system used to serve

the needs of a rather tightly-knit user community. At UCLA,

a misunderstanding over the transmittal of an application

form for funding delayed the assignment of a chargeable account

number for two months. A local user would not have had to use

the form, nor would he have to telephone long distance several

times coast- to- coast to clear up the matter. The problems

of the remote user in general will be made the subject of

Appendix A of this report.

Some observations from the implementation of the interim

configuration underscored the difficulty of emulating a human

user on an interactive system. A related matter is the emulation of a "batch" user of NASTRAII.

19
A factor that does not augur well for the intended

use of NASTRAN is that both the NASTRAN program and OS/ 360

are somewhat verbose. Both presuppose the user has a line

printer or a similar bulk printing device. The available

version of NASTRAN provides two copies of the NASA emblem;

this is perhaps a forgivable extravagance when contrasted

to the total cost of a NASTRAN run, but it is an annoyance

to the interactive remote user. UCLA's output also comes

with window dressing; the job number is displayed in large

block letters. This of course has utility to a busy operator

sorting line printer output, but it adds overhead to data

transmission. "

'

The process of drawing a connected network of structural

members is quite similar to the drawing of an electrical

network. The graphical input program should allow for constraint satisfaction by requiring alignment of several points

of connection for each member. These "nodes" are required to

be numbered and referenced by number in the NASTRAN bulk data

input. In general, structures will be three-dimensional;

the graphics program must be so oriented. It should allow

the user to rotate the picture, or flip it about coordinate

axes. It should be possible for a structural member to

be called from a list, stretched and scaled to desired dimensions, and attached one point at a time to the other members.

Node numbering (in a way so as to minimize the bandwidth of

the stress matrix) could be done automatically. The program

20
should be able to compile the graphical data structure into

NASTRAN bulk data statements. Loading of the structure might

be handled by requiring the user to apply force vectors to

his picture.

For static loads, a data structure similar to the one

used at NBS for the thermal design application completed

in FY 1971 should be adequate.

2.3.5 Planned Changes in Configuration

Reliability may not always present serious problems,

since host facilities are progressing toward more stable and

dependable performance. Fig. 4 seems to indicate this trend,

and appears to justify optimism in this respect. Careful

scheduling will also improve the ECOM-NBS link, and a more

operational stance on the part of the ARPANET would eliminate

any possible complaint in that quarter.

It is anticipated that certain difficulties may be

encountered in graphical translation and the automaton

NASTRAN "user". The automaton approach, while it appears

workable, is susceptible to several disadvantages:

CD It will under-uti lize the resources of a program

the size and complexity of NASTRAN.

(2) Extra processing required to translate a graphical

data structure into NASTRAN source data, and the reverse,

introduces inefficiency.

21
Fig. 4 Reliability of UCLA and BBN

Host Systems during FY 19 72

22
(3) There will always be a reliability question, due

to the imperfect translation capabilities an automaton may

have, and due to updating of NASTRAN and/or OS/36O that may

change an output sequence relied upon to ue the automaton.

No doubt there will be pressure to rewrite portions of

the CAD-E system as a single entity, though perhaps continuing

to execute on more than one processor, including those in a

remotely accessible network; there should also be pressure to

reduce the number of communication links in the process. It is

certain, however, that the sharing of resources made possible

through the network will provide earlier results than a completely independent approach, and will place the facilities of

a powerful design system in the hands of remote users.

23
3. CONCLUSIONS AND PLANS

A general test bed network configuration has been implemented during FY 1972. Many things have been learned, some

of which are documented in this report, concerning the practical problems involved using computer networks. A working

link has been established as described in Figure 1 and is

being used in support of ECOM on a regular basis. This link

is being evaluated and is scheduled for improvement as the

various facilities are delivered to NBS and elsewhere as required in the network.

Continued interaction between the staffs of ECOM and NBS

will lead to simplified and more useful protocols for interconnecting design terminals with remote computer services.

It will also lead early in FY 1973 to the implementation of

performance measurement tools within ECOM and network supported

configurations.

Early effort at NBS during FY 1973. will be aimed at

summarizing the overall year's study of performance criteria

for interactive graphics systems. At the same time a detailed

plan for instrumentation of the ECOM design terminal, and of

the link from that terminal through the ARPA Netv;ork to the

IBM 360/91 and/or other host comiputers will be prepared. This^

test bed is expected to be a fertile ground for examining the

problems of communications protocols, communications reliability,

communications flexibility, and in general all of those consid24
derations important to successfully providing substantial

computer service through a computer network to a point of

need, namely the design terminal in the design laboratory.

25
References

M.D. Abrams , H. Kawai , T.N. Pyke , Jr., "Performance

Measurement of Remote Access Computer Systems," NBS

Report No. 10 381 (.19 70 ).

T.N. Pyke, Jr., J. A. Hudson, S. Treu, "Performance

Measurement of Interactive Graphics Systems in Support

of Computer Aided Design and Engineering," NBS Report

No. 10451, June 1971.

L.G. Roberts, B.D. Wessler, "Computer Netv^ork Development

to Achieve Resource Sharing," SJCC 19 70, pp. 5 43-5 49.

R.H. MacNeal (ed. )

, NASTRAN Theoretical Manual , NASA SP

221 (1970), available from COSMIC, U. of Georgia, Athens,

Ga.

C.W. McCormick (ed. )

, NASTRAN User's Guide , NASA SP 222

(1970), available from COSMIC, U. of Georgia, Athena, Ga.

BBN Network Summaries (Communications to Dr. L.G. Roberts)

January- June 19 72.
APPENDIX A

RENDERING SERVICE TO THE REMOTE COMPUTER USER

Experience gained as on-site, local, and remote users

of university and commercial computer systems has provided

insight into various problems of informing and serving the

computer user. The universities have included Massachusetts

Institute of Technology, University of Pittsburgh, University

of Maryland, and University of California at Los Angeles.

Commercial sources have included Bolt, Beranek and Newman,

Inc.; Dialcom; and General Services Administration Time

Sharing. Computers have included Univac 110 8, GE 440,

Multics, PDP-10, Tenex, IBM/360, and XDS 940. Access has

been via the local public switched network, the local switched

network plus private connections to remote sites , the Federal

Telephone System, and the ARPANET.

Many of the problem areas have been identified by all

the servers. Some do not exist everywhere; some exist but

have not yet been identified, much less solved. This part

of the report serves primarily to identify present and

potential problems, and secondly to propose some solutions.

The material in this Appendix is organized under the

following headings:

1. Advent of Remote Users

2. Classification of User Communities

3. Problem Definition

4. Information Classification

5. Administrative Policy Relating to Financial Arrangements

6. Information Dissemination

6.1 Documentation

6.1.1 Function to be Served

6.1.2 Methodology

5.1.3 On-line Information

6.1.4 Off-line Information

6.1.5 Published Documentation

6 . 2 Assistance

7. Technical Capabilities

7.1 Communications

7.2 Supervisor and Security

7.3 File System and Editor

7 . 4 Languages

7.5 Configuration

8. Operating Procedures

9 . Summary

27
1. Advent of Remote Users

As the community of users of a computer sys.tem grows beyond

the original local community, the solutions to various managerial problems need to be re-examined. In many cases physical

proximity is an implicit component to the solution of problems.

When this physical proximity is removed the existing solutions

may prove to be inadequate. The purpose of this appendix is

to review and tabulate many of the managerial decisions which

need to be re-examined when a remote user community is added

to a computer system.

2 o Classification of User Comm.unities

For the purpose of this discussion 5 user comjnunities will be

divided into three groups. The first group is the on-site

users 5 where on-site may be extended to include those within

a psychologically acceptable walking distance. The second

group we shall call local, where local is defined to include

those within a local telephone calling area and within an

psychologically acceptable driving area. The third group

is everything that is left, called the remote group; by

definition these are the people who are too far avzay to drive

to the computer site and those for whom a telephone call to

the site is long distance. In this paper we shall be discussin

problems of rendering service to the remote user but a good

many of the issues raised also apply to the local user as well.

3. Problem Definition

When computer systems begin to service remote users some of

the formal procedures which appeared to be satisfactory for

on-site or local users may begin to exhibit defects. It may

be that these procedures were already inadequate but the local

and on-site communities developed a set of informal procedures

to augment the formal ones. It may also be that the establishe

procedures were completely satisfactory for the on-site and

local communities but failed when an attempt was made to

extend them to the remote community. It is the intent of

this paper through a series of questions and discussions to

identify the set of procedures which need to be re-examined

when remote users are added to a computer system. Hopefully

and most likely, not all of these procedural difficulties will

exist on every computer installation.

As indicated above, the definition of non-locality is extremely

subjective. It is very much influenced by the attitudes of

the users themselves and by the operating staff of the computer

facility. There are miany steps or modes of extending from an

on-site operation to one where consideration of remote users

needs to be taken. For the purposes of exposition we mention

28
the following: A batch system with a single I/O dispatch

station may expand its services by providing messenger service for pickup and delivery of I/O at remote sites. A

batch system may add remote batch capability. Conversational

terminals may be provided for a limited geographic area such

as a campus or may be made available on the direct-dial network. The "dialing area" for a conversational terminal system may be extended out of the local area by the use of a

regional or national network.

4 . Information Classification

There are many questions the user will have in coming to see

a new computer system. As he gains experience with the system,

these questions will be answered and new ones will occur.

Since various individuals will use the computer system in

different ways, the ordering of questions is not predictable,

nor is the level of sophistication. In fact the same individual

may ask relatively simple and relatively sophisticiated

questions concurrently as his needs for information about the

system develop differently in different application areas.

We could say that the answer to all these questions is a

management function, and therefore that this document is

directed to managerial problems. To do so, however, would

be to submerge individual identification into a broad heading.

Useful information would be lost in that way. It is observed

that the normal organization of computing centers creates

areas of administrative responsibility. In this discussion

we will therefore try to group together those questions that

seem to fall together under each separate administrative

responsibility. It is recognized that in many circumstances

the demarcation lines may be fuzzy and. the particular classification that we choose is therefore to be regarded as arbitrary .

5 . Administrative Policy Relating to Financial Arrangements

The first set of questions under this heading has to do with

the establishment and the working of accounts. How does a remote user know which administrative forms he must use and

how does he acquire these forms? When opening an account

what information is required and what restrictions are there

as to the classes of users who may be served and/or the rates

they may be charged. Are the procedures for processing the

forms designed to handle remote users? Are complete mail

addresses, titles and telephone numbers provided? In paying

for services or supplies what mechanisms are acceptable? If

purchase orders are to be used, is there any particular information that should be contained in them? What mechanism exists

for continuity between the lapse of one purchase order and the

issuance of another one, especially if such lapse is due to

administrative restrictions such as fiscal year termination?

29
Is there clear identification of which services are chargeable

against which accounts? For example, if the computer facility

operates more than one machine is a separate account necessary

for each machine? Can the account that is used for paying for

computer time also be used to pay for related supplies such as

manuals, tapes, disks, coding forms, etc.? If such charges

cannot be made against that account, is it possible to open

separate accounts for such supplies or must they be paid for

on a piecemeal basis?

Is there an administrative liaison acquainted with remote

user problems to whom administrative questions can be addressed?

Is this the same person you talk to about opening an account?

Assuming the existence of an account, another set of questions

presents itself. How does a remote user determine the status

of his account? How does he determine the charges accruing

to the account for any individual computer use session? How

often are statements issued and when issued how current are

they? Assuming the existence of an operating schedule, does

that schedule allow for users in different time zones? How

is this schedule announced? How closely followed is it?

How are remote users notified of changes in the schedule?

6 . Information Dissemination

6.1 Documentation

The discussion in this section includes documentation,

interactive tutorial programis , on-line help files and

all other means employed for communicating information

about the computer system. It is recognized that in

communication it is important to consider the recipient

of the information and that the community of remote

users may certainly be assumed to be heterogeneous.

Included in this community would be the novice who may

be categorized as using his first computer, the beginner

who may be using his first remote computer, the experienced

programmer who already uses several rem.ote access computer

systems and the system programmer who probably wants to

modify the basic set of services available.

6.1.1 Function to be Served

All of these people will have questions. Probably

they will all start at the same level, but the more

advanced will progress further and faster toward a

more advanced level of understanding. Their

questions may also be answered at many levels and

in fact when the question is first asked, the

inquirer may not know what level of response he

requires

.

30
Program documentation is a form of communication

and ought to be considered as such. The essence

of comjnunication is sharing . The word "communication"

is derived from the past participle of the Latin

communicare: "to impart or make common." The information theorists may have done us a disservice by

thinking along the lines of communications channels,

so that we regard the essence of communications as

"sending messages." This has obscured the true

essence, namely, that we send messages to share . Looking at computer system documentation in this

way, it seems there is a possessor of something to

be shared, called "information". This information

about a system (e.g. , that it exists, what bugs

it is known to have, how to use it, etc.) may

exist in the minds of a number of people. Indeed,

in most real-world situations, there is probably

no one person who knows "everything that is known"

about a given computer system.

The kinds of documentation that are needed are

as varied as the situations one can conjure up

when thinking of sharing. As a result, the extent

and degree of formality of documentation may range

over a wide spectrum. The difficulty comes when

one attempts to determine what kind of documentation is proper in a given situation.

Some of the factors which (should) influence the

amount and formality of documentation which is

proper in a given situation are

:

(1) The temporality of the information--that

is, how long will it remain accurate,

correct, and/or useful?

(2) The costs associated with inconveniences

and calamities which might arise if someone

who needs the information can't (or doesn't)

get it.

C3) The costs 5 measured in terms of time and

effort, associated with making the information available to those who are likely to

need it.

C4) The degree of sophistication of those who

share the information. Here it should

be remembered that any exchange between

two parties rapidly degrades to the level

of intelligence of the lesser party.

31
What we wish to suggest here is that the above

four factors are different in the case of remote '< computer usage as opposed to local usage, and

that an analysis of the problems of remote computer

usage might well consider these factors. For

instance, because the costs associated with calamities may be higher in the case of remote usage

,

more time and effort to prevent these calajnities

may be justified in the case of remote users.

6.1.2 Methodology

A constantly reoccuring question is meta-language

versus samples. Aside from the linguistic esthetics,

the real problem is how to clearly differentiate

between those character strings which must be reproduced exactly, and those which change from use

to use. Further complicating the question is the

existance of optional character strings (i.e. , the

null string is a special case).

Samples work fine up to some threshold of complexity.

This threshold is probably not constant, but rather

a function of the writing ability of the documenter.

(It is also a function of the reader, but that is

a free variable we can not hope to control. ) We

certainly suggest that samples (alone) be used when

they make everything perfectly clear.

When samples are not clear enough, meta-language

requires education on the part of reader and

writer, and that efficiency is traded for accuracy.

One problem in using meta-language is the identification of meta-language constructions (clearly

differentiated from those in the language being

described). Most commonly this is accomplished

by employing characters in the meta- des criptions

which are outside the character set for the language

being described. For languages whose character

sets include only capital letters, meta-language

could be written exclusively in lower case letters.

Numbers pose a problem which is usually left to

context Ci.e., it is left unsolved). Another

traditional approach has been to select individual

or pairs of characters and define them as metalanguage delimiters. Conventional use of delimiters

identifies all character strings occurring between

paired delimiters as being meta-language constructs.

It is most convenient if the delimiters are outside

the character set, then identification of them is

simple. Otherwise, identification of delimiters

is itself contextual dependent.

32
We may begin with the ASCII character set being

defined independent of any language. Furthermore, different implementations of the "same"

language may employ different subsets of the

ASCII character set. It is obvious that we

shall have to use the ASCII character set as being "inside". No ASCII character may be assumed

to be an intrinsic met a- character or meta-delimiter.

Thus we may either define new characters , probably

to be used as delimiters, or we can select our

delimiters from among the ASCII set and hope to be

able to recognize them by context. The commonly

used and known delimiters and their applications

are :

< > Angle brackets - used to enclose a metavariab le

.

[ ] Square brackets - used to enclose a construct

which may be optionally omitted.

{ } Brace - used to enclose a set of constructs

from which one and only one is to be selected.

If one of the constructs is NULL it must be

explicitly included. The alternatives are

written in a column, or may be separated by

a vertical bar "|" meaning logical OR.

^ Integral - used to enclose a construct which

may optionally occur from a to b times.

a

6.1.3 On-line Information

Progressing in degrees of formality, is there an

on-line graffiti file, that is to say a file in

which informal comments about the system may be

entered? If there is, how is the file maintained,

policed, and how does the remote user gain access

to it? Also, how is the information in the file

dated and how may an infrequent user gain access to

so-called ancient material?

Is there an on-line assistance facility? Can

the user obtain "help" information about aspects

of the system? If he doesn't know what to ask,

is there a mechanism for getting him started?

Is there a way for the novice to cut off information

when it reaches a saturating level of complexity;

similarily is there a way for the advanced programmer

to skip over the basic introductory material?

33
Coupled with such, on-line help-type sessions is

there also an on-line index so that a user may

skim through documentation to find the information

that he wants? If there is, how does this on-line

documentation relate to the normally published

documentation? How may the user access this

information? What access tools are available

for him?

6.1.U Off-line Information

If there is daily on-line "message of the day"

information dissemination, how is this handled

at the remote site? Is each individual to get

his own copy? Is someone assigned to print out

and post a copy of his own? How does the infrequent user obtain back copies of this on-line

information?

If there is a local off-line printed news type

publication how does the user obtain a copy and

subscription to it? What provision is made

for copies to multiple users at a given remote

site, especially if they come in under the same

contract? What provision is made for the remote

site to change mailing lists and subject categories for documentation distribution?

6.1.5 Published Documentation

In published documentation we find essentially

two classes. One is the set of documents which

are produced at and by the facility. Second is

the set of documents which are produced elsewhere,

by the manufacturer or by other computer facilities

from whom systems or subsystems have been borrowed.

It is our observation that the remote user is severe

burdened if he must go to the originating source

for each document. We therefore recommend that

all documentation be sold through the same source.

But what is that source?

How does the remote user purchase documents?

Where does he order them from? How does he

order them? How does he pay for them? Are

standing orders acceptable? Are subscriptions

acceptable for updates, revisions and errata? Are

back copies available? What is the delay time

between a user's request and the receipt of the

documentation ?

34
If the local documentation supplements or contradicts the vendor supplied documentation how does

the user find out about these conflicts? What is

^ the mechanism for resolution of such conflicts?

Are documents identified as to the level of

sophistication of the user who might employ

them? Is there a specific document or set of

documents directed to the new user? Does this

set of documents describe the capabilities of the

computer installation and provide an index to

other documentation? How is the availability of

documentation announced? How does the user determine which documentation is necessary as opposed

to merely available?

6 . 2 Assistance

Now let us turn to some questions of communications

and assistance. Assuming that there exists a mechanism

for data communication, what mechanism exists for voice

communication? Is WATS, Zenith, Enterprise or the

equivalent made available? Is there a single person

that remote users contact for assistance? What is his

level of technical competence? What is his level of

administrative responsibility? V\[hat amount of assistance

will be given to remote users? Are these remote users

to be made aware of the chain of command? V/hen the

contact person cannot answer a question or solve a problem., will he follow it up in-house with the appropriate person or will the remote user be referred to the

person in-house? To what extent is the remote user permitted or denied access to the technical and administrative staff?

Is there a way of leaving a message which will be

answered by the appropriate technical person? Is

there a way of communicating between computer users?

Is there a separate mechanism for answering easy and

hard questions? Is there an on-line conversation

assistance service? Is there a way for the remote

user to file a formal trouble report?

7 . Technical Capabilities

In this section we discuss some of the questions having to do

with the actual computer services which are available. The

answers to the questions raised herein will occur in the

documentation, which has been discussed above.

35
7.1 Comniuni cations

How do you make contact with, the computer system? What

data communication equipment is acceptable? Are there

separate access ports or procedures for different classes

of equipment? Are there any hardware, optional features

which are required for access to the system or which

are assumed by the system? What communications rates

and codes are supported? Are there any assumptions

or provisions concerning terminal characteristics such

as lines per page, columns per line, speed and existence

of formatting operations such as separate line feed,

separate carriage return, combined line feed carriage

return, horizontal tab, vertical tab, form feed and

backspace? Have any of the non-printing control characters

been assigned non-standard functions?

7 . 2 Supervisor and Security

Once you make contact with the computer system, how

do you initiate a session? What terminology is used:'

session, job, run, conversation, etc.? What is the

local name for the operation of identifying yourself

and the account to be charged? How do you do it?

What security is there to reduce the likelihood that

someone else can identify himself as you and charge

to your account or gain access to your files? Are

there passwords? If so, how are they established and

how may they be changed? Is it possible for a user to

change the account number under which he is operating,

or to charge some of the charges against an account

number other than the one that he signed onto? Are

there defaults in the sign-in procedure , and if so what

are they?

Concerning communication with the supervisor, is

there a control or command language which is used?

What is the syntax of this language? What is the

minimum capability with this language that is required

for the remote user? What is a minimum set that a

moderately advanced programmer would need to know?

7.3 File System and Editor

Is there a file system? If it is not called a file

system, what is it called? How does it differ from

other file systems? VJhat are its salient characteristics? VJhat is the minimum information a remote user

needs to know about the file system?

36
What names are used to identify a collection of information, a subset of that collection or a superset?

What restrictions are there on the uses of these sets?

What naming conventions exist? Can the same name refer

to more than one unit of information? Are the names

divided into adjectival qualifiers? If so, what are

the separators? What are the parts of the names called?

Are there default rules which permit the use of less

than the whole name? If so, what are they? flow are

units of information created and named? How are they

modified? In addition to the editors, are there in-line

editing features which work even when you are not employing an editor? (For example, deleting a single preceding

character, or deleting the entire preceding line.) How

are these in-line functions invoked? Can the way they

are invoked be changed by the remote user?

7.4 Languages

What languages are available? For each language how

is the translator (processor) implemented and what

difference does it make to the user? (For example,

batch load compiler, incremental compiler, load-and-go,

and interpreter. ) Can program units written in different

languages intercommunicate? Can they be combined to

form a program? What combinations are permitted, prohibited, known to work, possible but not guaranteed?

Is there compatibility in data structure as well as in

subroutine linkage convention? How do the dialects of

these languages compare to other dialects and to the

standard if one exists? What subsets of other dialects

are isomorphic to the subsets of the dialects existing

on this computer system.

7 . 5 Configuration

What devices are available on the computer system?

How are they configured and how does the configuration

affect the services that are available to the remote

user? Can a remote user direct output to a device other

than the one that he is using? For example, can a remote

user cause material to be printed on the on-site line

printer or punched by an on-site punch? Assuming that he

can, how does he get his output?

8 . Operating Procedures

Is the operating staff aware there are remote users? Are

there services available to remote users which are not

available to local users, and conversely? Is there a procedure for mailing output and other material to remote users?

37
How are operating procedure announcements made? Is there

a way of obtaining old announcements? When changes are

made is the remote user warned in advance? Is there a message which is automatically presented when a session is

initiated? How does someone who is not a regular system

user keep informed of these messages?

Is there an on-line file system? What limits are imposed

on storage? What charges? What backup procedure is maintained? How are backup copies of files loaded? Is there

off-line storage on tape or on disks? What is its capacity?

How is it addressed? How is it made available? What limitations are imposed? What does it cost? How does a remote

user request 5 renew and release tapes and disks? What procedure is available for him to inquire from the operator about

the status of such off-line storage? What procedures are

available for transporting or mailing such off-line storage

units in addition to other classes of output such as printed

paper, punched cards, plotter output, etc.

If multiple classes of service are available such as remote

batch, conversational, remote job entry, load-and-go, can

these services be intermixed?

9 . Summary ' ;

' ^

The remote user who employs multiple computer systems has

enough difficulty in organizing his thoughts and maintaining

his competence in the procedures and services which are made

available to him from each of the servers. It is incumbent

upon the servers to allow him to organize in an optimal

manner, and to provide him with sufficient information so

that he may effect this organization.

38
APPENDIX B

ECOM-NBS Synchronous Protocol

1.0 The ASCII character set will be used (see USA Standard

X3. ^ - 1968)

1.1 The basic unit of information v;ill be an 8-bit byte -

ASCII character + parity bit. (Low order bit is transmitted first, parity transmitted last.)

1.2 Synchronous m.essages will be blocked. At least 4 sync

characters (SYN 026) will precede each block.

1.3 The block is a line image and may contain a maximum of

132 text characters.

1.4 Text characters within the block (after STX and before

ETX) shall have ASCII octal values >_ 40g. (Sync characters, however, m_ay appear anywhere in the block.) (Sync

is not included in BP.)

1.5 The parity bit, tt , of all characters is normally odd

parity; it v/ill temporarily be even parity.

2.0 Several types of blocks will be recognized.

2.1 Message Block

- - - - Form.at;

Block

parity

calc

from

these

char.

(excl. SOH)

SOH

HEADER (SEL)

Variable Data

STX

TEXT

ETX

BP

001

003

make any length

39
2.1.1 Header (SEL char.)

T7 0 1 P d d ! d 1 d

1

i where it

P

i'

d

parity

duplicate block protect bit

device

0000 printer

0001 punch

not 0010 peripheral #3

used

in i 0011 peripheral #4

initial | versions 0100 - — peripheral

0101 peripheral

P protects against duplicate block transmission. If

rec. station acknowledges a message, and receives

another with the same P value it will reject the new

transmission (guards against ACK not being seen by

sending station). First message must have P = 0.

Peripheral sele-ction allows for forwarding messages

to different devices at the receiving station.

2.1.2 STX serves as: ' "

(a) end of header

(b) start of text characters with the next character

2.1.3 ETX ends the text block^ and must be followed by BP.

2.1.4 BP (block parity)

Block parity character

TT 1 b ! b b lb; b ; b ' b I 40
2.2

b ... b = logical exclusive OR of all characters in

the set.

SEL, STX, . .

. , ETX

7T is computed as though BP were any other character,

It is not the exclusive OR of the other parity bits,

(Sync characters are not used in forming BP).

Control Messages ACK, NAK, DCl, BEL, EOT

Message form.at common to all control messages:

SYN

c

}

at least 4 SYN

(026g)

2 repetitions of control character

{ACK, NAK, . . . }

2.2.1 ACK 0^6

Acknowledges message block just sent; trigger for

sender to send next message block. (Next message

must have a different duplicate block protect bit

in its SEL character.

)

2.2.2 NAK (?2 5

Requests retransmission of message block Just sent.

2.2.3 DCl 021

1st control message received; is equiv. to ACK . .

tells Xmitting station to send the first message

block. SEL char, must have P = 0 (see para. 2.1.1).

DCl also sent in response to BEL, at which time the

receiving station expects again P = 0 in the SEL.

41
2.2.4 BEL gi9S7

Used to Inform receiving station of delay; receiving

station will acknowledge with DCl, and will be prepared

for an SEL character with P = 0.

- -'^ 1 Use in case of card j a^is ^ transmission difficulties,

etc.

2.2.5 EOT 0!2^4 Indicates sending station has finished its transmission.

It now becomes the receiving station.

If a receiving station signals EOT instead of ACK

or NAK the sending station will stop transmitting

and assume receive status.

3.0 Summary of Control xMessages ...

3.1 Sending station:

3.1.1 - awaits '-DCl" before sending first m.essage block.

On receipt of "DCl"^ sets P bit in SEL character to

zero, formats next message from its input device,

and transmits it. Sending station awaits ACK or

NAK before transmitting next data block.

3.1.2 - on "ACK" 2 complements bit P^ formats next message

blocks and transmits it. On end of file condition

transmits "EOT''' control message ^ and assum.es receiver

status.

4-2
3.1.3 - on "NAK" , re-transmits last message block.

3.1.^ - on "EOT" J stops transmitting assumes receiver status.

3.1.5 - "BEL" can't be received.

3.1.6 - an unrecognized control message will be handled

as a "NAK".

3.1.7 - on transmission difficulties, under operator

intervention, sending station will send "BEL" to

clear line. (Example: if the RJE station experiences

a card j am.

)

Receipt of DCl v/ill resume transmission.

3.2 Receiving Station:

3.2.1 - sends "DCl" when it is ready for the first message

block. It then expects a zero P-bit in the SEL character of the first data block.

3.2.2 - on receipt of a data block (any message beginning

with "SOH"), checks to see vihether P agrees with the

expected P. If not, message is ignored, but is acknowledged with "ACK" . If so, message is checked for parity

and forwarded to its output device. If no errors, sends

"ACK" and complemionts its expected P. If there were

errors, it sends "NAK".

3.2.3 - on receipt of "BEL", resets expected P bit to zero,

and sends "DCl"

.

43
3.2.4 - on receipt of "EOT", assumes transmitter status.

3.2.5 - receipt of "DCl" is meaningless.

3.2.7 - receipt of an unrecognized control message will

result in sending ''NAK'* ,

44
FORM NBS-114A (1-71) U.S. DEPT. OF COMM. 1 . PU B LIC AT ION OR RE PORT NO. 2. Gov't Accession

BIBLIOGRAPHIC DATA No. SHEET

3. Recipient's Accession No. 30 June 1972

4. TITLE AND SUBTITLE

Use of Computer Networks in Support of Interactive Graphics

for Computer -Aided Design and Engineering

5. Publication Date

6. Performing Organization Code

7. AUTHOR(s) Marshall D. Abrams, Jerome A, Hudson, Paul Meissner,

Thomas N. Pvke, Jr., Robert M. Rosenthal. Prank H. ULmer

8. Performing Organization

N3SIR 73-217

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDS

DFPARTMFMT OF (~nNXMFRr~F

WASHINGTON, D.C. 20234

10. Project/Task/Work Unit No.

11. Contract/Grant No. 72-90013

12. Sponsoring Organization Name and Address U. S. Army Electronics Command

AMSEL-GG-OD

Ft. Monmouth, New Jersey 07703

13. Type of Report & Period Covered

InterijT_ 7/71 - 6/72

14. Sponsoring Agency Code

15. SUPPLEMENTARY NOTES

16. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here.) This report covers work performed between 1 July 1971 and 30 Jime 1972 as part of

a long-term study of interactive computer-aided techniques. The primary emphasis

during this period has been on investigating the feasibility of using conputer networks

in support of interactive graphics for conputer- aided design and engineeriiig. Alternative means for providing remote computer service have been studied. M experimental

configuration has been devised taking advantage of the fact that there is located at

the National Bureau of Standards a node of the ARPA Computer Network. Arrangements

were made via this configuration for users at the Electronics Command to utilize a

structural design program, NASTRAN, at a remote computer site. Emphasis has been

placed on the evaluation of performance of interactive design techniques using displays

supported by local and remote computers in a hierarchical arrangement. A variety of

problems are identified which must be considered in order to support interactive

graphics via a computer network; these are compounded vAiere the network itself is in

an evolving state of development. The report includes an outline of a synchronous

communication protocol which was developed for use between ECCM and N"BS.

17. KEY Vv'ORDS (Alphabetical order, separated by semicolons)

Computer-aided design; computer networks; interactive graphics, perforiiiance measurement

remote computer utilization

18. AVAILABILITY STATEMENT 19. SECURITY CLASS 21. NO. OF PAGES

(THIS REPORT)

POg UNLIMITED. 44

UNCLASSIFIED

I I FOR OFFICIAL DISTRIBUTION. DO NOT RELEASE

TO NTIS.

20. SECURITY CLASS

(THIS PAGE)

22. Pri

UNCLASSIFIED


\