Document revision date: 19 July 1999

These calculations differ on OpenVMS VAX and Alpha systems:

On Alpha Systems

On Alpha systems, the AUTOGEN command procedure calculates the appropriate size of your error log dump file. However, to calculate the size of the file manually, use the following formula, which calculates the file size required to hold all the error log buffers:

size-in-blocks(SYS$SYSTEM:SYS$ERRLOG.DMP) = number-of-error-log-buffers * blocks-per-buffer + 2

where:

number-of-error-log-buffers	Is the value of the system parameter ERRORLOGBUFFERS. This parameter sets the number of error log buffers that are permanently allocated in memory.
blocks-per-buffer	Is the value of the system parameter ERLBUFFERPAGES. This parameter sets the number of pages of memory in each buffer.

On VAX Systems

On VAX systems, the size of the error log dump file depends on your use of dump off system disk (DOSD):

• Without DOSD, error logs are written to the dump file SYSDUMP.DMP on the system disk. See Section 15.4.1 for sizing information.
• With DOSD:
  • Both error logs and system memory are written to the SYSDUMP.DMP file on the DOSD disk. See Section 15.4.1 for sizing information.
  • In addition, error logs are written to the stub system dump file SYSDUMP.DMP on the system disk. Because this is a fixed-length file of 2048 blocks, no sizing calculations are required.

Sufficient page file space is critical to system performance. The AUTOGEN command procedure calculates an appropriate size for your page file space. The size calculated by AUTOGEN should be sufficient. However, to manually calculate the size for page file space, use one of the following formulas.

On VAX Systems

On VAX systems, use the following formula:

size-in-blocks (total for all page files on the system) = size-of-average-process (in pages) * maximum-number-of-processes

• The size-of-average-process is the value of the average virtual size of the process. Use the following command to find it:

  $ SHOW PROCESS/CONTINUOUS/ID=pid

  
  Specify this value in blocks.

• The maximum-number-of-processes is the value of the MAXPROCESSCNT system parameter.

If the result of the formula is less than VIRTUALPAGECNT, use the value of VIRTUALPAGECNT instead.

To determine a system's virtual page count, enter the following command:

$ WRITE SYS$OUTPUT F$GETSYI ("VIRTUALPAGECNT")

On Alpha Systems

On Alpha systems, use the following formula:

size-in-blocks (total for all page files on the system) = physical-memory-size (in pagelets) + 8192 (supplementary amount)

To calculate the physical memory size in pagelets, follow these steps:

1. Enter the following command:

   $ SHOW MEMORY/PHYSICAL_PAGES

   
   The number of physical pages is listed in the Total column.

2. To compute the number of pagelets per page, divide the system page size by 512 (pagelet size). For example, a system with a page size of 8192 has 16 pagelets per page.
   To determine a system's page size, enter the following command:

   $ WRITE SYS$OUTPUT F$GETSYI ("PAGE_SIZE")

3. Multiply the number of pagelets per page by the number of physical pages. (The physical page value is in the Total column in the SHOW MEMORY/PHYSICAL_PAGES display.)

Adding 8192 to the physical memory size provides an extra margin of safety during periods of heavy paging activity.

After making the initial calculation, observe your system over time and make adjustments as necessary.

15.4.3.1 Representing Page File Size

The page file size you calculate can be represented in one of the following ways:

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

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 14.4 and Section 14.4.2.) The DCL command SHOW MEMORY/FILES also displays file usage, as explained in Section 15.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.

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

15.4.4.1 Representing Page 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 15.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 15-1 defines physical and selective dumps.
  Table 15-3 compares the information available in physical and selective system dump files.

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

  Type	Available Information	Unavailable Information
  Physical 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 14.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)
  By setting bit 2 of the DUMPSTYLE system parameter and by setting the environmental variable DUMP_DEV suitably, OpenVMS writes the system dump to a disk other than the system disk, as explained in Section 15.6.

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

15.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. Key processes:
   1. Current process on crash CPU
   2. Swapper
   3. Current processes on other CPUs
   4. Site-specific priority processes (see next section)
   5. Compaq-defined priority processes (hardcoded into BUGCHECK):
      • MSCPmount
      • AUDIT_SERVER
      • NETACP
      • NET$ACP
      • REMACP
      • LES$ACP
5. Key global pages (those that appear in the working set of any key process)
6. Other processes (the nonkey processes) resident at the time of the crash, in order by process index
7. Remaining global pages that appear in the working set of any nonkey 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 nonkey process.

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

On Alpha systems, a new category of processes, key processes, are dumped immediately following PT, S0/S1, and S2, including transition pages that link back. 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 or appears to be stuck in a miscellaneous wait state such as RWAST, the system manager can designate the process as a priority process and then force a crash.

15.6 Writing the System Dump File to an Alternate Disk

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

Requirements for writing the dump file off the system disk (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 writing DOSD on Alpha and VAX systems.

15.6.1 DOSD Requirements on Alpha Systems

On Alpha systems, writing the 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 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 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 15.8.
• 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, 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 1998 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 a full 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.

	privacy and legal statement
6017PRO_070.HTML