Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!ihnp4!ucbvax!XRT.UPENN.EDU!CLAYTON
From: CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.")
Newsgroups: comp.os.vms
Subject: Thoughts On Creating And Using A Cluster Common System Disk...
Message-ID: <8806020317.AA29481@linc.cis.upenn.edu>
Date: 2 Jun 88 03:18:00 GMT
Article-I.D.: linc.8806020317.AA29481
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 82

The following is provided as food for thought in light of VMS 5.x being in the 
not to distant future and the various systems that will be going through the 
upgrade process.

It is my recommendation that all systems be installed with the 'Cluster Common
System Disk' directory structure. This 'feature' has been around since the 
beginning of V4, but has been an OPTION in the installation procedure. The 
result is a VMS system disk that has the 'funny' and sometimes hard to follow 
logical name search lists for such entities as SYS$SYSTEM. These logicals 
first point to SYS$SYSROOT:[SYSEXE], then go to SYS$COMMON:[SYSEXE]. This 
format allows files to be either 'exclusive', using the term loosely, to a 
particular system or 'shared' among all cluster members.

The basis for this recomendation is detailed below.

1. ONLY by installing even number releases of V4, which are 'remastered' 
versions of the complete VMS system, can the option be invoked to build a 
cluster common system disk (CCSD). If your system happens to be at 4.7, with a 
single system boot disk and you now have a cluster, either CI or NI, walking 
in the door, you have a lot of work to do. First is to install 4.6 (again) 
and this time select the CCSD option, then install 4.7 (again), then install 
all the options (ie. DECnet and multi-processing keys) (again) that got wiped 
due to the install. This is very time consuming and can lead to significant 
errors.

2. The type of errors that occur are the result of how VMSINSTAL functions.
The current trend is to have layered products be either contained in the 
'normal' VMS directories, for example SYS$SYSTEM, or in their own directories 
which themselves are SUB-DIRECTORIES of the 'normal' directories. Examples of 
the specific problem products are DECserver software and DECpage. Both of 
these are contained in their own directories. The problem is due to which 
version of the logical name do you use to get to the software? The system 
startup files had the logical names associated with the product pointing to 
SYS$COMMON:[xxx], while the directory as a result of building a CCSD had the 
directory off of SYS$SPECIFIC:[xxx]. The result is a 'broken' product and a 
user community that is upset. This is fixed by RENAMing directory files around 
the system disk to get the directory placement to match the logicals, or 
vice-versa. This is time consuming and error prone, and has to be done product 
by product.

3. The other alternative, for the strong willed, is to make a CCSD the 'hard' 
way. This is to go into STARTUP.COM and change the logicals for the main VMS 
system logicals, then build your own [V4COMMON] directory with appropiate 
backlinks. This is VERY time consuming and VERY error prone. Plus ALL the same 
problems in #2 are still there, which takes more time and creates more errors.

4. There is considerable interest in people with 'cluster' background in the 
job market these days. With LAVC's on the rise and the future of having CI/NI 
clusters, combined, the outlook is bright. The knowledge has to be learned
though. The school of hard knocks is the best place to learn it, if the 
company can live with the possible problems. Having a SINGLE system cluster, 
functioning with a quorum disk, is a GREAT place to start getting use to the 
way the disk is set up. It will also show the difference when installing 
layered products, at least those from DEC. The only thing missing at that 
point then will be more nodes for a multi-node cluster. When that happens, 
you will hopefully not have to mope your way around the system logicals, and 
therby the directories, attempting to find things when problems occur. You 
will have already mastered them and the only new item to deal with is the 
hardware. 

5. IMAGINE the look of surprise on your boss's face when you tell him that the 
existing system is ready for its first cluster member and it only took a day, 
OR LESS, to do it. You will be well on your way to establishing a 'guru' 
status in the organization, as well as a rep for being a very good planner.

My bottom line is that it is not easy going to a CCSD, but once you are there 
a basis has been established from which to grow, for both yourself and the 
system.

SO, when you are passing through the last versions of VMS V4 or starting V5 
and VMSINSTAL asks you if you want a CCSD, I would HIGHLY recommend that you 
say YES, and get very use to the results.

Thank you for your time and efforts in reading this article!!

pdc

Paul D. Clayton 
Address - CLAYTON%XRT@CIS.UPENN.EDU

Disclaimer:  All thoughts and statements here are my own and NOT those of my 
employer, and are also not based on, or contain, restricted information.