- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: sysdump.sys
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-16-2006 11:43 PM
тАО05-16-2006 11:43 PM
sysdump.sys
How can I reopen/remane the sysdump.sys without reboot the system,
best regards from stefan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-17-2006 12:55 AM
тАО05-17-2006 12:55 AM
Re: sysdump.sys
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-17-2006 01:40 AM
тАО05-17-2006 01:40 AM
Re: sysdump.sys
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-17-2006 02:01 AM
тАО05-17-2006 02:01 AM
Re: sysdump.sys
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-17-2006 05:05 AM
тАО05-17-2006 05:05 AM
Re: sysdump.sys
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-17-2006 05:11 AM
тАО05-17-2006 05:11 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 08:54 AM
тАО05-18-2006 08:54 AM
Re: sysdump.sys
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 08:58 AM
тАО05-18-2006 08:58 AM
Re: sysdump.sys
Wouldn't that be a bug in BACKUP? Seems unlikely... I've never had problems using BACKUP to copy a dump file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 09:16 AM
тАО05-18-2006 09:16 AM
Re: sysdump.sys
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 11:12 AM
тАО05-18-2006 11:12 AM
Re: sysdump.sys
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).