sysdump.sys

[stefan brgström]

How can I reopen/remane the sysdump.sys without reboot the system,

best regards from stefan

[Wim Van den Wyngaert]

Do you mean analyze the contents ? That is done with ana/crash [name of dump file].

Wim

[Jim_McKinney]

You can rename SYSDUMP.DMP anytime. You can create a new one anytime. When the system boots it maps the existing SYSDUMP.DMP. So, if you rename it, and the system crashes and writes a crashdump, it will write to the original renamed file. If you create a new SYSDUMP.DMP it will not be used until the system has been rebooted (when it map the new one). If you delete the current SYSDUMP.DMP and the system crashes and writes a crashdump it will write to the blocks formerly occupied by the deleted file (which may have subsequently been allocated to other files). So, don't delete a SYSDUMP.DMP until you've booted without mapping it.

[Jan van den Ende]

Stefan,

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.

hth

Proost.

Have one on me (maybe at the Bootcamp in Nashua?)

jpe

[Jess Goodman]

Jim,

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.

[Andy Bustamante]

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

$ @SYS$UPDATE:SWAPFILES

A reboot is required.

Andy

[Martin Hoogenboom]

Stefan

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

Good luck
Martin

[Jim_McKinney]

> ended up with an unusable 'copy'.


Wouldn't that be a bug in BACKUP? Seems unlikely... I've never had problems using BACKUP to copy a dump file.

[Martin Hoogenboom]

Jim,

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.

Regards
Martin Hoogenboom

[Jim_McKinney]

Though it may be "open", the blocks within are not changing nor sitting in a cache. BACKUP should capture them from disk reliably. I've never observed an instance where it didn't.

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