not receiving a crash dump

[ono_vms]

Can anyone tell me how to fix a dump file that does nto contain a valid crash dump? I'm running a vax 6600 in a 2 node cluster w/vms7.3 & hsj controllers w/sw800. node 2 keeps crashing. I have tried to anal/crash sys$system:sysdump.dmp and get the FLAGS2 warning followed by a dump file is empty error. I've recreated the dump file using swapfiles.com and rebooted. I believe I've isolated the problem down to a bad cpu card but thought I'de confirm that with the dump file and either a bugcheck or machine check error denoting the suspect xmi slot. It's a 4 board multiprocessing env. This is driving me crazy. I've replace the clock arbiter and xtc cards and outswapped the cpu boards to find the suspect board, but still no dump!!! How can I get the system to produce a crash dump...anyone? Thanks

[Richard Whalen]

Sometimes the system is unable to write the dump because of the state the system is in or because critical data structures have become corrupted.

[Dean McGorrill]

often crashes with bad hardware are of little value. if you have a suspect cpu,
pull it and see if the system stops crashing for a good length of time. then you know you've got it. Dean

[Volker Halle]

ono_vms,

welcome to the OpenVMS ITRC forum - you entered at the 30th anniversary of the OpenVMS operating system !

Consider setting DUMP_STYLE = 3 to get a selective dump with full console output. Make sure you connect a printer or PC with a terminal emulator to capture the full console output.

Also check ERRLOG.SYS for a bugcheck message. Also note that the system may be halting and booting without writing a dump, if HALT is not set to RESTART and the system incurs an error halt.

Volker.

[John Travell]

The FLAGS2 warning is telling you that the DMP$V_VAXDUMP bit is not set.
Is the other member of your cluster also a vax ? If NOT, are the two nodes trying to share a dumpfile ?
Try doing $ dump/block=count=1 sys$system:sysdump.dmp

Mine is all zeros because my machine has never crashed since I built my 8.3 disk.
Yours should have a pattern where the textual interpretation contains the node name and lots of binary data that does not translate into text.
Capture the pattern, then compare it to the next crash. If it changes then the dump is being at least partially written.

I concur with choosing a selective dump.

A VAX keeps the most important structures right at the top of physical memory. In a full dump these get written last, or not at all if the file is either not big enough or an unrecoverable problem occurs while the dump is being written.
In a selective dump the most critical things get written FIRST, then less important things, and finally the full context of processes until you either run out of something to write, or run out of space in the file.
In either case, you have a MUCH better chance of finding out at least something about the crash, which would be much better than the apparently nothing you know now.

Finally, follow the advice to set the front panel switch to restart if it is not already there.
JT: