AD-A12? 166 LOCAL AREA NETWORE TERMINAL MANAGEMAENT IN SUPPORT OF /STOCK POINT OGISTIC' U) NAVAL PODTGRADUATE SCHOOLMONTEREY CA 0 DBARNES DEC 82

UNCLASFED / 172. N

7mmmhhmhmmhlmmhhhhhmhmmlIr ENDmmmm

11111 , fl 32

J&.

IIIIL251

I MICROCOPY RESOLUTION TEST CHARTNATIONAL BUREAU OF SIANDARDS 1963 A

NAVAL POSTGRADUATE SCHOOLMonterey, California

to

THESISj LOCAL AREA NETWORK TFRM'NAL MANAGEMENT

IN SUPPORT OF STOCK PO.IAT LOGISTICSINTEGRATED COM~MUN1CATIONS ENVIRONM~ENT (SPLICE)

by

Jerry D. Barnes C

December 1982

Thesis Advisor: Norman Schneideind

Approved for Public Release; Distribution Unlimited

* LUJ

83 04 25 093

DISCLAIMER NOTICE

THIS DOCUMENT IS BEST QUALITYPRACTICABLE. THE COPY FURNISHEDTO DTIC CONTAINED A SIGNIFICANTNUMBER OF PAGES WHICH DO NOTREPRODUCE LEGIBLY.

I

I,-

S21Y 27 ....... ll 7i

SZCuONTY CLASSIFICATION or Tools 044g eh. Saoa. m _______________

REPORT DOUETATION PAGE 8 3700 COMPLET~h G rom1.RPR UMR GOV? *ECM 00 -RCIPmEINTS CATALOG, #iumot

4 TIL (4 SGN~ffk 1. Type or REPORT A *OGOc COVEREDLocft - etwork Terminal Management in Master's ThesisSupport of Stock Point Logistics Inte- December, 1982grated Communications Environment (SPLICE Ii. *Prnurmmom ow mepoaT ,,ume

AUTNO,.) 11 ONTRAC 0f GRANT 0dIeM8O

Jerry D. Barnes

t. OENPORMING ORGANIZATION5 NANIE AND A000ESS Ia E PO 1A WORK UISfTp*j T TAUE S K

Naval Postgraduate SchoolMonterey, California 93940

it CON TROLLING OFFICE NA me ANia LOESS Ia. RCPORT OATE

Naval Postgraduate School December, 1982Monterey, California 93940 40 U19"o AE

14. MONITORING AGENCY NAMEC a ADDRESI(5Ij# -0m , oe C.AO.515, De*5) IS. SECURITY CLASS. (Wes I. lwpsj

UNCLASSIFIED

I s. OEL rIIC A TI ON I OWNGOA 01ftG

IS6. OISTOIuUTIONt STATEMEN191T (ad 15 600.5

Approved for Public Release; Distribution Unlimited

17. DISTRIBUTION STATEMENT fee the oba deP inmd in 85000 of IIImMd hi~

am. SUP0LLMLN"TARY WOTES

IS. Cy LV .00 (Conefu. on rver". .gd 11 ...... wF ON a.. orp 00 .me.')

Terminal Management, Virtual Terminal Protocol, Network VirtualTerminal, SPLICE, Local Area Network

20. ABSTRACT (CONORW 411 006 0040 it 'NIPPOOM .M d.S ft"Im 5.6* mONeI

This thesis examines the questions of user requirements, designconsiderations, and network environment for a local area networkTerminal Management function in support of the Naval Supply System

* Command's Stock Point Logistics Integrated Communications Environ-ment (SPLICE). Criteria are developed from this examination. Theinclude process-process communication, virtual terminal, and userdefined screen capabilities as well as a negotiated (Continued)

DO ',AN 3 1473 a0TI0" oNV 4 is OUSOLaeES/N 0102-014.6S1 IEuRT CLSPICATION OF TooIs paGE ("anw

- gUT CLAW-

ABSTRACT (Continued) Block # 20

virtal ermnalprotocol based upon a network virtual terminalconcept. Recommended generic and specific models of the TerminalManagement function applying these criteria are then presented.

Accession For

jDTIC TABIC

u j

D-t

OD Foria 1473JailJ 2.q3~~SASt~tSOlYn &gi e.I..

- 102--414-- -60 2 =re-~f or__ ?----- -w-00 am 110-

Approved f,-r public raleass; di _366ibution iirlimited.

Local Area Istw~rk rerain&i Nana ementin Support of Stock Point Logiszics

Integrated .oumumizitioas Eawironment (SPLICE)

by

Jerry D. BarnasLieutenantC Commandere S-zplt Corps, United States Navy

B.S. , 3regoa State Univirstty, 1969

Submitted in partial fulfillment of therequ;jremants for the jagree of

S1ASTER OF SCIENCE IN INFORIArION SYSrEIS

from th-i

NAVAL Po~rGRADUATE SCHOOLDezamber 1982

Approved by__

r4 sis avisor

59corld Realser

---------------------------------------------Ch air I, ~tme Df kimInistrattive Sci-ences

Dein 3f Informationi and 21icy Sciences

3

*~ .............

~rThis thesis examines tae usto of user cequirements,

design considerations, aad network environmuent for a local

Interatd CmmuncatonsEnvironagit J,.PLICEI. Criteril

process communi.cation, virtual teiliall, and user definedsccren capabIlities as well as a negotiated virtual terminalI

protecol based upon a aatwock virtual term-Laal concept.

Re~ommended generic ani s ps C4- c aodels Of the Terminaltiamagement function applying t~hase c:tri rm thenpre sen~ted.

IL

Now -

TABLE OF -ONTENrS

I. INTRODUCTION . . . . . . . . . . . . . . . .

A. OBJECTIVES OF RESEARCH. ............

B. BACKGROUND ................. 9C. ADDENDUM TO RE£IHARr AND kRANA THESIS ... 10

II REQUIREMENTS DEFINITION . . . ........... 13

A. OVERVIEW . . . . . . . . . . . . . . . . . . . 13

B. STOCK POINT REqUIREmENTS . . . . . . . . . . . 1I

C. NAVSUP POLICY A.ID DERECr)q .... ......... 15

D. CDNCLUSIONS AN ASSUMPTIOIS ......... 17

III. ASPECTS OF TERMINAL MANAGEmEN. .......... 19

A. OVERVIEW . . . ................ 19B. TH TECHNICAL CONCERNS .... . ... 19

C. LOCAL AREA NETW)RK (LANJ ENVIRONMENT 21

D. GENERIC TLA M3DEL . ................ 22

E. TERMINAL MANAGEIENT APPRD&ZHES .......... .2

1. Parametric ApprD)ch-s ........... 24

2. Virtual reriinal P:otD::ols ......... 26

F. REINHART AND ARANA rM ............ 29

IV. R ECOMMENDATIONS ................. 31

A. OVERVIEW ..... .............. 31B. GENERAL RECOMISENDATIONS ........... 31

C. RECOMMENDED TM IODEL . ............ 32

1. Input/Outpat Device ...... 32

2. Local Virtail Tarminai (LVT) ........ 33

3. Network Vi:tua! Ter-ii2a! (NVT) 33

4. Virtual Decainal ProtoDol (VTP) . .

5. Session Ex1iple ............. 31,

V. THE RECOMMENDED APPROACH . . ........... 35

A. THE ASSUMPTIONS............... 36

5

B.* THE CONCEPT .. *. *.. . *.. * .. *.36

C. TM IIIPLICATIDNS ..... *. **** *37

LIST OF REFERENCES *..* * . .. 38

INITIAL DISTRIBUJTIN LIST 43 ........

6

LISt OF FIGURES

1.1 Possible Logical LAN Connazti~ns ..

3.1 Possible Physi:Il LAN Cona:tions ....... 21

3.2 Generic Terminal lanagement lodel ....... 22

4.1 Recommended TH Lllel ............ . 32

* 7

- I

A,

k. OBJECTIVES OF RESPaCH

The objective of the Stock Point Logitzic.s Integrated

Coamunications Environment (SPLICEI LDzal Area 4etwork (LAN)

Project at the Naval Postgraduite Szhool, Mcntarey, was to

develop alternatives for SLICE LAIs. The thesis subiitZei

by Lieutenant Joesph N. R.ainhart III, USMC aad Lieutenant

Ricardo Arana, Peruvian Navy [Ref. 1], concernel itself with

the development of functional desig2 specifications for the

implementation of the Database and Terminal Man.gemant fun-

tions of a functionally list-ibut-d LAN ir. rasponse to the

reguirements of the Naval Supply System's stc:c poiats ini

inventory control points.

The cbjecrives of this thesis resea=ch is to further

define the requirements DE the SPLI-E users &nd to develop

from these needs a generic model of rerminal naaeent (TM)

functions necessary to siport the 3ervices :.guired. The

rationale for using a geai ric zode-l rather thin a specific

model lies in the evolutionary state of Naval Supply Systems

Command (NAVSUP) data przessing objectives. In an execu-

tive level briefing, the S.LICE project office stated

We cannot afford the lurzry of supporting "Nvy uniqu="software packages (in tme futuces. We snoly cannotafford the resource draw (drain) Our p lj:v Must notallow Unique solutions. Our s ystems mus ft0 within thet Jc0no.ogy and capabilit_.s ol the general IDP market-.lace. fef. 2]

In keeping with that policy, this thesis will attempt to

re-camend, using the Reindirt and rnna thesis as a thecrqt-

ical foundation, a TM faactiinal s eificatioa capable of

supporting presently envisionad SPLrtC LAN configurations,

8Copy availabla to DTiC does notpermit fully legible reproduction

while presenting the ?:)ibility t3 support avolu-.ionary

ccnfigurations of the futire.

B. BACKGROUND

SPLICE, as concieved by NAVSU? iescribes - rear-tsrz

system to provide badly aeeded 1:oil and system network

colmunication and management functions without further cver-loading the present host system. It also resenns the

conceptual foundation for respones to future- chi nes to both

customer requirements i.l tezhnobo)ical advanzes. SPLICE

draws together under one :onceptual umbrella the myriad of

new applications being leveloped ialependently throughout

the supply shore ?stablishaen-.

SPLICE, in its simplest form, "s designre to provils I

hardware and software irziite:zure zapable of supqcrtinga

wi-e variety of interactive ipplizition programs on both

local and remote termin-is. Jhen filly realized this capa-

bility will significantly ceduze tha proliferation of stan

alone computlers at support sitis pes-ently unable to obtain

data processing services otherwise.

Significant faztors vwiich will I-termine the saccess of

the SPLICE concept will be the speed and accuracy of da-.a

and file transfers withini and betw-_-a LANs and tde speed,

aczuracy and ease of interictiv t-rminal sessions. It is

the latter concern which is the reason for this thesis.

NAVSUP and Fleet 91ate.ial 3uppo: Office SPLICE documen-

tation provide detailed information on SPLIZE software

design considerations (Ref. 3], systems _ascifications

[Ref. 4], functional desigt (Ref. 51, ind telec)amuaciations

plans (Ref. 6]. References 7 and 3 p:cviIe insight into the

magnitude and variety of transactions contained in typicial

applications which SPLICE -ill be expected to sapport. Asthe LAN design project, with which this thesis is

9

.. . . - _ -- --.. ..- .....- - - - -

associated, is not :oastrained by SPLICE designs and

specifications, the above referenzes were usel primarily as

a source of purpose and oojectives. Reference 1 provides a

very readable synopsis of .eferencs 3 through 5 Readers

desiring such information ire refe:r.i to sections IA and I

of that document. In ke-ping wita the objective of their

research, Reinhart and Ariaa present-d their rerommend.Ations

for Database and rermiaat Managemeat functional specifica-

tions in support of a L14. In tae name of brsvity, i

lengthy condensation of that thesis w"iI not oe providel :i

this thesis. Instead, as this th---s uses the Reinhart and

Arna thesis as a jumpiag-off point, later Ieveloom..ts

and/or information that night modify that thesis will be

presented in section C of this introluztion.

Additional insights i3to the variety and size of the

tasks expected to be processed on th- SPLICE LA. were gained

by perscnal contazts with persons attached to the SPLIE

pzject office at NAVSJP headquarters in W-shington, D.C.

and functional managers at Naval S.ipply Centers in Oaklan!

and San Diego. The int--t of th's thesis, and thersfors

these interviews, was to establish in ths author's mind a

generic definition of iat--:active pr)c--ssing rejairements so

that Terminal I.anagement (r4) alte atives might be evalu-

ated. The results of t.-ese investigative . terviews are

contained in Chapter Ii of this thesis.

C. iDDENDUM TO EIUHAR! IND AR&NA T39SIS

in their background s-aztion, 3eiahart and kzana impliel

that a commerical prodact named Terminal Application

Processinq System (TAPS) was the most probable implemenra-

tion of terminal managemeat, database management, complex

management, and transport managamea-t functioas. At the

time, that was a valid assumption nd shared by NAVSUP.

Actual responses have shaown that a significiat numb- r of

vendors respondirg the tha SPLICE 3Dlicitation p:seer thei-r

own functional mcdales to rAPS ana ir-a bidding -1cZO=1iJLngly.

This action would appear to Suppor: Reinhart and Aranalscontention that a fun_-:rally dis'6:ibuted LANT without

central complex manager is viable.

Section ID of the thesis discisses SPLIZE fainctiona2.-molementation and provid:es a Jiagram i-n its ?*igur9- 1.3 ofapossib'e 4 mplementat, or. hrn updatad vzrsi;cn of that diaq:sz

is con-tained in Referer~e 3 arl FigaI:e 1.1 belo)w.

Iim1amflted ign Software Mbda.les

FW.z

L~±.J L~....... L.J La saiti

I ot" -

[...Ref. 9: p46

Figure 1. 1 Possible Logicil LAN Connections.

11

T

Also discussei in s-:tioa ID )f Reference 1 are the

relative merits of a high level latabase qu-ry l nguage

versus the interactive ipliAztioa programs app:cach of

i NAVSUP. The thesis implies that N&VSUP shoull, ard there-

fore has yet to, investigate the fsa.sibility :f a database

• query language capabilit- within SPLICE. rhis author's

interviews and a review E NAVSUP olicy guidance in-dicate

that NAVSUP has the eventaal levelopmsnt and use of such a

query lanquage high or. their ADP pci,)ity list.

1

12

A. OVEVIEW

The method employed in attemoting to -r.ve at a

requirements definition for the Terzinal Manigem.nt (rMI

function was a series of intervi.w-s- using standard ques-

t-:ns. The interviews dare :onduztel with p-rsons at -heNaval Supply Centers at Oakland ind San Diego. These

centers were chosen primarily because of locale, but thi--

choice does not diminish the effectiveness of the inzer-

viaws. Between them, Sii Diego aid Oakland, conduct the

entire range of stock point operations, with the exception

of strateqic forces support. San Diago supports a major

fleet presence, a large training :ommand, two iajor air

stations, and numerous so)re zainteaince and aiminis-zative

cozman~s. Oakland supports a smaller fl-et presence, one

ai.r szat on, fewer shore s-ablishasats, but serves as a

clearing house for Western Pacifi- :equirements. Both

centers presently support remote ta-nina! cperatilos. Both

have implemented either or both I3 or/and APADE to varyina

degrees. These terminal based interactive applica-tion

programs are zurrently executed on stand-alonz minicorpu-

ters, but their mere existence allows th functional

managers using them to aiswer questi-ons not answerable by

managers without experience with this type of approach.

The impressions girzired froi these interviews ar-A' contained in section B below. Seat'orn C discasses informa-tion gain.ed in meetings with NAVSUP SPLICE project offic .

personnel. Section D suaaizes tne user reglirements and

associated assumptions thit will a. used throughout the

remainder of this thesi3 ln evaluatiag TM approaches.

13

B. STOCK POINT MEQUIRENEIrS

Interviews with stock point funztional managars quickly

established the presence of manageriil difficulties expectel

in trying to hold together in ongoing production effort

based on established procedures and technology while trying

to simultaneously implemeat a newe: technology. Despite

their tribulations, these managers were most willing to

shire their experiences ta date with terminal based interac-

tive application programs.

Both IDA and APADE are designed :o utilize a menu-driven

form mode of interactive ita entry ini file inguiry/update.

Both have extensive process options available to the

terminal user.

The APADE users, primarily in th. purchasing division of

the Procurement Department, !)gicalLy and physically sepa-

rate data entry functions from data iaguiry/update

functions. This is basel mostly uD time constraints of

data entry and the volume of these transactioas. The T4

imDlications of this separation is that the data entry

clerks would be best served by the least creative, leastcomplicated T4 that woull still sipport interact ive for

data entry, i.e., when finished with one form, the user

wants another form immediately, not a aelpful but neverthe-

less key-stroke consuming mena. ]I the other hand their

co-wcrkers who are responsible for har.ling a rather large

number of document iagiries fro not aloays patient

customers would find the aoility to split their screen into

multiple sections and to coaduct a separate inguiry or

update in each section very helpful. The purzzasing admin-

istrative personnel ire frequentLy asked to produce

information (written and oral) that requires multiple access

to files and/or manual minipulation of the data accessed.

The primary ca use of their effort is -hat they are

con strained by the f Drimaits, both isplay and reports,

designed into the system. Phe zzapability to design a

multiple-use screen ani report fo)rzat at the termIna. isindicated.

The IDA users, financial accouating, commonly referred

to as Triple-N, do not separate- their dazta entry from

inquiry/update. Each clerk who has a terminal has often

foind himself inthe situAtion of naeing to view a record

from more then ore file. rhis situatLon is especially preva-leat when reconciling vendor i6nvo1=ces with requisitions.

This need is presently met by zalliag a clerk who has accessto the recessary files (XPADE or UU ? S) and passing the

necessary informatiJon by pione -- iai:omatio_-n inleed!The Customer Services personnel primarily interface with

the UADPS appli catios rzsid-ng on :he Burroughs host main-

f raime. Their interaction with the zomputerr is varied, but

basically inquiry In nature. Data -entry is normally batchprocessed, and will in all likelhood remaiLn so until OCR

technology replaces the current card :aaders. Because most

queries are made to rec-ords stored and processed in 80

column card format, a scrolIl-mo)de te-:ainal pressntation with

the ability to ccntirually enter guerz--es and !direct replies

to a nearby printer i-s the near- concensus choice for

terina ineraction. k less frequent icti:vity conducted by

Customer Services- personnel regaiies them to spend hours

researching and cross referenrcing re-ords from various UADPS

and financial files (now IDA files) . This :easeazrch isnormally conducted by tbhe tost experlaenced and senior clerks

ani supervisors in the livision, so it would seem that

countless hours could be saved, not to me-ition dollars, ifthese persons could break away from the standard displays to

vh".ch they are now 1Lited and set up a screen displaysuitable for researching and controlling the source ofdi-splay input.

In warehousing and material receipt functions, -he use

of automation has just begun, primarily in stowage and

retrieval operations. The day of tie use of bar ccdes and

light pens for receipt processing and inventory management

is still somewhat distant. Although there is good reason to

suspect that these devices should ba considered peripherals

and therefore not within the purview of this thesis, the

author can envision a scenario where they would be direct

input devices to severil UADPS a~pitation programs. As

suoh, the author has chosen to in .e them i athe category

of potential terminals.

C. NIYSUP POLICY AND DIREITION

In addition to a survey of szork point psrsonnel, a trip

was made to Washington, D.C. to maet with SPLICE project

office personnel. The objective of th- meetings was to gain

an appreciation for the lirection of SPLICE LA~s. Although

the development of a generic T4 model from requ'irement needs

is deemed academically justifiable, there remained the

co.cern that to stray t3o far fros the realities of the

Naval Supply System woula -esult i an academic exercise of

little import. The quotation cited in Chapter I, Objectives

of Research setion, conviaced this a:hor that such a model

coild in fact be of use, particularly it view Df the iesire

to move away from "Navy uaique" softare. The functional T3

model presented in Chapter IV repressnts the autror's lesire

to produce a recommendation for the near future, and there-

fore embraces the reality of the SPLICE environment mor

- than the generic TM model presented in Chapter IlI.

Additional information gained fzom thee meetings

included familiarization with the long-term ooJectives of

SPLICE implementation. ALthough th-e objectives do not fit

the category of user requirements, taey ara paraphased below

.........

because failure to keep them in miad in a dasigr p:--cess

increases the probability that the -esultant design may too

restrictive to be of value in meeting future growth.

- Data must be made ivailable to the customer, easily

accessed from wherever tie customer is located on a conti-

nuous basis around the clock.- A distributed data base must be developed.

_ojs 121 JjAVSUP AD?

- All punched cards ziist be elizinated.- The use of point-of-sale tarminals ani hand held

terminals with optical strnning z-pibiliies at data entry

points.

- The use of bar coda and magnetic strips in inventory

control and warehousing applications.

D. CONCLUSIONS AND ASSURPrIONS

The following conclsions regarding the TM requirements

of users of the SPLICE LAN are bised upon tae interviewsdiscussed above and observations of -erminal use at stock

points. Assumptions based upoa the same observations

coapled with -he author's experi.ence in st-ock point

operations.

1. A TM must be able to support a wide varisty of termi-nals, varied not only in nake/model, but also in cperational

character istics.

2. A TM must be able to sappo.t character, lire, page,scroll, and form mode editing =ipab'iltes at the same

term i nal.

3. A TM should provide the ability for a user to locally

format a display area, and resultant hardcopy output.

17

--V - .- *

4. A user should be able to simultaneously display

mult-iple processes utilizig diffeceit application programs.

5. A TM should provide the mechanism to allow applica-

tion to application interaction (author's assumption)

6. A TM should be able to suppDrt non-interactive data

entry, such as light pens and hind-held ):R (author's

assumpt. ion).

7. A TM should provide a generil framework within which

future terminal functions cin be iccomodat d (author's

assumpticn).

8. A TM design must rezogniza the rlelative lack of

sophist*icxation cf potentiLl isers vid the probability of

high turnover in these positions.

I

18

A. OVERVIEW

In addition to the user ragairements discussed in

Chapter II, investigatioi and evaliation of alternai've TM

techniques requires an ippreciati on for the technical

concerns of a TM. Section B discusses these ccncerns.

Section C outlines the LkN environment assu-ze for ths

thesis. Section D presents the authD-'s view of a generc r1

molel. Section E then explores son.e of the r4 approaches

cited in contemporary literature. Section F contains a

review of the TM approach advocated by Reinhart anr Arana(aef. 1 ].

B. T1 TECHNICAL CONCERNS

TM, as a list of widely agreed to discrete functions and

protocols, does not exis:. Rather, there exists an impres-

sive, if somewhat confusi .j, spectrln of alternative methods

of implementing a TM. )a the most ambitious end of this

spectrum is a TM module ihich provides the fill range of

functions described in the Presentation Layer (layer 6) of

the International Standarle Organiza:in (ISO) 3pen Systems

Interconnection (SI) referenze na5.l. One .f the many

definitions of the task of the Presintation Layer "...is to

support communications by providing commonly known virtual

devices and commonly known virtuil information to tha

distributed applications" Ref. 10: p. 227]. A less amb-

tious TM would be zoectel only to "hide terminaljdiosyncracies from the iplicition programs" Ref. 11: p.

484]. The latter repres-ting a sabset of the former.

19

It is helpful to try to describe the design conce:ns of

a TM and then to blend these concerns with user requirements

to form a model of the ideal or eneric TM which would

recognize both the designer's and ,sa.r's concerns.

A suggested list of concerns of the T1 designer is

found in Reference 12 (pp. 82-84). Thase concerns are:

1) C oDjp_ 2f th_e jeQin al gandling - Assuming the wide

r variety cf terminals and ittendant variety of characteris-

tics, the parameters which affect local handling of a

terminal must be known to the rM, and to nc other LAN module

nor to remote users.

2) D a e de - rlie rM sh o ld provide methods for

selecting/providing support for boti half-duplex or full-

duplex operations.3) Tkmal ata Stu ure - Lik? terminal control char-

acteristics, the TM must be aware of the data structureparameters of the terminal as well as the command language

primitives available for minipilation of that structure.

4) SyRnet g - The desiqn of the TM must be concernedwith the desirability of symmetries! forms of connection,

e.g. process-proceess and t:erminal-te: inal interactions

5) fteqotiiai!o.s - :he TM must provide-- a dynamizmechanism ro negotiate th.e fac-iliti.es and parameters to be

used in each interconnection.

6) Attejt:ions - The ri must be :apable of interpr.ttiniand handling the variety of methods used in te=rminals and

processes to signal "breac,, "abort", and other such atten-

tion commands. These signals are normally expedited signals

"out-of-band" or outside tie normal flow of data.

23

AA

- - - - - - - - --. . . . ..-------- -T- -

C. LOCAL AREA NETWORK (LAN) ENVIRONIENT

The LAN environment ia which thz T3 beirg discussed in

this thesis will operate is a fully distributed LAN based

upr. seven primary functional softwcve modules; local commu-

nications, national conmaiications, front-end processing,

session services, terminal manigemant, databasei zanagemea ,

and peripheral management. Figure 1.1 Introduced th logical

connecti.ons of this LAN. Figura 3.1 presents a possible

physical connection confi; uration.

~I--~ o,-I e " ... 0

Free.

owt. me

~tm1 ftguumi Map

NW. -MAi Chstcla VithusA

IVRe. 9:Mo p. 4-7]

SFigure 3.1 Possible Physical L&aI Connections.

21

.. 1IIII I....... : vin

wpm.

This thesis also assuies - muJltLplexed data/cont:o. bus

capable of supporting half and full-duplex coamunications.Further, it is assumed that the terminals connected or

potentially connectable to this LA.9 are hetro ene.ous ani

that the hetrogenous mix dill be in & constant state of flux

during the next decade.

D. GENERIC TN MODEL

Given the user requiremenzs, design concerns, and envi-

ronmental assumptions developel abov., Figure 3.2 presents

the authcrls attempt to meet these =riteria w-.th a generi

TM model.

PHYSICAL

INPUT

DEVICE

PHYSICAL TERMINAL APPLICATIOD~~~DEVICE ---

i HADLERPROCESS PROCESS

, PHYSICAL

DEVICE TERMINAL

_jAPLICATION! PROTOCOLI

Figure 32 Generic Terminal linagement Model.

22

-- - -- - - --- '

Figure 3.2 has the following components:

1) A generic taratnal with in inpat capability

(keyboard, light pen, optical scanner, etc.) anJ an optional

output device (CRT screen, signal light, teletype, etc.).

2) A device or module which Za a.darstand the signnls

coaing from the input device and can send signals to the

output device which it cai rezognize. This component also

has a command language of its own which allows tha aser to

design an output display iad to map tore than orie prccess to

that display.

3) This component re)resents t%e terminal in dealings

with the application proc-ess (one per processl. It also

builds and manipulates a terminal lata structare for each

Process.4) This component represents the applicatiDn program in

dealings wi-h the termial process (one per rocess). it

also builds and manipulates an application data structure.

for each process.

5) This component -ats the riles for aad format ofcommunications between the terminal processes and applica-

tion processes (for all processes).

In the most simplistic terms omponents 3 and 4 aze

attorneys for their clients, the tsrminal and the applica-

tion program, respecti-ely. They, aad only they, know their

clients capabilities and expectations. Both ar. very strong

willed and therefore need an arbitrator (component 5) to

ensure that communicatin-s are meaningful ind properly

coo rd ina ted.

At this point t his model simply provides an ideal T1

whose generic components, if implemented idally, wouli

provide a modular TM capLble of meeting user requiremeats

and design concerns while having the flexibility to respond

to changes. A recommended spacific implementi:ion of this

model will be presented in Chapter IV.

23

E. TERMINAL R&IAGEMENT APPROACHES

Approaches to TM ran be generally discussed in two

broad, and unfortunately aot mutually exclusive, categories;

parametric and virtual terminal.

1. karaztuic Apna2az:es

Generally, paramstric teriial protocols attempt to

list a set of terminal rhararteristizs with sach type of

terminal having a diffzere t set of pirameters f~r each char-

acteristic. The host zomputer may then set tai parameters

available on that terminal to ialues neeled for the

process/application [Ref. 12: pp. 8-86].

This approach is used by the ARPkRET Telenet

protocol and by systems impleB3enting Interna-tional

Consultative Committee for Telsphoaes and Telegraphs (CCITT)

recommendat ions.

When evaluating these two approaches the IRPAgEr

Terminal Interface Processor (rIP) is compa=e9 to the ccirr

Pazket Assemblpr/Disassembler (PAD). Both approaches use a

primitive command langua-= to open aid close connections ar.

to set terminal parameters. The prizary differencs being

the perceive role each plays in the network architectura.

In the ARPANET the TIP is a iimit=e =rapabili-y logical host

with knowledge of terminal par met ars. Wh=er as, ths CCITT

considers a PAD an integral part of ":he network acting as an

interface between data terminating equipment (DZE). A DTE

can be either a host or a terminal [Ref. 12: pp. 84-86],

[Ref. 13: pp. 335-348], [Raf. 14: pp. 586-587].

The PAD cited in TITT proto:ols is the mosz compre-

hensively defined pa-amett'c approaci to terminal handling.

There are three basic approved rerommeniazions covering

oparation o: the PAD; X.3 4hich defies the PAD itself, X.28defines the interface between the terminal and the PAD, an

2I4

- - ...... ..........

X.29 defines the interfare between the PAD and the host

(Ref. 12: pp. 84-86].

The shortcoming of these approaches is that the PAD

protocols provide no geneic fuzcti):s. They assume thatthe application in the host knows what the teruinal will do

and that the terminal will do what is intsa.dd Rief. 14:

pp. 586-5871.Telenet' s Intera=tive Terninal Intecfaca (Ir£I

provides an enhanced set 3f paramt rs which helps offload

sone cf the terminal handling rEsponsibili-ies from the

host. Telenet offers a farther refinament called a virtual

terminal which includes a few generiz f-inctioas on top of

the ITI parameters. Ln.ortunately, the ARPNET vir:ual

terminal w as designed primarily to support scroll-type

terminals which have mach fewer parameters than more

sophisticated page and form mode terminals. Although the

list of parameters was extended, few of the options (parame-

tric values) were implemeated [Ref. 14: pp. 586-587].

Both these approaches are most suitable for

providing TM for existing terminals, the more h:mogeni-y the

better. To be really useful, these fancti.ons should be

standardized so that tie host sy-stem can rely upon a

PAD/interface with known properties. Even with sr- riza-

tion the envolvement of the host sys:?_ in TM wui %-till be

extensive or the list of ?AD/interfa.=: parameters would beenormous (Ref. 13: pp. 347-348].

As several of the user requirements and design

concerns discussed earlie imply the need for the greatest

amount of transparency achievable ind further iiply an

n.reasirng number and vriety of terminals, the parametri:

approaches appear too limited.

25

Virtual Terminal Protocols (VTP) have undergone

significant evolution since the first VTP was placed in ise

by the ARPANET. This FTP was de3s-gned primarily with

scroll-mode terminals in mind. It is based upon three basic

principles; the concept of a 'network virrual te:ml.nall, the

concept of negotiation of options, aal a symm:etrical view o!

terminals and processes [a.f. 12: p. 88] [Ref. i4: p. 588].

This first VTP laid very firm grouni for further sophistica-

tion of the Virtual Terni~al (VT). UJfortunately, although

the Telenet VTP was designed with fifty-Iight parameters,

very few were actually imlemented. It therefore remains to

explore a few more of the many VrP approaches developed

since the ARPANET VTP.

A model which fozases on page and fora mode termi-

nals was developed by Schizker and Da._nki. It is used in the

European Informatics Netdork (EI4I) and is I-scribed in

Reference 15 (p. 485). rhis model is called a data struc-

ture model. In it a data structure is viewed as containin4

a set of fields each of wh" ch has ca:tain a:tributes such as

size of the field, what type of characters It contains,

whe.rher cr not the field -in be modified by the user, qtc.

This definition of a data structuz = has become widely

accepted and will be used in the r-nainder cf this thesis.

This model assumes that a. lication programs are written to

perform abstract operations on a data structure and that the

rezote (user) process has 5 similar iata structare. The VTO

is the mechanism by which the changes made by the applica-

tion process to its data structur are passed to the aser

process so that its data stractuce can be changed accord-

ingly, and vice versa.

25

- -- '

A refinement of the dlat structure model is

described in Reference 13 (pp. 362-355). In this model a

terminal has a data str a-ture and a controlling process

called a "T-PAD" with a relationship much lik_ that

described in the parametric approach in subsection 1 of this

section. Similarly, the host system has a data structure

with which it is desi;nz-1 to inteaict via a controlling

process called an "S-PAD". The messages passed between

these two "PADs" to negotiate the data structure and the

available commands to mnipulate the data structure are

contained in the VTP. Ti.e appeal of this approach is two-

fold; the S-PAD implies a NVT concept such as lascribed by

Tanenbaum in Reference 15 (p. 4231, where a NVT is an

abstract terminal the characteristics of which are assumea

by all interactive application progrims; secondly, a symme-

trical approach such as t.is allows not only the traditional

tarminal to application interaction, but also terminal to

terminal and application to applicatioa interaction, given a

sufficiently adept VTP. The utility of such capabilities

can be shown in a common Stock Point scenario. This scen-

ario exists when an application pro;=am, such as APADE,

creates records that are duplicated or enter - . into files

necessary to the correct operation of anothec application

program, such as IDA. For instance, the astablishaent of a

cotract, which requires a record ipdate in an APADE file,

also necessitates an update of a fiancial re=cord in an D

-4file. Such changes can be made by bitch processing (current

practice) or by application to application interaction such

as made possible by a T4 "iplementina this type of model.

The apprcach above is very .-imilar in fnction, if

not vocabulary, to the NV? envisionel for ARPANET's Telenet

protocol and the INWG VrP. All are deemed symmet-ical in

that each side of a session has its own view of the state of

the VT (Retf. 1: p. 589]. Tis as opposed to an

27

asymmetrical model where the VT is :onsidered only from the

perspective of the application progria. In such a model the

physical terminal is transformed by software to appear as a

VT to the application pro;ram [Ref. 16: p. 304]. This

approach cannot support terminal to terminal or process to

process interaction [Ref. 14: p. 588].In each of the vr concepts described the VT's are

supported by two elementary protocols; a virtual terminal

display data transformation protocol and a cont:ol protocol.The data transformation protocol maps display commands fromthe sending process into the prescribed input data formats

*for the receiving process. The coatrol process exchanges

non-display information for coo:dinating interactions[Ref. 17: p. 85].

A more expansive approach -s offered in Reference

10. In this approach three ibstractions (virtualizations)are proposed; a virtual device, a conceptual data type

definticn, and a conceptail image. Thc? virtail device isconsidered an association between a definition of a struc-ture for a (device) data object and a set of ope.rations

which are the orly means for accessiag this (levice) dataobject. The conceptual data type lefinition : a simila=

asecciation, but with -regard to th- szzucturE of data andthe operations which 2ay be p-.fo.:ed on lara structure

objects. The conceptual image is considered a Ifini:icn ofthe means by which a mapping of the aDnceptual data o. the

virtual device is obtained. The thrust of -his concept is

that in a hetrogenous nstwork, assiaptions regarding inden-

tical virtual devices and data structures may not be

desireable and possibly aot practi.-ally viable. Only an

agreement of negotiated parameters need be known by each

partner. The authors wrote a follow-on article, (Ref. 18],

in which they presented a detailed recommendation of the

protocols and options for each of these virtualizations.

23

All of the above approaches :eguire the negot-ations

of options/parameters to be used in a session, be they

device characteristics, data s:ructure o- commands.

Negotiations are either asynchronous or master-slave (synch-

ronous) depending on the symmetry of the interac-tion and the

trust the designers place in whaterer mechanism they mayhave implemented to resolve negotiation d.ailocks. The

literature regarding negotiation al.orithms seems polarized

with each side singing ths praises )f -their approach. The

author's preference is included in the TH modlal presented in

Chapter iV.

F. REINHART MID ARANA rN

In Reference I (p. 55), th- iathors proposed a TI

approach based upon a "Vitual terminal" manag zent concept.

The primary feature of their VT is that it "... converts a

single physical terminal into multiple virtual terminals,

each of which may be writ rn into or gueried for input". To

support this concept the idea of a user defined screen

con figuration is propose. This iould allow a user to

diwide his screen into ,'windows" a an of which cn-ans the

display of a separate process. klthough only one window/

process would be active at a given mmens., it is clear thatthe implementation of this concept iould satisfy severL.l -

the requirements and concerns a.:essed earlier in this

thesis.

The thesis also discuss on page 74 the use of a generic

terminal transformation tiole. rhis table, as proposed by

Hillsberg [Ref. 19] is ased to convert specific physical

terminal sub-functions to generic zoamands and vice versa.

Although this thesis owes its rots to the Reinhart and

Arna effort, subsequent readings ani investigation havq lei

this author to step back from lost of the specifics

* _ _ _ -29

Iprasented in their thesis ind mova tvward a broade- concept

for TH functional specification usi2g their coazepts as an

inspiration.

I3

- - -. ----- ----- - - ---

IV_. O_ HI2S

A. OVEEVIEW

The recommendations :ontained in this chap-er are a

marriage of the generic ri model prseanted arl the variety

of specific approaches liszussed in :hapter III. The result

is a specific mcdel consisting of cozponents and protocols

interfacing those components. General recommendations ar.

listed in section B below. Sectioa Z presents the recom-

mended model.

B. GENERAL RECOMEDATIONS

1) The TM should be based upon the concept of a NVT.

Eazh application program should be aals to assume that i.t 4i3

dealing with a terminal where the default parameters will be

used unless the user negotiates different parameters using

the NVT capability.

i 2) The TM should support the highest level of abstrac-

tion technologically available.

3) Negotiation of devize definitions should be hierarch-

ica . Standard classes of terminals definina mandatorych.racteristics (minimum Dirameter values) shoild reside at

the highest levels of the hierarchy. 3ptior.al (aeqotiatible

operations should reside at lower levels.

4) The TM should support user defined .creen format for

use in both displaying aultiple processes aad designing

display and possible report format.

31

C. RECOIHlEIDED TH HODEL.

Figure 4.1 presents the TeraLnal Management lodel.

:ezommended by the author. rhe :zaponents are sxplaine!

below.

L V T JN V T

TERMINAL APPLICATION

TERMINAL PAPPLICATION

TERMINAL APPLICATION PROGRAM

DATA DATA

STRUCTURE STRUCTURE

ai -----

Fiqure 4.1 Recomnendet rn Model.

A terminal is viewed as two separate devices. The

separation recognizes that a LAN may recieve input from

devices that have no outpit capability, e.g. light pens, 3CR

scanners, etc. The T4 aust be able to handlt 3 inputs froisuch devices. Additionally, the ability to transform and

control inputs is conceived to be totally separated from the

ability to contrc. and map output.

32

,,.. i. j

The function of the LVT is to hide the idiosychra-

cies of the user terminal from the LAN and to map its data

structure and any changes to that structure to the terminal

display device. The LVT =onsists of a terminal process (TPI

component and a iisk-basel terminal lata structure (TDS).

The TP utilizes a geaeric terminal transformation

table (see Ref 19) to virtualize tarminal sub-functions and

a hierarchically organized set of terminal primitives and

parameters as discussed in paragraph 8.3 above. The TP also

uses a user defined map of the scresi display for output.

The TP is responsible for representing the terminal

in negotiations with the applicatiDa process (or anotherTPI . It is also respoasible for napping terminal input

cosmands to the rDS and for mapping TDS changes to the

output unit. These functions are ;cparable to the "T-PAD"

discussed in Reference 13 and :'hapter UI.

3. vjt~~oj Vjtual Ja2a_ ar

The NVT is configured identizally to the LVT with an

application process (AP) in plice of the TP. rh- AP has the

same data structure molifications r-soonsibiii:ies, except

that it takes orders from and reports zhanges to an applica-

tion program as opposed to a terminal.

The major conceptual difference between the .VT and

the LVT is that the NVT is a parametr'c model of the artirs

network's concept of a terminal. Its primitives and parame-

ters are fixed. The application program's requirements are

met by passing necessary ?arameter values to the AP. Note

that the number of parameters are fixed, but that each

parameter may offer more than one option (value). The AP

then represents the appliration prog am in negotiations with

the T? as to what values will actually be used. Obviously,

33

_ __.. ... .... . .. .. ,

the AP will not agree to any parametric values lower thatthe program requires, bat it may agree to higher values

should the TP insist. The AP hilas all negotiatied values

from the program except those that tie program expects.

The VTP is a message based protocol with several

functions, discussed here in chronological order. The VTP

controls the the exchang- of negotiation messages between

the TP and AP. During th.se negotiations the primitives and

parameter values of control messages are selected as well as

the con-ents of the data structure. The recommended negoti-

a-ior protocol will be zplained i the session example

below. Cnce all values are set, the VTP becomes responsible

for passing control messages betw-e the TP and AP for the

maa ipulation of their respective 1ata structures. In

ful fillinq this responsibility, the VTP controls the

seluencirg of messages ac=Drding t3 the communication method

selected during r.egotiations, i.e., alternating or free-

running, and dictates the format of these messages.

5. je

a) The user logs on his terminal identifying himself

and the terminal ID. Ier2inal ID --n be done automatically

if the capability exists.

b) The TP will compute the cozmand signals needed to

handle this particular terminal u;ing the transformation

table. The TP will then bagin a sczee formatting subroutine

conversation with the user, in which the first user response

- may result in a default s-reen. (aot.: asking the question

rather than waiting for the user to request screen format-

ting should evoke curiosity and quic(en the learzing process

for this feature) This routine will zonstruct the output map

for the TPs subsequent interaction sith the ouzput device.

3!4

II

C) Once the user has defined the screen format

desired, the first (and possibly oaly) command to call an

application program is entared.

d) The TP passes this message to the LAN which may

need to send it out to tha long-haul neztwork.

e) The destination nole will establish an AP to

which the application program passes its termiaal and data

structure requirements. it this point, and throughout the

negotiation process, the VP is ensuring one-way

coiumunications.

f) Once negotiatiois have bee comole:ed, the appli-

cation program directs the AP to set the initial state of

its data structure. Upoi doing so, the AP, asing the VTP

message format, passes the agreed lita structure instruc-

tions to the TP which both creates an identical initial

state in its lata struztu.e and maos the lata structure to

the user-defined screen format.

g) At this point the VTP may allow free-running

(asychror.ous) communications if both parties can support

suh.

Sh when the appli.ation program is completed, the

ccnnecticn is severed and the TP bagins its user dialouge

ane w.Admittedly, this TM model Is a compromise between

the generic goals presented i-. Chapt.r III and the practical

J.mplications of NAVSUP's 1-3dicition to applicttion programs.

A more esthetically pleasilg concept is outlined in Chapter

V.

35

t

V. ZL ~lUI ~hl

A. THE ASSU PTI Sc h

The concept discussed in this chapter is a recommenda-

tiorn for the future. tt is bise on the follcwing

assumptions:

1) NAVSUP is will.ing to abandon the levelopment and useof application programs in. favor of fEnctional modules and a

distributed database systea.

2) NAVSUP defines the set of gueries and reports it

wishes the system to provide.

3) NAVSUP is willing to allow increased local flexi-

bility in the design of display an :eport formats.

B. THE CONCEPT

Given the above assuiptions, the envisioned data base

system wculd be built by ase of a dita base ',1--signer , and

program generator such as discassed ia Reference 23 . rde

basic tool of this buillin; process is called a Hierarchical

Interactive Query (HI-I)I language. The result of this

process would be a database capable. of supporting programs

written in a COBOL Data Manipulation Language (OHL) for data

entry and inquiry. The primary charin f this concept is the

reduction of redundant reaord field in different applica-

tion files and the concomitant reduction in required file

splce. Given that there i:e only tw3 primary fields forming

the backbone of the vast m2jority of stock point and inven-

tory control point transactions, the requisition number

(order number) and the National Stock Number (or part

number), the concept of i hierar:hica3 data base system to

support what is now 3uooorted by 9ADPS file managementprograms is not so far-fetzhed.

35

I' _ _ _

A second enhancement this approa. h offers is the elimi-

nation of the need for applization to application

4nteraction, be it batch or interactive. Because the finan-

cial data field for a UADPS requisition entry is the same

field used in IDA, the need for passing this iraforaa-ion to

the IDA application progrir for entry is eliminated.

C. TH IMPLICATIONS

Adoption of the systen described above would not neces-

si:ate scraping the TM ze:oimendel in Chapter IV, but t:

fully capitalize on th _ benefits of the system, certain

changes would be necessary.

The most important zhange wouli be to enhance the

Terminal Process (TP) by providing it with a data stzucturs

description language whiza would loizally be a subset of

the system's Data Manip larion Language (DML). This

language would be available to a a3_r to name fields and

zones and for defining tae attribitas and dimensions of

such. This capability would enable users to easily design

screen and report formats tailDrel t: their needs. But, such

a capability would require a rethinking of che application

program's master role in establishing data structure

parameters.

As this concept would move away from th- application

emphasis on form or page lasigns ia data structures, changes

would also be necessary in NVT an! VTP paraieters. Both

could be simplified becas.s they wouLd not have to be struc-

tured to support a myrial of often conflictin; application

programs.

Should the assumptions in sectioa A evolve , the concept

outlined in this chapter is strongly recommended for further

study.

Copy available to ETIC' E'L ",.permit fully legible topioductio:.

37

LIST 3F RZERENZES

1. Rsinhart, 4oesph N. III and &can&, 114-ardo Datiase"TE-111 Ii ragjm elt Funct15all = fes

2. Informal communications w th Naval Suoply SystemsCommiand personnel, September, 1982.

3. U.S. Navy Fleet latarial Sup3P7t Office1 EnvironmentD--vision: Code 91441, Stock o~nt oaistizs Tpts.t~ommun.jtij la t;:2n rV

4. Feet Material. Suo pct Office Dapa:tment of the Navy,Document No. F9&LO-O Oi-9255-SS-SUO1, it ck f at

5. Fleet Material Support Officz Departmnet f the Navy,Dccument No. FLL-00 O-92-35- F-DSU3,- 12tc PoZ.t

6. Naval Supply* Systeas Commani (Code 341I51 LogaisticsTel.ecom- muni.cations Branch, SPLICE TQ'ez31nMa~5.bsvsscm j~aJ2t RIin ( NgrkTl

7. Naval Supply Systens Conmani (:ode Ou1), :nteq-atedD sbu-sement and A:mICunrinj. Da'a ?xchan

a. na Val Supply Syst!eus Commani (Code 0U441, AADEalystemms.::-0a z ;y A3t Study, May 1: 991.

9. Schreilewind, Norzaa F. Furctioral De:I of A Loa

A;21U~two;_h1g Sto c F-r5o.st__ W

It T he- Presentation Serv,-:e M od e.1II o"!t

Co 4 V4rvy ,l).13, N3..4, pp. 453-L489 ,December

33 Copy available to TITIC dc,!,: not

permit f!.N".

12. Day oJol'n D. "Termiaal, File r ransfer, and Remote JobPro ol2s for EIqtrogeneoiis Cumpuder Networks".Protocols for Data Zommunication Netwoiks, Franklin F.

13. Davies, D. W.; Barber, D. L.; Price, W. L.; andScocmoniles Compte: Nltyork3 and Their Pr2-------SJoan Wiley anfofv ~ . tcl

14i. Day, JohnD. "Terminal Protozols,' IFFE rransaction-S

15. Tanenibaum, An~raii S., 221puter Networks,Prent2.ce-Hall, InZ.F 1981-----

16. Hagnee, F. "Ai Survey of rermial Protoco's" Coinou ZerNetwors, Vol. 3, pp. 293-314, November, 1974 --.-

17. Stack, Thomas R. and D-llncourt, Kathleen A."Protocols for Local Area Networks",. 'EE 1980 Trendsanda API Ioans: ;Z2mpqter Network 4_:r32a p

18. Schiniler, S-gram; Flasche, 36t-; and Bor7-anrn, Carszen,IIOSI - Level 6 Protocols", mot C-;Impr,:cat"ns,Vo:1. 5, No. 2, pp. 79-95f fAprif7Yr f-

19. Hillsberg, B.L. "Generic Terminal SUDOO~t"rAssoci.ation for Computin; mazhrs:y,, O-zerat". a =i-Revlew, Vol. 15, 1o 2, Apri 1981.-

20. Gerritsen, Rob "A Ptzel-Iminary.Sys, em for ths Design ofDBTG Data Structucem" Comnza- ' ons of .ae ACI, Vol.18, No- 10, PP.-5;~7~~fg5

3;

IINITIAL D[STRIBOTI3 LIST

No. Ccpies

1. Defense Tech.picai Ir.formation Z-nter 2Cameron $tat:-nAlexandria, Virginia 22314

2. Library, Code 0142 2Naval Postqraduate SzhoolMonterey, California 93940

3. Professor N.F. Sc~neilewipd, -_- 54SS 2Department ;f Adm~iastratve Sc-_-ncesNaval Posti aduate SzhoclMonterey, Cali;fornia 93940

4. Professor Norman . Ltons, Cole. 54LBDepartment of AdmiLns rative Sz._ ncesNaval Postqraduate SzhoolMonterey, California 93940

5. Naval Postgraduate S:-oolComputer Technology :urrccular DfficeCode 37Monterey, California 93940

6. LCDR J. D. Barnes S-' USN 2Commander Naval 1upoiy Systems -ommandCode 041 5i14Washington D.C. 20375

7. Ms. Mary WilloughbyP.O. Box 94Mendocino, CA 95460

8. LCDR Dana Full-1Commander, Naval Supply Systems :ommandCode 04151Washington D.C. 20375

9. LCDR Ted TaseFlet Material Suport OfficeCode 94LMechanicsburg, PA 17355

I43

............

-i--I-~i-- -- -- ---.- - - - - - -- - - --i