[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference spezko::cluster

Title:+ OpenVMS Clusters - The best clusters in the world! +
Notice:This conference is COMPANY CONFIDENTIAL. See #1.3
Moderator:PROXY::MOORE
Created:Fri Aug 26 1988
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5320
Total number of notes:23384

5288.0. "How to upgrade w/ separate system disks" by NNTPD::"[email protected]" (Rick Wells) Fri Apr 18 1997 10:36

How should you proceed to upgrade a cluster with separate system disks
which is functioning in a common environment by having required VMS
files (sysuaf, rightslist, license database, vmsmail_profile, qman)
located on a shared cluster disk via /system/exec logical names?

Do these files have to be copied to the local system disk, and then 
system disk upgraded, then the files copied back to the shared disk,
etc., while the cluster is obviously shutdown?  Then repeat for other
nodes' to upgrade their private system disks.

This is an Alpha 4100 FDDI cluster with each system having local SCSI
RZ29s.  Each system disk is shadowed, locally.  Each user disk and the
disk with the shared required VMS files, is shadowed across the FDDI.
The upgrade will be 6.2-1H3 to 7.1.  I know the system disk shadowing
has to be broken prior to upgrade.
[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name		DateLines
5288.1See "Rolling Upgrade" Upgrade Documentation...XDELTA::HOFFMANSteve, OpenVMS EngineeringFri Apr 18 1997 12:003
    This is called a "rolling upgrade", and this is documented in
    the OpenVMS Installation and Upgrade Manual.
5288.2Files not on system disk?NNTPD::"[email protected]"Rick WellsMon Apr 21 1997 14:0514
I'm not as concerned with whether to do a concurrent or rolling upgrade
as I am about what to do, if anything, about the system files which have
been relocated off the system disks of the two Alpha 4100s.  I am left
to assume that upgrading is possible only if all required system files
are located on the system disk being upgraded.  Files in question are:
SYSUAF.DAT, NET*PROXY.DAT, RIGHTSLIST.DAT, VMSMAIL_PROFILE.DATA,
QMAN$MASTER.DAT, SYSALF.DAT, LMF$LICENSE.LDB, NETNODE_UPDATE.DAT,
VMS$PASSWORD_HISTORY.DATA, VMS$PASSWORD_DICTIONARY.DATA, VMS$PASSWORD_
POLICY.EXE.

One thing, if it could be confirmed that the format and data of any
of these files remains unchanged during an upgrade, it would at least
save the step of copying them BACK to the shared location after upgrade.
[Posted by WWW Notes gateway]
5288.3This upgrade is documented...XDELTA::HOFFMANSteve, OpenVMS EngineeringMon Apr 21 1997 16:0732
:I'm not as concerned with whether to do a concurrent or rolling upgrade
:as I am about what to do, if anything, about the system files which have
:been relocated off the system disks of the two Alpha 4100s. 

   You might want to review the upgrade documentation, as this
   topic is discussed there.

:I am left
:to assume that upgrading is possible only if all required system files
:are located on the system disk being upgraded.  Files in question are:
:SYSUAF.DAT, NET*PROXY.DAT, RIGHTSLIST.DAT, VMSMAIL_PROFILE.DATA,
:QMAN$MASTER.DAT, SYSALF.DAT, LMF$LICENSE.LDB, NETNODE_UPDATE.DAT,
:VMS$PASSWORD_HISTORY.DATA, VMS$PASSWORD_DICTIONARY.DATA, VMS$PASSWORD_
:POLICY.EXE.
:
:One thing, if it could be confirmed that the format and data of any
:of these files remains unchanged during an upgrade, it would at least
:save the step of copying them BACK to the shared location after upgrade.

    Officially, one must copy the files to the system disk,
    perform the upgrade, and then copy the new files back
    to their site-specific location(s).  (If you _need_ the
    system to work immediately on the final upgrade-related
    reboot, and want to avoid any odd problems, follow the
    upgrade documentation.)

    In practice, one can usually skip the relocation step.
    (In the case of V6.2-1H3 to V7.1, I don't believe any of
    the above-mentioned files changed format in any incompatible
    fashion...)