Adjusting System Parameters

The OpenVMS System Generation (SYSGEN) utility maintains system parameters and system files. The following table summarizes SYSGEN parameters which control resources directly used by GT.M.

SYSGEN PARAMETER

GT.M CONSIDERATIONS

GBLPAGES

For the run-time libraries: 1500 pages VAX

4000 pages AXP

For each simultaneously installed GT.M application image: 1 page per block

For each BG segment: ((blocksize/512) * .7) * #global_buffers + 2150 + lock_space

For each MM segment: (File_size + journal_buffer_size + lock_space + 2) pages

GBLPAGFIL*

For each BG segment:

((global_buffer_count * block_size/512) + global_buffer_count/10 + journal_buffer_size + lock_space + 29) pages + 2150 + lock_space

For each MM segment: (journal_buffer_size + lock_space + 2) pages

GBLSECTIONS

For the run-time libraries: 7 sections

For each simultaneously installed GT.M application image: 2 sections

For each simultaneously active BG database segment: 1 section

For each simultaneously active MM database segment: 2 sections

NOTE: The number of concurrent users of any given file does not effect these requirements

LOCKIDTBL

For each simultaneously active

GT.M process: 3

database segment: 1

database journal: 1

RESHASHTBL

LOCKIDTBL/4 rounded up to the nearest power of 2

VIRTUALPAGECNT

(VAX only)

For the run-time libraries: 1500 pages

For the largest GT.M image (including ZLINKed routines) : 1 page/block

For the process that uses the largest amount of memory: sufficient data space

For the sum of all BG segments accessed by the process that uses the largest amount of memory:

((global_buffer_count * block_size /512) + global_buffer_count/10 + lock_space + 29) pages

For the sum of all MM segments accessed by the process that uses the largest amount of memory:

(File_size + lock_space + 2) pages

To calculate an exact impact of GT.M databases on the SYSGEN parameter GBLPAGFIL, add the total number of pages of all active GT.M database sections (those names starting with GTM$S_) on the INSTALL LIST/GLOBAL output.

For example:

GT$S_$1$DIA0$7F2076A00000
(00000000) WRT DZRO PRM SYS Pagcnt/Refcnt=9441/37764
GT$S_$1$DIA1$C9E7E2000000
(00000000) WRT DZRO PRM SYS Pagcnt/Refcnt=512/3072
GT$S_$1$DIA1$348932000000
(00000000) WRT DZRO PRM SYS Pagcnt/Refcnt=224/2240
GT$S_$1$DIA0$7F2046A00000
(00000000) WRT DZRO PRM SYS Pagcnt/Refcnt=9441/0

The total page count for these sections is 19618 (9441+512+224+9441).

In addition to the SYSGEN parameters in the table above, the following parameters may have a critical effect on proper operation of OpenVMS and GT.M:

NPAGEDYN

This parameter controls the amount of non-paged dynamic memory available to the system. If NPAGEDYN is too small, OpenVMS performance becomes very poor. A necessarily large NPAGEDYN deprives users of working space. NPAGEDYN can be set empirically by starting with a generous value, then monitoring the use of the memory it provides, and adjusting it as needed.

SYSMWCNT

This parameter controls the target size for the system working set. Because GBLPAGES are in the system working set, coordinate SYSMWCNT revisions with changes in GBLPAGES. If you use AUTOGEN, it changes the SYSMWCNT by one (1) for each 128 pages of change in GBLPAGES. Values of SYSMWCNT that are not matched to the configuration can cause such severe OpenVMS thrashing that response times for simple tasks may be measured in hours.

WSMAX

This parameter controls the largest working set permitted for the system. M string facilities and GT.M local variables, which are essentially limited only by OpenVMS address space, usually lead to images which require large working sets. Such working sets are categorized in the OpenVMS documentation as typical of AI applications. Working sets can also be set empirically by starting with a large value, monitoring actual usage by a range of users and adjusting as needed.

For more information on system parameters, refer to the OpenVMS System Management Utilities Reference Manual. For more information on OpenVMS tuning, refer to the OpenVMS Performance Management Manual.

Setting Page File Size

Ensuring continuous operation of any OpenVMS system depends on having a page file of adequate size. A conservative approach to this issue is to establish a very large page file of 300,000 to 400,000 pages, monitor its use, and reduce it based on empirical evidence. Generally, the page file requires around 100,000 pages or less. Consider the use of secondary page files to balance your disk channel usage. For information on monitoring and managing page faulting, refer to the OpenVMS Performance Management Manual.

For Alpha, the page file should be the physical memory size ((in megabytes) + 8192). Refer to the OpenVMS System Manager manual for more information.

For VAX, the page file should be the size of the average process multiplied by the maximum number of processes. If the VIRTUALPAGECNT system parameter is larger, use that value.

Invoking AUTOGEN

AUTOGEN is a command procedure supplied by Compaq/HP that attempts to ensure that SYSGEN parameters fall within HP's(formerly Compaq) recommended limits. AUTOGEN performs the valuable task of propagating changes to interrelated parameters. When you change a parameter related to some other parameter AUTOGEN analyzes your modifications and adjusts related parameters.

Set the system parameters by specifying them in your SYS$SYSTEM:MODPARAMS.DAT file and invoke AUTOGEN in SYS$UPDATE. Some parameters take effect immediately, while others take effect only after you reboot the system.

Example:

$ SET DEFAULT SYS$SYSTEM
$ CREATE MODPARAMS.DAT
MIN_GBLPAGES = 50000
MIN_GBLPAGFIL = 40000
MIN_GBLSECTIONS = 100
MIN_VIRTUALPAGECNT = 600000
MIN_WSMAX = 4096
<CTRL-Z>
$ SET DEFAULT SYS$UPDATE
$ @AUTOGEN GETDATA REBOOT NOFEEDBACK

In this example, the DCL command SET DEFAULT sets the default to the directory specified by the logical name SYS$SYSTEM. SYS$SYSTEM contains files processed by AUTOGEN.

The DCL command CREATE creates the MODPARAMS.DAT file and inserts each separate line following the command as a record of the new file. Pressing <CTRL-Z> signals the end of the input.

The DCL command SET DEFAULT sets the default to the directory specified by the logical name SYS$UPDATE. Invoking AUTOGEN from the system manager's account ensures that you have the required privileges. GETDATA is an AUTOGEN start-phase which collects all data required by the AUTOGEN system generation phases. REBOOT is the AUTOGEN end-phase that reboots the system to allow some parameters to take effect. NOFEEDBACK is an execution type which tells AUTOGEN not to use feedback information gathered from the system.

For more information on AUTOGEN, refer to the OpenVMS System Management Utilities Reference Manual.

Enabling Virtual Terminal Operation

To prevent application problems, dial-up lines that may be accidentally disconnected are often configured so that they can be physically disconnected without terminating the process. This presents a security risk, as a user can connect to the process simply by connecting to the line without having to login. Virtual terminals can be used to improve security on such lines because they only allow access to a disconnected process after going through the standard login procedure with the owner's name.

Virtual terminals also allow spawned processes to be controlled from a single terminal. Multiple independent processes can be controlled from a single terminal as well. Virtual terminals require some additional overhead. Refer to the OpenVMS documentation for more information.

Perform the following actions to enable virtual terminal operation, usually in SYS$MANAGER:SYSTARTUP_VMS.COM. See SYS$MANAGER:SYSTARTUP_VMS.TEMPLATE.

  • For VAX, invoke SYSGEN and issue the command connect/noadapter vta0/driver=ttdriver.

  • For Alpha, invoke SYSMAN 10 and issue the command connect VTA0 /noadapter/driver=sysloadable_images=ttdriver

  • In SYSGEN, set bit 17 of TTY_DEFCHAR2 ON to enable virtual terminals for all lines or OFF to disable them.

  • Issue the command: set term/perm/ [no]disconnect to adjust individual terminals with respect to the default.

Refer to your TCP/IP package's documentation for instructions on how to enable virtual terminals for the TELNET connection.