-At,2 O16 INTEGRATED INFORMATION SUPPORT SYSTEM (IISS) VOLUME 5 1/1COMMON DATA MODEL S (U) GENERAL ELECTRIC COSCHENECTADY NY PRODUCTION RESOURCES CONSU

UdCLASIFIED J L ALTHOFF Ii NOV 85 D5-626141338 F/G 12/5 UL

EhlllhEllllEE////III/II///3 smmo

MOCROCOPy RESOLUTONI TEST CHART

AD-A182 016 F rii Cof 1

AFVAL-TR-86-4006Volume VPart 30

INTEGRATED INFORMATIONSUPPORT SYSTEM (IISS)Volume V - Common Data Model SubsystemPart 30 - File Utilities Development Specification

General Electric Company D TICProduction Resources Consulting A ZLECTE4One River RoadSchenectady, New York 12345 JUL 07 W7

Final Report for Period 22 September 1980 - 31 July 1985

November 1985

Approved for public release; distribution is unlimited.

MATERIALS LABORATORYAIR FORCE WRIGHT AERONAUTICAL LABORATORIESAIR FORCE SYSTEMS COMMANDWRIGHT-PATTERSON AFB, OH 45433-6533

• cN: T "II" II 'i :f'f, Y. , '. 'r, . ., 2 .)

NOTICE

When Government drawings specifications. or other data are used for any purpose other thanin connection with a definitely related Government procurement operation, the United StatesGovernment thereby incurs no responsibility nor any obligation whatsoever, and the fact that thegovernment may have formulated, furnished, or in any way supplied the said drawings.specifications. or other data. is not to be regarded by implication or otherwise as in anymanner licensing the holder or any other person or corporation, or conveying any rights orpermission to manufacture, use. or sell any patented invention that may in any way be relatedthereto

This report has been reviewed by the Office of Public Affairs (ASD/PA) and is releasable to theNational Technical Information Service (NTIS) At NTIS. it will be available to the generalpublic including foreign nations.

This technical repo has been reviewed and is approved for publication.

DA ID L.IJUDION' PROJECT MANAGER DA TE

'IGHT PATTERSON AFB OH 45433

FOR THE COMMANDER.

"__ C2 'EFALD C. SHUMAKER, BRANCH CHIEF DATE

AFWAL/ML TCWRIGHT PATTERSON AFB OH 45433

"ff your address has changed, if you wish to be removed from our mailing list, or if theaddressee is no longer employed by your organization please notify AFWALUMLTC, W-PAFB, OH45433 to help us maintain a current mailing list."

Copies of this report should not be returned unless return is required by security cn ri ,,,contractual obligations, or notice on a specific document

'. -1

Unclassified4G8ChJt.,W Ci.S 0eSATlO'. of Two$ VAGN~

REPORT DOCUMENTATION PAGE

a& 5CW.ITv C,.A~js39.GT,@ AWTNORITW 3 *SIUYh.v.AItOf RAPOI

Approved for public release.zs P~ha~s~~a~a.,swtefta~hCSuI*b.Idistribution Is unilated.

41 VPLRPORMOINI O^QAhtIZA?IO% A&PORaNumalmiI S1 MOIa7@SfgG ONSA#.tlA?,f 00011 ai,@a, ^UMS

AFVAL-TR-06-4006 Vol V. Part 80

S&~ hAIMS 00 01141101160iE O^GA19AtJQ a Office SYMBOL. 1*. IWAI Of "OftITORS'S ORGANIAL&0tO

General El~etric Company itoibiAWLMT

of- A0041SA red*. UrSam ON iP Cmb 7b. LOORES ICf. BS a owI Como

a River RoaSchenectady. 3T1 2345 VPAF3. ON 45433-6533

40Ge W 00M O* SWI4JPsS OR N OPPICS SwASOL a. PROCb09mg NST060at~T SOI9iTIP &C.ATit $DNNMSION

Air rorce Systems Commad. USAF ________________________

Is LOARIM felea LSa me SIP Coo) I SOumC 0 .0"FEINO 9110PfO@SAMS SRAU? VASE WFOK W11117

~Wflbt-Patersom hIr3. Ghis 46433 IL N I 0.01.IG

___. __1,"_____ ____ _____ ____ ___fame&"*#11 7500 62 01

(see Reverse)J

13. 0SftSOkA. AuTNOmSIAlthoff._7 J.

i3s. TV.IOP of PORT 131L tIME COVIAS 16 A Of P400 (Yoe~... p, Is PACE COVTVimal t*ebasosl 1ep.11 32 "pt 190- 8) &SIT BOBS 19S5 ovember 21

iS SWPP61M~AARV OTATION The computer software contained herein are theoretical and/orreferences that In so way reflect Air Force-owned or -developed

SCAN Project, Prlority 63201 computer software.

1 ~ COl, mess1 Wa.SUACT'r m~fug fe~ie.~ an am's Ummifneptm oeP t 6n 'momb',90IL 116 16410 1 su o1305 OOLS

2'This document Is the development specification establishing thefunctional requirements of the IISS Configuration Item FileUtilities which provide file transfer, file delete and uniquefile naming services to other conponents of IISS.

20 GIl?SAiuTaOm.'AWAaL&ag'ITv Of AS~tAC? aISYA&t SRCV014TatL CSSIPCALT6

60"tanew is DPWLIMITS D W sae"m' r MCua Unclassified

236 RAMIg Of R515PO13&. WSIVIUAL 11 bT16iP440111 006WO10 23, OPPICS 5YW00

DOFORM 1473.83 APR G9ItIO% O I A% a3 011,06.. nasile

U Chub:? 96iAN'*A10f of* a*PtRIl PAQ1

11. Title

Integrated Information Support System (IISS)Vol V - Common Data Model SubsystemPart 30 - File Utilities Development Specification

A S D 86 143517 Jul 1986

- .

FAcze;Io., For

[TIS CRA&I -V

I DTIC TAB ESL:L jr;-ourced Q--J :f: o

yt y

~- ,l.b.;ty Codes. , d ,'c! I or

:4-/--

DS 6201413301 November 1985

PREFACE

This development specification covers the work performedunder Air Force Contract F33615-80-C-5155 (ICAM Project 6201).This contract is sponsored by the Materials Laboratory. AirForce Systems Command, Wright-Patterson Air Force Base, Ohio.It was administered under the technical direction of Mr. GeraldC. Shumaker, ICAM Program Manager, Manufacturing TechnologyDivision, through Project Manager, Mr. David Judson. The PrimeContractor was Production Resources Consulting of the GeneralElectric Company, Schenectady, New York, under the direction ofMr. Alan Rubenstein. The General Electric Project Manager wasMr. Myron Hurlbut of Industrial Automation Systems Department,Albany, New York.

Certain work aimed at improving Test Bed Technology hasbeen performed by other contracts with Project 6201 performingintegrating functions. This work consisted of enhancements toTest Bed software and establishment and operation of Test Bedhardware and communications for developers and other users.Documentation relating to the Test Bed from all of thesecontractors and projects have been integrated under Project 6201for publication and treatment as an integrated set of documents.The particular contributors to each document are noted on theReport Documentation Page (DD1473). A listing and descriptionof the entire project documentation system and how they arerelated is contained in document FTR620100001, Project Overview.

The subcontractors and their contributing activities wereas follows:

TASK 4.2

Subcontractors Role

Boeing Military Aircraft Reviewer.Company (BMAC)

D. Appleton Company Responsible for IDEF support,(DACOM) state-of-the-art literature

search.

General Dynamics/ Responsible for factory viewFt. Worth function and information

models.

iii

DS 6201413301 November 1985

Subcontractors Role

Illinois Institute of Responsible for factory viewTechnology function research (IITRI)

and information models ofsmall and medium-size business.

North American Rockwell Reviewer.

Northrop Corporation Responsible for factory viewfunction and informationmodels.

Pritsker and Associates Responsible for IDEF2 support.

SofTech Responsible for IDEFO support.

TASKS 4.3 - 4.9 (TEST BED)

Subcontractors Role

Boeing Military Aircraft Responsible for consultation onCompany (BMAC) applications of the technology

and on IBM computer technology.

Computer Technology Assisted in the areas ofAssociates (CTA) communications systems, system

design and integrationmethodology, and design of theNetwork Transaction Manager.

Control Data Corporation Responsible for the Common Data(CDC) Model (CDM) implementation and

part of the CDM design (sharedwith DACOM).

D. Appleton Company Responsible for the overall CDM(DACOM) Subsystem design integration

and test plan, as well as partof the design of the CDM(shared with CDC). DACOM alsodeveloped the IntegrationMethodology and did the schemamappings for the ApplicationSubsystems.

iv

116ti&%W &

DS 6201413301 November 1985

Subcontractors Role

Digital Equipment Consulting and support of theCorporation (DEC) performance testing and on DEC

software and computer systemsoperation.

McDonnell Douglas Responsible for the support andAutomation Company enhancements to the Network(McAuto) Transaction Manager Subsystem

during 1984/1985 period.

On-Line Software Responsible for programming theInternational (OSI) Communications Subsystem on the

IBM and for consulting on theIBM.

Rath and Strong Systems Responsible for assistance inProducts (RSSP) (In 1985 the implementation and use ofbecame McCormack & Dodge) the KRP II package (PIOS) that

they supplied.

SofTech, Inc. Responsible for the design andimplementation of the NetworkTransaction Manager (NTM) in1981/1984 period.

Software Performance Responsible for directing theEngineering (SPE) work on performance evaluation

and analysis.

Structural Dynamics Responsible for the UserResearch Corporation Interface and Virtual Terminal(SDRC) Interface Subsystems.

Other prime contractors under other projects who havecontributed to Test Bed Technology, their contributingactivities and responsible projects are as follows:

Contractors ICAM Project Contributing Activities

Boeing Military 1701, 2201, Enhancements for IBMAircraft Company 2202 node use. Technology(BMAC) Transfer to Integrated

Sheet Metal Center(ISMC).

v

DS 6201413301 November 1985

Contractors ICAM Project Contributing Activities

Control Data 1502, 1701 IISS enhancements toCorporation (CDC) Common Data Model

Processor (CDMP).

D. Appleton Company 1502 IISS enhancements to(DACOM) Integration Methodology.

General Electric 1502 Operation of the TestBed and communicationsequipment.

Hughes Aircraft 1701 Test Bed enhancements.Company (HAC)

Structural Dynamics 1502, 1701, IISS enhancements toResearch Corporation 1703 User Interface/Virtual(SDRC) Terminal Interface

(UI/VTI).

Systran 1502 Test Bed enhancements.Operation of Test Bed.

vi

DS 620141330

1 November 1985

TABLE OF CONTENTS

Page

SECTION 1.0 SCOPE.................................... 1-11.1 Identification........................ 1-11.2 Functional Summary.....................1-2

SECTION 2.0 DOCUMENTS............................... 2-12.1 Reference Documents................... 2-12.2 Terms and Abbreviations................2-1

SECTION 3.0 REQUIREMENTS.............................3-13.1 Computer Program Definition...........3-13.1.1 System Capacities................... 3-13.1.2 Interface Requirements..............3-13.1.2.1 Interface Block Diagram...........3-13.2 Detailed Functional Requirements ... 3-23.2.1 Function FSD - File Send............3-23.2.1.1 Inputs

(from requesting process)........3-33.2.1.2 Processing........................ 3-33.2.1.3 Outputs........................... 3-43.2.2 Function FRC - File Receive.........3-43.2.2.1 Inputs............................ 3-43.2.2.2 Processing........................ 3-53.2.2.3 Outputs........................... 3-53.2.3 Function FDL - File Delete..........3-63.2.3.1 Input................3-63.2.3.2 Processing........................ 3-63.2.4 Function FNM - File Namer...........3-63.2.4.1 Input............................. 3-63.2.4.2 Process ing........................ 3-63.2.4.3 Outputs........................... 3-7

SECTION 4.0 QUALITY ASSURANCE PROVISIONS............4-14.1 Introduction and Definitions..........4-14.2 Computer Programming Test

and Evaluation....................... 4-1

SECTION 5.0 PREPARATION FOR DELIVERY.................5-1

vii

DS 6201413301 November 1985

SECTION 1

SCOPE

1.1 Identification

This specification establishes the performance,development, test, and qualification requirements of a set ofcomputer programs identified as Configuration Item FileUtilities.

Cii CI constitutes one of the subsystems of the CommonData Model Processor- (CDMP) which is described in the SystemDesign Specification (SDS) for the ICAM Integrated SupportSystem (IISS). The CDMP scope is based on a logical concept ofsubsystem modules that interface with other external systems ofthe IISS. The CDNP has been portrayed with three configurationitems: The Precompiler, the Distributed Request Supervisor(DRS), and the Aggregator. In addition, File Transfer FileDelete and File Namer are included as utilities to be used bythe CDMP and other IISS components. The following narrativeportrays the scope of the CDMP in a compile and a runtimeenvironment. ! 77,

Operation of CDkP at Precompiler Time.

To make use of the CDM, a user embeds neutral datamanipulation language (NDML) commands in COBOL programs. ThePrecompiler scans COBOL application program source code,identifies and parses NDML commands, applies transformationsfrom external schema form to conceptual schema form, identifiesdata location, decomposes the commands to appropriate singledatabase requests, applies transformations from conceptualschema form to internal schema form, and selects appropriateaccess paths through identified databases.

The Precompiler generates code that will be activated atrun time to access the identified databases and to performrequired internal-to-conceptual-to-external transforms. It alsogenerates query graphs that control the management of therun-time transaction processing by the DRS.

Operation of CDMP at Application Run Time

The DRS selects the appropriate sequence in which toprocess multiple single database accesses that may result from

l-1

DS 6201413301 November 1985

one NDML command. The scheduling of the accesses is done at runtime based upon query graph information and a count of each setof qualifying records. The DRS controls the distributedactivities presenting the aggregated result to the requestingapplication program.

1The DRS invokes the execution of request processors which

may exist at multiple workstations. Once activated, a requestprocessor accesses the target data base and outputs qualifyingrecords on a sequential output file. The request processorsignals the DRS when it has completed processing a request withthe name of the file that contains the qualifying records alongwith a volume count.

The DRS analyzes volume count from the various queryprocessing operations in order to minimize file transportationcosts. Based on the cost data, it activates the File Transferutility to transport the least cost files to the appropriatehost for aggregation processing.

The Aggregator responds to control messages from the DRSIt receives intermediate sets of qualifying records onsequential files resulting from single database accesses. Itjoins them appropriately to prepare the aggregate results

After the final aggregation has been accomplished, theStager/Scheduler initiates the conceptual to externaltransformer to convert the final data into the form expected bythe original request in the application.

Any intermediate files that were created during the runt.me operation of the CDMP are deleted by requests to the FileDelete Utility.

1.2 Functional Summary

Although the File Transfer utility will be usable by testbed components that require a basic file transfer capability.the primary functions are:

* To transfer the results of a request processor retrievalto another host where it will be aggregated with data

iN from another request processor.

e To transfer the results of an intermediate aggregationstep to another host where is will be further aggregatedwith other data.

1-2

" To transfer the f inal d&gfregdited 0III t trat r.conceptual external tr.nsf orm-r wheyr , t w ,..Lconver ted t o ex te r naI f U IML4t dari ;r e ,ede tb ILoriginal reque~itor

" To transfer generated prof r&m. fryou (-TU .1 :S1. t. ,danother

The primary useE of the Fi le Lx*;ett art

*To delete file containing reques-t Frock-'-Lr rLtaf ter it haE been Lent tc; ancthei hount t,, tx&ftwith aIsoiated query pxY~o esuj t.!

*To deiete a f ile contaiining intermediate aggreeit or.results

" To delete a file containing the final aggregated resuitEafter it has been transformed from Conceptual toExternal format by the CE tranisformer

* To delete a file containing the final results from anNDML request after the information has been proceE:&1 I-the requesting application.

*To delete temporary files used by the NDML precompiler-

The primary uses of the File Namer are:

" To provide system wide unique file names for anyrequesting process.

* Specifically, unique file names are needed for temporaryquery results files.

*Specifically, unique file names are needed by the NDMLprecompiler for temporary files and for storage ofgenerated programs.

1-3

DS 6201413301 November 1985

SECTION 2

DOCUMENTS

2.1 Reference Documents

1. DeJean, J.P., Test Bed System DevelopmentSpecification, General Electric Company, Schenectady,New York, November 9, 1982.

2.2 Terms and Abbreviations

Attribute Use Class: (AUC)

Conceptual Schema: (CS)

Common Data Model Processor: (CDMP)

Common Data Model: (CDM) Describes common data applicationprocess formats, form definitions, etc, of the IISS and includesconceptual schema, external, internal schemas, and schematransformation operators.

Data Field: (DF) An element of data in the externalschema. It is by this name that an NDML programmer referencedata.

Database Management System: (DBMS)

Distributed Request Supervisor: (DRS) This IISS CDMsubsystem configuration item controls the execution ofdistributed NDML queries and non distributed updates.

Domain: A logical definition of legal attribute classvalues.

Domain Constraint: Predicate that applies to a singledomain.

External Schema: (ES)

Forms: Structured views which may be imposed on windows orother forms. A form is composed of fields where each field is aform, item, or window.

Forms Processor: (FP) A set of callable execution time

2-1

DS 6201413301 November 1985

routines available to an application program for form

processing.

Internal Schema: (IS)

Integrated Information Support System: (IISS) A testcomputing environment used to investigate, demonstrate and testthe concepts of information management and informationintegration in the context of Aerospace Manufacturing. The IISSaddresses the problems of integration of data resident onheterogeneous databases supported by heterogeneous computersinterconnected via a local Area Network.

Mapping: The correspondence of independent objects in twoschemas: ES to CS or CS to IS.

Network Transaction Manager: (NTM) Performs thecoordination, communication and housekeeping functions requiredto integrate the application processes and system servicesresident on the various hosts into a cohesive system.

Neutral Data Manipulation Language: (NDML) A languagedeveloped by the IISS project to provide uniform access tocommon data, regardless of database manager or distributioncriteria. It provides distributed retrieved and single nodeupdates.

ORACLE: Relational DBMS based on the SQL (Structured QueryLanguage, a product of ORACLE Corp. Menlo Park, CA). The CDM isan ORACLE database.

Parcel: A sequential file containing sections source codeof the input application program.

Request Processor: (RP) A COBOL program that will satisfya retrieval or update NDML subtransactlon against a particularDatabase Management System.

User Interface: (UI) Controls the user's terminal andinterfaces with the rest of the system.

Virtual Terminal Interface: (VTI) Performs the interfacingbetween different terminals and the UI. This is done bydefining a specific set of terminal features and protocols whichmust be supported by UI software which constitutes the VirtualTerminal Definition. Specific terminals are then mapped againstthe Virtual Terminal software by specific software modules

2-2

DS 6201413301 November 1985

written for each type of real terminal supported.

2-3

DS 6201413301 November 1985

SECTION 3

REQUIREMENTS

3.1 Computer Program Definition

3.1.1 System Capacities

The File Transfer operates on ASCII files with records thatare fixed in length (all same size) or variable length recordfiles that do not exceed a maximum records exceeding the maximumare truncated.

The File Delete operates on ASCII file.

3.1.2 Interface Requirements

3.1.2.1 Interface Block Diagram

------------ FILE --------- INITIATION -----------I I TRANSFER I I MESSAGE I IIREQUESTINGI REQUEST I FILE I--------------)I FILE I

I ------------- I I ACKNOWLEDGE I IPROCESS I I SEND 1< --------------- RECEIVE I

I COMPLETION I I DATA RECORDS I IY STATUS --------------- ) I------------ COMPLETION I

Y STATUS II I II'-----------------

------------ +---------+ -----------

The File Transfer CI Is composed of twofunctional components, File Send and FileReceive.

A requesting process sends a File Transfermessage to the File Send at the host where theoriginal file to be transmitted resides. TheFile Send then sends an initiation message to theFile Receive at the host where the file is to becreated. After receiving acknowledgment fromFile Receive the File Send reads the source fileand creates messages containing the file data.

3-1

DS 6201413301 November 1985

It transmits these messages to the File Receivewhere they are reconstructed into a new file.When the file transfer is completed, File Sendnotifies the requesting process.

------------- ---------------I I DELETE REQUESTI REQUESTINGI ----------------------- I FILE

I PROCESS I I DELETE

+------------- ----------------

A requesting process sends a File Delete requestin the form of a message to the host where thefile to be deleted resides.

------------ FILE NAME REQUEST --------- NEXTI I--------------------) I I NAME -------------IREQUESTING1 I FILE 1 ------- I I

I I I I PERMANENT IPROCESS I I NAMER -I I

I ------------------- I LAST I FILE IIFILE NAMES & STATUS I NAME I I

------------ --------- USED -------------+"LAST FILENAME USED"

A requesting process sends File Name request inthe form of a message to the File Name queueserver. After generating the next group ofnames, the File Namer sends a reply message witha status to the requesting process. The file"LAST FILE NAME USED" is used to periodicallyrecord the last file name assigned for each host.

3.2 Detailed Functional Requirements

The following subsections document the File Utility's major

functions and describes the input-output requirement.

3.2.1 Function FSD - File Send

The file send function transfers files from host to host in

3-2

DS 6201413301 November 1985

the testbed environment. The file send function residing at onehost sends it contents to a file receive function on a remotehost. The file send receives file characteristics and operatinginstructions from a requesting process. It in turn passescontrol information to the file receive function.

3.2.1.1 Inputs (From requesting process)

A. Name of file to be sent.B. Record length of records contained in file.C. Name of file to be built.D. Logical location of where file is to be sent.E. Indicator on whether to delete or keep Input file after

transfer.F. "Ready to Receive" (from File Receive).G. "End of File Transfer" or "File Transfer Unsuccessful"

(from File Receive).

3.2.1.2 Processing

A. Receive File Transfer initiation message fromrequesting process via the NTN, to Transfer File. Themessage contains the inputs A thru E message from3.2.1.1. above.

B. Send message to location where file is to be sent toinitiate file receive routine. Send name of file to becreated and record length, from step B, above.

C. Receive "ready to receive" message from file receiveroutine.

D. Open input file to be sent.E. Read input records and place in output buffer.

Continue until output buffer is full or all recordsfrom file have been read. Keep a count of total numberof records in file.

F. Send message to file receive routine containing datafrom E, above.

G. Repeat E and F, as necessary, to send entire file.H. Send message to file receive routine inidcating all

records have been sent and total record count from stepE.

I. Wait for "End of File Transfer" or "File TransferUnsuccessful" completion message from File Receive.

1. If "File Transfer Unsuccessful" is received, checkto see if this is first or second attempt to sendthe file. If first, try again by restarting fromthe beginning. If second try, send unsuccessful

3-3

DS 6201413301 November 1985

message to requesting process and terminate.

2. If "End of File Transfer" continue with K, below.

K. Check input parameter E, under 3.2.1.1 above and deleteoriginal input file if the delete parameter is set.Note: use the File Delete utility to execute thisstep.

L. Send a completion message to the process requesting the

file transfer.

M. Terminate the File Send.

3.2.1.3 Outputs

A. Nessage to receiving host to initiate File Receive.

* Name of file to be created* Record length

B. Records containing data to be transferred.

C. "End of File" message (containing count of number ofrecords sent).

D. Completion message to requesting process containing

transfer status.

3.2.2 Function FRC - File Receive

The File Receive function operates in conjunction with theFile Send function in the test bed environment. File Send,residing at one host, sends its contents to File Receive on aremote host. Prior to receiving any of the file contents, FileReceive receives control information from File Send thatcontains the name of the file to be built and other filecharacteristics.

3.2.2.1 Inputs

A. Message from File Send to initiate receive process.

* Name of file to be created." Record length of records in the file.

B. Data records to build new file.

3-4

DS 6201413301 November 1985

C. "End of File" message from File Send, which includes a

count of the records sent.

3.2.2.2 Processing

A. Receive initiation message from File Send. (See inputA in 3.2.1.1, above).

B. Create (open) output file to be written.

C. Send "Ready to Receive" message to File Send.

D. Read input records being sent by File Send and place onoutput file opened in B, above. Keep a count of numberof logical records received and written.

E. Repeat Step D until all records have been written tooutput file as denoted by "End of File" message fromFile Send.

F. Compare count of number of logical records writtenagainst number of records sent. Then take one of thefollowing actions:

* If the counts are equal, send "End of File transfer"message to File Receive.

" If the counts are not equal, delete the output filebeing created, and send "File TransferUnsuccessful" message to the File Send routine,terminate.

G. Close the output file.

H. Terminate.

3.2.2.3 Outputs

A. "Ready to Receive" message to File Send.

B. Newly created data file.

C. "End of File Transfer" message or "File TransferUnsuccessful" message

3-5

DS 6201413301 November 1985

3.2.3 Function FDL - File Delete

The File Delete utility purges files residing on the localhost. The request to delete a file can originate on any host inthe IISS environment.

3.2.3.1 Input

A. File Delete initiation message containing name of fileto be deleted.

3.2.3.2 Processing

A. An interface module, upon receiving the file name andits host of residence will issue an operating systemcall to delete or purge the file if the file is on thesame host as the interface module.

R. If the file is "off-host", a message is sent to thefile delete process on that host which will thenexecute a call to the operating system (on local host)to delete the file using the file name supplied ininput A, above.

C. No status reply is expected from the file deleteinterface or the file delete process.

3.2.4 Function FNM - File Namer

The File Namer utility generates unique file names for anyhost node of the IISS. The request for file names can originateon any host in the IISS environment.

3.2.4.1 Input

A. File Namer must be told by the requester that it needsa file name. The fact that a call is made to theinterface module indicates this.

B. The interface module may send a message to the filename queue server for a group of file names. The factthat a requesting message arrives at the queue serverindicates that a group of file names is desired.

3.2.4.2 Processing

A. The file name interface maintains a group of file namesrecieved from the queue server. When this group hasbeen passed out, one per request, the interface module

3-6

DS 6201413301 November 1985

will request another group from the queue server.

B. The file name queue server will maintain an in-memorytable of the last name assigned for each host. Thiswas loaded from the "LAST FILE NAME USED" file atprocess initiation. When a request comes in. a blockof names is generated by incrementing the numericportion of the name. If the numeric portion "rolls"past all 9's, then the letter portion of the name isincremented. The group of file names is sent back tothe requestor in the reply message.

C. After every 50th request, the current version of thenext file name to use is written to the "LAST FILE NAMEUSED" file. This also is done when the NTM signals thesystem shutdown.

D. This function assumes no other users of the hostcomputer will be generating file names of the typedeveloped, as no operating system calls or checks aremade. This can be insured by reserving a specialdirectory or file name template for IISS use.

3.2.4.3 Output

A. A file image ("LAST FILE USED") of the next file namesto be used is stored on disk to prevent re-use of filenames across system shutdown and startup.

B. A group of file names is sent in a reply message to therequesting file name interface routine.

C. A single file name is returned from the file nameinterface routine to the requesting application.

3-7

DS 6201413301 November 1985

SECTION 4

QUALITY ASSURANCE PROVISIONS

4.1 Introduction and Definitions

"Testing" is a systematic process that may be preplannedand explicitly stated. Test techniques and procedures may bedefined in advancce and a sequence of test steps may bespecified. "Debugging" is the process of isolation andcorrection of the cause of and error.

4.2 Computer Programming Test and Evaluation

The quality assurance provisions for test will consist ofthe normal testing techniques that are accomplished during theconstruction process. They consist of design and codewalk-throughs, unit testing, and integration testing. Thesetests will be performed by the design team.

The integation test developed for the file utilities willconsist of a number of test cases developed for other componentsof the CDM. Because file utilities are essentially servicemodules, they will be tested by other CDM components.

Unit testing will primarily involve testing each of theutilities with skeleton routines calling the "service" interfacemodule directly.

4-1

DS 6201413501 November 1985

SECTION 5

PREPARATION FOR DELIVERY

The implementation site for the constructed software willbe the ICAM Integrated Support System (IISS) Test Bed Sitelocated in Albany, New York. The software associated with thefile utilities will be clearly Identified and will includeinstructions on procedures to be followed for installation ofthe release.

5-1SU.S.Government N Inting office I8 il I 0I t,0912

a