Not creating Crash Dump file - what am I missing?

[Rich Hearn]

Bill & Steve - apologies for my delay in getting back here.


Bill,

Thanks for the boot_dev info - it, obviously, needs to be corrected. It does confuse me tho' that the node Cache2 has the same set up and *does* write a crash dump.

Each boot disk is a shadowed local disk to each system, so I thought I was ok with it.
Your thoughts about the corrections will be applied...


Steve,

the boot device is local (internal) and shadowed using Dka0 and Dkb0 - the thinkin' being if a controller "died" we'd have the redundancy - maybe not so good in retrospect...
Volume Name is: CACHE1_V83-0 Shadow Set is: Dsa1: Disk order is: _$1$DKA0: _$1$DKB0: None
Volume Name is: CACHE2_V83-0 Shadow Set is: Dsa2: Disk order is: _$2$DKA0: _$2$DKB0: None

This *used* to work - that's what's got me befuddled. I've not made any *intentional* changes (we all know how that goes :^)

Thanks for your thoughts and time.
Rich
_

[The Brit]

Rich,
This is just an excerpt from an old Alpha management manual. Note number 3. below.

On Alpha systems, the requirements for writing the DOSD are the following:

The dump device directory structure must resemble the current system disk structure. The [SYSn.SYSEXE]SYSDUMP.DMP file will reside there, with the same boot time system root.
Use AUTOGEN to create this file. In the MODPARAMS.DAT file, the following symbol prompts AUTOGEN to create the file:
DUMPFILE_DEVICE = $nnn$ddcuuuu


You can enter a list of devices.

1. The dump disk must have an ODS-2 file structure.

2. The dump device cannot be part of a volume set.

3. The dump device cannot be part of a shadow set unless it is also the system device and the master member of the shadow set.

Use the following format to specify the dump device environment variable DUMP_DEV at the console prompt:

>>> SET DUMP_DEV device-name[...]

If I remember correctly, the DUMP_DEV definitions are only required if you are dumping OFF the system disk. (not true in your case)

Dave

[Rich Hearn]

Dave,

"the DUMP_DEV definitions are only required if you are dumping OFF the system disk"

Ah, that could explain why I never recall having set it before.

Tnx,
Rich
_

[Steve Reece_3]

Hi Rich,

Having shadowed disks is just fine and dandy and will achieve resilience (as you suggest).
The thing you need to do is switch one of the disks to a different SCSI ID - make them, say, DKA0 and DKB100.

If I recall correctly, I think the name of the chap that described crashing and having different SCSI IDs on disks being essential was Richard Bishop. If you have the same SCSI ID on two disks in a shadow set, the driver that is being used for the crash dump writing isn't sure which is the master member so will sometimes get it right, othertimes get it wrong.

Steve

[Rich Hearn]

Steve,

Fascinating stuff. Faux pas par excellence on my part I'd say, what with the same drive #'s. I'll have to see what I can do to get them changed. Thank you for picking up on my missing your point - do 'preciate you clarifying.

Rich
_