 |
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.
|
|
|
|
|
