[comp.os.vms] Answer To The SYSDUMP.DMP Placement And Analysis Problems...

CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (08/21/87)

Information From TSO Financial - The Saga Continues...
Chapter 16 - August 9, 1987

There was a question from the Netherlands concerning the use of system common
dump file, SYSDUMP.DMP, and the impact of a multi system shutdown/crash. The
following error was received.

	$ ANALAYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP
	%SDA-E-NOREAD, unable to access location 80002C58
	-SDA-E-NOTVALID, information not in physical memory

The dump file in the SYS$COMMON area was said to be the size of the largest 
memory configuration, plus 4 (I hope). 

There is a very vital sequence of events that occur when a dump file is USED 
and I believe is the problem here. 

The writing of memory contents to the dump file is done as a 'last gasp' type
of operation. The 'normal' device driver is NOT used to perform the function
and thereby all cooridination with other systems for access to this file is
NOT done. The result is that if multiple systems shutdown/crashed at the same 
time the net effect can be a 'mixture' of the different systems. This would
happen on systems that have more memory then can be written in one I/O to the
disk. If the memory is small enough to write with one I/O, then you would get
the last system to perform the write in the dump file.

This is the primary reason I have seperate dump files for the systems that
are critical. By eliminating the over writing, some knowledge can be gained
about the cause of the crash.

Paul D. Clayton - Manager Of Systems
TSO Financial - Horsham, Pa. USA
Address - CLAYTON%XRT@CIS.UPENN.EDU