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.
|DECnet Phase V Name and Address||Autoregistration Allowed1||Autoregistration Disallowed2|
|Yes||Not required||Yes||Not required|
|Yes||Not required||No||Before booting the system for the first time, reregister the system as a DECnet-Plus system.|
|Yes 3||Before booting the system for the first time, change the Phase IV name in the namespace to the new DECnet-Plus name.||No||Before booting the system for the first time, change the Phase IV name in the namespace to the new DECnet-Plus name.|
|Yes 3||Before booting the system for the first time, change the Phase IV name in the namespace to the new DECnet-Plus name.||No||Before booting the system for the first time, change the Phase IV name in the namespace to the new DECnet-Plus name and then reregister the system as a DECnet-Plus system.|
220.127.116.11 Registering a System You Changed from DECnet-Plus to Phase IV
Use decnet_register to reregister a system in the namespace
after changing the system from DECnet-Plus to Phase IV. Phase IV
systems cannot autoregister in the namespace. See your network
management book for further information.
3.2.5 Migrating OpenVMS Cluster Nodes (OpenVMS Only)
Before you start to transition any system in a OpenVMS cluster, you need to gather the following information:
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:
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:
Figure 3-2 shows the LAN once transition has started.
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:
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.
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.
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:
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.
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:
The results of this last set of changes are that:
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:
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:
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.
|-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.
Check the entries in the Phase IV proxy file for wildcards:
To generate the NCL commands, issue the following command as superuser:
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 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: