DOCSLIB.ORG

Multiple Protocols: the Network Manager's Previous Screen Headache Joe Pruskowski Payoff Many IS Professionals Face the Task of Managing Complex Networks

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Multiple Protocols: the Network Manager's Previous Screen Headache Joe Pruskowski Payoff Many IS Professionals Face the Task of Managing Complex Networks 50-10-30 Multiple Protocols: The Network Manager's Previous screen Headache Joe Pruskowski Payoff Many IS professionals face the task of managing complex networks. This article discusses methods of connectivity, including multistacking and the use of software-based gateway technology, in an effort to help managers effectively deal with multiple protocols in the LAN environment. Problems Addressed Rightsizing is a goal of many CIOs today. The basic method to attain true rightsizing is to move information closer to the individual workers within the organization, especially through client/server computing. By their very nature, networks are the logical structure to make this happen. Many corporations have a mix of both departmental and corporate LAN systems combined with legacy systems, all with disparate methods of communicating in a network. Today's networks are very open, but often very chaotic. Managing such complex networks has become a real challenge for network managers. For connectivity, IS managers often rely on one of two common methods: stacking multiple protocols, or “multistacking,” and using gateway technology. For IS managers facing integration decisions, information on all of the options is critical. LAN Client Support The dominant LAN Network operating system is NetWare, and therefore the standard for LAN protocols is IPX/SPX. Parallel to the LAN , legacy systems are still using their proprietary protocols to support access to mission-critical applications and data. Typically IBM's System Network Architecture, DEC's Local Area Transport and DECnet, together with a variety of applications running on TCP/IP, have become the most prominent protocols running on the host. Exhibit 1 shows the interactions between clients and hosts within the network. Client and Host Interactions Because the networks in most organizations are made up of a variety of protocols, users in various places on the network cannot access the resources they need. A company attempting to solve this problem must deal with some significant issues: · Initial setup cost, including purchase and installation cost, for each workstation on the network. · Ongoing administrative support costs, which include the purchase and installation of software upgrades and the maintenance of network address management. Each protocol stack has a different naming scheme. For example, a LAT host name is a simple test string (e.g., SYSTEM1), where a TCP/IP node name is tree-structured dot notation (e.g., SYSTEM1.NORTHWEST.ICXN.COM). · The limited number of applications supported by any one protocol. Previous screen · The burden on the infrastructure when there are too many protocols to support efficiently. This burden is realized by the network hardware, which now must deal with managing multiple protocols. Support personnel must also know how to deal with these protocols. · The high administrative costs in large, heterogeneous networks. This is a serious problem because the costs continue to climb. What IS Multistacking? Multistacking means that every LAN client would have to run all other legacy protocols (e.g., System Network Architecture, Local Area Transport, and DECnet)in addition to its native protocol (e.g., Internetwork Packet eXchange) to gain access to all corporate data. The number of LAN clients that must run multiple protocol stacks in most major corporations is very large—typically measured in the thousands. While in theory multistacking will solve the problem, it comes with an entire set of its own problems, multiplied by the sheer number of LAN clients that are affected. Some of the major problems that must be dealt with on each DOS/Windows system are: · Conflicts in memory usage, since many stacks still run in real-mode. · Conflicts in Terminate and Stay Resident (terminate and stay resident) programs. · Conflicts in network address spaces (i.e., differing address schemes). · Use of network device drivers by multiple protocol stacks, which require complicated setup procedures. Connectivity Alternatives to Multistacking There are a number of solutions available today that minimize protocol stack propagation, each with its advantages and disadvantages. Proprietary Vendor-Specific Suites These are typically sold by the major computer vendors. Examples would be Pathworks from Digital Equipment Corp. and IBM's LAN Server products. These usually provide a high level of functionality, but are mainly account control mechanisms and can be cumbersome to use. In addition, they are usually expensive because license has to be purchased for every user on the network. Standardization on One Protocol Stack In an ideal world, this would be Open Systems Interconnection, though TCP/IP seems to be filling this role as a practical solution. However, although TCP/IP is found on the backbones of many corporations, it rarely makes it to the client. TCP/IP can be cumbersome to install on a large number of nodes, but it does provide an excellent “intermediate” protocol. Because TCP/IP can support a wide variety of equipment, there are many parameters that must be set up on each TCP/IP system, not the least of which is the node number, which has to be assigned for each node. This approach can also be expensive, as it is purchase on a per-node basis. The Software Gateway Previous screen Another alternative to multistacking is the use of gateway technology. Gateway technology was first introduced as rather expensive hardware. A single vendor had to install and maintain the gateway, typically at a very high cost to the user. New gateway technology is software-only and can be run on virtually any commodity hardware platform. An early example is Novell's NetWare for Systems Application Architecture, which connects LAN clients to IBM mainframes. Another is InterConnections' Leverage Gateway Services, which is based on Novell's NetWare for Local Area Transport technology and connects Digital Equipment Corporation systems with NetWare clients. The gateway technology emerging today serves as a true gateway-- one type of protocol is actually converted to a different protocol type. An example of this would be an inbound terminal session over NetWare Internetwork Packet eXchange that is converted at the gateway to an outbound LAT terminal session. There are several advantages to this new type of gateway: · It can reside on any Intel 386/486/Pentium hardware platform and provides protocol translation between the LAN client and host environments. · It is ultimately manageable using the industry-standard Simple Network Management Protocol protocol. The management capabilities are based on the translation tables that are inherent within the gateway. This allows for “logical network management” of network resources, building on the physical management capabilities that are currently being deployed by a wide variety of vendors. Logical network management brings meaningful information to the network manager, such as the number of sessions in use and the number of files transferred. · Concurrent user licensing is cost-effective. Any supported host can be accessed by the LAN clients. The user company does not have to license each host to allow access from its client systems. · Concurrent host usage is cost-effective. Any supported host can be accessed by the LAN clients. The user company does not have to license each host to allow access from its client systems. · The number of protocol stacks on the LAN client and host are greatly reduced. · There is no need for additional kernel-mode protocol stacks on the host machines. By applying software gateway technology to the multiple protocol situation, IS professionals have a new set of tools that can help them achieve their goals. A Sample Case The next section examines the system at a major airline reservation center. The center has a large collection of NetWare LANs with thousands of IPX/SPX clients. In addition, there are dozens of hosts that are a combination of Digital Equipment Corporation and UNIX systems. These systems are all physically connected, but use very different network protocols to communicate. The LAN clients mainly use Internetwork Packet eXchange, the UNIX systems use TCP/IP, while the DEC systems use a combination of Local Area Transport and DECnet. Personnel at the center take reservations over the phone using a reservation system Previous screen that runs on UNIX and is connected via TCP/IP. From the same desktop system, they also perform outbound telemarketing (e.g., making customers aware of an upcoming new frequent flyer program) and must access a VAX/VMS system for lead information via the LAT protocol. In terms of connectivity, the company could: · Install all protocol stacks (i.e., Internetwork Packet eXchange, Transmission Control Protocol, LAT) at each client. Installing all these protocol stacks at each client would add wear and tear on the network management personnel alone. The stacks have to be loaded and configured on each client and, over time, must be maintained. There is also a charge for each stack-per-client. · Install a TCP/IP stack on all hosts and clients. In most cases this does not support all of the applications required, so it becomes restrictive and might require at least an IPX stack to be coresident. Although the network management personnel have fewer stacks to worry about, they still have to configure and manage two stacks at each client. · Install gateways at the edges of the LAN infrastructure to the host systems. This saves network management personnel wear and tear because the protocol translation gateway is installed at a central point. There are fewer stacks to worry about, and by simply leaving Internetwork Packet eXchange on the LAN clients, the LAN becomes easy to manage on an ongoing basis. Cost is also minimized because money is saved on protocol stacks and their subsequent maintenance. In the future, more companies will implement strategic protocols such as IPX and TCP/IP across their network backbone while applying software gateway technology to bring legacy systems into the network.
Load more

Recommended publications
  • Digital Technical Journal, Number 3, September 1986: Networking
    Netwo;king Products Digital TechnicalJournal Digital Equipment Corporation Number 3 September I 986 Contents 8 Foreword William R. Johnson, Jr. New Products 10 Digital Network Architecture Overview Anthony G. Lauck, David R. Oran, and Radia J. Perlman 2 5 PerformanceAn alysis andModeling of Digital's Networking Architecture Raj Jain and William R. Hawe 35 The DECnetjSNA Gateway Product-A Case Study in Cross Vendor Networking John P:.. �orency, David Poner, Richard P. Pitkin, and David R. Oran ._ 54 The Extended Local Area Network Architecture and LANBridge 100 William R. Hawe, Mark F. Kempf, and Alan). Kirby 7 3 Terminal Servers on Ethernet Local Area Networks Bruce E. Mann, Colin Strutt, and Mark F. Kempf 88 The DECnet-VAXProduct -A n IntegratedAp proach to Networking Paul R. Beck and James A. Krycka 100 The DECnet-ULTRIXSoftware John Forecast, James L. Jackson, and Jeffrey A. Schriesheim 108 The DECnet-DOS System Peter 0. Mierswa, David). Mitton, and Ma�ha L. Spence 117 The Evolution of Network Management Products Nancy R. La Pelle, Mark). Seger, and Mark W. Sylor 129 The NMCCjDECnet Monitor Design Mark W. Sylor 1 Editor's Introduction The paper by Bill Hawe, Mark Kempf, and AI Kirby reports how studies of potential new broad­ band products led to the development of the Extended LAN Architecture. The design of the LANBridge 100, the first product incorporating that architecture, is described, along with the trade-offs made to achieve high performance. The speed of communication between terminals and systems depends on how they are connected. Bruce Mann, Colin Strutt, and Mark Kempf explain how they developed the LAT protocol to connect terminals to hosts on an Ethernet.
    [Show full text]
  • Networks· Communications
    - Networks· Communications, ;--___...........................................e e_e __ • • • • • • • • • • • • • • • • • • • • • • • • • • • • . ... • • • • • • • • • ~---- Local Area Transport (LAT) Architecture i Network Manager's Guide " wore~D~DD~D Local Area Transport (LAT) Arch itectu re Network Manager's Guide Order No. AA-OJ 188-TK July 1985 The Local Area Transport (LA T) Architecture Network Manager's Guide is intended for network managers and system managers. It contains information about the LAT architecture. This guide also in­ cludes information for configuring and managing LAT networks. SUPERSESSION/UPDATE INFORMATION: This is a revised manual. AA-DJ18B-TK First Printing, July 1985 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corpora­ tion assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital or its affiliated companies. Copyright © 1985 by Digital .Equipment Corporation The postage-prepaid Reader's Comments form on the last page of this document requests the user's critical evaluation to assist us in preparing future documentation. The following are trademarks of Digital Equipment Corporation: DEC MASSBUS RT DECmate PDP UNIBUS DECnet P/OS VAX DECUS Professional VAXcluster DECwriter Rainbow VMS DIBOL RSTS VT ~D~DDmD RSX Work Processor Ethernet is a trademark of Xerox Corporation. This manual was produced by Networks and Communications Publications.
    [Show full text]
  • Openvms Cluster Load Balancing
    OpenVMS Cluster Load Balancing Presented by Paul Williams www.parsec.com | 888-4-PARSEC To Download this Presentation, please visit: http://www.parsec.com/public/ClusterLoadBalancing.pdf To E-mail Paul [email protected] www.parsec.com | 888-4-PARSEC Outline • Load Balancing Mechanisms • Batch and Print Queues • TCP/IP • DECnet • Local Area Transport (LAT) • Host Based Volume Shadowing • MSCP Server • Lock Manager • Questions and Answers Evaluating Load Balancing Mechanisms What happens when? •A new request is made •A node fails •Resources are exhausted on a node •A node is returned to service Load Balancing Goals •Never direct a request to a non- functional node •Direct requests to the node which can provide the best level of service •Direct requests to other nodes prior to scheduled downtime •Make failover and recovery transparent to user Load Balancing Mechanisms •Failover - All requests go to a single node while it is up •Round Robin - Balanced based only on number of requests serviced •Load Based - Balances requests based on ability of serving nodes to handle the work OpenVMS Queue Manager • Maintains all queues, forms and characteristics • Manages all jobs in each queue • Must run on one node in a VMScluster • Default is any node • Failover is automatic and transparent to users $ start /queue /manager /on=(class2,class3,*) $ show queue /manager /full Master file: STAFF_DISK:[COMMON]QMAN$MASTER.DAT; Queue manager SYS$QUEUE_MANAGER, running, on CLASS2:: /ON=(CLASS2,CLASS3,*) Database location: STAFF_DISK:[COMMON] Generic Batch Queues
    [Show full text]
  • CERN Guide to Installing ULTRIX
    CERN Guide To Installing ULTRIX Alan Lovell CN Division Version February Contents Intro duction Conguration Hardware Installation General SCSI Identication Settings DECstation DECstation Connection to the Network Before Ordering Making the Connection System Software Installation Preparing for the Installation System Backup Disk Partitions Factory Installed Software FIS Performing the Installation Installing the Supp orted Software Subsets Installing The Unsupp orted Software Subsets Remote Installation Services How Do I Use the Remote Installation Service Remote Installation of the Supp orted Software Subsets Remote Installation of Additional Software Upgrading Your System Upgrading to Version A Upgrading to Version Preparing for the Upgrade Performing the Upgrade Post Upgrade Pro cedures The License ManagementFacility LMF Registering a License Loading the License System Tailoring Setting up TCPIP Dening the External Gateway Conguring the BINDHesio d Naming Service Dening the SearchOrder Adding the Names Servers Setting up Mail ULTRIX Version Systems ULTRIX Version Systems Starting the Network File System NFS Time Setting After
    [Show full text]
  • Decserver 90L+ Owner's Manual
    DECserver 90L+ Owner’s Manual Order Number: EK-DSRVG-OM.001 January 1992 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies. Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical data and Computer Software clause at DFARS 252.227-7013. © Digital Equipment Corporation 1992. All Rights Reserved. Printed in U.S.A. FCC NOTICE: The equipment described in this manual generates, uses and may emit radio frequency energy. The equipment has been type tested and found to comply with the limits for a Class A computing device pursuant to Subpart J of Part 15 of FCC Rules, which are designed to provide reasonable protection against such radio frequency interference when operated in a commercial environment. Operation of this equipment in a residential area may cause interference, in which case the user at his own expense may be required to take measures to correct the interference. The following are trademarks of Digital Equipment Corporation: DEC, DECbridge, DECconnect, DECnet, DECserver, Digital, VMS, LAT, VAX, and the DIGITAL logo.
    [Show full text]
  • Cisco IOS Decnet Command Reference August 2010
    Cisco IOS DECnet Command Reference August 2010 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Digital Technical Journal, Volume 3, Number 3: Availability in Vaxcluster
    • Availability in VAXcluster Systems • Network Performance and Adapters Digital Technical Journal Digital Equipment Corporation Volume 3 Number 3 Summer 1991 Editorial Jane C. Blake, Editor Kathleen M. Stetson, Associate Editor Leon Descoteaux, Associate Editor Circulation Catherine M. Phillips, Administrator Sherry L. Gonzalez Production Mildred R. Rosenzweig, Production Editor Margaret Burdine, Typographer Peter Woodbury, illustrator Advisory Board Samuel H. Fuller, Chairman Richard W. Beane Robert M. Glorioso Richard]. Hollingsworth John W. McCredie Alan G. Nemeth Mahendra R. Patel E Grant Saviers Victor A. Vyssotsky Gayn B. Winters The Digital Technicaljournal is published quarterly by Digital Equipment Corporation, 146 Main Street ML01-3/B68, Maynard, Massachusetts 01754-2571. Subscriptions to the journal are $40.00 for four issues and must be prepaid in U.S. funds. University and college professors and Ph.D. students in the electri­ cal engineering and computer science fields receive complimen­ tary subscriptions upon request. Orders, inquiries, and address changes should be sent to the Digital Technical journal at the published-by address. Inquiries can also be sent electronically to DTJ®CRL.DEC.COM. Single copies and back issues are available for $16.00 each from Digital Press of Digital Equipment Corporation, 12 Crosby Drive, Bedford, MA 01730-1493. Digital employees may send subscription orders on the ENET to RDVAX::JOURNAL or by interoffice mail to mailstop ML01-3/B68. Orders should include badge number, site location code, and address. Allemployees must advise of changes of address. Comments on the content of any paper are welcomed and may be sent to the editor at the published-by or network address.
    [Show full text]
  • VT1000/VT1200 & Decimage User Guide
    This document was prepared and published by Educational Services Development and Publishing, Digital Equipment Corporation. Installing and Using The VT1000 Video Terminal Order Number EK–V1000–UG–002 Digital Equipment Corporation First Edition, February 1990 Second Edition, June 1990 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies. Restricted Rights: Use, duplication, or disclosure by the U. S. Government is subject to restrictions as set forth in subparagraph(c)(1)(ii)oftheRights in Technical Data and Computer Software clause at DFARS 252.227–7013. Copyright © by Digital Equipment Corporation 1990 All Rights Reserved. Printed in Taiwan. FCC NOTICE: The equipment described in this manual generates, uses, and may emit radio frequency energy. The equipment has been type tested and found to comply with the limits for a Class A computing device pursuant to Subpart J of Part 15 of FCC Rules, which are designed to provide reasonable protection against such radio frequency interference when operated in a commercial environment. Operation of this equipment in a residential area may cause interference, in which case the user at his own expense may be required to take measures to correct the interference.
    [Show full text]
  • Decnet LAVC Network
    Appendix K - DECnet DECnet Originally created to allow 2 PDP-11s to communicate over Ethernet, DECnet was introduced in 1975 by the Digital Equipment Corporation. DECnet is now used to enable DEC equipment to communicate in an intranet environment. DECnet encompasses 2 architectures, VAX and MIPS. DECnet VAX Architecture VAX, Virtual Address Extension, is a CISC architecture that comprises of Micro-VAX and VAX wide systems. VAX equipment can run either VMS or Ultrix. Most VAX servers can be clustered, thereby creating high availability systems that are scalable, can load balance, and can share data and peripherals. VAX servers and peripherals communicate over an external bus called LAVC or Local Area VAX Cluster. LAVC are characterized with 2 to 96 VAX devices interconnected by an external bus. LAVC also incorporate the use of Terminal Servers. SCA, or System Communication Architecture, provides for LAVC over standard Ethernet. Since Ethernet is an extendable technology, hosts and peripherals can be located in dispersed geographical locations. LAVC over Ethernet can be used to transport various network protocols at the same time. In some cases LAVC devices use a CI bus, or Computer Interconnect bus. This is a high speed bus, usually 70Mbps over 4 coaxial cables, which connects all devices at a star coupler. This bus is limited to 50ft, restricting it to close quartered equipment. On the bus is a HSC, or Hierarchal Storage Controller, that allows for data storage shadowing. Data storage shadowing is a process by which data is written to two dispersed storage devices at the same time. DECnet LAVC Network VT100 VT220 VT52 Computer Terminal server Ethernet VAX Micro VAX Star Coupler CI BUS Micro VAX Disk array Disk array DECnet MIPS architecture DECnet MIPS devices run ULTRIX.
    [Show full text]
  • Linux HPC Cluster Installation
    Front cover Acrobat bookmark Draft Document for Review June 15, 2001 6:30 pm SG24-6041-00 Linux HPC Cluster Installation xCAT - xCluster Administration Tools Developed by Egan Ford IBM ^ xSeries Intel-based Linux® Installing Red Hat® with Kickstart and xCAT Luis Ferreira, Gregory Kettmann Andreas Thomasch, Eillen Silcocks Jacob Chen, Jean-Claude Daunois Jens Ihamo, Makoto Harada Steve Hill and Walter Bernocchi ibm.com/redbooks Draft Document for Review June 15, 2001 6:29 pm 6041edno.fm International Technical Support Organization Linux High Performance Cluster Installation May 2001 SG24-6041-00 6041edno.fm Draft Document for Review June 15, 2001 6:29 pm Take Note! Before using this information and the product it supports, be sure to read the general information in “Special notices” on page 239. First Edition (May 2001) This edition applies to Red Hat® Linux® Version 6.2 for Intel® Architecture. This document created or updated on June 15, 2001. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. © Copyright International Business Machines Corporation 2001. All rights reserved. Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. Draft Document for Review June 15, 2001 6:29 pm 6041TOC.fm Contents Figures .
    [Show full text]
  • RSTS/E Programming Manual Order Number: AA-EZ09B-TC
    RSTS/E Programming Manual Order Number: AA-EZ09B-TC August 1990 This manual dascribes RSTS/E spedal programming techniques. It contains infonnation on device-dependent featuresand the use ofsystem function calls. Operating System and Version: RSTS/E Verdon 10.0 Software Version: RSTS/E Version 10.0 &Mentec w Update Notice No. 1 RSTS/E Programming Manual Order Number: AD-EZ09B-T1 September 1992 New and Changed Information This update contains changes and additions made to the RSTS/E Programming Manuel. Copyright ©1992 by Digital EquipmentCorporation All Rights Reserved. Printed In U.S.A. Instructions The enclosed pages are replacements oradditions to current pages In the RSTS/E Programming Manual, The change bars(|) onthe replacement pages Indicate new or revised material. Old Page New Page Title page/Copyright page Title page/Copyright page iii/iv through xv/xvi iii/iv through xv/^vi xix/xx xix/xx 1-7/1-8 1-7/1-8 through 1-8.1/blank 1-21/1-22 through 1-23/1-24 1-21/1-22 through 1-23/1-24 2-1/2-2 through 2-5/2-6 2-1/2-2 through 2-6.1/blank 2-21/2-22 2-21/2-22 2-29/2-30 2-29/2-30 3-1/3-2 81/3-2 through 82.1/blank 4-1/4-2 4-1/4-2 4-5/4-6 4-5/4-6 tiirough 4-6.1/t^ank 4-15/4-16 through 4-19/4-20 4-15/4-16 through 4-19/4-20 4-23/4-24 4-23/4-24 4-27/4-28 4-27/4-28 4-37/4-38 4-37/4-38 4-45/4-46 4-45/4-46 8-3/8-4 through 8-11/8-12 8-3/8-4 through 811/812 8-21/8-22 821/822 through 822.1/blank 8-35/8-36 835/836 through 836.1/836.2 8-51/8-52 through 853/8-54 851/852 through 853/8-54 8-87/-888 887/888 through 8-88.1/blank 897/898 through 899/8100
    [Show full text]
  • Decnet-ULTRIX
    DECnet-ULTRIX Network Management Order 'Number: AA-EE38D-TE DECnet-ULTRIX c Network Management May 1990 This manual introduces DECnet databases and components and shows how you use the Network Control Program (ncp) to configure, monitor, and test the components. Supersession/Update Information: This is a revised manual. Operating System and Version: ULTRIX V4.0 c Software Version: DECnet-ULTRIX V4.0 o Order Number: AA-EES8D-TE AA-EE38D-TE May 1990 c The infonnatlon in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital or its affiliated companies. Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Copyright ©1985, 1987, 1990 by Digital Equipment Corporation All Rights Reserved The following are trademarks of Digital Equipment Corporation: DEC PDP VAX DECnet ULTRIX VMS DECUS UNIBUS mamDDmDlM UNIX is a registered trademark of AT&T in the USA and other countries. This manual was produced by Networks and Communications Publications. c c Contents Preface. • . • . • . • . • . • • . • • . vii Chapter 1 Overview of the OECnet Network 1.1 DECnet and the ULTRIX Operating System •....•.........•.•.......
    [Show full text]