- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: SYSDUMP.DMP - retaining contents of
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-30-2009 02:08 PM
тАО01-30-2009 02:08 PM
I would be grateful for some advice on the issue of retaining the contents of SYSDUMP.DMP and SYS$ERRLOG.DMP (plus other files that might get used when a crash occurs)
Environment: AlphaServer ES47 (partitioned) running OpenVMS 7.3-2. DUMPSTYLE is set to 9
Irrespective if there was a system crash or a complete power failure, can you tell me what I need to do to make sure the contents of these files are not overwritten or reinitialized when the system is brought back up. We want to ensure that valid content is available for examination by HP's technical staff if needed.
I am aware of using ANAL/CRASH to copy the contents to a seperate file, or alternatively using BACKUP with /IGNORE=NOBACKUP. My question really relates to what happens once we have had a failure (system crash or perhaps a prelonged total power outage)
For this example, let's say that the Restart control setting is set to HALT. If we are at the cheveron prompt, will simply performing a straight BOOT erase the contents of either of the above files, or perhaps not provide enought information for later diagnosis. if the later was true then do I need to issue a CRASH command to write additional information out to the dump files?
The reason I made reference to a power outage was because we have recently experienced two outages that cut power to the CPU. Even if a straigh power loss would not write informaton out to the dump files, I would still like to know what is the safeguard steps we need to take when a 'normal' crash occurs.
Below is a brief extract form HP describes part of the problem....
When the system went down last night it generated a CDL or crash data log. The CDL was written to the VMS error log. In the case, I can see that it was a CLOCK POWER FAULT VOLTAGE FAILURE. The CPU module has VRMтАЩs or voltage regulator modules on the board. Theses VRMтАЩs can power down the module/partition. On earlier versions of the firmware, they had problems with False environmental errors. They would sense errors when there really were none. IтАЩm recommending two things. One, upgrade the firmware because there were problems in earlier versions. I donтАЩt think this is the fix but it should be done and Two, replace the DUO/CPU module because the VRMтАЩs are on it.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-30-2009 02:41 PM
тАО01-30-2009 02:41 PM
Re: SYSDUMP.DMP - retaining contents of
dump file was to have something to examine
after you re-boot. What good would it be if
it got wrecked by a re-boot?
You can expect it to get wrecked
(overwritten) by the next _crash_.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-30-2009 02:45 PM
тАО01-30-2009 02:45 PM
Re: SYSDUMP.DMP - retaining contents of
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2009 01:07 AM
тАО01-31-2009 01:07 AM
Re: SYSDUMP.DMP - retaining contents of
it just stays intact.
Now, _IF_ you use the PAGEFILE for dumping (remember the prices of disks, say 20+ years ago) _THEN_ you _MUST_ save it before regular system use resumes. The construct can still be found in use, but at todays prices it really deserves a review.
Nowadays, the second reason for saving takes precedence: ANOTHER crash before this one has been analysed.
Adding the ANAL/CRASH COPY command to the boot sequence is the prefered, simple way to get around that. Int hat case, a review of the need to retain old copies after a crash is advisable.
This combination covers for all cases, AFAIK.
hth
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2009 03:01 AM
тАО01-31-2009 03:01 AM
Re: SYSDUMP.DMP - retaining contents of
Where should we apply the ANAL/CRASH COPY cmmand in the startup sequence. Do we modify one of the DEC (ooops, HP) site independent procedures or simply insert it in he begining of systartup_vms.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2009 04:32 AM
тАО01-31-2009 04:32 AM
Re: SYSDUMP.DMP - retaining contents of
I may have this all wrong but when a system crashes I gather that it takes a snapshot of main memory but does not actually write to the dump files at that time, but rather to a series of snapshot files.
When the system eventually reboots, the boot process checks the details about the previous system shutdown and availablity of these snapshot files. If it finds that previous shutdown was not normal, and there are snapshot files, then it will start to build the DUMP file using the information in the snapshot file. After the system is up, the critical information relating to the crash would then be available for analysis.
If the above was in any way correct, then is there a need to execute the CRASH command at the cheveron prompt?
______________________
An additional question in rgards to another dump file that appears in discussion threads along with SYSDUMP.DMP, SYS$SYSTEM:SYS$ERRLOG.DMP
Should this file (like sysdump.dmp) also be copied as part of the boot sequence to preserve its contents, and if so what is the command to do so...
I apologize if this is starting to turn into a one stop session in all things relating to crashes, but I really would like to get a better initial grasp as to what is the correct course of action.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2009 05:04 AM
тАО01-31-2009 05:04 AM
Solutionif a system crashes, it first dumps the current in-memory errlog entries to SYS$SYSTEM:SYS$ERRLOG.DMP, then it tries to write system memory into SYSDUMP.DMP.
During boot, the errlog entries from SYS$ERRLOG.DMP are automatically extracted and appended to ERRLOG.SYS, so you don't loose any possible errlog entries from the time immediately preceeding the crash. There is no need to copy/save SYS$ERRLOG.DMP.
CLUE$STARTUP is automatically run during startup and examines SYSDUMP.DMP. If the dumpfile has not yet been been analyzed, it creates the CLUE summary text file of the crash footprint in CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS.
If you want to automatically save a copy of the SYSDUMP.DMP file after a system crash, you should use the CLUE$SITE_PROC logical name (please see the SDA documentation for details):
http://h71000.www7.hp.com/doc/82final/6549/6549pro_001.html#invokin
You only need to use the >>> CRASH command under 2 circumstances:
- if you want to force a crash on a hung system. Type CTRL-P (or press HALT button), then type >>> crash
- if the system has halted by itself (should not normally happen on OpenVMS) and you did NOT have AUTO_ACTION set to RESTART. Typing >>> CRASH will then try to write a dump. With just >>> B in this case, you will loose ALL information about the problem, as there will be no errlog entries saved and no dump written.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2009 06:39 AM
тАО01-31-2009 06:39 AM
Re: SYSDUMP.DMP - retaining contents of
We were debating the issue of having the system restart control set to HALT or RESTART, but that was primarily related to issues surrounding various applications automaticly restarting where there might be problems.
So if I'm reading things correctly, if we have it set to HALT and the system crashes, the only way we can guarantee saving all the valid information would be to initiate the CRASH command... and conversely, if we did have it set to RESTART then we would not have to initiate CRASH.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2009 07:46 AM
тАО01-31-2009 07:46 AM
Re: SYSDUMP.DMP - retaining contents of
under normal circumstances, OpenVMS will not issue a HALT instruction in kernel mode. But there are some situations, in which the CPU may halt due to some error (e.g. a kernel stack not valid halt) or the PC gets loaded with an address, which points to data instead of instructions and there happens to be a ZERO in that data stream.
If you have not >>> SET AUTO_ACTION RESTART, you will typically loose all context information in these case, as a normal operator would just type >>> B, if he sees the system at the console prompt.
Also in case of those unexpected HALTs, the system will remain down until operator intervention. With AUTO_ACTION = RESTART, the system will write a dump and reboot automatically (depending on the setting of BUGREBOOT, default=1).
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-01-2009 12:41 PM
тАО02-01-2009 12:41 PM
Re: SYSDUMP.DMP - retaining contents of
Preserving the dump by taking a complete copy with the SDA COPY command is obviously the "gold standard", but even with cheap disk space, dumps are large, and there is a limit to how many can be retained in the long term.
All is not lost if you accidently overwrite a dump, as the system automatically gebnerates a CLUE log on reboot if the system crashes. See SYS$ERRORLOG:CLUE$node_date_time.LIS. These are text files containing the crash "footprint", whicch is often sufficient information to identify the reason for the crash. See SYS$STARTUP:CLUE$STARTUP.COM.