BMW6957@TAMCHEM.BITNET.UUCP (03/24/87)
Regarding the recent question about changing the area address under
RSX. I can't seem to get through to the interested party, so I'll post
my response to the net. Maybe the VMS types on INFO-VAX will appreciate
how easy they have it after reading this.
First, I'll assume that the operating system is RSX-11M, rather than
RSX-11S or RSX-11M-PLUS (why? Because that's what I have :-) ). PLUS
should be similar enough that this info will still be useful.
Unless you intend to make more drastic changes than simply re-addressing
the area, you will not need to do another SYSGEN nor NETGEN. You shouldn't
need to do another SYSGEN in any event, but a NETGEN would be necessary if
you changed from a non-routing to a routing node or vice-versa (for example).
There are 3 utilities which are used to modify the network under RSX:
CFE - Configuration File Editor, updates the premanent database
VNP - Virtual Network Program, updates the system's boot image
NCP - Network Control Program, updates the running (Volatile) network
I will assume that you are using the default filenames of CETAB.MAC for the
permanent database and RSX11M.SYS for the boot image. CETAB.MAC is in UFD
[net,54], where 'net' is the network group (usually 5). RSX11M.SYS should
be in the system UFD, [1,54].
First, you will need to find out a little about how the network is currently
configured. Log onto the running system as a privileged user and set your
CLI to MCR (if you're currently using DCL, the command SET TERM MCR should
do it). Then type the command NCP SHOW EXEC (If NCP is not installed, first
install it with INS [5,54]NCP -- assuming the network group is 5). If the
address of the executor does NOT include the area number, then you are
running a phase III node and you shouldn't have to change anything. A phase
III node is always in the same area as the phase IV node to which it is
attached. If the executor address includes the area number, then you will
have to make some changes. Now, set your UFD to that of the boot image
(SET /UIC=[1,54], if your system is standard) and RUN [5,54]VNP. When
VNP prompts for a filename, give it the filename of the boot image --
RSX11M is the norm. At the VNP> prompt issue the command SHOW EXEC.
If you get the message:
VNP - Communications Executive Not Loaded
Then your network has not been loaded into the boot image. Exit VNP with
a control-Z.
Next, if your network HAS been loaded into the boot image, it will probably
be easier to remove it with VNP and then use VNP to reinstall the network
after making the changes. There is a problem with this, since VNP can be
used to make minor changes to the network so that the permanent database
(CETAB.MAC) may not be an accurate reflection of the current network. You
may want to use VNP as above to get a list of known circuits, known processes,
known lines, known nodes, system, and executor parameters to compare them
with those in the permanent database. I don't use VNP, but I believe the
commands are (in VNP, of course) SHOW KNOWN CIRCUITS, SHOW KNOWN PROCESS,
SHOW KNOWN LINES, SHOW KNOWN NODES, SHOW SYSTEM, and SHOW EXEC CHAR. You
should be able to remove the network from the boot image with the VNP
command CLEAR SYS (you may have to set various items to STATE OFF, first).
Now, you should use CFE to update the permanent database (NEVER USE AN
EDITOR OTHER THAN CFE ON CETAB.MAC! NEVER, NEVER, NEVER!). Changing
the area of the executor WILL NOT "carry along" the other nodes. Each
node address will need to be changed separately. If you have an extensive
node database, it might be wise have NCP show the known nodes to a file
so that it can be editted into the appropriate CFE commands (Use, at
MCR level with the net up, the command NCP SHOW KNOWN NODES TO file).
To use CFE, change your UFD to [5,54] (assuming the network group is 5).
and then RUN CFE. When CFE prompts for a filename, give it the name of
the permanent database (CETAB.MAC) or simply hit a return to take the
default. At the CFE prompt, the node area can be changed with
CFE> SET EXEC ADDRESS area.node HOST area.node
For each remote node that needs to be changed, use
CFE> CLEAR NODE xxx ALL
CFE> SET NODE area.node NAME xxx
If you have all these commands in a text file, then simply enter @filename
at the CFE> prompt. Exit CFE with a control-Z and the database will be
updated. To cancel the changes, exit CFE with the KILL command.
Finally, if your network was NOT loaded into the boot image, you should be
finished. The changes will take effect at the next boot (actually at the
next network load, which is usually done at boot time). If your network
WAS loaded into the boot image, use VNP to load the new network parameters
(Assuming that you have already removed the old network, the VNP command
SET SYSTEM should load the new one).
BEWARE that VNP (like the system utility VMR) will corrupt your system's
boot image if a crash occurs during processing. This may leave your system
in an unbootable state, so ALWAYS be sure you have a current backup of the
system disk before attempting any of this!
Hope this helps.
Brad Wilson
Chemistry Department
Texas A&M University
BMW6957@TAMCHEM.BITNET
(409) 845-2529carl@CitHex.Caltech.EDU.UUCP (03/25/87)
> Regarding the recent question about changing the area address under > RSX. I can't seem to get through to the interested party, so I'll post > my response to the net. Maybe the VMS types on INFO-VAX will appreciate > how easy they have it after reading this. Apparently you've never managed a VMS system running DECnet. Your war story sounds not much different than the way things go when you want to make substantial changes to your network on a VMS system. > First, I'll assume that the operating system is RSX-11M, rather than > RSX-11S or RSX-11M-PLUS (why? Because that's what I have :-) ). PLUS > should be similar enough that this info will still be useful. And I'll assume that the operating system is VMS V4.5 (since the upgrade from V4.4 involved substantial changes to the Network Control Program's interface to important parts of the network databases on my VAX). VMS V4.4's software should be similar enough that this info will still be useful unless you've got PSI (or worse, PSI-ACCESS) as part of your network software. > Unless you intend to make more drastic changes than simply re-addressing > the area, you will not need to do another SYSGEN nor NETGEN. You shouldn't > need to do another SYSGEN in any event, but a NETGEN would be necessary if > you changed from a non-routing to a routing node or vice-versa (for example). Similarly under VMS; though if you're planning to run PSI, be prepared to generate your network databases from scratch if you misinterpret the placement of a comma somewhere in the installation guide. > There are 3 utilities which are used to modify the network under RSX: > CFE - Configuration File Editor, updates the premanent database > VNP - Virtual Network Program, updates the system's boot image > NCP - Network Control Program, updates the running (Volatile) network > I will assume that you are using the default filenames of CETAB.MAC for the > permanent database and RSX11M.SYS for the boot image. CETAB.MAC is in UFD > [net,54], where 'net' is the network group (usually 5). RSX11M.SYS should > be in the system UFD, [1,54]. VMS has but a single utility in place of the three on RSX. Under VMS, NCP gets to edit both the volatile and the permanent databases. (Unless, of course, you've got PSI. Then you've got lots of disjointed utilities that let you manage your (highly distibuted) network databases. I'm still not sure what a number of the PSI utilities do, other than looping indefinitely, purging your entire DECnet database, and letting you use three databases in addition to those that come with DECnet to define access to your network (By the way, if anybody out there's figured out how to use PSIAUTHORIZE to grant reverse-charging access to your DTE to users on some (but not all) remote DTE's, I'd appreciate hearing about it). You don't have to worry about non-default names for your decnet databases on your VMS system; they've got to be in the default locations with the default names, and with the passwords for the default accounts stored in the clear. > First, you will need to find out a little about how the network is currently > configured. Log onto the running system as a privileged user and set your > CLI to MCR (if you're currently using DCL, the command SET TERM MCR should > do it). Then type the command NCP SHOW EXEC (If NCP is not installed, first > install it with INS [5,54]NCP -- assuming the network group is 5). If the > address of the executor does NOT include the area number, then you are > running a phase III node and you shouldn't have to change anything. A phase > III node is always in the same area as the phase IV node to which it is > attached. If the executor address includes the area number, then you will > have to make some changes. Now, set your UFD to that of the boot image > (SET /UIC=[1,54], if your system is standard) and RUN [5,54]VNP. When > VNP prompts for a filename, give it the filename of the boot image -- > RSX11M is the norm. At the VNP> prompt issue the command SHOW EXEC. > If you get the message: > > VNP - Communications Executive Not Loaded > > Then your network has not been loaded into the boot image. Exit VNP with > a control-Z. Under VMS, you don't have to go to quite this much trouble. You don't HAVE to change UIC's to deal with the network (unless you've got the "Coloured Books Software" package layered on top of PSI; then you MUST be logged in as SYSTEM to modify the extra authorization database that comes with that product (and the system account MUST have the rightslist identifier SYSTEM). You just log in on an account with OPER and SYSPRV privileges and type the command "MCR NCP SHOW EXEC". If the address of the executor does not include the area number, then you're running.... (just like for RSX). At this point the systems diverge: you don't build DECnet into the boot image under VMS. This means that it has to go through a series of rather longish DCL procedures every time you boot your system. > Next, if your network HAS been loaded into the boot image, it will probably > be easier to remove it with VNP and then use VNP to reinstall the network > after making the changes. There is a problem with this, since VNP can be > used to make minor changes to the network so that the permanent database > (CETAB.MAC) may not be an accurate reflection of the current network. You > may want to use VNP as above to get a list of known circuits, known processes, > known lines, known nodes, system, and executor parameters to compare them > with those in the permanent database. I don't use VNP, but I believe the > commands are (in VNP, of course) SHOW KNOWN CIRCUITS, SHOW KNOWN PROCESS, > SHOW KNOWN LINES, SHOW KNOWN NODES, SHOW SYSTEM, and SHOW EXEC CHAR. You > should be able to remove the network from the boot image with the VNP > command CLEAR SYS (you may have to set various items to STATE OFF, first). On the other hand, since under VMS NCP can be used to make minor (or major) changes in the network without necessarily affecting the permanent database, there's no guarantee that the permanent database accurately reflects you current configuration. (PSI, of course, just LOVES to modify your volatile database via DCL procedures after you've got your basic DECnet software running). Your only sure way to find out how your machine's network interfaces are configured is to (you guessed it) use the commands "MCR NCP SHOW EXECUTOR STATUS", "MCR NCP SHOW EXECUTOR CHARACTERISTICS", "MCR NCP SHOW KNOWN LINES STATUS", "MCR NCP SHOW KNOWN LINES CHARACTERISTICS", "MCR NCP SHOW KNOWN CIRCUITS STATUS", "MCR NCP SHOW KNOWN CIRCUITS CHARACTERISTICS", "MCR NCP SHOW KNOWN OBJECTS STATUS", "MCR NCP SHOW KNOWN OBJECTS CHARACTERISTICS", "MCR NCP SHOW KNOWN NODES STATUS", "MCR NCP SHOW KNOWN NODES CHARACTERISTICS", (and if you've got PSI, "MCR NCP SHOW MODULE X25-PROTOCOL KNOWN DTES CHARACTERISTICS", "MCR NCP SHOW MODULE X25-PROTOCOL KNOWN DTES STATUS", "MCR NCP SHOW MODULE X25-PROTOCOL KNOWN GROUPS CHARACTERISTICS", "MCR NCP SHOW MODULE X25-PROTOCOL KNOWN GROUPS STATUS", "MCR NCP SHOW MODULE X25-PROTOCOL KNOWN NETWORKS CHARACTERISTICS", "MCR NCP SHOW MODULE X25-PROTOCOL KNOWN NETWORKS STATUS", "MCR NCP SHOW MODULE X25-SERVER STATUS", "MCR NCP SHOW MODULE X25-SERVER CHARACTERISTICS", "MCR NCP SHOW MODULE X25-SERVER KNOWN DESTINATIONS STATUS", "MCR NCP SHOW MODULE X25-SERVER KNOWN DESTINATIONS CHARACTERISTICS", "MCR NCP SHOW MODULE X29-SERVER STATUS", "MCR NCP SHOW MODULE X29-SERVER CHARACTERISTICS", "MCR NCP SHOW MODULE X29-SERVER KNOWN DESTINATIONS STATUS", and "MCR NCP SHOW MODULE X29-SERVER KNOWN DESTINATIONS CHARACTERISTICS"). > Now, you should use CFE to update the permanent database (NEVER USE AN > EDITOR OTHER THAN CFE ON CETAB.MAC! NEVER, NEVER, NEVER!). Changing > the area of the executor WILL NOT "carry along" the other nodes. Each > node address will need to be changed separately. If you have an extensive > node database, it might be wise have NCP show the known nodes to a file > so that it can be editted into the appropriate CFE commands (Use, at > MCR level with the net up, the command NCP SHOW KNOWN NODES TO file). > To use CFE, change your UFD to [5,54] (assuming the network group is 5). > and then RUN CFE. When CFE prompts for a filename, give it the name of > the permanent database (CETAB.MAC) or simply hit a return to take the > default. At the CFE prompt, the node area can be changed with > > CFE> SET EXEC ADDRESS area.node HOST area.node > > For each remote node that needs to be changed, use > > CFE> CLEAR NODE xxx ALL > CFE> SET NODE area.node NAME xxx Under VMS, you use NCP to update the permanent database (there are times I've wished there were separate utilities for administering the volatile and permanent databases; for example, the time a PSI installation procedure asked me if I wanted to update the permanent database with the new definitions for the X.25 part of our network, and I foolishly told it go ahead. The procedure's idea of updating a database was to purge all definitions, then write the data regarding the X.25 part of the network into these nice empty files). To change the address of the executor node, you 1) Use the command "MCR NCP DEFINE EXECUTOR ADDRESS nn.mmm" to change the address; 2) Shut down the DECnet; this means shutting down the PSI package (10% chance of a fatal bugcheck that crashes your system) and the Coloured Books Software as well (40% chance your system won't survive attempting to unload this sucker; it's mean); 3) Start the DECnet again (some small chance that the DECnet didn't give back all of the memory it was using when it shut down and will now crash your system because it can't find enough); 4) Start the PSI package (this one NEVER gives back all the memory it was using until the system's thoroughly dead); 5) Reload the Coloured Books Software (chances are that this one's left bits and pieces of itself lying about in memory, and it gets very upset when it runs across them while it's loading). You can change the addresses of other nodes while your DECnet is running; under VMS, if you phrase your definitions of the remote nodes both ways ("MCR NCP DEFINE NODE nodename ADDRESS address" AND "MCR NCP DEFINE NODE address NAME nodename"), you can update the vast majority of the node addresses without ever having to do an explicit purge. This has the advantage of not tampering with any nodes that you're not redefining; you won't, for example, purge some records from your permanent database, only to realize after the fact that some of those records contained access restrictions as well as address information. > If you have all these commands in a text file, then simply enter @filename > at the CFE> prompt. Exit CFE with a control-Z and the database will be > updated. To cancel the changes, exit CFE with the KILL command. Similarly under VMS; provided that you've kept the text file up-to-date. Of course, NCP doesn't bother to hold the changes you're making until you give it a final "write the new system to the database" command; it makes the changes immediately. > Finally, if your network was NOT loaded into the boot image, you should be > finished. The changes will take effect at the next boot (actually at the > next network load, which is usually done at boot time). If your network > WAS loaded into the boot image, use VNP to load the new network parameters > (Assuming that you have already removed the old network, the VNP command > SET SYSTEM should load the new one). > BEWARE that VNP (like the system utility VMR) will corrupt your system's > boot image if a crash occurs during processing. This may leave your system > in an unbootable state, so ALWAYS be sure you have a current backup of the > system disk before attempting any of this! All in all, it sounds as if there's not a whole lot of difference between dealing with the network databases on a VMS system and dealing with them on an RSX system.