Conference vaxaxp::alphanotes

   The OpenVMS notes conference is VAXAXP::VMSNOTES.  This is the
   porting-to-Alpha and generic-Alpha-platform-questions conference.

   Note that one can use the IPL C (IPC) handler and a few (documented)
   console commands to resolve a quorum hang, from the console of one
   of the wedged systems.  See the Alpha Installation and Upgrade Manual
   for information on the IPL C (IPC) handler.

:    Is it possible to define a multiple root system disk, adjusting the
:    system parameters in order to satisfy both conditions? 

   Yes, assuming there are no shared storage resources (such as
   multi-host DSSI, CI, or SCSI, or if there is a MC controller) that
   connect this system with other systems.  (Shared resources require
   that all nodes be members of the same VMScluster at all times.)

:    If yes, which is the most opportune way to do it?

   Using AUTOGEN and MODPARAMS.

   Perform an OpenVMS installation onto the target system disk, and use
   CLUSTER_CONFIG to set up an additional root on the disk.  Set up the
   NISCS VMScluster group and password: CLUSTER_AUTHORIZE.DAT.  (See
   SYSMAN, or use CLUSTER_CONFIG.)

   Before using each root, MOUNT and access the target system disk, and
   set up MODPARAMS.DAT in the root.  Use the AGEN$INCLUDE_PARAMS directive
   in MODPARAMS to include a `common' parameter file from a directory such
   as SYS$COMMON:[SYSEXE], and use only a *very* few entries (2?) in the
   root-specific MODPARAMS.DAT file.

   The central difference between the two roots (and the two MODPARAMS.DAT
   files) involves the settings of two SYSGEN parameters: the node (root)
   that boots into the VMScluster as VAXCLUSTER=1 and NISCS_LOAD_PEA0=0,
   and the node (root) that does not has both set =0.  The rest of the
   node configuration can be the same...  (Note that the alternate root
   can get `moldy' if not carefully maintained -- if your customer is
   not familiar with working with a multi-root system disk, you might
   want them to stick with the IPC handler for the few times they need
   to `tweak' quorum, or look at alternative votes configurations, with
   the use of a quorum disk.)
    
   Boot the system into one root as a VMScluster member, and boot it into
   the other as a standalone node.

    re .*
    
    For another solution, it may be adequate to boot conversationally and
    set VAXCLUSTER=1 when you wish to boot into the cluster. In that case
    there would not be a second system root and so some parts of the system
    startup might have to be conditional based on cluster membership. (On
    the other hand if the system is there purely for quorum it may be so
    independent of the cluster that nothing in the startup ends up
    depending on cluster membership.)

    
:    For another solution, it may be adequate to boot conversationally and
:    set VAXCLUSTER=1 when you wish to boot into the cluster.

   If using this approach, set *both* NISCS_LOAD_PEA0 and VAXCLUSTER to
   zero to avoid connecting to the VMScluster, or set both non-zero to
   join the VMScluster.  In particular, do not leave NISCS_LOAD_PEA0 set
   non-zero with VAXCLUSTER set zero.

   This configuration also obviously requires setting up the VMScluster
   group and password via SYSMAN.  This password can be left registered
   when standalone.

re .3
    
>                  -< Beware VAXCLUSTER=0 & NISCS_LOAD_PEA0=1 >-
    
    What exactly goes wrong?

:>                  -< Beware VAXCLUSTER=0 & NISCS_LOAD_PEA0=1 >-
:    What exactly goes wrong?

   Corruptions.  Certain OpenVMS VAX configurations can effectively
   become an unrecognized partitioned VMScluster, and the usual nasty
   corruptions can occur.  (Hopefully, the OpenVMS Alpha fix for this
   will get ported over to OpenVMS VAX -- OpenVMS Alpha does not load
   CLUSTER_AUTHORIZE if VAXCLUSTER=0.)

    re .5
    
    This is a bug, right? If I say VAXCLUSTER=0 I will be very surprised if
    a cluster forms.

:    This is a bug, right? If I say VAXCLUSTER=0 I will be very surprised if
:    a cluster forms.

   I learned long ago to specify both parameters, just to be certain.
   Yes, I (personally) view this (mis)behaviour as a bug.
   No, that doesn't imply this bug will get fixed.
   Yes, the developer responsible for this is aware of this behaviour.

    re .7
    
    In that case (i.e. it doesn't get fixed) it might be prudent for the
    system startup to check for this situation i.e. the standard VMS system
    startup could do it but this particular customer could add it to the
    site startup (or one of the other site specific files executed during
    startup).

   When using the system debugger, one needs to have these parameters
   set up this way to prevent the VMScluster from forming and to allow
   access via the cluster NI port driver.  (The appropriate fix for the
   corruption is thus likely down in the low-level code that loads
   CLUSTER_AUTHORIZE.)

Note on CI clusters, you can set VAXCLUSTER=0, yet HSC disks will still be 
configured.  If you mount the HSC disk that are in use by other nodes, 
while VAXCLUSTER=0, you will most certainly corrupt the disk!

This was, in fact, a "feature" of Version 3.x, which did not include 
clustering software, but allow access to HSC disks for expended storage.  
As long as you didn't mount the same disk on two different nodes, you were 
safe from corruption, but living dangerously.


							-Paul

:... you were safe from corruption, but living dangerously.

   In more recent versions of OpenVMS, setting VAXCLUSTER=0 on a shared
   CI (with other nodes running in a VMScluster) has been known to lead
   to random system crashes.  (I experienced one configuration that crashed
   rather regularly back around V5.0 -- it went toes-up rather regularly,
   due to a bugcheck deep down in the tape services support code.)

        I don't know about CI clusters but on DSSI at least I could not
        even boot from DSSI disk (with VAXcluster 0) until I finally set
        SCSSYSTEMID to nonzero value. This was some 8 years ago when I
        migrating from MicroVAX II to MicroVAX 3300 with DSSI disks.
        
        The error message was something like
        
        	SCSSYSTEMID is not set to a non-zero value
        
        
        Apparently SCSSYSTEMID = 0 inhibited loading PAdriver. I would
        imagine that with this setting one could have system on CI but
        not really participating on the CI activity.
        
        _veli