HP OpenVMS Systems Documentation

Table 3-2 describes how you use decnet_register to reregister a Phase IV system currently registered in the namespace after migrating the system to DECnet-Plus.

3.2.4.3 Registering a System You Changed from DECnet-Plus to Phase IV

Before you start to transition any system in a OpenVMS cluster, you need to gather the following information:

• The DECnet Phase V node name and address.
  When a node is configured as a cluster member, the DECnet Phase V name and address are used to set the sysgen parameters scsnode and scssystemid. With Phase IV, the DECnet name and DECnet Phase V address you enter during cluster configuration has to be the same as the name and address you enter during the DECnet for OpenVMS configuration procedure. With DECnet-Plus, scsnode can be different from the DECnet node name and the scssystemid can be different from the DECnet Phase V address.
• If the OpenVMS cluster system you are migrating participates in the cluster alias, you need the following information:
  • Is the cluster making the transition gradually so that it is operating with a mixture of Phase IV and DECnet-Plus systems, or all at once?
  • If gradually, should the cluster alias be enabled on this system?

    Note Do not enable the cluster alias on any DECnet-Plus OpenVMS cluster system until you have migrated all the systems participating in the alias.

  To migrate an OpenVMS cluster node, when net$configure.com prompts you for the system's node name and address, enter the system's Phase IV node name and Phase IV address. For more information about migrating OpenVMS cluster nodes to DECnet-Plus, refer to DECnet-Plus for OpenVMS Installation and Basic Configuration or DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration.

  3.2.6 Migrating Local Area Networks

  Migrating your LAN requires you to pay close attention to your routers. During Step 1 of your planning activities, you identified the routers in your network and specified their type, location, and function. Now you need that information.

  This section shows the steps of a typical transition of a two-area LAN, highlighting:

  • How DECnet-Plus software is introduced to the LAN
  • How routing works with a mixture of Phase IV and DECnet-Plus systems
  • How all the routers are gradually configured to use the link state protocol
  • How the network eventually makes a complete transition to DECnet-Plus

  This section, without specific NCL commands, describes the LAN migration in a general way. See your router documentation for detailed instructions. Figure 3-1 shows an example of a LAN to be migrated to DECnet-Plus.

  Figure 3-1 Two-Area Phase IV LAN to Be Migrated to DECnet-Plus

  ---

  

  Begin the transition with the following steps:

  1. Install DECnet-Plus on one router and three end systems on the LAN.
  2. Configure each DECnet-Plus system's address to the same node address it had as a Phase IV end node.
  3. Configure the router to use the routing vector protocol at level 1 and level 2.

  Areas 4 and 55 are still separate and distinct. Phase V routers allow multiple areas to exist on a LAN if the areas have Phase IV-compatible addresses.

  Figure 3-2 shows the LAN once transition has started.

  Figure 3-2 Phase IV LAN with Some DECnet-Plus Systems

  ---

  

  Note Although each system has the same address it had as a Phase IV node, the addresses are never displayed (by NCL, for example) in the familiar Phase IV-style. In this LAN, the end system with the address 4.3 actually has the address 49::00-04:aa-00-04-00-03-10:20. DECnet-Plus automatically converts and stores the Phase IV address in this form.

  The next step is to configure all level 1 routing in area 4 to link state as follows:

  1. Upgrade all the routers in area 4 to DECnet-Plus.
  2. Configure all the area 4 routers to run the link state protocol at level 1.

  At this point, at level 1, area 4 is link state, and area 55 is routing vector. Level 2 in both areas is still routing vector.

  Note Changing the routing algorithm that each router runs does not affect the end systems. DECnet-Plus end nodes use the ES-IS protocol to communicate with Phase V routers, regardless of the routing algorithm the router is running.

  Continue upgrading routers until both areas are running link state at level 1. This requires all routers to be upgraded to DECnet-Plus. Both areas are still using Phase IV-compatible addresses.

  When all the level 2 routers in the LAN are running DECnet-Plus, you can convert the level 2 network to use link state simply by issuing a command to the router.

  Figure 3-3 shows the network configuration.

  Figure 3-3 LAN with Link State at Levels 1 and 2

  ---

  

  The next step is to move area 4 to DECnet Phase V addressing, which allows you to enable autoconfiguration and eventually remove area 4 from the network. The LAN can contain only one DECnet Phase V address area, as well as multiple Phase IV areas.

  This example shows the creation of DECnet Phase V address area 100. In this example, the IDP is unique, with an AFI of 39 and an IDI of 345. The new DECnet Phase V area is 39:345:00-64. For instructions on how to construct your own unique IDP, see Chapter 4.

  Follow these steps:

  1. Upgrade all end systems in area 4 to DECnet-Plus.
  2. During each configuration, answer YES when the script asks if you want to enable autoconfiguration.
  3. Add the DECnet Phase V area to all the area 4 routers using NCL.

  Immediately, each DECnet-Plus end system on the LAN (in both areas) autoconfigures to the new DECnet Phase V address. Each system also maintains its original manually-configured area 4 or 55 address. These systems are now multihomed (they have two distinct addresses). Thus, communication can reach the DECnet-Plus end systems in area 4 by the addresses 4.id or 39:345:00-64.id. The same is true for any DECnet-Plus end system in area 55. Figure 3-4 shows an example.

  Figure 3-4 LAN with Multihomed Systems

  ---

  

  Finally, when all Phase IV end systems in area 4 are either migrated to DECnet-Plus or moved to another area, you can remove area 4 from the network. Follow these steps:

  1. Clear the Phase IV-compatible area 4 address from each end system using NCL.
  2. Remove area 4 from each area 4 router using NCL.

  The results of this last set of changes are that:

  • All end systems that were in area 4 are now autoconfigured into the DECnet Phase V address area 39:345:00-64 and are no longer multihomed.
  • Unless an end system has a Phase IV-compatible address, it cannot communicate with Phase IV nodes or to nodes in areas that have only Phase IV routers. In this example, because the DECnet-Plus node in area 55 is still multihomed to a Phase IV-compatible address as well as the DECnet Phase V address space, it can still communicate with Phase IV nodes and to nodes in areas with Phase IV routers.

  Figure 3-5 shows the next stage of the LAN configuration.

  Figure 3-5 LAN with One DECnet Phase V Area

  ---

  

  Eventually, the LAN manager finishes migrating the systems in area 55 to DECnet-Plus, so that area 55 can be removed from the LAN, thus completing the transition to a DECnet-Plus LAN. For now, though, the LAN can remain in the transition environment.

  3.2.7 Configuring a DECnet-Plus End System in a Multivendor OSI Network

  The DECnet-Plus software supports OSI addressing and OSI data-packet formats, allowing you to configure a DECnet-Plus end system as an OSI end system in a multivendor OSI environment. You can also configure other vendors' OSI end systems in a DECnet Phase V network (see your network management guide).

  To configure a DECnet-Plus end system to operate in a multivendor OSI network, install the DECnet-Plus software and configure the system as follows:

  • Answer no when the configuration script asks if you want the system to autoconfigure its address. Manually enter the NET or NETs specified by your network administrator.
  • If you choose to use the DECdns name server software, configure the system as a DECdns clerk or server.
  • If you choose to use the DECdts time server software, configure the system as a DECdts server or clerk.

  3.3 Additional Tasks

  You have several additional transition tasks. Some are performed automatically, and others you perform, perhaps on an on-going basis, as your network operation requires:
  • If your network uses a distributed namespace, manage .DNA_Registrar and the other DECdns access control groups.
    See Section 7.4 for a discussion of possible access control policies. See the DECnet-Plus DECdns Management guide for details on modifying access.
  • If your network uses a distributed namespace, replicate the node directories and any other name server directories you have created.
    See Section 8.2 for guidelines on replicating node directories. See the DECnet-Plus DECdns Management guide for general replication guidelines and for details on how to replicate directories.
  • Become familiar with NCL. The following tools and documentation are available:
    • Use the CONVERT command of decnet_migrate. On the CONVERT command line, you specify an NCP command and the tool then displays the nearest NCL equivalent.
      For complete information about running decnet_migrate, see your network management guide.
    • Read Section 3.3.4 in this book as well as the introduction to using NCL and its command syntax in the DECnet-Plus Network Control Language Reference.
    • Use the network management GUI and enable the display of NCL output. See DECnet-Plus for OpenVMS Network Management for more information.
  • Modify all command procedures or shell scripts that issue NCP commands; convert the NCP commands to NCL equivalents.
    Use the commands of the decnet_migrate convert tool. For information about how to use these commands, see your network management guide.
  • Periodically obtain a report of the network's configuration to check the progress of the transition.
    Use the decnet_migrate tool's COLLECT and REPORT commands. For information about how to use these commands, see your network management guide.
  • If communication problems develop, use the SHOW PATH command of decnet_migrate to determine the communication paths between the nodes. For information about how to use this command, see your network management guide.
  • Set up interphase links between level 2 routers using different routing algorithms.
    Use the decnet_migrate tool's ipl_initialization_file command. For information about how to use this command, see your network management guide.
  • Convert the Phase IV object database to a DECnet-Plus application database.
    For OpenVMS, answer YES during net$configure.com to the question that asks if you want to convert Phase IV databases.
    For DIGITAL UNIX, use the objtoncl tool (see Section 3.3.1).
    
    
  • Convert the DECnet Phase IV proxy file to a DECnet-Plus proxy database.
    Use the proxytoncl tool to convert the /etc/dnet_proxy file (see Section 3.3.2). <>
  • Convert the MOP database to a DECnet-Plus MOP client database.
    For OpenVMS, answer YES during net$configure.com to the question that asks if you want to convert Phase IV databases.
    For DIGITAL UNIX, run update_mopdb (see Section 3.3.3).

  3.3.1 Converting the Phase IV Object Database with the OBJTONCL Utility (DIGITAL UNIX Only)

  Session Control maintains a database of applications that is similar to the Phase IV object database. This application database includes information about DECnet utilities, such as FAL (file access listener) or dlogin, and user-written application entities that are registered using NCL commands. The applications list is used to associate incoming connect requests with the relevant processes to handle them. If a Phase IV application uses the object spawner to start up a target application, you must convert the object database to an application database for the program to function properly.

  The objtoncl utility allows you to convert your Phase IV object databases to DECnet-Plus application databases. This utility generates the appropriate NCL commands needed to make the conversion. You can use this utility to convert all the objects in a volatile database, all the objects in a permanent database, or selected objects in either type of database.

  The objtoncl utility uses the following syntax:

  /usr/field/objtoncl [-v] [-p] [-f] [filename] [object name]

  The switches allow you to specify which object database to convert. The object name allows you to specify a particular object in a given database. Table 3-3 explains each switch.

  Table 3-3 OBJTONCL Switches

  Switch	Meaning
  -v	Specifies conversion of the objects in the volatile database in /usr/lib/dnet/objects_v.
  -p	Specifies conversion of the objects in the permanent databases in /usr/lib/dnet/objects_p. This switch does not have to be specified explicitly because it is the default.
  -f	Allows you to specify a particular object database file name.

  If you only want to convert specific objects, you can specify them as part of the command line argument. For example, the following arguments specify the conversion of specific objects in a specific database file:

  objtoncl -f objects.saved myobj yourobj hisobj herobj

  You can redirect the output of the command line to a file. You can then modify the NCL commands before inputting the file into NCL.

  3.3.2 Converting the Phase IV Proxy File (DIGITAL UNIX Only)

  Phase IV nodes use a proxy file, /etc/dnet_proxy, to specify proxy access. DECnet-Plus systems use a proxy database managed by NCL instead. When you upgrade your Phase IV node to DECnet-Plus, if you want to maintain the same proxy access, you can also upgrade the Phase IV proxy file to a DECnet-Plus proxy database.

  DECnet-Plus provides a transition tool, /usr/field/proxytoncl, that generates the NCL commands necessary to create proxy entries in the DECnet-Plus proxy database. These proxy entries are equivalent to the entries in the original Phase IV proxy file.

  Note Check the entries in the Phase IV proxy file for wildcards: You can use wildcards to specify user names (node::*). The resulting NCL commands create proxy access for all users on the specified node. You cannot use wildcards to specify node names (*::* or *::user_name). The resulting NCL commands create proxy access on the node with the name "*".

  To generate the NCL commands, issue the following command as superuser:

  # /usr/field/proxytoncl

  The command displays the NCL commands to standard output. You can redirect the NCL commands to a file and modify them before inputting the file to NCL. Two reasons to modify the resulting NCL commands before using them are:

  • If the Phase IV proxy file contains more than one remote account granting access to the same target user, the resulting NCL commands create the same session control proxy subentity name for those proxy entries. Edit the commands so that the session control proxy subentity name is unique.
  • The node names listed in the Phase IV proxy file are Phase IV node synonyms. The DECnet-Plus proxy database must have all DECnet-Plus full names.
    The proxytoncl command attempts to convert the Phase IV node synonyms from /etc/dnet_proxy to their full names. It prints out a warning message for the names it fails to convert. Edit the commands to replace each Phase IV synonym with a DECnet-Plus full name.

  3.3.3 Converting the MOP Database (DIGITAL UNIX Only)

  If your DECnet-Plus system will be a remote installation service (RIS) server or DIGITAL UNIX load host, you need to create the new MOP client database required by the MOP Version 4 protocol. You create this database using /usr/field/update_mopdb, which converts the Phase IV MOP database, /usr/lib/dnet/nodes_p, to the new DECnet-Plus MOP client database, /var/dna/mop_client_db.

  During installation, if you have a nodes_p and no existing MOP client database on your system, decnetsetup automatically runs the MOP database conversion tool and creates a new MOP client database for you.

  If decnetsetup did not create a database for your system, you can create one manually using the /usr/field/update_mopdb tool, as follows:

  1. Make sure you have an updated copy of /usr/lib/dnet/nodes_p on your system.
  2. Issue the following command:
     % /usr/field/update_mopdb [Return]
     This creates an NCL script, named /var/dna/scripts/create_mop_client_db.ncl, which contains the commands that create the database.
  3. Run the create_mop_client_db.ncl command file:
     ncl> do create_mop_client_db.ncl [Return]
     This command file creates the DECnet-Plus MOP client database, /var/dna/mop_client_db.

  After completing these steps, your system is ready to function as an RIS server or an DIGITAL UNIX load host.

  ---

  Previous

  Next

  Contents

  Index