DTJ Number 3 September 1987 - Digital Technical Journals

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