- Integrated Systems
- About Us
- Integrated Systems
- About Us
05-17-2006 01:40 AM
05-17-2006 02:01 AM
and if you want to preserve the dump, past an intervening (planned or unplanned) reboot, just make a copy with BACKUP. Be sure to use the /IGNORE=NOBACKUP qualifier, or all you get is the header info and the allocated amount without the data.
Have one on me (maybe at the Bootcamp in Nashua?)
05-17-2006 05:05 AM
VMS now (since at least VMS 6.2) keeps the SYSDUMP.DMP file open, so you can't really delete it - if you try it gets marked for delete and becomes a lost file after next reboot. So there is no longer any danger of overwriting other files on the system disk.
05-17-2006 05:11 AM
Are you trying to preserve crash dump information? You can use SDA to create a copy of your dump file.
$ ANALYZE/CRASH_DUMP sysdump.dmp
SDA> copy $1$dga32:[temp]crash_17_May_2006.dmp
will copy the dump information into the a new file. This approach only writes valid information and may use less disk space than copying the file with BACKUP.
The file is mapped when the system boots, you can't delete it while the system is up. If you rename it, the allocated space is still used to write a crash dump information, should the need arise until the next boot.
You can change the size of the dump file with
A reboot is required.
05-18-2006 08:54 AM
Open/Reopen the dump file (for analyse or copy) is using ANALYSE /CRASH_DUMP SYSDUMP.DMP
The only correct way to make a valid copy/backup of an existing dump is using the ANAL/CRASH_DUMP method specified by Andy.
I had recently tried the VMS BACKUP trick JAN suggested but ended up with an unusable 'copy'.
05-18-2006 08:58 AM
Wouldn't that be a bug in BACKUP? Seems unlikely... I've never had problems using BACKUP to copy a dump file.
05-18-2006 09:16 AM
Well... bare in mind that the dump file is open in the recent VMS versions. Probably to prevent unaware sysman's to move or delete the file (i can't think of any other reason).
Then there is some statement about backing up open files not always being valid.
I dont think this can be called a bug.
05-18-2006 11:12 AM
Do you use host-based volume shadowing? clustered environment? If not, ignore the rest... If so, it's possible for the shadow members to contain different data in the blocks where the dump file resides. The dump file is mapped to a single disk prior to the startup of the shadowing software during the VMS bootstrap. The writes are directed only to this disk and since they don't occur in the context of VMS, the shadowing software still running in the cluster is not handling them - so there is no synchronization of the disks for these writes. In this event you need either to use some tool to force the dump data to be written from the member with the valid dump to the other(s). Or, alternatively, you can determine which disk is the shadow master and force a shadow copy in the appropriate direction. Otherwise, if you attempt to read the dump you'll likely find that SDA declares it to invalid as some reads are directed to one shadow member and some to other(s).
05-18-2006 08:57 PM
Copying a dump file with backup does not really work any more.
Purely Personal Opinion
05-19-2006 05:22 AM
It works for me - always has, and still does. It doesn't seem reasonable to me that BACKUP would not be able to reliably copy a dump file. It's just a file whose blocks are stable when VMS is "up".