L CLUSTER_TOOLS, SYSTEM_MANAGEMENT, Unsupported Cluster management tools/hacks BYEBYENODE.MAR J This is a quick hack to force a remote system out of the cluster. It canG be used when a remote system hangs for example at high IPL (bewteen 3 1 and 6), or when the SMIserver does not respond. E It uses an internal routine in the connection manager. There is one M problem with this approach, and that is that this routine (CNX$DISC_REMOVE) G is not available in any symboltable which we can include in the link. I So what we do is use MATCHC to find the sequence of instructions around M the place where we expect the code, and issue an error if we can't find it. M If we got the address, we JSB to it and let that routine do the dirty work. ; The net result will be that the remote node will CLUEXIT. F This is strictly a HACK, and as such it may fail at any time. Use atH your own risk. (I included a check to prevent removal of the node fromI which this program runs, although it was fun to get a system in a state N in which the only clusternode was removed from the cluster and in longbreak,? without quorum....). It was tested on VMS V5.5 thru T6.2-FT1. COPY_SHADOW_DUMP.MAR C This program is created to retrieve a system dump from a Phase II C shadowed systemdisk. The problem is that the bugcheck code writes B to the member we booted from (normally), but as far as shadowingD is concearned the disks are the same. A merge copy which may startE after a crash may not be able to correct the blocks of the dumpfile C on all the disks of the shadowset. Suppose that a dumpfile starts A at the end of the disk, and ends at the beginning of it. When a B system crashes we will start writing at the end of the disk, andF it is very well possible that when we reach the part of the dumpfileE at the beginning of the disk that that part has already been merged D by a merge copy. The net result is inconsistent data as far as theH dumpfile is concearned. This can of course be corrected by dismountingE members of the shadowset except the master, and remount the members D after which a full shadowcopy will correct things. This may have aC rather high impact, which most customers don't want on their live F systems. Another way to correct things is to trigger a merge copy onH the fly. That's certainly possible but it involves kernel-mode hackingH which is always error-prone. What we do here is look for the retrievalI pointers of the dumpfile (they are already stored in memory by SYSINIT) H and look which shadowset member is the master. We then copy all blocksB mapped by the dumpfile from the master member to an output file. > This version supports both the Alpha- and VAX architectures. FORCE_MERGE.MAR > This program is created as a hack to force a merge copy on aC Phase II shadowset. It uses a routine inside the SHdriver for the B dirty work. We call this entrypoint with the correct parameters.J We also disable writelogging because we want a full merge copy to occur.
