Conference vaxaxp::alphanotes

    Geoff,
    
    There's no SYSGEN parameter for the device, just a symbol in MODPARAMS
    - DUMPFILE_DEVICE. But that's only to get AUTOGEN to do the file
    creation and sizing in the right place.
    
    If you've got dumpstyle bit 2 set and console variable dump_dev set, 
    and the SYSDUMP.DMP in the [SYSn.SYSEXE] of that device you should be 
    all set, but clearly you aren't :-(
    
    Set bit 1 in DUMPSTYLE and try again. There's a host of diagnostic
    messages output while it's validating the dump device and file. Post
    the output here and I'll see if I can see what you're missing.
    Something obvious if I could take a step back, but I'm too close to
    this all the time and don't always think of the obvious (can't see the
    wood for the trees)
    
    - Richard.

:    In the mean time could someone just tell me if DOSD does work? 

   It does.

:    Hoping to get my hands on the real V7.1 release notes next week instead
:    of the EFT1 version I've got now.

   See VAXAXP::VMSNOTES notes 8 and 9 for pointers to the on-line kits
   and on-line documentation.  And the manual you want is the System
   Management Manual, not the release notes manual.

   You can also see http://axiom.zko.dec.com:8000/docset/, and specifically,
   http://axiom.zko.dec.com:8000/docset/ssb71/6015/6017p050.htm#dump_off
   will take you directly to the DOSD documentation.  (It's in chapter
   15 of the V7.1 manual, if the above link changes -- that documentation
   area is live and is regularly updated.)

:    I've been trying it, but the sysgen DUMPFILE_DEV isn't recognised,
:    so how do I tell OpenVMS which device to use?  I've

   It's a symbol used/needed by AUTOGEN, and not a SYSGEN parameter. 
   (One should not directly access SYSGEN parameters anyway -- the
   file MODPARAMS.DAT is the prefered mechanism for adjusting SYSGEN
   parameters.)

	--

   VAXAXP::VMSNOTES is where most OpenVMS-specific discussions are
   going -- this conference is for porting and generic-Alpha issues.

    Re: .1
    
    Thanks for the reply, Richard.
    
    I've attached the relevant displays - anything obvious?
    
    The SYSDUMP.DMP file was created by AUTOGEN on DKA300.
    
    
    Re: .2
    
    Thanks for the pointers, Steve.
    
    
    ==========================================================

$DIR $1$DKA300:[SYS0.SYSEXE]/SIZ=ALL

Directory $1$DKA300:[SYS0.SYSEXE]

SYSDUMP.DMP;1		82928/82928

Total of 1 file, 82928/82928 blocks.



$! dumpstyle = 15


>>>sh dump_dev
dump_dev		dka300.3.0.6.0

>>>sh dev
.
.
dka300.3.0.6.0		DKA300			RZ28M   0466
.
.
>>>crash

CPU 0 restarting

.
.
.

**** Searching devices listed in DUMP_DEV

     Checking entry #01 in DUMP_DEV...
 ...could not find valid dump file
**** Trying DUMP_DEV devices a second time...
     Checking entry #01 in DUMP_DEV...
 ...could not find valid dump file
**** Trying DUMP_DEV devices a third time...
     Checking entry #01 in DUMP_DEV...
 ...could not find valid dump file
**** No valid dump device was found in DUMP_DEV
**** Attempting to write the crash dump to the system disk

.
.
.

    show logical sys$topsys (being pedantic but I want to be certain)
    
    also go into SDA and do SHOW EXEC and post the details for
    EXCEPTION or EXCEPTION_MON - it's the link date/time I want,
    in case by some weridness you have a wrong image.
    
    And show dev $1$DKA300/full too.
    
    Beyond that, I'm probably going to need to talk to you directly - 
    I can't see what is missing.
    
    - Richard.

    Do the console and VMS agree on which device is really DKA300?
    The names don't always match...
    
    d.

    Is ALPSHAD01_071 installed on this system??  Is the dump_dev shadowed??
    
    A dependency was missed when the kit was built and EXCEPTION(_MON) were
    left out of the kit...  ALPSHAD02_071 includes the matching 
    EXCEPTION images..
    
    Cheers,
    jeff
    

    Re .4
    
    Here's the info you asked for, Richard.
    
    Any clues?
    
    ====================================================================
    
$SH LOG SYS$TOPSYS/FULL
  "SYS$TOPSYS" [user] = "SYS0" (LNM$SYSTEM_TABLE)


SDA> SH EXEC gives

	EXCEPTION	 Linked 25-NOV-1996  22:05


$SHO DEV/FUL $1$DKA300

Disk $1$DKA300: (GLOB1), device type DEC RZ28M, is online, mounted, file-
    oriented device, shareable, served to cluster via MSCP Server, error logging
    is enabled.

    Error count                    0    Operations completed                 19
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                1    Default buffer size                 512
    Total blocks             4110480    Sectors per track                    86
    Total cylinders             2988    Tracks per cylinder                  16
    Allocation class               1

    Volume label              "ODDS"    Relative volume number                0
    Cluster size                   4    Transaction count                     1
    Free blocks              3955520    Maximum files allowed            411048
    Extend quantity                5    Mount count                           1
    Mount status              System    Cache name          "_$1$DKA0:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache   395552
    File ID cache size            64    Blocks currently in extent cache      0
    Quota cache size               0    Maximum buffers in FCP cache        654
    Volume owner UIC        [SYSTEM]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  subject to mount verification, file high-water marking, write-
      back caching enabled.

    

    Re .6
    
    Jeff,
    
    ALPSHAD01_071 is not installed and the dump device is not shadowed.
    
    Is this patch essential for DOSD?  See info in .-1.
    
    Cheers,
    
    Geoff

    No, SHAD02_071 is only required if you are using shadowing and if
    you have SHAD01_071 installed.  SHAD01 changed the SHAD$ structure
    and it turns out that it is used in EXCEPTION.EXE.
    
    If you are running with the SSB SYS$SHDRIVER, then you should also 
    be running with the SSB EXCEPTION.EXE.   It does not contain any
    fixes in regards to DOSD.
    
    Oh, and of course, SHAD02 is strongly recommended for any V7.1
    customers that use shadowing..
    
    Cheers
    jeff
    

    Geoff and I have taken this offline - I'm still none the wiser what's 
    wrong. It's not a different view of which disk is which between console
    and VMS; and it's not a SYSDUMP.DMP that is too badly fragmented to be
    used.
    
    More next week...
    
    - Richard.

   Also check that both the console and OpenVMS are refering to the same
   disk as DKA300 -- that's (unfortunately) not always the case when there
   are multiple SCSI controllers around...

    OK now I've found the cause, and a simple workaround.
    
    If any of the directories in the path to the dumpfile (in 
    this case 000000.DIR, SYS0.DIR, SYSEXE.DIR) are more than 
    six blocks long and the entry of interest in the directory
    isn't in the first six blocks, the primitive file system
    can't find the entry.
    
    So the workaround is to clean up [000000], since in this
    case that's the directory that is over six blocks.
    
    And now to find out what is wrong with the caching code in
    the primitive file system...
    
    - Richard.

    Re .-1
    
    Having deleted some files from the MFD on the alternate dumpfile disk,
    I've just successfully dumped to that disk.
    
    Thanks to all for their suggestions and help!
    
    Geoff