- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: DOSD peculiarity
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
Forums
Discussions
Discussions
Discussions
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
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
09-25-2008 10:59 PM
09-25-2008 10:59 PM
Experimenting with DOSD on OpenVMS Alpha V8.3, I noticed something weird. Maybe someone can shed some light.
I changed the DUMPSTYLE system parameter to 13, specified DUMPFILE_DEVICE to be $1$DKD600 in MODPARAMS.DAT, created $1$DKD600:[SYS0.SYSEXE]SYSDUMP.DMP using SYSGEN, ran AUTOGEN, shutdown the node, specified DUMP_DEV to be DKD600 in the SRM, and booted the node.
After the boot, I checked the open files on SYS$SYSDEVICE and on $1$DKD600. To my surprise the file [SYS0.SYSEXE]SYSDUMP.DMP was listed as open on SYS$SYSDEVICE but not on $1$DKD600 (apart from INDEXF.SYS no files were open on DKD600). However, if I force a crash, the dump is written to $1$DKD600:[SYS0.SYSEXE]SYSDUMP.DMP.
Any idea why VMS lists the old dump file to be open on SYS$SYSDEVICE, and keeps quiet about the dumpfile on DKD600?
Thanks for any insight in this.
Kris (aka Qkcl)
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-25-2008 11:07 PM
09-25-2008 11:07 PM
Re: DOSD peculiarity
DKD600,
This is needed in case the system crashes before DKD600 is mounted; it may also be the reason that the dumpfile on the system disk is open at all times. Or it may indeed indicate a minor bug.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 12:58 AM
09-26-2008 12:58 AM
Re: DOSD peculiarity
"For best results, include the MOUNT command in SYS$MANAGER:SYCONFIG.COM". May be mounted too late ?
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 12:59 AM
09-26-2008 12:59 AM
Re: DOSD peculiarity
It would be a good idea to crash the system to see where the crash goes.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 01:04 AM
09-26-2008 01:04 AM
Re: DOSD peculiarity
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 01:18 AM
09-26-2008 01:18 AM
Re: DOSD peculiarity
did a forced crash (OPCCRASH) to test whether my DOSD file was
working, at the suggestion of one poster. Bingo! It works, despite the
fact that the file does not show as open when I did SHOW DEVICE/FILE.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 02:10 AM
09-26-2008 02:10 AM
Re: DOSD peculiarity
> DKD600,
>
> This is needed in case the system crashes before DKD600 is mounted
I don't care. I really want the dump file off the system disk.
Re: Wim
> DKD500 may not be ODS-5 and not be part of a shadow set.
According to the System Manager's manual, the ODS-5 restriction is lifted.
> May be mounted too late ?
The mount happens in SYLOGICALS; and according to said manual:
"Although not a requirement, HP recommends that you mount the dump device during system startup. If the dump device is mounted, it can be accessed by CLUE and AUTOGEN and for the analysis of crash dumps. For best results, include the MOUNT command in SYS$MANAGER:SYCONFIG.COM."
So it isn't necessary to even mount the disk (but I will put the MOUNT in SYCONFIG and try again).
> It would be a good idea to crash the system to see where the crash goes.
As I said in my original post, I've crashed the system and the dump goes to DKD600. No problem there.
> did a forced crash (OPCCRASH) to test whether my DOSD file was
working, at the suggestion of one poster. Bingo! It works, despite the
fact that the file does not show as open when I did SHOW DEVICE/FILE.
That's part of my question. Why doesn't it show as an open file, and the dump file in SYS$SYSTEM does (although not used anymore, I guess).
Regards,
Kris (aka Qkcl)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 02:29 AM
09-26-2008 02:29 AM
Re: DOSD peculiarity
may be this is a bug and they are keeping the wrong file open ? But then the protection is gone too ...
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 02:34 AM
09-26-2008 02:34 AM
Re: DOSD peculiarity
fwiw
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 03:20 AM
09-26-2008 03:20 AM
Re: DOSD peculiarity
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 03:42 AM
09-26-2008 03:42 AM
Re: DOSD peculiarity
the dump file is something special, and if you think of it, it should be.
Suppose somehow something to do with RMS, or even lower level IO from within the OS, is not functioning as it should. A true case for a crash dump analysis, but... how would it be written?
The (fysical) block mapping of the DUMP file is mapped VERY low level, directly available the Crash handler.
The writing occurs without any file system assistence, and hence NO care is given to any filesystem mechanism whatsoever.
And this is also the reason that it is NOT a good idea to move or delete the file: IF a crash should occur in such case, the dump gets written to the disk location that was determined from SYSDUMPs location during bootstrap; and any (part of) any file in that location will simply be overwritten.
Maybe that was the original reason to open the file way back when: prevent it from being (re)moved. And that idea was considered no longer being as relevant, (or simply forgotten) when DOSD was implemented....
--- we have used DOSD for many, many years; and never had any trouble with it. It just worked as descibed.
hth
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 04:38 AM
09-26-2008 04:38 AM
Re: DOSD peculiarity
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 05:27 AM
09-26-2008 05:27 AM
Re: DOSD peculiarity
Put the name of the disk to be used in the DUMP_DEV environment variable. On Alpha, this is done with a SET DUMP_DEV command at the console prompt. On I64, it is done using the command procedure SYS$MANAGER:BOOT_OPTIONS.COM.
No Itanium over here. What is the boot_options.com doing ?
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2008 05:41 AM
09-26-2008 05:41 AM
Re: DOSD peculiarity
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-29-2008 10:45 PM
09-29-2008 10:45 PM
Re: DOSD peculiarity
Even very early mount of disk didn't help. I think SYSINIT opens it when only the system disk is open. So, it can't open the dump file at that moment.
fwiw
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-30-2008 04:35 PM
09-30-2008 04:35 PM
SolutionSome history...
Before V5 there was a rather nasty bug/feature in VMS (as it was then). As Jan has pointed out, the dumpfile is "special" in that it's written to the physical device, not through the filesystem (since we need to avoid any code which may have been the cause of the crash - like the file system). That's also why the dump file needs to fit in a single header.
Back then, at boot time the system would find the dump file and remember the physical location on disk. At dump time, it would just spew out the bits to that physical location on the disk.
But what if someone had deleted the dump file in the mean time? Oh dear, the disk was corrupted. Not good. Since disk space back then was expensive and scarce, this happened far too often! "Here's a big file that we don't really need".
The simple solution introduced in V5 was to check for a dump file at boot time and open the file permanently. That way even if it was deleted, the blocks would only be marked delete pending, thus preventing corruption.
Note that the file being open is completely independent of the dumping itself. It doesn't mean it will be used to dump, it's just a safety mechanism to prevent it from being deleted.
With DOSD, then mechanism has changed completely. I doubt that the code path that opens the dump knows or cares about DOSD. DOSD finds the dump file when it's needed, so deletion is no longer an issue.
Bottom line is, if you have a file SYS$SYSTEM:SYSDUMP.DMP, OpenVMS will always open it at boot time, regardless of if it's the real dump file or not. If you don't want this to happen, or you want to get rid of it, RENAME the file to something else, reboot, then delete it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-30-2008 09:47 PM
09-30-2008 09:47 PM
Re: DOSD peculiarity
That pretty much answers my questions.
Thanx.
Kris (aka Qkcl)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-30-2008 09:49 PM
09-30-2008 09:49 PM
Re: DOSD peculiarity
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-01-2008 02:02 AM
10-01-2008 02:02 AM
Re: DOSD peculiarity
May be this about clue is needed too.
DOSD (Dump Off System Disk) allows you to write the system dump file to a device other than the system disk. For SDA CLUE to be able to correctly find the dump file to be analyzed after a system crash, you need to perform the following steps:
Modify the command procedure SYS$MANAGER:SYCONFIG.COM to add the system logical name CLUE$DOSD_DEVICE to point to the device where the dump file resides. You need to supply only the physical or logical device name without a file specification.
Modify the command procedure SYS$MANAGER:SYCONFIG.COM to mount systemwide the device where the dump file resides. Otherwise, SDA CLUE cannot access and analyze the dump file.
fwiw
Wim