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...