DOSD peculiarity

[Jan van den Ende]

Kris,

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

[Walter Miller_1]

At one time for OpenVMS VAX DOSD, a stub SYSDUMP.DMP had to reside in the SYS$SYSTEM directory in order for ERRORLOG buffers to be saved. Maybe this is a carry over from that time.

[Wim Van den Wyngaert]

Found this in 2005 tech jou.

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

[Wim Van den Wyngaert]

Ignore. I was thinking you had Itanium.

Wim

[Wim Van den Wyngaert]

Tested all my stuff on 7.3 and found that nothing enabled the opening of the dumpfile on the non-system disk.

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

[John Gillings · Accepted solution]

Kris,

Some 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.

[Kris Clippeleyr]

John,
That pretty much answers my questions.
Thanx.
Kris (aka Qkcl)

[Kris Clippeleyr]

As stated above.

[Wim Van den Wyngaert]

Clue has no clue of DOSD.

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