CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (06/02/88)
In regards to the recent discussion of the impact to changing the DECnet node address, and/or the DECnet node name the following was offered by Jan Vorbrueggen. Beware of a side effect (at least in a cluster) of changing a node's SCSSYSTEMID (because you're changing its DECnet address, for instance). This will result in all queues and their entries being unusable after the necessary reboot. The easiest way around this is to start off with a new queue file (e.g., START/QUEUE/MANAGER/NEW). While I agree with what Jan has said, with certain qualifications, there is even larger areas of concern when doing this sort of thing in a cluster and/or a network that have not been touched on based on the messages I have recieved. 1. It is a VERY good idea to make the SCSSYSTEMID SYSGEN parameter be the 'equal' of the DECnet node address. This is done by the following formula: DECnet area number * 1024 + node number An example of this is for DECnet node 2.36, which has the 'equal' SCSSYSTEMID value of '2 * 1024 + 36' or 2084. The BIG help in using the DECnet node number for SCSSYSTEMID is that the DECnet number HAS to be unique among the 'whole' network. This same rule also applies to VAXClusters. All members of a cluster have to have a unqiue number. Therfore, why NOT use the same number when the rule governing it is the same and its use in both places does not conflict with each other?? Who knows what VMS V6 and beyond will bring in terms of VAXClusters and/or networks. The one thing for sure is it will be harder to get unique numbers. 2. In a VAXCluster, if either the SCSSYSTEMID or the SCSNODE parameter is changed, but not both, the system will not be allowed to boot into an existing VAXCluster if there are 'surviving' members who know the system under the old parameters. There is code in VMS that 'should not' let this new member with different parameters continue the boot process. The result is a hung system in the boot process while the other members of the VAXCluster should continue processing. The way around this is to change BOTH of the SYSGEN parameters at the SAME time and THEN do a boot. The system will 'look' like a brand new member to the cluster and it will be let in, provided nothing else has changed. The reason that both of these parameters have to change is the surviving members have a data structure which contains the node names and ids for all the systems that have been members. The ONLY way to get rid of entries in this table is to have all the machines halted at the same time, and then boot the cluster members. It should be noted that the installation notes for even number release of VMS, when doing a rolling cluster upgrade, calls for the changing of both these parameters. 3. As for what Jan had said above, as far as I can tell, the only problem with queues is ones that are 'execution' queues. These are the ones driving the printers or having the batch jobs execute on them. This can be fixed by performing the startup of the queue manager with the START/QUEUE/MANAGER command from the the system startup files. This will enable you to SHOW and INITIALIZE queue entries to change the needed parameter, which is the '/ON=' qualifier. Once the new node name is defined for the appropiate queues, then the START/QUEUE command can be issued and the jobs will pick up from the queues. I do not recommend that the '/START' qualifier be used on the INITIALIZE command, so that any errors can be picked up and corrected before the queue is started. This process does not have any job entries lost from the queues, which would happen with the answer that Jan gave. If lost job entries is not a problem, then by all means start a new queue file and eliminate the sad internal state of a long lived queue file that exists on VMS 4.X systems. Hope this helps to eliminate future problems or provide a basis for further discussions. :-) pdc Paul D. Clayton Address - CLAYTON%XRT@CIS.UPENN.EDU Disclaimer: All thoughts and statements here are my own and NOT those of my employer, and are also not based on, or contain, restricted information.