Article 150809 of comp.os.vms:
In article <9607090545.AA29657@gate.fim.fgan.de>,
win@gate.fim.fgan.de (Wingert from FIM) writes:
[...]
> There are files in a mixed architecture cluster which can't be on a common
> disk (p.e. SYLOGICALS.COM, CLUSTER_AUTHORIZE.DAT ...). But they must be
> consistent. In case of this I have a new old wish: File shadowing. This would
> make system managers work very easy.
You've identified a potential problem, but the solution you
propose is both complicated to implement, doesn't currently exist,
and is potentially more confusing than the _simple_ solution(s) that
you can implement right now.
1) CLUSTER_AUTHORIZE.DAT should never need to be changed.
You simply need to COPY a single, "master" version of it
to all your system disks, VAX and Alpha. Then forget
about it. :-) Since it's hard t form a cluster if all
nodes don't already share the same cluster ID and
password, this is only an issue the first time you add a
non-satellite node to the cluster. Unless you've got 44
nodes each with their own system disk, this shouldn't be
a problem...
2) There was a recent thread (some of which you may have
missed) dealing with how to share cluster-common files.
I posted a method I've found suitable. Basically, choose
one disk, perhaps the system disk of your primary server,
whether an Alpha or a VAX, and define a logical name, say
CLU$COMMON that points to the [VMS$COMMON] directory on
that disk. Then you put cluster-common files, such as a
master version of SYLOGICALS.COM, in CLU$COMMON:[SYSMGR].
With this arrangement, the server node and it's
satellites are unchanged. On the "other" architecture
nodes, you write a skeleton SYLOGICALS which (a) mounts
the server node's system disk, and (b) executes the
SYLOGICALS.COM in CLU$COMMON:[SYSMGR]. The idea is
trivially extensible to other site-specific files, such
as SYSTARTUP_VMS.COM, etc.
I don't see the idea of "file shadowing" as a proper solution even
if it were available. In the old, pre-cluster days, we solved these
sorts of things with nightly jobs which copied the master file(s) to
target nodes via DECnet. That is certainly a maintainable and low-
overhead solution. File shadowing just sounds like a heavy hammer
to me... :-)
> If I could specify a fileshadowset,
> I must not change any system logical and I will have identical files for both
> platforms. I must not specify any logicals and it functions in every case.
> (dear Stephen RMS global buffers would not help here).
I've read this a couple of times. Forgive me, but I don't
understand your point.
> Since today I have an additional question. Background: We have window
> terminals with EWS (VAXeln window server). This software we have only for
> VAX. But the VAXes are all satellites. On one VAX I have enabled the
> service of DECnet IV and defined the EWS window terminal node characteristics
> (p.e. LOAD FILE). If the NETNODE_REMOTE.DAT is common this information
> would be seen also from the bootserver (an alpha). Does this make any
> trouble, or is there a possibillity to define node characteristic only on one
> node (with a common NETNODE_REMOTE).
There's no problem whatsoever sharing NETNODE_REMOTE in a
cluster. In this particular case, only those nodes on which you
have NCP> SET CIRCUIT xxxx SERVICE ENABLED (I think that's the right
syntax, check before using) will answer the MOP requests that the
EWS terminals broadcast. Note that the SERVICE ENABLED setting for
any node is kept in one of the SYS$SPECIFIC:[SYSEXE]NET*.DAT files
(I don't know which one) and it _not_ shared with any other node.
Of course one assumes that you've got at minimum a VAX server
and an Alpha server, both with service enabled, so both will
potentially answer MOP requests.
A) If the VAX and Alpha system disks that a (normal)
satellite needs to boot from are accessible from both the
VAX and Alpha servers, either server can answer MOP
requests from both VAX and Alpha satellites. This is
supported.
B) If I recall, the logical name EWS$LIBRARY is defined in
SYS$STARTUP:EWS$STARTUP.COM. If you don't execute this
command file on the Alpha, then it won't (successfully)
answer the MOP request. You will get an OPCOM message to
the effect that the requested (by the EWS node) file
couldn't be found, but that's not a problem, and the VAX
server will _also_ answer the MOP request and go ahead
with the download. Basically, there's no problem here.
> I have asked for a way to findout all
> common files, in case of system integrated and layered products. I think the
> following files must be common:
UCX$*******.DAT, AMDS$****.DAT, DFG$*******.DAT and ...
> You see there are lot of common files more then specified within VMScluster
> docu and SYLOGICALS.COM file. So I can it say only again: We need file
> shadowing.
No, you just need to "work smart". It seems to me that you've
latched onto a possible solution, but you haven't thought through
the easy ways to address these problems in the absense of that
solution. Cluster common files can be shared by all nodes simply be
locating them on a cluster-accessible disk. Just because they
normally are installed on a node's system disk doesn't mean that you
can't place them elsewhere (DFG allows this sort of thing, for
example) or that one node's system disk can't be mounted by another
different-architecture node. By all means, share your SYLOGICALS
and SYSTARTUP_VMS, etc., files cluster-wide. It's easy to do...
-Ken
--
Kenneth H. Fairfield | Internet: Fairfield@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...