topic Re: sysdump.sys in Operating System - OpenVMS

sysdump.sys

stefan brgström — Wed, 17 May 2006 06:43:45 GMT

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

best regards from stefan

Re: sysdump.sys

Wim Van den Wyngaert — Wed, 17 May 2006 07:55:25 GMT

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

Wim

Re: sysdump.sys

Jim_McKinney — Wed, 17 May 2006 08:40:57 GMT

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.

Re: sysdump.sys

Jan van den Ende — Wed, 17 May 2006 09:01:07 GMT

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

Re: sysdump.sys

Jess Goodman — Wed, 17 May 2006 12:05:27 GMT

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.

Re: sysdump.sys

Andy Bustamante — Wed, 17 May 2006 12:11:07 GMT

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

Re: sysdump.sys

Martin Hoogenboom — Thu, 18 May 2006 15:54:16 GMT

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

Re: sysdump.sys

Jim_McKinney — Thu, 18 May 2006 15:58:11 GMT

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

Re: sysdump.sys

Martin Hoogenboom — Thu, 18 May 2006 16:16:05 GMT

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

Re: sysdump.sys

Jim_McKinney — Thu, 18 May 2006 18:12:19 GMT

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

Re: sysdump.sys

Ian Miller. — Fri, 19 May 2006 03:57:24 GMT

Note that SDA COPY command does some addtional processing (especially on VMS I64).

Copying a dump file with backup does not really work any more.

Re: sysdump.sys

Jim_McKinney — Fri, 19 May 2006 12:22:26 GMT

> Copying a dump file with backup does not really work any more.

How so?

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