HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

sysdump.sys

 
stefan brgström
Occasional Visitor

sysdump.sys


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

best regards from stefan
11 REPLIES
Wim Van den Wyngaert
Honored Contributor

Re: sysdump.sys

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

Wim
Wim
Jim_McKinney
Honored Contributor

Re: sysdump.sys

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
Honored Contributor

Re: sysdump.sys

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
Don't rust yours pelled jacker to fine doll missed aches.
Jess Goodman
Esteemed Contributor

Re: sysdump.sys

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.
I have one, but it's personal.
Andy Bustamante
Honored Contributor

Re: sysdump.sys


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

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net

Re: sysdump.sys

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
This must be Thursday, I never could get the hang of Thursdays.
Jim_McKinney
Honored Contributor

Re: sysdump.sys

> 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

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
This must be Thursday, I never could get the hang of Thursdays.
Jim_McKinney
Honored Contributor

Re: sysdump.sys

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).
Ian Miller.
Honored Contributor

Re: sysdump.sys

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.
____________________
Purely Personal Opinion
Jim_McKinney
Honored Contributor

Re: sysdump.sys

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