DOSD peculiarity

[Kris Clippeleyr]

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)

[Willem Grooters]

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.

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

Kris,

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

Wim

[Wim Van den Wyngaert]

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

Wim

[Wim Van den Wyngaert]

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

[Kris Clippeleyr]

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)

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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