DTJ Number 3 September 1987 - Digital Technical Journals

More documents

Recommendations

Info

New Productscould the network name space be built on thelocal name space of an individual node? Howwould network functions be accessed from withinthe operating system itself? To what extentshould a user be aware that he is specifying a networkfunction rather than a local one?This paper will describe how the design ofthe VMS system facilitates the integration of networkingcapabilities. The DECnet-VAX producttakes advantage of this design to provide networkingservices that are faithful to the DNAphilosophy while still tailored to the uniqueVA XfVMS environment.Foundations of the DEC net- VAXProductThe foundation of all networking applicationsis the ability of a program on one system to exchangedata with a program running on anothersystem. In the DECnet architecture this capabilityis called task-to-task communication. It is thebackbone upon which a wide range of VMS networkingfacilities are built. These facilitiesinclude• Remote file access and virtual terminalsuppon• Layered product extensions, such as distributedmail and remote database applications• Applications that rely heavily on file accessand task-to-task capabilities, developed byusers and third-pany companies• Distributed network management operationsThe DECnet-VAX implementation had to satisfythe needs of both end users and applicationdevelopers. Therefore , its main goals were toprovide remote file access and task-to-task communicationcapabilities that would be easy tolearn and use, functionally complete, and accessiblethrough the standard VMS 1/0 interfaces.Providing a high degree of transparency fornetwork activities was the key to achieving thesegoals. For example, transparency at the file levelmeans that accessing a file on a remote node isconceptually the same as accessing the file onthe local system. That access should not requirethe use of different commads or any changes toapplication programs.The VMS design was influenced by severalimportant concepts that laid the foundation forintegrating networking capa;bilities and evolvinga highly transparent user ip.terface to network.servtces.I1One fundamental concept is that the VMS systemtreats network operatiohs as a natural extensionof local 1/0 operations. The DECnet-VAXimplementation, from the session layer (providinglogical link services) down to the physicaldevice layer, is modeled after the file accessprimitives of the VMS file system. Both networkand file system operations use the assign channel(ASSIGN) , queue 1/0 (QIO) , and deassign channel(DASSGN) system serviCes as their programminginterface, and make u$e of the same subsetof QIO functions. Both ophittions divide theirwork between higher level fu nctions requiring aprocess context to provide a large address spaceand 1/0 handled through appropriate devicedrivers. At this level of abstraction, the programmingsteps required to engage in task-to-taskcommunication are quite similar to those neededto access a local file.Another design decisioq having a profoundeffect on the style of inte!rface to remote fileaccess was to integrate the! record managementservices (RMS) into the VMS system. RMS is usedfor all common file access operations by theoperating system as well as by most VMS utilities.These services provided a platform from whichto develop a common interface for both localand remote file access, as well as task-to-taskcommunication. The DEnet-VAX developersachieved transparent remot file access by incorporatingthe data access protocol (DAP) modulesin RMS to communicate wih a remote file accesslistener (FAL) . For local filJ access, RMS uses theQIO interface to the file system. For remote fileaccess, RMS uses the QIO interface to create alogical link to the FAL server program throughthe session layer of the network. FAL thenaccesses the file by acting as a local user of RMSon its system. The use of RMS is illustrated conceptuallyin Figure 1.The definition of a VS fi le specificationwas extended to include the node name with aprovision for an optional atcess control stririg topass authorization informaion to the remote system.The syntax of a node specifier is one of thefollowing:nodename::nodename"username password account''::Digital Tecbnical]ournalNo. 3 September 198689
The DEC net- VA X Product - An Integrated Approach to NetworkingLOCAL NODEFILEACCESSREQUESTRMSSERVICESILO cREMLVMSFILE '----SERVICESNETWORKSERVICES-DISKDRIVERCOMMUNICATIONSDRIVERIr---DISKNETWORKFILEACCESSCOMMUNICATIONSNETWORKFALREQUESTRMS'----DRIVER r-- SERVICES SERVER SERVICES. . .REMOTE NODEFigure 1RMS Interfa ce to Local and Remote FilesMoreover, the concept of a quoted file specificationwas introduced to allow file name informationon a non-VMS system (one not adhering tothe parsing rules specified for VMS files) to berepresented. In addition, two special forms ofquoted string were adopted to specify the targetentity in task-to-task communication. Thus thesyntax of a file specification for network accesscan be one of the following:nodespec::device:[directory]file.type;versionnodespec::' 'foreign-file-specifier' 'nodespec::"TASK= taskspec"nodespec::"n="where the latter two forms are used to identify anetwork task by name or object number.Another important early design decision was toprovide fu ll access to remote fi les, beyondremote file transfer and manipulation functions,through RMS. Currently, almost every RMS fu nctioncan be performed over the network on aremote VAX/VMS system. Thus most applica-tions using RMS can employ the network transparentlyto• Access sequential, relative , and indexed(ISAM) files• Utilize different access methods (sequential,random by relative record number, relative bykey, and record file address)• Operate in either record or block mode• Communicate with a network task as thoughreading and writing to a sequential fileRMS is used throughout the VMS system by theDigital Command Language (DCL) interpreter,VMS utilities, and the run-time library routinessupporting high-level languages. As a result,transparent remote fi le access and task-to-taskcommunication are available at the fo llowinginterface levels: DCL commands, high-level languager;o statements, RMS services, and I/Orelatedsystem services. Figure 2 illustrates theserelationships.90Digital TecbnicalJournalNo. 3 September 1986
Page 1 and 2:
Netwo;king ProductsDigital Technica
Page 3 and 4:
Editor's IntroductionRichard W. Bea
Page 5 and 6:
BiographiesRaj Jain Raj Jain gradua
Page 7:
BiographiesDavid R. Oran Dave Oran
Page 10 and 11:
increase the sizes of networks, we
Page 12:
New Productsmust be able to coexist
Page 15 and 16:
A Digital Network Architecture Over
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
---A Digital Network Architecture O
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Performance Analysis and Modeling o
Page 29 and 30:
---Performance Analysis and Modelin
Page 31 and 32:
Performance Analysis and Modeling o
Page 33 and 34:
---Performance Analysis and Modelin
Page 35 and 36:
--Performance Analysis and Modeling
Page 37 and 38:
The DECnet/SNA Gateway Product• H
Page 39 and 40: The DECnetjSNA Gateway ProductFrom
Page 41 and 42: The DECnetjSNA Gateway Productcommu
Page 43 and 44: The DECnetjSNA Gateway ProductUSER
Page 45 and 46: The DECnetjSNA Gateway ProductThe u
Page 47 and 48: The DECnetjSNA Gateway ProductDECne
Page 49 and 50: The DECnetjSNA Gateway Productopera
Page 51 and 52: The DECnetjSNA Gateway ProductSegme
Page 53 and 54: The DECnetjSNA Gateway Product• O
Page 55 and 56: WiUiam R. HaweMark F. KempfAlanJ. K
Page 57 and 58: The Extended Local Area Network Arc
Page 75 and 76: Terminal Servers on Ethernet Local
Page 89: Paul R. Beckjames A. KryckaThe DECn
Page 93 and 94: The DECnet- VA X Product - An Integ
Page 95 and 96: The DECnet- VAX Product - An Integr
Page 97 and 98: The DEC net- VA X Product - An Inte
Page 99 and 100: The DECnet- VAX Product - An Integr
Page 101 and 102: john Forecastjames L. jacksonjeffre
Page 103 and 104: The DECnet,ULTRIX SoftwareComponent
Page 105 and 106: The DECnet- ULTRIX Softwarehave pro
Page 107 and 108: The DECnet- ULTRIX Softwaresystems.
Page 109 and 110: Peter 0. MierswaIDavid J. MittonMar
Page 111 and 112: The DECnet-DOS Systemthat CCB, whic
Page 113 and 114: The DECnet-DOS Systemdata link laye
Page 115 and 116: Tbe DECnet-DOS SystemNDU and the vi
Page 117 and 118: Th e DECnet-DOS Systemconsole can a
Page 119 and 120: The Evolution of Network Management
Page 131 and 132: The NMCCjDECnet Monitor Design5. Op
Page 133 and 134: Th e NMCCjDECnet Monitor DesignFigu
Page 135 and 136: The NMCCjDECnet Monitor DesignKERNE
Page 137 and 138: The NMCCjDECnet Monitor Designinto
Page 139 and 140: The NMCCj/JECnet Monitor DesignThe
Page 141 and 142:
The NMCCjDECnet Monitor Designcan s
Page 143 and 144:
Editorial StaffEditor - Richard W.
show all

DTJ Number 3 September 1987 - Digital Technical Journals

Create successful ePaper yourself

Delete template?

Save as template?