HP OpenVMS Systems

Dump file held open?

» close window

The Question is:

 
Dear Wizard,
 
Any suggestions in order to correct the below situation?
 
Thanks in advance,
Mirtos Anastasiades
 
 
Open VMS Version V6.2-1H3. Running on an AlphaServer 4100 5/466 4MB
 
 
SYSTEM $ sh dev dsa0:
Device                  Device           Error    Volume         Free
Trans Mnt
 Name                   Status           Count     Label        Blocks
Count Cnt
DSA0:                   Mounted              0  ALPHASYS       1482327
869   1
$1$DKB100:    (ODVMS1)  ShadowSetMember      0  (member of DSA0:)
$1$DKC100:    (ODVMS1)  ShadowSetMember      0  (member of DSA0:)
 
 
SYSTEM $ dir dsa0:[000000...] /siz/grant
Grand total of 369 directories, 18435 files, 6858611 blocks.
 
 
SYSTEM $ dir/siz/dat DSA0:[SYS0.SYSEXE]SYSDUMP.DMP;3
Directory DSA0:[SYS0.SYSEXE]
SYSDUMP.DMP;3        1624878   3.12.98 11:12:57.74
 
 
SYSTEM $ copy DSA0:[SYS0.SYSEXE]SYSDUMP.DMP;3 dsa40:[000000.archive]
 
 
SYSTEM $ del DSA0:[SYS0.SYSEXE]SYSDUMP.DMP;3
 
 
SYSTEM $ dir dsa0:[000000...] /siz/grant
Grand total of 369 directories, 18434 files, 6858611 blocks.
 
 
SYSTEM $ anal/disk dsa0:
Analyze/Disk_Structure for _DSA0: started on 24-APR-1999 12:41:42.90
%ANALDISK-W-DELHEADER, file (9220,208,1) SYSDUMP.DMP;3
 marked for delete
 
 
SYSTEM $ anal/disk/repa dsa0:
Analyze/Disk_Structure/Repair for _DSA0: started on 24-APR-1999
12:56:09.07
%ANALDISK-W-DELHEADER, file (9220,208,1) SYSDUMP.DMP;3
 marked for delete
 
 
 

The Answer is :

 
  Reboot.  OpenVMS is currently holding the SYSDUMP.DMP system dump
  file open, which is expected and completely intentional behaviour
  with respect to the system dump file.  This behaviour is intentionaly
  and avoids the data corruptions that were regularly observed on OpenVMS
  releases prior to the change (made in V5.0) -- these corruptions occured
  when the dump file was erroneously deleted and the system later crashed
  and wrote to the disk blocks formerly occupied by the dump file.
 
  As background, the OpenVMS bugcheck code will write directly to
  the disk blocks designated as the dump file using very simple and
  very primitive I/O device drivers and data structures, and the
  complete removal of the dump file -- without resetting the target
  for writing out the bugcheck -- will cause data corruptions when
  the bugcheck is written to storage no longer allocated to the dump
  file.   These and related constructs are deliberately primitive,
  as it is very desireable that the system bugcheck dump be written
  even when a system corruption has arisen.
 
  As there is no way available to reset the target area for the OpenVMS
  system dump while while OpenVMS is running -- and to thus safely
  permit the dump file to be completely deleted -- a system reboot
  is required to release the storage occupied by the dump file.
 
  The primary PAGEFILE.SYS and SWAPFILE.SYS are handled similarly.
  (Note that some system configurations write dumps to the pagefile,
  and also note that very primitive I/O is used with all these files.)
 
  The most common sequence used to remove these files involves using
  a RENAME to .OLD or similar name (a name that will prevent OpenVMS
  from accessing the file during a bootstrap), a system reboot, and
  then use DELETE to release the storage occupied by the file.
 

  

     

     
answer written or last revised on ( 2-AUG-2001 )
     
» close window