Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!phast.PHYS.WASHINGTON.EDU!SEYMOUR
From: SEYMOUR@phast.PHYS.WASHINGTON.EDU
Newsgroups: comp.os.vms
Subject: DUMPing into pagefile
Message-ID: <UWAVM.ACS.WASHINGTON.EDU:LB@EPmLD*>
Date: 23 Dec 87 23:44:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 32

There was a question about putting vms sysdump.dmp somewhere
useful, instead of occupying lots of otherwise lost disk
space.
Dear ol' dec provides it: (this is a RTFM answer)
(ref: vol 10a, system dump analyzer ref manual, sect 2.2)

Use sysgen to set SAVEDUMP to 1  (non zero).
That tells the system to do the dump into the pagefile
instead of into sysdump.dmp.
Upon rebooting, that setting will take effect.
The pagefile will receive all of your memory, plus 4 pages.
(the original question mentioned a dump file equal to the
memory size... it MUST be 4 blocks bigger, or it's useless)
Upon your next crash (does vms crash?) your pagefile will come up
with those pages occupied, so it had better be big enough to hold
all of that and still boot and run through your startup files.
You release the space by invoking ANALYZE/crash sys$system:pagefile.sys
and then telling ANALYZE to
   COPY destination_file
that will copy the dump to a (non contiguous) file and free the pagefile
pages.
You can look at the dump with analyze before copying it.  The pagefile
pages are not released for normal use until the copy is done.  If you
just want to throw away the dump, you can copy to the NL: device.
SHOW MEMORY shows the pagefile usage.  DEC recommends that you make the
COPY part of your sys$manager:systartup.com file.
DEC also recommends that your pagefile be at least 1000 (1k) blocks
larger than the required dumpfile size.  CMKRNL privlege is required
to free-up the pagefile, but not for the copy operation.
i do it. It works. It's wonderful for rd53 systems.

dick seymour,  bitnet: seymour@uwaphast  (univ of washington)