miscellaneous puzzles

From: Phillip Helbig (HELBPHI@sysdev.deutsche-boerse.com)
Date: 04/07/03 

From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>
Date: Mon, 07 Apr 2003 16:56:49 +0100 (MET)

Here are a few puzzling things I came across while working on my
hobbyist cluster this weekend.

A:

When I have a shadow set (both members physically connected to node A
(for now), all disks in the cluster MSCP-served) mounted one one node, I
can mount in on node B by issuing MOUNT/SYSTEM there or MOUNT/CLUSTER on
either node (though the latter is overkill). When I then DISMOUNT it on
node B, OPCOM says that the physical devices have been removed from the
shadow set, which sounds scary! Actually, it was only dismounted, and
could be immediately remounted and dismounted again etc on node B. On
node A, of course, it was mounted all the time. Is this confusing
message a bug or feature?

B:

SYLOGICALS.TEMPLATE contains this:

$! The user should include definitions for the devices, directories, and file
$! names for the various core VMScluster and DECnet files, typically including
$! all of the logical names and file names shown below. (The file locations
$! shown below use search list logical names such as SYS$SYSTEM: for clarity
$! -- be aware that the files actually reside in the system disk system-common
$! root, and not in the system-specific root. eg: the common files reside in
$! SYS$SYSROOT:[SYSEXE], in the case of any files accessable via SYS$SYSTEM:.)
   ^^^^^^^^^^^^^^^^^^^
Shouldn't that be SYS$COMMON:[SYSEXE]? (Of course, SYS$SYSROOT is
confusing since it is defined to be a search list to SYS$SPECIFIC and
SYS$COMMON with only the second translation being CONCEALED, so saying
that the files reside in SYS$SYSROOT:[SYSEXE] isn't much help,
especially when the whole point of the text is to say in which directory
they actually reside! In other words, the text above is not just
unclear but WRONG after "eg:".)

C:

Autogen delivered this gem (VAX VMS 7.2):

MSCP_SERVE_ALL parameter information:
        Override Information - parameter calculation has been overridden.
           The calculated value was 4. The new value is 1.
           MSCP_SERVE_ALL has been set to the hard-coded value of 1.
 
How can the calculated value be 4?!

The documentation says:

   MSCP_SERVE_ALL
   MSCP_SERVE_ALL controls the serving of disks during a
   system boot. Specify one of the following values:

   Value Description

   0 Do not serve any disks. This is the default.

   1 Serve all available disks.

   2 Serve only locally attached (non HSC) disks.

I have it hard-coded to 1 in MODPARAMS.DAT.

D:

I've been noticing some strange things during shutdown and reboot. Is
there a general rule of thumb about what should be explicitly shutdown
in SYSHUTDWN.COM? In particular things relating to the mounting and
dismounting of disks, including but not limited to those containing swap
and page which are not on the system disk and shadow sets.

Relevant Pages

  • shadow sets, cluster, merge, MVTIMEOUT, dismount
    ... I have only SCSI disks. ... In the case of system disks, both members have ... has files open on a shadow set and this shadow set disappears, ... necessary to dismount it on B and C in order to avoid a merge? ...
    (comp.os.vms)
  • Re: HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMO
    ... We will have some disks that are ... > served and available to the rest of the cluster during the reboot. ... > rebooting system and another shadow set member on another node. ... If they are on the node going down---does SHUTDOWN dismount the physical ...
    (comp.os.vms)
  • Re: (DIS)MOUNT/POLICY=MINICOPY in mixed VAX-ALPHA cluster
    ... > member of a shadow set on it and another member on another node. ... > logical disks consist of a shadow set of two physical disks with the ... > can I just dismount a member and benefit from the fast copy when I add ...
    (comp.os.vms)
  • (DIS)MOUNT/POLICY=MINICOPY in mixed VAX-ALPHA cluster
    ... member of a shadow set on it and another member on another node. ... logical disks consist of a shadow set of two physical disks with the ... can I just dismount a member and benefit from the fast copy when I add ...
    (comp.os.vms)
  • Re: Errors during shadow set merge
    ... I have been getting errors during shadow set merges since I bought ... getting 16 errors on DKA0 and 83 errors on ... I will swap out one of the disks and give it a try. ... Then I merged the shadowset on the problem machine. ...
    (comp.os.vms)