[comp.os.vms] Changing DECnet Area #'s

tpmsph@ecsvax.UUCP (Thomas P. Morris) (04/13/88)

	Here at the University of North Carolina at Chapel Hill,
School of Public Health, we're in the process of connecting our
building-local ethernet to a campus-wide and state-wide extended
ethernet (using a Bridge IB/1 to connect baseband to broadband enets).

Our current DECnet area is #1. We've got 3 VAXen hosts, about 5-10 
DECnet defs for PC's and 10 DECserver 200's, all with definitions in
our DECnet database. What sort of problems should I expect in trying
to change over our area number from 1 to 30?

Any helpful suggestions or warnings would be welcome.

-----------------------------------------------------------------------------
Tom Morris                                 BITNET: TOM@UNCSPHVX
UNC School of Public Health                UUCP  : ...!mcnc!ecsvax!tpmsph

        "It's a joke, boy! I say, it's a joke! Don't ya get it?"
                                                -Foghorn Leghorn
-----------------------------------------------------------------------------

SYSRUTH@utorphys.BITNET (05/07/88)

You probably won't have any problems at all, as long as *everything*
has its address changed (you can probably keep the same within-area
address sequence, or you might want to assign ranges to each group,
which would reduce the risk of conflict when adding new nodes; but maybe
that isn't an issue for you), and as long as all your VAXes are at
Version 4.n (as I assume they are). Here at U. of Toronto we went
from area 1 to area 60 about a year or so ago, with no major problems.
We had to co-ordinate everything well in advance because there are so
many groups around campus in the DECnet. If you are running cluster
software on any of your systems, you may have to modify the SCSSYSTEMID
parameter (in fact, you might need to modify it anyway). Also make
sure that each system has the NCP maximum area and maximum address
parameters set up to handle the new numbers.
     
Essentially, just make up a new table of node definitions (don't forget
the EXECUTOR one for each node), purge (?) the permanent databases, feed
the new table into NCP (permanent), change SCSSYSTEMID if necessary,
and reboot everything (easiest), preferably at the same time. Note that
you may lose touch for a few minutes with any nodes that are ahead of/
behind you in the procedure, but they will come back. If you are all
in the same area, you won't even need an area router. Don't forget to
change your DECservers' addresses as well. You might find it easiest to
use the DSVCONFIG routine as the basis for a new routine to add the
required information to your new database.
     
As far as I recall, that's all there is to it. (Std. disclaimer: check
into things yourself, I take no responsibility for the reliability of my
memory - it's not ECC :-) ). If I find anything else, I'll let you know.
     
Ruth Milner
Systems Manager
University of Toronto Physics