topic Re: DOSD peculiarity in Operating System - OpenVMS

DOSD peculiarity

Kris Clippeleyr — Fri, 26 Sep 2008 05:59:23 GMT

Learned colleagues,

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)

Re: DOSD peculiarity

Willem Grooters — Fri, 26 Sep 2008 06:07:01 GMT

I remember that DUMP_DEV should mention all possible devices wheer the dump could be created, in the right order. In this case:

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.

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 07:58:41 GMT

DKD500 may not be ODS-5 and not be part of a shadow set.

"For best results, include the MOUNT command in SYS$MANAGER:SYCONFIG.COM". May be mounted too late ?

Wim

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 07:59:25 GMT

Kris,

It would be a good idea to crash the system to see where the crash goes.

Wim

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 08:04:55 GMT

Just to be sure : is dumpstyle still 13 after the autogen ?

Wim

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 08:18:21 GMT

Found this in comp.os.vms

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

Re: DOSD peculiarity

Kris Clippeleyr — Fri, 26 Sep 2008 09:10:40 GMT

Re: Willem

> 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)

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 09:29:46 GMT

http://h71000.www7.hp.com/wizard/wiz_2359.html

may be this is a bug and they are keeping the wrong file open ? But then the protection is gone too ...

Wim

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 09:34:15 GMT

If you rename the dump file it will not open the file. If you're very lucky it will open the right file. But then again it's a bug that it opened the sysdevice dump first.

fwiw

Wim

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 10:20:45 GMT

If you don't keep the file open, mark it as no move or a defragmenter could put it on another place. And then your dump would go to the old place. If newer VMS versions didn't change the old behaviour.

Wim

Re: DOSD peculiarity

Jan van den Ende — Fri, 26 Sep 2008 10:42:07 GMT

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

Re: DOSD peculiarity

Walter Miller_1 — Fri, 26 Sep 2008 11:38:01 GMT

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.

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 12:27:56 GMT

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

Re: DOSD peculiarity

Wim Van den Wyngaert — Fri, 26 Sep 2008 12:41:20 GMT

Ignore. I was thinking you had Itanium.

Wim

Re: DOSD peculiarity

Wim Van den Wyngaert — Tue, 30 Sep 2008 05:45:17 GMT

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

Re: DOSD peculiarity

John Gillings — Tue, 30 Sep 2008 23:35:57 GMT

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.

Re: DOSD peculiarity

Kris Clippeleyr — Wed, 01 Oct 2008 04:47:40 GMT

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

Re: DOSD peculiarity

Kris Clippeleyr — Wed, 01 Oct 2008 04:49:39 GMT

As stated above.

Re: DOSD peculiarity

Wim Van den Wyngaert — Wed, 01 Oct 2008 09:02:54 GMT

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