Document revision date: 15 July 2002

Once you determine an initial size for your page file or files (either with AUTOGEN or manually), monitor page file usage by executing AUTOGEN with the following command:

$ @SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES FEEDBACK

With this command, AUTOGEN writes page file usage and size recommendations to the feedback report AGEN$PARAMS.REPORT. (For more information about AUTOGEN and the feedback report, see Section 15.4 and Section 15.4.2.) The DCL command SHOW MEMORY/FILES also displays file usage, as explained in Section 16.3.

Keep page file usage less than half the size of the page file or files. If a paging file starts to fill to the point where system performance is being affected, a message is printed on the console terminal. If this happens, increase the size of your page file or files or install additional files.

Limit the amount of page file space consumed by user programs by using the /PGFLQUOTA qualifier of the AUTHORIZE commands ADD and MODIFY. (Refer to the AUTHORIZE section in the OpenVMS System Management Utilities Reference Manual for more information.) Do not reduce the value of /PGFLQUOTA below 1024. Size requirements of the page file vary widely, depending on user applications.

16.4.4 Calculating Swap File Size

Sufficient swap file space is critical to system performance. The AUTOGEN command procedure calculates an appropriate size for your swap file space. To manually calculate the size for swap file space, use the following formula:

size-in-blocks (total for all swap files on the system) = maximum-number-of-processes * average-working-set-quota-of-processes-on-system

where:

maximum-number-of-processes	Is the value of the MAXPROCESSCNT system parameter.
average-working-set-quota-of-processes-on-system	Is the average value of the WSQUOTA limit for processes running on the system. On VAX systems, specify the value in pages. On Alpha systems, specify the value in pagelets.

16.4.4.1 Representing Swap File Size

The size you calculate can be represented in any of the following ways:

• In the primary swap file only
• Distributed across primary and secondary swap files
• If you have removed the primary swap file in SYS$SYSTEM, distributed across a number of secondary swap files

Once you have determined an appropriate size for swap file space (either manually or with AUTOGEN), monitor swap file usage with the DCL command SHOW MEMORY/FILES as explained in Section 16.3. Keep at least one-third of the swap file space unused; otherwise, system performance can be severely affected.

In certain system configurations, it might be impossible to preserve the entire contents of memory in a disk file. For instance, a large memory system might not be able to supply enough disk space for a full memory dump. If your system attempts to save all of memory but the dump file is too small to accommodate the entire dump, the System Dump Analyzer utility (SDA) might not be able to analyze the dump.

On VAX systems, insufficient dump space would also prevent the Crash Log Utility Extractor (CLUE) from being able to analyze the dump.

Options for Minimizing System Dump File Size

Use one of the following options to minimize the size of the system dump file when disk space is insufficient:

• Selective dumps
  To preserve those portions of memory that contain information most useful in determining the causes of system failures, you can use selective system dumps. Table 16-1 defines physical and selective dumps.
  Table 16-3 compares the information available in physical and selective system dump files.

  Table 16-3 Comparison of Physical and Selective System Dump Files

  Type	Available Information	Unavailable Information
  Physical dump (also known as full dump)	Complete contents of physical memory in use, stored in order of increasing physical address and error log buffers.	Contents of paged-out memory at the time of the crash.
  Selective dump	System page table, global page table, system space memory, error log buffers, and process and control regions (plus global pages) for all saved processes.	Contents of paged-out memory at the time of the crash, process and control regions of unsaved processes, and memory not mapped by a page table.

  
  To direct your system to save selective system dumps, set bit 0 of the system parameter DUMPSTYLE. System parameters and their values are in an appendix of the OpenVMS System Management Utilities Reference Manual. For information about how to change system parameter values, see Section 15.5.

• Compressed dumps
  On Alpha systems, if you set bit 3 of the DUMPSTYLE system parameter, OpenVMS writes the physical or selective system dump in a compressed format. (The exact amount of the compression depends on system use, but the typical compressed dump is about 60 percent of its original size.) If you use compressed dumps, AUTOGEN sizes the system dump file at 2/3 of its uncompressed size.
• Dump off system disk (DOSD)
  If you set bit 2 of the DUMPSTYLE system parameter and meet all the other requirements, OpenVMS writes the system dump to a disk other than the system disk. For details, see Section 16.7.

Section 16.5.1 discusses the order in which information is written to a selective system dump on Alpha and VAX systems. Section 16.5.2 discusses how this order can be fine-tuned on Alpha systems.

16.5.1 Understanding the Order of Information in a Selective System Dump

The following lists show the order in which information is written to selective dumps on VAX and Alpha systems.

On VAX systems, information is written to selective dumps in the following order:

1. System page table (SPT)
2. System space (including process page tables, page frame number (PFN) database, and global page table (GPT))
3. Global pages that appear in the working set of any process
4. Processes resident at the time of the crash:
   1. Current process on crash CPU
   2. Predefined processes (hardcoded into BUGCHECK)
   3. Current processes on other CPUs
   4. Other processes resident at the time of the crash, in order by process index

On Alpha systems, information is written to selective system dumps in the following order:

1. Page table (PT) space for shared addresses (S0/S1/S2)
2. S0/S1 space
3. S2 space
4. Any system space pages (P1, S0/S1, S2) that have been replicated for performance reasons, where the contents of the replicated page is different from the original
5. Memory map pages for Galaxy shared memory regions, if appropriate
6. Key processes:
   1. Current process on crash CPU
   2. Swapper
   3. Current processes on CPUs that have failed to record their crash state
   4. Current processes on other CPUs
   5. Site-specific priority processes (see next section)
   6. Compaq-defined priority processes (hardcoded into BUGCHECK):

      MSCPmount
      AUDIT_SERVER
      NETACP
      NET$ACP
      REMACP
      LES$ACP

7. Any processes in a resource or miscellaneous wait state (for example, RWAST)
8. Key global pages (those that appear in the working set of any key process)
9. Other processes (the non-key processes) resident at the time of the crash, in order by process index
10. Remaining global pages that appear in the working set of any non-key process

Note that on Alpha systems, processes are dumped in two stages: the page tables for the process first, and then the body of the process.

Usage Notes on VAX and Alpha Systems

On both VAX and Alpha platforms, no process is dumped twice. For example, on Alpha systems, if the current process is the Swapper, it is dumped only once.

Similarly, on Alpha systems, no global page is dumped twice. Therefore, if a page in the working set of a key process is dumped in the "Key global pages" section, it is not dumped again later just because it is also in the working set of a non-key process.

16.5.2 Fine-Tuning the Order That Processes Are Written in Selective System Dumps (Alpha Only)

On Alpha systems, a set of processes, known as key processes, are dumped immediately following PT, S0/S1, and S2, including transition pages that link back to the process. The system manager can designate additional processes to be treated as key processes. These processes have priority over other processes in a dump, thus ensuring that the selected processes are successfully written when the dump file is too small to contain all processes.

How to Perform This Task

To designate the order of processes in a dump, follow these steps:

1. Copy the file SYS$SYSTEM:SYS$DUMP_PRIORITY.TEMPLATE to SYS$SYSTEM:SYS$DUMP_PRIORITY.DAT.
2. Following the instructions in the file, edit the .DAT file to contain a list of the processes to be dumped early in the dump.
3. Run the image SYS$SYSTEM:SYS$SET_DUMP_PRIORITY.EXE. Note that the image is automatically run during system startup if the data file SYS$SYSTEM:SYS$DUMP_PRIORITY.DAT exists.

You can edit the data file and run the image at any time the system is running. Therefore, if a process is hung, the system manager can designate the process as a priority process and then force a crash.

16.6 Writing the System Dump File to the System Disk

If you have more than one path to the system disk, or the system disk is a shadow set with multiple members, you must take additional steps to ensure that a system dump can be written to the system disk.

16.6.1 System Dump to System Disk on Alpha

If there is more than one path to the system disk, the console environment variable DUMP_DEV must describe all paths to the system disk. This ensures that if the original boot path becomes unavailable because of failover, the system can still locate the system disk and write the system dump to it.

If the system disk shadow set has multiple members, the console environment variable DUMP_DEV must describe all paths to all members of the shadow set. This ensures that if the master member changes, the system can still locate the master member and write the system dump to it.

If you do not define DUMP_DEV, the system can write a system dump only to the physical disk used at boot time using only the same physical path used at boot time. For instructions on setting DUMP_DEV, see Section 16.7.1.

Certain configurations (for example, those using Fibre Channel disks) may contain more combinations of paths to the system disk than can be listed in DUMP_DEV. In that case, Compaq recommends that you include in DUMP_DEV all paths to what is usually the master member of the shadow set, because shadow set membership changes occur less often than path changes.

You can write the system dump to an alternate disk (see Section 16.7.1), but when doing so you must still define a path to the system disk for writing error logs. Therefore, DUMP_DEV should contain all paths to the system disk in addition to the paths to the alternate dump disk.

If there are more paths than DUMP_DEV can contain, Compaq recommends that you define all paths to the dump disk and as many paths as possible (but at least one) to the system disk. Note that the system disk paths must come last in the list.

16.6.2 System Dump to System Disk on VAX

To ensure that the system can locate the system disk and write the system dump to it when there is more than one path to the system disk, or when the system disk shadow set has multiple members, you must follow the platform-specific instructions regarding booting. On some VAX systems, you must set appropriate register values; on other VAX systems, you must set specific environment variables. See the upgrade and installation supplement for your VAX system for details.

Note that if the system has multiple CI star couplers, the shadow set members must all be connected through the same star coupler.

16.7 Writing the System Dump File to an Alternate Disk

You can write the system dump file to a device other than the system disk (DOSD) on OpenVMS systems. This is especially useful in large-memory systems and in clusters with common system disks where sufficient disk space is not always available on one disk to support customer dump file requirements.

Requirements for DOSD are somewhat different on VAX and Alpha systems. On both systems, however, you must correctly enable the DUMPSTYLE system parameter to enable the bugcheck code to write the system dump file to an alternate device.

The following sections describe the requirements for DOSD on Alpha and VAX systems.

16.7.1 DOSD Requirements on Alpha Systems

On Alpha systems, DOSD has the following requirements:

• The dump device directory structure must resemble the current system disk structure. The [SYSn.SYSEXE]SYSDUMP.DMP file will reside there, with the same boot time system root.
  Use AUTOGEN to create this file. In the MODPARAMS.DAT file, the following symbol prompts AUTOGEN to create the file:

  DUMPFILE_DEVICE = "$nnn$ddcuuuu"

  
  You can enter a list of devices.

• The dump disk must have an ODS-2 or ODS-5 file structure.
• The dump device cannot be part of a volume set.
• Although not a requirement, Compaq recommends that you mount the dump device during system startup. If the dump device is mounted, it can be accessed by CLUE and AUTOGEN and for the analysis of crash dumps. For best results, include the MOUNT command in SYS$MANAGER:SYCONFIG.COM.
• For the Crash Log Utility Extractor (CLUE) to support DOSD, you must define the logical name CLUE$DOSD_DEVICE to point to the dump file to be analyzed after a system crash. For instructions, refer to Section 16.9.
• The dump device cannot be part of a shadow set unless it is also the system device and the master member of the shadow set.
• Use the following format to specify the dump device environment variable DUMP_DEV at the console prompt:

  >>> SET DUMP_DEV device-name[...]

  Note On DEC 3000 series systems, the following restrictions on the use of the DUMP_DEV environment variable exist: This variable is not preserved across system power failures because DEC 3000 series systems do not have enough nonvolatile RAM to save the contents of the file. You must reset the DUMP_DEV variable after a power failure. (DUMP_DEV is preserved across all other types of restarts and bootstraps, however.) You cannot clear DUMP_DEV (except by power-cycling the system). You must use console firmware Version 6.0 or greater because earlier versions do not provide support for DUMP_DEV.

  
  On some CPU types, you can enter only one device; on other CPU types, you can enter a list of devices. The list can include various alternate paths to the system disk and the dump disk.
  By specifying an alternate path with DUMP_DEV, the disk can fail over to the alternate path when the system is running. If the system crashes subsequently, the bugcheck code can use the alternate path by referring to the contents of DUMP_DEV.
  When you enter a list of devices, however, paths to the system disk must come last.

How to Perform This Task

To designate the dump device with the DUMP_DEV environment variable, and enable the DUMPSTYLE system parameter, follow these steps:

1. Display the value of BOOTDEF_DEV; for example:

   >>> SHOW BOOTDEF_DEV

   BOOTDEF_DEV dub204.7.0.4.3,dua204.4.0.2.3

2. Display the devices on the system as follows:

   >>> SHOW DEVICES

   Resetting IO subsystem... dua204.4.0.2.3 $4$DUA204 (RED70A) RA72 dua206.4.0.2.3 $4$DUA206 (RED70A) RA72 dua208.4.0.2.3 $4$DUA208 (RED70A) RA72 polling for units on cixcd1, slot 4, xmi0... dub204.7.0.4.3 $4$DUA204 (GRN70A) RA72 dub206.7.0.4.3 $4$DUA206 (GRN70A) RA72 dub208.7.0.4.3 $4$DUA208 (GRN70A) RA72 >>>

   
   In this example:

   • DUA204 is the system disk device.
   • DUA208 is the DOSD device.
3. To provide two paths to the system disk, with the dump disk as DUA208 (also with two paths), set DUMP_DEV as follows:

   >>> SET DUMP_DEV dua208.4.0.2.3,dub208.7.0.4.3,dub204.7.0.4.3,dua204.4.0.2.3

   
   In this example, dua208.4.0.2.3 and dub208.7.0.4.3 are paths to the dump device; dub204.7.0.4.3 and dua204.4.0.2.3 are paths to the boot device.

   Note The system chooses the first valid device that it finds in the list as the dump device. Therefore, the dump disk path entries must appear before the system disk entries in the list.

4. Display all environment variables on the system by entering the SHOW * command; for example:

   >>> SHOW *

   auto_action HALT baud 9600 boot_dev dua204.4.0.2.3 boot_file boot_osflags 0,0 boot_reset ON bootdef_dev dub204.7.0.4.3,dua204.4.0.2.3 booted_dev dua204.4.0.2.3 booted_file booted_osflags 0,0 cpu 0 cpu_enabled ff cpu_primary ff d_harderr halt d_report summary d_softerr continue dump_dev dua208.4.0.2.3,dub208.4.0.4.3,dub204.7.0.4.3,dua204.4.0.2.3 enable_audit ON interleave default language 36 pal V5.48-3/O1.35-2 prompt >>> stored_argc 2 stored_argv0 B stored_argv1 dua204.4.0.2.3 system_variant 0 version T4.3-4740 Jun 14 2000 15:16:38 >>>

5. Enable the DOSD bit of the DUMPSTYLE system parameter by setting bit 2. For example, enter the value of 4 at the SYSBOOT> prompt to designate an uncompressed physical dump to an alternate disk with minimal console output:

   >>> BOOT SYSBOOT> SET DUMPSTYLE 4

The OpenVMS System Management Utilities Reference Manual and online help contain details about the DUMPSTYLE system parameter.

On VAX systems, DOSD has the following requirements:

• The system must be connected directly to, and must boot from, CI controllers.
• The dump device must physically connect to the same two HSx CI controllers as the boot device. These two controllers must be connected through the same CI star coupler.
• The dump device directory structure must resemble the current system disk structure. The [SYSn.SYSEXE]SYSDUMP.DMP file will reside there, with the same boot time system root.
  Use AUTOGEN to create this file. In the MODPARAMS.DAT file, the following symbol prompts AUTOGEN to create the file:

  DUMPFILE_DEVICE = "$nnn$ddcuuuu"

  
  You can list only one device.

• The volume label can be up to 12 characters long. The ASCII string DOSD_DUMP must be part of this volume label. For example, valid volume labels are DOSD_DUMP, DOSD_DUMP_12, 12_DOSD_DUMP. The label is read and retained in a memory boot data structure.
• The dump device cannot be part of a volume set. Compaq strongly recommends that the dump device also not be part of a shadow set.
• The dump device cannot be MSCP unit zero (0); only units 1 to 4095 (1---FFF) are supported.
  You can designate the dump device as follows:
  • On VAX 7000 configurations, by using bits 16 through 27 of the DUMPSTYLE system parameter. Note that the DUMP_DEV environment variable that is provided on VAX 7000 configurations is not used by OpenVMS VAX.
  • On configurations other than the VAX 7000, by using bits 16 through 27 of register 3 (R3). You can use this portion of the register to specify the dump device.
  
  The OpenVMS System Management Utilities Reference Manual and online help contain details about the DUMPSTYLE system parameter.

	privacy and legal statement
6017PRO_073.HTML