This is an old revision of the document!
(Under Construction!)
HOW TO CAPTURE A CRASH DUMP
Sometimes a VMS problem manifests itself as a system crash. A VMS system crash is not an accident or a mistake – it is an intentional response by the operating system (actual program code written by the VMS Engineering Team) – to protect data on disk from any corruption, for example, due to a severe programming error or hardware fault.
A VMS system crash always stops/terminates all normal processing, writes out the complete contents of physical memory (or as much of it as possible) into the “crash dump file” (usually SYS$SYSTEM:SYSDUMP.DMP), and then halts the system, either stopping at the system console's P00»> prompt (awaiting your manual action to power-down, repair and/or reboot), or rebooting the system as configured by the console's settings.
After the next reboot, the contents of the crash dump file SYSDUMP.DMP will either “just sit there,” possibly to be overwritten by the next system crash (which could be minutes, or years, in the future), or – if the system's startup command files are properly configured – those contents will be copied into another, secondary or alternate crash dump file (this preserves each crash-instance in the case of a cascading series of crashes only minutes apart).
As a VMS sys-admin, you should know precisely how your VMS system(s) are configured to handle your SYSDUMP.DMP file upon reboot after a crash. PARSEC can assist you with information on determining your systems' config, both in this wiki and/or with an MEP white-paper (available through your PARSEC Account Representative).