Conference spezko::cluster

   Log a medium-priority QAR (or IPMT) against OpenVMS on TRIFID::.

   G:: will use VMScluster protocols to access the DSSI disks even
   when it is not configured in a VMScluster, so this and other DSSI
   systems will tend to load various VMScluster support modules during
   the bootstrap.

   This looks like a SYSBOOT/SYSGEN bug -- setting VAXCLUSTER to zero
   should likely implicitly disable loading of the NISCS drivers -- it
   should force-set NISCS_LOAD_PEA0 to zero.  (It's not clear how or if
   this can be done, and this whole sequence of events is strictly
   conjecture.)

   This looks like the same reason why we tell folks that nodes on a
   CI they need to have VAXCLUSTER set non-zero on all CI nodes...
   If an uncoordinated access is made -- such as an access to that
   shadow set when VAXCLUSTER was set to zero -- then corruptions
   can and will occur.

   In the interrum, "don't do that", or -- if you do, also disable the
   loading of the NISCS driver.

Curious. I just experimented a little bit with this, and on both Vax and Alpha
when setting vaxcluster=0 and niscs_load_pea0=1 then pedriver does not get 
loaded. Are you sure there's no other interconnect besides the network?
(This was with OpenVMS VAX V6.2 and OpenVMS Alpha V7.1).

Jur.

    Thanks Steve and Jur for your answers.
    
    re .1:
>Log a medium-priority QAR (or IPMT) against OpenVMS on TRIFID::.
    Done. QAR# 1390 in the V6 database (I couldn't set a "component" or 
    "abstract", can this be done after entering the QAR?)

>G:: will use VMScluster protocols to access the DSSI disks even
>when it is not configured in a VMScluster, so this and other DSSI
>systems will tend to load various VMScluster support modules during
>the bootstrap.
    Yes. And the VMScluster support modules should only form and use VCs with
    DSSI, right?
    (btw: there are no other DSSI systems in this particular cluster)

>This looks like a SYSBOOT/SYSGEN bug -- setting VAXCLUSTER to zero
>should likely implicitly disable loading of the NISCS drivers -- it
>should force-set NISCS_LOAD_PEA0 to zero.  
    Agree. I did the same (boot conv..set VAXC=0..cont) with system H, with
    absolutely no problems. There is no DSSI on that system though.

>This looks like the same reason why we tell folks that nodes on a
>CI they need to have VAXCLUSTER set non-zero on all CI nodes...
    Yes but in this case the interconnect is NI. 
    Imagine what happens when there is not only one VMScluster on the NI, 
    will we see *all* disks from *all* VMSclusters on the NI?

>In the interrum, "don't do that", or -- if you do, also disable the
>loading of the NISCS driver.
    Well, this lesson has been learned painfully ...

re .2:
>Curious. I just experimented a little bit with this, and on both Vax and Alpha
>when setting vaxcluster=0 and niscs_load_pea0=1 then pedriver does not get 
>loaded. 
    Did you use a system with a local DSSI. I managed to boot H with 
    VAXCLUSTER=0, and it worked as expected.

>Are you sure there's no other interconnect besides the network?
    Yes. All VCs to members are LAN based.
    We set VAXCLUSTER back to 1 and booted G, here's what can be seen:

View of Cluster from system ID 1998  node: G
+-------------------+---------+--------------------------+
|      SYSTEMS      | MEMBERS |         CIRCUITS         |
+--------+----------+---------+-------+--------+---------+
|  NODE  | SOFTWARE |  STATUS | RPORT | RP_TYP | CIR_STA |
+--------+----------+---------+-------+--------+---------+
| G      | VMS V6.2 | MEMBER  |       | LAN    | OPEN    |
|        |          |         |     5 | SHAC   | OPEN    |
|        |          |         |     7 | SHAC   | OPEN    |
| HSD10  | HSD B259 |         |     0 | RF72   | OPEN    |
| DISK1  | RFX V256 |         |     4 | RF31   | OPEN    |
| D      | VMS V6.2 | MEMBER  |       | LAN    | OPEN    |
| H      | VMS V6.1 | MEMBER  |       | LAN    | OPEN    |
| F      | VMS V6.1 | MEMBER  |       | LAN    | OPEN    |
| E      | VMS V6.1 | MEMBER  |       | LAN    | OPEN    |
| A      | VMS V6.2 | MEMBER  |       | LAN    | OPEN    |
| B      | VMS V6.2 | MEMBER  |       | LAN    | OPEN    |
| C      | VMS V6.1 | MEMBER  |       | LAN    | OPEN    |
+--------+----------+---------+-------+--------+---------+

If you ask for PEDRIVER to be loaded by explicitly setting NISCS_LOAD_PEA0
to one, PEDRIVER will be loaded even if VAXCLUSTER is zero if there are
other MSCP devices on the system.

See the VMScluster Systems for OpenVMS manual, Appendix A, Table A-1, which
contains the explicit warning:

	Caution: If the NISCS_LOAD_PEA0 parameter is set to 1, the
	VAXCLUSTER system parameter must be set to 2.  This ensures
	coordinated access to shared resources in the VMScluster and
	prevents accidental data corruption.

We warned you.

/john

Doesn't sound like a good idea.

What would be used for cluster ID? Is CLUSTER_AUTHORIZE.DAT still used?

-Mike

Yes.  PEDRIVER reads CLUSTER_AUTHORIZE.DAT on initialization and will form
circuits with other PEDRIVERs that match.

/john

    re .4:
    Thanks John, this explains what we saw. So, I'm afraid, the answer to
    the question in the base note (What did I do wrong?) is: You didn't RTFM...
    
    And from your text I assume that Jur's systems (in .2) had no MSCP
    devices. 
    
    Thanks to all,
    I appreciate it.
    Raymond.

>    And from your text I assume that Jur's systems (in .2) had no MSCP
>    devices. 

Right. Looking through the code i can see that on Alpha PEdriver's authorization
code is not loaded if vaxcluster=0. The same thing is not done on vax, you
can qar this.

Jur.