From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 28-SEP-1989 16:32
To:	MRGATE::"ARISIA::EVERHART"
Subj:	V5.2 upgrade tips

Message-Id:  <8909282015.AA10676@crdgw1.ge.com>
Received: From ICDC.LLNL.GOV by CRVAX.SRI.COM with TCP; Thu, 28 SEP 89 10:59:11 PDT
Date: Thu, 28 Sep 89 10:59 PDT
From: SCHAEFFER@amstel.llnl.gov
Subject: V5.2 upgrade tips
To: INFO-VAX@KL.SRI.COM
X-Vms-To: INFO-VAX

The following lessons were learned during a recent upgrade of a CI only
cluster, consisting of 2 750s, from VMS 4.7 to VMS 5.2. I hope I can save
someone else the time I lost by not knowing these things in advance.

The first thing I learned is that the 'G' option of VMSINSTAL is broken. This
is so in version 4.7 but may have been fixed in later versions. I didn't see
anything in the release notes to indicate there was ever a problem but I had
dutifully moved the version 5.0 savesets to disk prior to starting the upgrade
in an attempt to minimize the downtime required. When I ran VMSINSTAL to
perform the upgrade it returned:

%VMSINSTAL-E-NOPROC, The kit's installation procedure is missing.

A call to Digital's telephone support center confirmed that this was the result
of the bug in the 'G' option. At this point I installed from tape because it
wouldn't have saved any time to load the savesets to disk again but you can get
a good copy by COPYing the files to disk. I did this with the 5.2 upgrade but
more on that later. Another, albeit less damaging, problem was that the VMS
savesets must be in the [000000] directory on disk or VMSINSTAL complains and
tells you to move them. This isn't the case for layered products. 

Another thing that is annoying but not really a problem is that when your
savesets are on an HSC mounted disk you have to answer the VMSINSTAL question
about the location of the savesets by using the HSC name followed by '$DUAx',
i.e. you can't use $1$DUAx. This is documented in the upgrade guide.
                    
I'll skip ahead, chronologically, to describe another problem with VMSINSTAL.
When I was installing VAXset, which consists of 6 products, I ran into a
problem that Digital wasn't aware of. I had put all of the savesets into a
subdirectory and when VMSINSTAL asked for the products to be installed I
responded with an '*'. It installed the first product fine but the others
failed and on the 4th it blew up completely and I found myself staring at the
old '$'. I then tried installing each product individually and it worked
perfectly. Why? I don't know. I've done this before without problem so I guess
it's just under 5.2 that it's broken.

It wasn't clear to me that the other system roots would be upgraded along with
the one I was running the upgrade from. It turns out that not only are the
files upgraded/renamed the same way as they are in the root from which the
upgrade is performed, but the first time you boot each of the other systems
they do an AUTOGEN with reboot operation automatically to get them to at least
a usable state. Very nice. You'll still have to do the normal post-upgrade
tuning.

I had to put the version 5.2 savesets on disk because the only distribution I
could get from our in-house distribution center was on TK50 (their 9-track
drive is broke). Naturally, we don't have TK50s on our 750s so the savesets
were loaded onto a disk on a microVAX and then netted over to the cluster. Both
of these transfers were accomplished with COPY and no problems were
encountered. If you do this you'll notice that the DECwindows tape doesn't have
a '.A' or '.B' saveset. Don't worry... DECwindows is installed as an option in
the VMS 5.2 upgrade and it works fine. You can also copy just the savesets from
the DECwindows TK50 if you're upgrading from disk as all the .EXEs are there so
that you can boot the TK50 when installing from TK50.

By now you have probably seen the net traffic on the subject of version 5.2
having a bug with fragmented files and extended headers. We performed the old
backup-and-restore operation on all of our disks to make sure we didn't have
any seriously fragmented files. We haven't seen any problems so far.

You may have a problem running LIBDECOMP if you don't increase the system
account's (assuming you're running from the system account) quotas to the new
defaults supplied in the SYSUAF.TEMPLATE file. The first time I ran it it
bombed out because BYTLM and PGFLQUO were too low even though they were fine
for version 4.7.

Registering license PAKs was a real treat. We have several types of CPUs here
and when I received some REAL license PAKs from Digital they didn't give me a
clue as to which of our 30 machines these PAKs were for so I used them for all
of them. Evidently these PAKs were for the microVAXs since the units listed on
the PAKs were correct for microVAXs but not even close for 750s. It turns out
that you can modify the number of units to meet your needs. I assume there must
be some limit on this but I didn't test it... I just increased our VAXset PAK
units from the 20 listed to 200 to run on 2 750s. The manual on LMF probably
addresses this but I haven't had time to read that one yet :-(.

The version 5.2 upgrade includes a command procedure to improve DECnet security
by giving each of the normal objects (mail, phone, fal, etc.) their own
directory and account including password. It is
SYS$UPDATE:NETCONFIG_UPGRADE.COM and is long overdue and much appreciated in my
opinion. It works just fine but you don't want to run it more than once! What
happens is that it adds direcroty, account and password information for each of
the objects in NCP and then runs AUTHORIZE to add the associated information.
If you run it a second time (perhaps to add the directories to another system
root) it generates new passwords and successfully changes them in NCP but gets
an error trying to add the accounts in AUTHORIZE. Now you're left with
passwords that don't match and none of the objects are accessible! Oops! Just
create the directories from DCL. Of course, this assumes your using a common
SYSUAF.DAT and NETOBJECT.DAT.

Steven J. Schaeffer
Lawrence Livermore National Laboratory
P.O. Box 808 L-546
Livermore, CA 94550

Ma Bell:	(415) 422-2304
FTS:		532-2304
INTERNET:	SCHAEFFER%AMSTEL@ICDC.LLNL.GOV