CLAYTON@xrt.upenn.EDU ("Clayton, Paul D.") (07/13/87)
Information From TSO Financial - The Saga Continues... Chapter 10 - July 12, 1987 I have been reading with a certain curosity the people who have stated that their 8XXX systems will not do a AUTOREBOOT when they are part of a VAXCluster. I must admit that I have not had the problem except for once and I am passing along my fix for it. The one time the 8XXX systems would not AUTOREBOOT, or BOOT for that matter, I tracked it down to one line in the BOOT command file that is used to load the registers with values then loads VMB and starts it up. The solution was to MAKE SURE that ALL systems in the VAXCluster had the EXACT same data being loaded in the R2 register. The 7:0 bits designate the CI port of the primary HSC that is used to get to the system disk. Bits 15:8 designate the CI port to the 2nd HSC that is dual ported to the system disk. On my system when these values were not ALL the same, in my case '100', the systems that had the values one way would all boot and work fine, but the other systems would hang in VMB.EXE. Reversing the boot sequence of systems resulted with the reverse of what happened before. The bottom line for me is that ALL have 100 in R2, my HSC's are CI port numbers 0 and 1, and ALL systems have no problems booting anytime regardless of which HSC has the system disk under control, and the sequence of the booting. I am assuming here that the AUTOREBOOT flag is enabled in the PRO console to also try and get this FEATURE to work. :-) Hope this is some help to those with the problem, and I would be interested to hear if this solves anyones problem with hanging systems. :-) Paul D. Clayton - Manager Of Systems TSO Financial - Horsham, Pa. USA Address - CLAYTON%XRT@CIS.UPENN.EDU