Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Crash dump OpenVMS AXP V6.2

SOLVED
Go to solution
geir_2
Super Advisor

Crash dump OpenVMS AXP V6.2

Hi,

To night our system crashed suddenly crashed at 23:30. I tried to read the error log, but it's quite difficult to get some useful information from it. If someone want to read the output I have included it below:

I will appreciate advise.

Thanks

geir
14 REPLIES
geir_2
Super Advisor

Re: Crash dump OpenVMS AXP V6.2

Hi,

The system didn't save a crash dump file. How is it possible to enable creation of crash dump file, when the system crash???
Thanks

PS:
What's a normal size of the crash dump file. I assume it's huge.
Karl Rohwedder
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

With the SYSGEN parameter DUMPSTYLE you are able to control what is being dumped (all memory -> huge dumpfile or selective -> smaller dumpfile). The dumpfile can be on another disk.

If you habe no entry in MODPARAMS.DAT Autogen should tell you at the end of its report file, what size the dumpfile should have.

If you habe no dumpfile, VMS can dump into the PAGEFILE.

Pls. see the System Managers Manual for details.

You crash was a MACHINECHK, this may point at some hardware error.

regards Kalle
Ian Miller.
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

Do you know why no crash was created?
Is there a dump file?
____________________
Purely Personal Opinion
Jan van den Ende
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

Geir,

a crash dump file is NOT created during a crash.
That is reasonable: IF the system crashes, there is ample reason NOT to trust the full availability of the file handling mechanisms.

If a dump is to be written, as much as possible has to be pre-arranged, and as little as possible of OS functionality should be used.
So, the file has to be pre-allocated, and the various variables (size, exact location, whatever else may be needed) get loaded into memory. The writing of the dump itself bypasses the file system, and uses a very basic IO mechanism directly to the (already known) exact hardware locations.
(that is why the dumpfile MUST exist before the bootstrap, and a dumpfile should NOT be moved or deleted: if a dump gets written, it is to the disk positions that were valid DURING boot. If those positions are freed, they get re-used. But a dump will overwrite those positions!)

In short: if you might need a dump, you should prepare for that ahead of time.

See the System Managers Manual (like Kalle suggested) for instruntions about HOW to da that. Or maybe, use those to check if you already have a dump, and how to find it.

Success.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Richard Brodie_1
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

DECevent might be able to decode the error log entry.
geir_2
Super Advisor

Re: Crash dump OpenVMS AXP V6.2

Hi,

Thanks for the answers. It was not created a dump file when the system crashed. I'm not sure how important this file is, maybe I should drop it??

Is it possible to see that the reason for the crash dump was related to the hardware
MACHINECHK?? I thought the reason was software related (NTP TimeStamp). But it's only a guess.


We also had some trouble with DECnet, after the system crash. Any ideas??

Thanks
Ian Miller.
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

What is value of DUMPSTYLE system parameter?
The file SYS$SYSTEM:SYSDUMP.DMP should exist so its available for a crash dump if needed.

Machine Check crash dumps are often but not exclusively associated with hardware problems.
Are there any hardware errors in the error log immediately before the crash entry?

Is there a SYS$SYSTEM:SYS$ERRLOG.DMP file?
This may contain additional error log entries.
Use SDA command CLUE ERRLOG to extract them.
____________________
Purely Personal Opinion
Arch_Muthiah
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

Geir,

You can control dump-file size and creation by AUTOGEN symbols DUMPSTYLE and DUMPFILE in the computer's MODPARAMS.DAT file.

Usually when system is ---crashing---, the system will notify the other nodes (if it is a cluster node) with message "I am going crash - and the PANIC string". And it will immly take the snapshot of MAIN memory (all the status details about the process/ objects/program/application were running at that time). So there won't be any physical DUMP files created when system completes the Crash.

Then when we Reboot the system abain, the boot process will check the details about previous system shutdown and availablity of snapshot files. If it finds that previous shutdown was not normal, and there is a snapshot files, then it will start build the DUMP file using the information in the snapshot file and after that system will continue its booting process. After system up, we can see the DUMP file in the system.

USing the DUMP file, we can find what are all the process/programs(local or network) were running before the system crash, what instructions caused the system to crash, using the values in stacks, frame pointer, and program counter.


Archunan
Regards
Archie
Jan van den Ende
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

Re Archunan,


the system will notify the other nodes (if it is a cluster node) with message "I am going crash - and the PANIC string". And it will immly take the snapshot of MAIN memory (all the status details about the process/ objects/program/application were running at that time). So there won't be any physical DUMP files created when system completes the Crash.

Then when we Reboot the system abain, the boot process will check the details about previous system shutdown and availablity of snapshot files. If it finds that previous shutdown was not normal, and there is a snapshot files, then it will start build the DUMP file using the information in the snapshot file


This is new to me!

Do you have any pointers to confirm this?

I would be VERY interested, and guaranteed to spend several hours getting all details!

Please quench my doubts.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
geir_2
Super Advisor

Re: Crash dump OpenVMS AXP V6.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.
Honored Contributor

Re: Crash dump OpenVMS AXP V6.2

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?
____________________
Purely Personal Opinion
geir_2
Super Advisor

Re: Crash dump OpenVMS AXP V6.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.
Honored Contributor
Solution

Re: Crash dump OpenVMS AXP V6.2

MCR SYSGEN SHOW SAVEDUMP
MCR SYSGEN SHOW DUMP
____________________
Purely Personal Opinion
John Travell
Valued Contributor

Re: Crash dump OpenVMS AXP V6.2

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.