WARNER..NAGY@FNALB.BITNET (Frank.J.Nagy@jade.Berkeley.EDU, (12/24/87)
Richard Steinberger <STEINBERGER@KL.SRI.COM> writes: > There is a dump file on my system disk that is 32767 blocks large (the > same size as physical memory). My understanding is that this area will > be used by VMS in case the system crashes. The contents of memory will > be stored here. This is fine; but I was wondering if there are any ways > to have this file/disk area serve two functions since it seems to be > unused during "normal" VMS operations. For example, is there a way that > it can also be a page or swap file until/unless the system crashes? > Are there other uses or should I just keep my hands off? Thanks > in advance to all who respond. To make a full system save after a crash, the dump file should be your physical memory size (in pages) + 4 blocks (1 for header and 3 for error log buffers, I believe). If the dump file is shorter, VMS will just not write all of physical memory out which just means that SDA will probably not be able to analyze the system crash. So, if disk space is *much* more important than analyzing a system crash (which is true of some systems), then you could either create a 0 length dump file (REBOOT before doing a PURGE or you'll be sorry). Alternatively, I believe# if there is no SYSDUMP.DMP file, the crash dump will be saved in the pagefile. The system parameter SAVEDUMP will then preserve the portion of the pagefile with the crash dump until SDA is used to copy the crash dump to another file for analysis. Because this *reserves* pagefile space, your pagefile must be larger than physical memory and the crash dump should be emptied out of the pagefile before startup is completed to release the pagefile space. #This is an unverified statement, maybe someone else in netland can respond as to what circumstances are needed to have VMS use the pagefile for system dumps. We have debugging systems which have a normal pagefile setup, other systems with a 0 block pagefile (if the system crashes there, we depend upon being able to reproduce it on a debug station), and VAXClusters (CI and LAVC) with a single SYSDUMP.DMP in SYS$COMMON:[SYSEXE]. The *common* dumpfile is only good if a single VAX crashes, but certainly saves disk space in clusters with 128 MB 8800's and 60 MB 8650's! = Frank J. Nagy "VAX Guru & Wizard" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510
jeh@crash.cts.com (Jamie Hanrahan) (12/26/87)
In article <8712250121.AA26559@jade.berkeley.edu> WARNER..NAGY@FNALB.BITNET (Frank.J.Nagy@jade.Berkeley.EDU, VAX Wizard & Guru) writes: >Richard Steinberger <STEINBERGER@KL.SRI.COM> writes: >> There is a dump file on my system disk that is 32767 blocks large (the >> same size as physical memory). My understanding is that this area will >> be used by VMS in case the system crashes. The contents of memory will >> be stored here. This is fine; but I was wondering if there are any ways >> to have this file/disk area serve two functions since it seems to be >> unused during "normal" VMS operations. For example, is there a way that >> it can also be a page or swap file until/unless the system crashes? >> Are there other uses or should I just keep my hands off? Thanks >> in advance to all who respond. > >To make a full system save after a crash, the dump file should be your >physical memory size (in pages) + 4 blocks (1 for header and 3 for error >log buffers, I believe). If the dump file is shorter, VMS will just not >write all of physical memory out which just means that SDA will probably >not be able to analyze the system crash. So, if disk space is *much* >more important than analyzing a system crash (which is true of some >systems), then you could either create a 0 length dump file (REBOOT before >doing a PURGE or you'll be sorry). > >Alternatively, I believe# if there is no SYSDUMP.DMP file, the crash dump >will be saved in the pagefile. The system parameter SAVEDUMP will then >preserve the portion of the pagefile with the crash dump until SDA is >used to copy the crash dump to another file for analysis. Because this >*reserves* pagefile space, your pagefile must be larger than physical >memory and the crash dump should be emptied out of the pagefile before >startup is completed to release the pagefile space. > Frank Nagy is correct. To modify your system so that crash dumps get written to SYS$SYSTEM:PAGEFILE.SYS, do the following: 1. Rename SYSDUMP.DMP to something else, like SYSDUMP.OLD . 2. Ensure the PAGEFILE.SYS has as many blocks as you have pages of physical memory, + 4, + enough to get through STARTUP.COM and to run SDA when you come up after a crash (on our MicroVAXes, where we routinely use the PAGEFILE.SYS as the dump file, I've found that an extra 2000 blocks are sufficient; I haven't experimented to see how close this can be cut). 3. Set the SAVEDUMP (or is it DUMPSAVE?) SYSGEN parameter to 1. WRITE CURRENT. 4. In SYSTARTUP.COM, very near the beginning, do the following: $ ANALYZE/CRASH SYS$SYSTEM:PAGEFILE.SYS COPY SYS$ERRORLOG:SAVEDUMP.DMP ! or wherever SET OUTPUT SYS$ERRORLOG:CRASH.LIS SHOW SUMMARY SHOW PROCESS SHOW STACK ... whatever other SHOWs you want (see the SDA manual) EXIT 5. Shut down and reboot. Since the system can't find SYSDUMP.DMP, subsequent crashdumps will be written to PAGEFILE.SYS . 6. Delete SYSDUMP.OLD (or whatever you called it). SDA, when invoked with ANALYZE/CRASH from the startup process, will exit immediately if the system is booting normally (i.e. not after a crash). The COPY command copies the crash dump from the paging file to somewhere else, and also frees the blocks in the paging file for use by the pager. The other commands give you a file, CRASH.LIS, which gives you a "first look" at the crash; these can be omitted if you like. You probably also want to $ PURGE/KEEP=some_low_number SYS$ERRORLOG:SAVEDUMP.DMP after the EXIT command. As for Frank's problem with dump files on clusters of large-memoried VAXes, there's always the solution shouted at the Advanced Q&A session at the end of the Nashville DECUS Symposium... "Buy less memory".
klb@philabs.Philips.Com (Ken Bourque) (01/05/88)
Frank Nagy's remarks are correct - if there is no dump file VMS will put the
dump in the page file, but will not preserve it during the next boot unless
SAVEDUMP is nonzero. If you do this, you must be sure to run SDA in SYSTARTUP
and COPY the dump into another file. If the page file runs low on space the
pages containing the dump will be released and it will be lost. I use this
method as SOP and it works fine, although SDA will complain about "No valid
dump" in the page file until one actually gets put there. It's all spelled out
in Chapter 2 of the SDA manual and in Chapter 3 of the System Manager's manual.
--
Ken Bourque klb@philabs.philips.com ...!{uunet,ihnp4,decvax}!philabs!klb