Crash dump OpenVMS AXP V6.2

[geir_2]

Hi,
It was not created a dump file (SYS$SYSTEM:SYS$ERRLOG.DMP) when the system crashed. I have only accept to the errorlog.

Does it mean that's impossible for me to find a specific reason for why the system crash? I saw that some suggest hardware error, because of MACHINECHK in the log file.

Is it likely that the same will happend in the immediate future?

Geir

[Ian Miller.]

Re Archunan,
sounds very unixy to me.
There is a lastgasp datagram sent by nodes departing a VMS cluster.
When VMS boots it looks for a system dump file and opens it incase there is a crash. If there is no dump file the system can use the primary pagefile however a dump in the pagefile is going to be overwritten on the next boot unless the system parameter SAVEDUMP is set to 1. The contents of memory are written to the dump file - exactly what depends on DUMPSTYLE system parameter.

Error log buffers in memory not yet processed are written to SYS$ERRLOG.DMP.

Geir - is there a SYSDUMP.DMP? What is the value of DUMPBUG and SAVEDUMP?

[geir_2]

Thanks for the answer.

There's no SYS$ERRLOG.DMP and SYSDUMP.DMP file. How it possible to read the value of DUMPBUG and SAVEDUMP?

Geir

[Ian Miller. · Accepted solution]

MCR SYSGEN SHOW SAVEDUMP
MCR SYSGEN SHOW DUMP

[John Travell]

It's a month now since this thread was last update. Is the problem now considered dead ?

If you do not have a dump file you have to make a choice of what to do.
1. Live without a dumpfile. You get an instant reboot on any failure, but no evidence as to WHY the failure occurred.

2. Create a minimal dumpfile. IIRC V6.2 did not have SYS$ERRLOG.DMP, and the practice in those days was to create a 32 block dumpfile.
This is absolutely useless for discovering the real reason a failure occurred, but it DOES preserve the ERRORLOG buffers, so if the crash was a machine check or a few other mainly hardware causes you have all of the evidence you need.

3. create a selective dumpfile, DUMPSTYLE bit 0 SET, i.e. 1,3,5,7 9 or any other odd number. The optimum value is 9, compressed selective dump to a file on the system disk, or 13, compressed, selective, to a different disk (special case rules apply here).

4. Create full dumpfile. Best, but largest, so slowest to write. This takes the longest time between operational before the crash to operational again afterwards.

For most people a compressed selective dump gives them the best of both worlds, most of the time they have everything needed to fully resolve a crash, with an acceptable dumpfile write time before the reboot.

For what it's worth, in almost 20 years of VMS crash analysis I can only recall ONE crash where resolution was impossible because of data critical to that event not being saved by a selective dump.

If you want advice on how to setup a dumpfile, just yell. I have set this to notify me if anyone replies.

If this issue is considered dead, please close this thread.