|
HP OpenVMS Systemsask the wizard |
|
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.
|