Document revision date: 19 July 1999

Use the MIN_ prefix if you do not want AUTOGEN to set a parameter below a specified value. MIN_ refers to the minimum value to which a parameter can be set by AUTOGEN. The following example sets the minimum value to 400,000:

MIN_PAGEDYN = 400000

14.5.1.3 Specifying a Maximum Value with the MAX_ Prefix

Use the MAX_ prefix if you do not want AUTOGEN to set a parameter above a specified value. MAX_ refers to the maximum value to which a parameter can be set by AUTOGEN. The following example sets the maximum value to 400,000:

MAX_PAGEDYN = 400000

14.5.1.4 Specifying an Absolute Value

Use this method to specify a value for a parameter that AUTOGEN does not calculate. (Refer to the AUTOGEN section of the OpenVMS System Management Utilities Reference Manual for a table of the system parameters modified in AUTOGEN calculations.)

To specify an absolute parameter value, add an assignment statement in the following format to MODPARAMS.DAT:

parameter = parameter-value ! comment

For example, the following command assigns the node name BIGVAX to the SCSNODE parameter:

SCSNODE = "BIGVAX" ! the node name

14.5.1.5 Defining the Number of VAXcluster Nodes (VAX Only)

In a VAXcluster environment, use the NUM_NODES symbol to prevent temporary changes in VAXcluster membership from affecting AUTOGEN's calculation of VAXcluster-related parameter values. Define the NUM_NODES symbol in MODPARAMS.DAT to specify the number of nodes that are to run in the VAXcluster. AUTOGEN uses this value to set parameters that are affected by the number of VAXcluster nodes. For example, include the following line in MODPARAMS.DAT:

NUM_NODES = 30

14.5.1.6 Defining the Number of Ethernet Adapters (VAX Only)

In a VAXcluster environment, define the NUM_ETHERADAPT symbol in MODPARAMS.DAT to specify the total number of Ethernet adapters in the VAXcluster system. For example, include the following line in MODPARAMS.DAT:

NUM_ETHERADAPT = 40

14.5.1.7 Presetting Parameter Values Before Adding Memory (VAX Only)

On VAX systems, if you plan to upgrade your system hardware by adding a large amount (512 MB or more) of memory, you might want to preset your system parameters to values appropriate for the additional memory. Presetting your system parameters minimizes the possibility of memory upgrade problems caused by inappropriate parameter values.

How to Perform This Task

Perform the following steps:

1. Add a line to SYS$SYSTEM:MODPARAMS.DAT in the following format:

   MEMSIZE = total-number-of-pages-of-memory-after-upgrade

   
   For example:

   MEMSIZE = 2048 * 1024 ! (2048 page per MB * 1GB of memory)

2. Run AUTOGEN to the SETPARAMS phase.
3. Perform the hardware upgrade to add the additional memory.
4. Edit MODPARAMS.DAT to remove the line added in step 1.

To override AUTOGEN's observations regarding the presence (or absence) of DECnet, set the MODPARAMS.DAT parameter LOAD_DECNET_IMAGES to TRUE (or FALSE). Controlling the setting is useful for sites that have no synchronous network hardware but want to run asynchronous DECnet.

14.5.1.9 Values Set for NPAGEDYN and NPAGEVIR

For the benefit of OpenVMS VAX systems with limited physical memory, AUTOGEN logs a warning message in its report if NPAGEDYN exceeds 10 percent of physical memory or if NPAGEVIR exceeds 33 percent of physical memory.

AUTOGEN also limits its own calculated value for NPAGEDYN to 20 percent of physical memory, and limits NPAGEVIR to 50 percent of physical memory. These calculated values are adequate for most workstations and systems with 16 or fewer megabytes of physical memory. If your system requires a larger value, you can override the AUTOGEN calculated values by setting higher values in MODPARAMS.DAT.

14.5.2 Specifying a Minimum Required Age for Feedback (VAX Only)

On VAX systems, AUTOGEN feedback is useful only when a system has been running long enough to accurately reflect the system's normal work load. By default, AUTOGEN uses feedback if the data is older than 24 hours. On VAX systems, you can define the logical name AGEN$FEEDBACK_REQ_TIME to specify, in hours, a different minimum age required for feedback. AUTOGEN uses this value to determine whether the feedback is to be used.

For example, you might define the logical name as follows, to indicate that AUTOGEN should use feedback if it is older than 19 hours:

$DEFINE/SYSTEM AGEN$FEEDBACK_REQ_TIME 19

To define this logical name each time the system starts up, add this command to SYLOGICALS.COM.

14.5.3 Including an External Parameter File in MODPARAMS.DAT

You can include external parameter files in MODPARAMS.DAT. For example, you might want to set a system parameter to the same value on all nodes in a VAXcluster or an OpenVMS Cluster environment; you might also want to specify node-specific values for other system parameters. You could specify the cluster-common values in a separate cluster-common file and include this cluster-common file in the MODPARAMS.DAT file on each system in the cluster.

To include a parameter file, place a command in the following format in MODPARAMS.DAT, or in any parameter file that is included in MODPARAMS.DAT:

AGEN$INCLUDE_PARAMS full-directory-spec:filename

Example

To include a cluster-common parameter file named CLUSTERPARAMS.DAT, create a common parameter file with the following name:

• SYS$COMMON:[SYSEXE]CLUSTERPARAMS.DAT

Add the following line in the MODPARAMS.DAT file in the system-specific directory of each cluster:

AGEN$INCLUDE_PARAMS SYS$COMMON:[SYSEXE]CLUSTERPARAMS.DAT

14.5.4 Turning Off Logging of DCL Statements

The contents of MODPARAMS.DAT are evaluated as DCL statements; you can make assignments to symbols with names that are not system parameters (for example, scratch variables or conditional assignments based on other values). Traditionally, every such assignment is logged in AGEN$PARAMS.REPORT, sometimes creating a large file with many logging statements that do not interest users.

You can prefix any assignments that you prefer not to log in AGEN$PARAMS.REPORT with a dollar sign ($). When AUTOGEN encounters a MODPARAMS.DAT record beginning with a dollar sign, it does not check the list of known system parameters and does not log this record to AGEN$PARAMS.REPORT.

14.6 Automating AUTOGEN Reports

Compaq recommends that you create a batch-oriented command procedure to automatically run AUTOGEN on a regular basis and send the resulting feedback reports to an appropriate Mail account. Example 14-2 provides a sample command procedure.

The command procedure in Example 14-2 runs two passes of AUTOGEN. On the first pass, AUTOGEN runs during peak workload times to collect data on realistic system work loads. This pass does not degrade system performance. On the second pass, AUTOGEN runs during off-peak hours to interpret the data collected in the first stage.

The procedure sends the resulting report, contained in the file AGEN$PARAMS.REPORT, to the SYSTEM account. Review this report on a regular basis to see whether the load on the system has changed.

Example 14-2 shows a sample command procedure. Use this procedure only as an example; create a similar command procedure as necessary to meet the needs of your configuration.

Example 14-2 Sample AUTOGEN Command Procedure

$ BEGIN$: ! ++++++++++ AGEN_BATCH.COM ++++++++++ $ on warning then goto error$ $ on control_y then goto error$ $! $! Setup process $! $! Set process information $ set process/priv=all/name="AUTOGEN Batch" $! Keep log files to a reasonable amount $ purge/keep=5 AGEN_Batch.log $ time = f$time() ! Fetch current time $ hour = f$integer(f$cvtime(time,,"hour")) ! Get hour $ today = f$cvtime(time,,"WEEKDAY") ! Get Day of the week $ if f$integer(f$cvtime(time,,"minute")) .ge. 30 then hour = hour + 1 $! $! Start of working day... $! $ 1AM$: $ if hour .le. 2 $ then $ next_time = "today+0-14" $ gosub submit$ ! Resubmit yourself $ set noon $! $! Run AUTOGEN to TESTFILES using the parameter values collected earlier $! in the day (i.e., yesterday at 2:00pm) $ if today .eqs. "Tuesday" .OR. today .eqs. "Thursday" .OR. - today .eqs. "Saturday" $ then $ @sys$update:autogen GETDATA TESTFILES feedback (2) $ mail/sub="AUTOGEN Feedback Report for system-name" - sys$system:agen$params.report system (3) $ ! Clean up $ purge/keep=7 sys$system:agen$feedback.report (4) $ purge/keep=7 sys$system:agen$feedback.dat $ purge/keep=7 sys$system:params.dat $ purge/keep=7 sys$system:autogen.par $ purge/keep=7 sys$system:setparams.dat $ purge/keep=7 sys$system:agen$addhistory.tmp $ purge/keep=7 sys$system:agen$addhistory.dat $ endif $ goto end$ $ endif $! $ 2PM$: $ if hour .le. 15 $ then $ next_time = "today+0-17" $ gosub submit$ $ if today .eqs. "Monday" .OR. today .eqs. "Wednesday" .OR. - today .eqs. "Friday" $ then $ @sys$update:autogen SAVPARAMS SAVPARAMS feedback (1) $ endif $ goto end$ $ endif $! $ 5PM$: $ if hour .le. 18 $ then $ next_time = "tomorrow+0-1" $ gosub submit$ $ endif $! $! End of working day... $! $ END$: ! ---------- BATCH.COM ---------- $ exit $!++ $! Subroutines $!-- $! $ SUBMIT$: $ submit/name="AGEN_Batch"/restart/noprint - (5) /log=AGEN_batch.log - /queue=sys$batch/after="''next_time'" sys$system:AGEN_batch.com $ return $!++ $! Error handler $!-- $ ERROR$: $ mail/sub="AGEN_BATCH.COM - Procedure failed." _nl: system $ goto end$

The commands in this procedure perform the following tasks:

1. Executes the first pass of AUTOGEN during peak workload times to collect data on realistic work loads. This command runs a very fast image so it does not degrade system response.
2. Executes the second pass of AUTOGEN during off-peak hours to interpret the data collected in the first pass.
3. Mails the resulting report file named AGEN$PARAMS.REPORT to the SYSTEM account.
4. Cleans up the files created.
5. Resubmits the command procedure.

If the command procedure report described in Section 14.6 shows AUTOGEN's calculations are different from the current values, correct the tuning by executing AUTOGEN with one of the two following commands:

• If the system can be shut down and rebooted immediately, execute the following command:

  $ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK

• If the system cannot be shut down and rebooted immediately, execute the following command to reset the system parameters:

  $ @SYS$UPDATE:AUTOGEN GETDATA SETPARAMS FEEDBACK

  The new parameters will take effect the next time the system boots.

SYSMAN provides the ability to inspect and modify system parameters for an entire cluster or for any group of nodes, rather than just one system. The PARAMETERS commands available in SYSMAN duplicate the parameter functions of the System Generation utility (SYSGEN).

You can use SYSMAN to manage system parameters as follows:

Task	For More Information
Show parameter values	Section 14.7.2
Modify current values in the parameter file	Section 14.7.3
Modify active values on a running system 1	Section 14.7.4

SYSMAN provides the commands and functions shown in Table 14-3.

Table 14-3 SYSMAN PARAMETERS Commands

Command	Function
PARAMETERS SHOW	Displays parameter values. Requires the name of the parameter.
PARAMETERS USE	Reads a set of parameters from memory or disk into the work area for inspection or modification. Requires a file name or the additional parameters ACTIVE or CURRENT.
PARAMETERS SET	Changes parameter values only in the work area; more permanent modification requires the PARAMETERS WRITE command. Requires the name and value of the parameter.
PARAMETERS WRITE	Writes the content of the work area to memory or to disk. Requires a file name or the additional parameters ACTIVE or CURRENT.

For more information about the temporary work area, see the next section.

14.7.1 Understanding Parameter Values and SYSMAN

It helps to understand the different system parameter values explained in Section 14.1.1. Briefly, current values are stored in the default parameter file on disk. Active values are stored in memory and are used while the system is running. In addition to these values, SYSMAN writes a temporary copy into its own work area on disk. Figure 14-2 illustrates these different sets of values and how SYSMAN commands affect them. In this figure:

1. WRITE ACTIVE writes temporary parameter values to memory.
2. USE ACTIVE reads values from memory into the work area, where you can modify them.
3. WRITE CURRENT writes temporary parameter values to disk, where they become current values. They become active the next time the system boots.
4. USE CURRENT reads the current values from disk into the work area, where you can modify them.

Figure 14-2 SYSMAN Temporary, Active, and Current Parameter Values

During a typical session, you can display and change values in the following sequence:

1. Read values into SYSMAN's temporary work space with the USE command. USE ACTIVE reads in active values. USE CURRENT reads in current values.
2. Display the parameter values with the SHOW command.
3. Change a value with the SET command. You must use the WRITE command to activate the value.
4. Make the change effective with the WRITE command:
   • WRITE ACTIVE writes the value to the set of active values. (You can change an active value only if the parameter is a dynamic parameter.)
   • WRITE CURRENT writes the value to the set of current values.

For a list of all the system parameters, refer to the OpenVMS System Management Utilities Reference Manual.

14.7.2 Showing Parameter Values with SYSMAN

Use the SYSMAN command PARAMETERS SHOW to display parameter values for all the nodes in a cluster.

Examples

1. The following example shows one method to display information about parameters. In this case, using the /LGI qualifier displays all login security control parameters. You can display many categories of parameters, such as /ACP, /ALL, and /SPECIAL. Refer to the OpenVMS System Management Utilities Reference Manual for a complete list of parameters and parameter categories.

   $ RUN SYS$SYSTEM:SYSMAN SYSMAN> PARAMETERS SHOW/LGI Parameters in use: Active Parameter Name Current Default Min. Max. Unit Dynamic -------------- ------- ------- ------- ------- ---- ------- LGI_BRK_TERM 0 1 0 1 Boolean D LGI_BRK_DISUSER 0 0 0 1 Boolean D LGI_PWD_TMO 30 30 0 255 Seconds D LGI_RETRY_LIM 3 3 0 255 Tries D LGI_RETRY_TMO 20 20 0 255 Seconds D LGI_BRK_LIM 5 5 0 255 Failures D LGI_BRK_TMO 300 300 0 -1 Seconds D LGI_HID_TIM 300 300 0 -1 Seconds D

2. The following example invokes SYSMAN and specifies the environment to be the local cluster, which consists of NODE21 and NODE22. The example also displays the active value for the LGI_BRK_TMO parameter, which controls the number of seconds that a user, terminal, or node is permitted to attempt login. In this case, it is 600.

   $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER %SYSMAN-I-ENV, Current command environment: Clusterwide on local cluster Username MORIN will be used on nonlocal nodes SYSMAN> PARAMETERS SHOW LGI_BRK_TMO Node NODE21: Parameters in use: ACTIVE Parameter Name Current Default Minimum Maximum Unit Dynamic -------------- ------- ------- ------- ------- ---- ------- LGI_BRK_TMO 600 300 0 -1 Seconds D Node NODE22: Parameters in use: ACTIVE Parameter Name Current Default Minimum Maximum Unit Dynamic -------------- ------- ------- ------- ------- ---- ------- LGI_BRK_TMO 600 300 0 -1 Seconds D

Use the SYSMAN command PARAMETERS WRITE to write system parameter values and the name of the site-independent startup command procedure to your choice of parameter file or the current system parameter file on disk.

The PARAMETERS WRITE CURRENT command sends a message to OPCOM to record the event, unless you have changed the system message format with the DCL command SET MESSAGE.

Examples

1. The following example creates a new parameter specification file:

   SYSMAN> PARAMETERS WRITE SYS$SYSTEM:NEWPARAM

2. When used with the PARAMETERS SET command, the PARAMETERS WRITE command modifies the current system parameter file on disk:

   SYSMAN> PARAMETERS SET LGI_BRK_TMO 300 SYSMAN> PARAMETERS WRITE CURRENT

	privacy and legal statement
6017PRO_067.HTML