Document revision date: 30 March 2001

OpenVMS Alpha Version 7.1 and later contains system parameters that control the operation of bus-addressable pool (BAP). AUTOGEN sets these parameters correctly. If you choose to skip AUTOGEN, follow the instructions in this section to set the BAP parameters.

The CIPCA, CIXCD, KFMSB, and Qlogic 1020ISP adapters are the first among an expanding list of adapters to use bus-addressable pool (BAP). BAP is a non-paged dynamic, physical-address-filtered memory pool used to overcome I/O bus and 32-bit adapter physical addressing limits.

The following list contains the system parameters that control the operation of BAP:

• NPAG_BAP_MIN
• NPAG_BAP_MAX
• NPAG_BAP_MIN_PA
• NPAG_BAP_MAX_PA

If one or more system adapters use BAP, you must adjust the BAP system parameters after installing or upgrading the operating system: You can do this automatically using AUTOGEN with the FEEDBACK qualifier. The typical AUTOGEN with FEEDBACK command to set these parameters follows:

$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT FEEDBACK

If you prefer not to use this command because you want to adjust only the BAP parameters settings, you can use the following procedure:

1. Run SYS$SYSTEM:AGEN$FEEDBACK.EXE manually.
2. Search SYS$SYSTEM:AGEN$FEEDBACK.DAT for BAP_... values.
3. Run SYSGEN to set the following system parameters with the corresponding BAP_ values you obtained in Step 2:

   AGEN$FEEDBACK Data	System Parameter	Units
   BAP_MIN	NPAG_BAP_MIN	bytes
   BAP_MAX	NPAG_BAP_MAX	bytes
   BAP_MIN_PA	NPAG_BAP_MIN_PA	Mb. PA 1
   BAP_MAX_PA	NPAG_BAP_MAX_PA	Mb. PA 1

   ---

   ¹PA represents the memory physical address value.
   

   ---

The BAP allocation amount depends on the adapter type, the number of adapters, and the version of the operating system. The size of physical memory and the I/O bus determine whether the BAP remains separate or is merged with normal nonpaged dynamic memory (NPAGEDYN).

The general rule that determines whether BAP remains separate follows:

• PCI adapters using BAP: separate if physical memory > 1 GB
• XMI adapters using BAP: separate if physical memory > 4 GB

For systems whose BAP is merged with nonpaged pool, the initial amount and maximum amount of nonpaged pool (as displayed by the DCL command SHOW MEMORY/POOL/FULL) do not match the value of the NPAGEDYN and NPAGEVIR system parameters. Instead, the value of the NPAG_BAP_MIN system parameter is added to NPAGEDYN to determine the initial size, and the value of NPAG_BAP_MAX is added to NPAGEVIR to determine the maximum size.

On OpenVMS systems with merged BAP, the values of the NPAGEDYN... system parameters typically need to be increased. After your system has been running a few days, you can adjust these values by one of the following three methods:

• Use AUTOGEN with the FEEDBACK qualifier which will automatically adjust the values of the NPAGEDYN... system parameters.
• Use the DCL command SHOW MEM/POOL/FULL to analyze NPAGEDYN/BAP pool utilization. Then change the values of the NPAGEDYN... system parameters with SYSGEN, based on the results of this command.
• Run SYS$SYSTEM:AGEN$FEEDBACK.EXE as previously described. Check the AGEN$FEEDBACK.DAT file for the feedback results for the NPAGEDYN... system parameters and adjust them accordingly, using SYSGEN.

Page, swap, and dump files are created by default. However, you should understand these files. In addition, you might want to change them to meet the needs of your site.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Displaying information about page and swap files	Section 16.3
Calculating appropriate sizes for files	Section 16.4
Minimizing dump file size when disk space is insufficient	Section 16.5
Writing a dump file on a system disk with multiple paths or shadow set members	Section 16.6
Writing the dump file to a device other than the system disk	Section 16.7
Using SDA to analyze the contents of a crash dump	Section 16.8
++Using SDA CLUE commands to obtain and analyze summary crash dump information	Section 16.9
+Using CLUE to obtain historical information about crash dumps	Section 16.10
Saving the contents of the system dump file after a system failure	Section 16.11
Copying dump files to tape or disk	Section 16.12
Freeing dump information from the page file	Section 16.13
Installing page and swap files	Section 16.14
Removing page, swap, and dump files	Section 16.15
Creating and modifying page, swap, and dump files	Section 16.16
Controlling access to process dumps	Section 16.17.2

This chapter explains the following concepts:

Concept	Section
Understanding dump files	Section 16.1
Understanding page and swap files	Section 16.2
Understanding the order of information in a selective system dump	Section 16.5.1
++Understanding SDA CLUE	Section 16.9.1
+Understanding CLUE	Section 16.10.1
Understanding process dumps	Section 16.17

When the operating system detects an unrecoverable error or an inconsistency within itself that causes the system to fail, it writes the contents of the error log buffers, processor registers, and memory into the system dump file, overwriting its previous contents.

The contents of error log buffers are also written to the error log dump file. The error log dump file is provided so that the system can be updated on reboot to include error log entries that were created but not written at the time of a system crash.

System Dump File

When writing the system dump file, the system displays console messages and information about the error or inconsistency. The last message tells you that the dump file was successfully written.

Console messages and the system dump file are important sources of information in determining the cause of a system failure. Use the contents in the following ways:

• Use the System Dump Analyzer utility (SDA) to analyze the contents of the dump and determine the cause of a failure.
• On Alpha systems, use SDA CLUE commands to obtain and analyze summary dump file information.
• On VAX systems, use CLUE to obtain historical information from system dump files.
• Contact your Compaq support representative, indicating that you have made a copy of the contents of the system dump.

The default system dump file, SYS$SPECIFIC:[SYSEXE]SYSDUMP.DMP, is created during installation. (You do not need a system dump file to run the operating system. However, you must have a system dump file to diagnose system crashes.) AUTOGEN automatically determines an appropriate size for the system dump file for your hardware configuration and system parameters. Refer to Section 16.5 for information about minimizing system dump file size if disk space is insufficient.

For special configurations or varying work loads, you can change the size of the system dump file. For information, see Section 16.16.1. You can write the system dump file on a disk other than the system disk. This is referred to as dump off system disk (DOSD). For more information, see Section 16.7.

Error Log Dump File

AUTOGEN creates the error log dump file during installation; its size depends on your configuration and system parameters. Error log dump files on VAX and Alpha systems have the following differences:

• On Alpha systems, the error log dump file is called SYS$ERRLOG.DMP; it is located on the system disk. When an operator initiates a shutdown, the system writes the contents of error log buffers to the error log dump file and not to the system dump file. Thus, the last system crash dump is not overwritten.
• On VAX systems, the error log dump file is called SYSDUMP.DMP. How the system handles this file depends on whether you are using dump off system disk (DOSD):
  • With DOSD, error logs are written to a stub error log dump file, SYSDUMP.DMP, on the system disk. Also, both the error logs and system memory are written to the SYSDUMP.DMP file on the DOSD disk.
  • Without DOSD, both the error log and system memory are written to the SYSDUMP.DMP file on the system disk.
  
  On VAX systems with or without DOSD, the last system crash dump is always overwritten when an operator initiates a shutdown.

The operating system uses the latest version of SYS$SYSTEM:SYSDUMP.DMP to store system crash dumps. If SYSDUMP.DMP does not exist in SYS$SYSTEM, the operating system uses the system page file, SYS$SYSTEM:PAGEFILE.SYS, overwriting the contents of that file.

If the SAVEDUMP system parameter is set, the crash dump is retained in PAGEFILE.SYS when the system is booted. If SAVEDUMP is clear, the system uses the page file for paging; any dump written to the page file is lost.

If you use SYS$SYSTEM:PAGEFILE.SYS to capture system crash dumps, you should later free the space occupied by the dump for use in system paging, with either of the following methods:

• Use the SDA COPY command to copy the dump from the page file to a different file.
• Use the SDA RELEASE command to delete the information from the page file.

For detailed instructions, see Section 16.13.

Include the appropriate commands in the SYSTARTUP_VMS.COM startup command procedure to free dump information from the page file each time the system reboots.

The two types of system dumps are physical and selective. Table 16-1 defines physical and selective system dumps. Table 16-3 compares the information available in physical and selective system dump files.

Table 16-1 Definitions of Physical and Selective System Dumps

Type	Description
Physical dump	Writes the entire contents of physical memory to the system dump file. To ensure a useful physical dump, the system dump file must be large enough to contain all of physical memory.
Selective dump	Stores those portions of memory most likely to be useful in crash dump analysis. A selective system dump is useful when disk space is not available to hold all of physical memory.

Requirements for Creating a Useful System Dump

The following requirements must be met for the operating system to write a useful system dump file:

• The system parameter DUMPBUG must be set to 1 (the default value).
• If the system parameter SAVEDUMP is set to 0 (the default) the file SYS$SPECIFIC:[SYSEXE]SYSDUMP.DMP must exist on the system disk.
• If the file SYS$SPECIFIC:[SYSEXE]SYSDUMP.DMP does not exist on the system disk, the page file must be used to store the dump. The system parameter SAVEDUMP must be set to 1 and the file SYS$SPECIFIC:[SYSEXE]PAGEFILE.SYS must exist on the system disk.
• If the file SYS$SPECIFIC:[SYSEXE]SYSDUMP.DMP does not exist and SYS$SPECIFIC:[SYSEXE]PAGEFILE.SYS is not available for system dumps, you must create the dump file on an alternate disk (see Section 16.7).
• If sufficient disk space is not available to allow a system dump file that can hold all of memory, the system parameter DUMPSTYLE must be set to the appropriate value to store a selective system dump. For more information, refer to Section 16.5 and the OpenVMS System Management Utilities Reference Manual.
• The system dump file (or page file if the SAVEDUMP system parameter is set) must be large enough to hold all information that is to be written if the system fails.
  If the system parameter DUMPBUG is set, AUTOGEN automatically sizes SYSDUMP.DMP if enough disk space is available.
  If the system parameter SAVEDUMP is set, AUTOGEN performs no operations on the system dump file.
  AUTOGEN sizes the page file only for paging use, regardless of whether the SAVEDUMP system parameter is set.

BACKUP Considerations

A system dump file has the NOBACKUP attribute; therefore, the Backup utility (BACKUP) does not copy the file unless you use the qualifier /IGNORE=NOBACKUP when invoking BACKUP. When you use the SDA COPY command to copy the system dump file to another file, the operating system does not automatically set the new file to NOBACKUP. If you want to set the NOBACKUP attribute on the copy, use the SET FILE command with the /NOBACKUP qualifier as described in the OpenVMS DCL Dictionary.

Security Considerations

By default, SYS$SYSTEM:SYSDUMP.DMP is protected against world access. Because a system dump file can contain privileged information, you should keep this level of protection on system dump files. Similarly, when you copy system dump files using the System Dump Analyzer utility (SDA) as explained in Section 16.11 and Section 16.13, be sure to protect the copy from world read access. For more information about file protection, refer to the OpenVMS Guide to System Security.

16.2 Understanding Page and Swap Files

As part of memory management, the operating system makes efficient use of physical memory by moving information between physical memory and files stored on disk. The system does this in two ways: paging and swapping. Table 16-2 defines these and related terms.

Table 16-2 Paging and Swapping Terminology

Term	Definition
Paging	A memory management operation that provides the efficient use of physical memory allotted to a process. Paging moves infrequently used portions of a process workspace out of physical memory to a file. For more information about paging, refer to the OpenVMS Performance Management manual.
Page file	The file to which the system writes paged portions of memory. The OpenVMS installation process creates a page file named SYS$SYSTEM:PAGEFILE.SYS. If necessary, you can use SYS$SYSTEM:PAGEFILE.SYS in place of the system crash dump file. For more information, see Section 16.1.1.
Swapping	A memory management operation that provides the efficient use of physical memory available for the entire system. Swapping moves the entire workspace of a less active process out of physical memory to a file. For more information about swapping, refer to the OpenVMS Performance Management manual.
Swap file	The file to which the system writes swapped portions of memory. The OpenVMS installation procedure creates a swap file named SYS$SYSTEM:SWAPFILE.SYS.
Primary page and swap files	The default page and swap files created during OpenVMS installation. These files are named SYS$SYSTEM:PAGEFILE.SYS and SYS$SYSTEM:SWAPFILE.SYS.
Secondary page and swap files	Additional page and swap files that you might create for performance or disk space reasons. If you kept the primary page and swap file on the system disk, the system uses the space in the secondary files for paging and swapping in addition to the space in the primary page and swap files. For information about creating secondary page and swap files, see Section 16.16.

Installing Files

Page and swap files must be installed before the system can use them. The system automatically installs the latest versions of SYS$SYSTEM:PAGEFILE.SYS and SWAPFILE.SYS during startup. If you create secondary page and swap files, you must make sure the system installs them during startup. For more information about installing page and swap files, see Section 16.14.

File Sizes and Locations

AUTOGEN automatically determines appropriate sizes for the files for your hardware configuration and system parameters. For special configurations or varying work loads, you might want to change the size of the page or swap file. For information, see Section 16.16.1.

If your system does not require the page file for storing system crash dumps, you can move it off the system disk. However, you should keep one page file on the system disk, if possible, so that you can boot the system if another disk holding the page files becomes unavailable. The swap file can also be moved off the system disk.

	privacy and legal statement
6017PRO_070.HTML