OpenVMS System Manager's Manual

Example

The following example includes several commands used to fix problems preventing the deletion of a queue:

 
$ DELETE/QUEUE JADE_BATCH (1)
%DELETE-E-NOTDELETED, error deleting JADE_BATCH 
-JBC-E-QUENOTSTOP, queue must be stopped to perform operation (2)
$ STOP/QUEUE/NEXT JADE_BATCH (3)
$ DELETE/QUEUE JADE_BATCH (4)
%DELETE-E-NOTDELETED, error deleting JADE_BATCH (5)
-JBC-E-REFERENCED, existing references prevent deletion
$ SHOW QUEUE/FULL
   .
   .
   .
Generic batch queue CLUSTER_BATCH (6) 
  /GENERIC=(JADE_BATCH,RUBY_BATCH,OPAL_BATCH) /OWNER=[SYSTEM] 
  /PROTECTION=(S:M,O:D,G:R,W:R) 
   .
   .
   .
$ STOP/QUEUE/NEXT CLUSTER_BATCH (7)
$ START/QUEUE CLUSTER_BATCH/GENERIC=(RUBY_BATCH,OPAL_BATCH)(8)
$ DELETE/QUEUE JADE_BATCH (9)  
 

This example does the following:

1. The DELETE/QUEUE command attempts to delete the queue.
2. The message indicates that the queue is not stopped.
3. The STOP/QUEUE/NEXT command stops the queue after allowing the current job to complete.
4. The DELETE/QUEUE command again attempts to delete the queue.
5. This time, the message indicates that references to the queue exist.
6. The SHOW QUEUE/FULL command shows information about all queues. However, the only reference to JADE_BATCH names the queue as a target queue for the generic queue CLUSTER_BATCH.
7. The STOP/QUEUE/NEXT command stops the generic queue that targets JADE_BATCH.
8. The START/QUEUE command eliminates the reference to JADE_BATCH by restarting the generic queue without specifying JADE_BATCH as a target.
9. The DELETE/QUEUE command successfully deletes the queue.

To delete a file using the PRINT/DELETE or SUBMIT/DELETE command, the clusterwide queue manager process must have access to the file specified. Otherwise, the file is printed or submitted but not deleted.

You can ensure that the PRINT/DELETE or SUBMIT/DELETE command deletes the specified files by mounting the disks on which the files reside clusterwide. To mount a disk clusterwide, use the /CLUSTER qualifier with the MOUNT command.

However, if your operating environment does not allow you to mount a disk clusterwide, you can resolve this problem by running the queue manager process on a node that has access to the disk. You can specify the node on which the queue manager process runs by specifying the /ON=node qualifier with the START/QUEUE/MANAGER command. For more information about this qualifier, see the OpenVMS DCL Dictionary.

13.8.7 Adding or Deleting a Device Control Library Module

When attempting to add or delete a device control library module, you might see the following message:

$LIBRAR-F-OPENIN, error opening module-name
-RMS-E-FLK, file currently locked by another user 

To add or delete a library module, you must stop all output queues to which the library is assigned. To determine which queues the library is assigned to, perform the following steps:

1. Enter a command in the following format:

   SHOW QUEUE/FULL/OUTPUT=filespec 
   

   
   where filespec is the name of a file to which the display output of the command is to be sent.
2. Use the SEARCH command to search the output file for the name of the library.

The result of your search will include all queues to which that library is assigned. Stop the queues and reenter the command to add or delete the library module.

Note

The SHOW QUEUE/FULL display shows the library assigned to a queue only if you explicitly assigned a library for the queue by including the /LIBRARY qualifier with INITIALIZE/QUEUE or START/QUEUE. If you do not explicitly assign a library to a queue, the default library, SYSDEVCTL, is used.

If the module you are trying to delete is in the default library, SYSDEVCTL, you must stop all queues for which SHOW QUEUE/FULL displays no library. To make sure the SYSDEVCTL library appears in the SHOW QUEUE/FULL display in the future, specify /LIBRARY=SYSDEVCTL when you restart the queue.

If you cannot stop the queues immediately, perform the following steps:

1. Use the COPY command to copy the library to be modified into your own directory.
2. Add the module to the copy, or delete the module from the copy.
3. Use the COPY command to copy the library back to the directory SYS$COMMON:[SYSLIB]. As long as you use the same name for the modified library, the library will be picked up by each queue when the queue is stopped and restarted.

If your site has a large number of different printers, you can help prevent this problem by using more libraries, so that each library is assigned to fewer queues. For example, you should create and assign a different library for each type of printer, as explained in Section 13.6.8.3.

13.8.8 Fixing a Disabled Queue

The queue manager attempts to correct any kind of corruption detected. If the queue manager detects corruption in a queue record, it might disable a queue to isolate the corruption. When a queue is disabled, the following message is written on the console and in the operator log file:

%QMAN-I-QUEDISCOR, queue 'queue_name' has been 
disabled due to database corruption 

When a queue is disabled, any attempt to modify or submit a job to it returns the following message:

%JBC-E-QUEDISABLED, disabled queue cannot be modified, nor can a job be 
submitted to it 

If you see either of the previous messages, do the following:

1. Contact your Digital support representative
2. Delete the queue and create a new queue to replace it.

If you encounter a problem with your queues, and you want to report it to Digital, please provide as much information as possible. Section 12.12 specifies the information that is most useful to Digital in diagnosing your queuing system problems.

When your system is installed or upgraded, values of system parameters are automatically set by the command procedure SYS$UPDATE:AUTOGEN.COM (AUTOGEN), which is supplied by Digital. Digital recommends you use AUTOGEN regularly to adjust the values for system parameters to fit your hardware configuration and your system's work load.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Converting your customized parameter settings for use with AUTOGEN	Section 14.3
Modifying system parameter values with AUTOGEN (recommended method)	Section 14.5
Controlling AUTOGEN's parameter settings with MODPARAMS.DAT	Section 14.5.1
Automating AUTOGEN reports	Section 14.6
Managing system parameters with SYSMAN	Section 14.7
Managing system parameters with SYSGEN	Section 14.8
Managing system parameters with a conversational boot	Section 14.9

This chapter explains the following concepts:

Concept	Section
System parameters	Section 14.1
Default, current, and active values of system parameters	Section 14.1.1
Pages and pagelets	Section 14.1.2
The recommended method for changing system parameter values	Section 14.2
The AUTOGEN command procedure	Section 14.4
AUTOGEN feedback	Section 14.4.1
The AUTOGEN feedback report (AGEN$PARAMS.REPORT)	Section 14.4.2
AUTOGEN phases	Section 14.4.3
The AUTOGEN parameter file (MODPARAMS.DAT)	Section 14.4.4

14.1 Understanding System Parameters

• Memory management
• Scheduling
• Security attributes
• System caches
• Windowing system choice
• Terminal configuration
• VAXcluster or OpenVMS Cluster system attributes

The OpenVMS System Management Utilities Reference Manual lists and describes each system parameter.

Your distribution kit provides default values for system parameters to allow you to boot any supported configuration. When your system is installed or upgraded, the SYS$UPDATE:AUTOGEN.COM command procedure executes to evaluate your hardware configuration, estimate typical work loads, and adjust the values of system parameters as needed.

Each system parameter has associated minimum and maximum values that define the scope of allowable values.

Parameter Types

System parameters can be one or more of the following types:

Type	Description
Dynamic	The value of a dynamic system parameter can be modified while the system is active by changing the active value in memory. In contrast, if you change the value of a parameter that is not dynamic, you must change the current value stored in the parameter file, and you must reboot the system for the changed value to take effect. For information on active and current values, see Section 14.1.1.
General	The value of a general parameter affects the creation and initialization of data structures at boot time.
Major	Major parameters are most likely to require modification.
Special	Special parameters are intended for use only by Digital. Change these parameters only if recommended by Digital personnel or in the installation guide or release notes of a Digital-supplied layered product.

Parameter Categories by Function

System parameters can be divided into the following categories, according to their function:

Category	Function
ACP	Parameters associated with file system caches and Files-11 XQP (extended QIO procedure) or ancillary control processes (ACPs).¹
Cluster	Parameters that affect VAXcluster or OpenVMS Cluster system operation.
Job	Parameters that control jobs.
LGI	Parameters that affect login security.
Multiprocessing	Parameters associated with symmetric multiprocessing.
PQL	Parameters associated with process creation limits and quotas.
RMS	Parameters associated with OpenVMS Record Management Services (RMS).
SCS	Parameters that control system communication services (SCS) and port driver operation. The parameters that affect SCS operation have the prefix SCS.
SYS	Parameters that affect overall system operation.
TTY	Parameters associated with terminal behavior.
User-defined	The following parameters can be user-defined: USERD1 (dynamic) USERD2 (dynamic) USER3 USER4

A system has several different sets of values for system parameters. The following table describes these values:

Value	Description
Default values	Values provided with the system to allow you to boot any supported configuration.
Current values	Values stored in the default parameter file on disk and used to boot the system. On VAX systems, the default parameter file is VAXVMSSYS.PAR. On Alpha systems, the default parameter file is ALPHAVMSSYS.PAR.
Active values	Values that are stored in memory and are used while the system is running. You can change the active value on a running system only for system parameters categorized as dynamic system parameters.
Values stored in other parameter files	For special purposes, you can create a parameter file other than the default parameter file that is used to store current values.

When the system boots, it reads the current values into memory, creating active values. An active value remains equal to the current value until you change either the active value or the current value.

When you execute the AUTOGEN command procedure through the SETPARAMS phase, it changes current values.

The System Management utility (SYSMAN) and the System Generation utility (SYSGEN) allow you to show and modify both current and active values. Use the USE and WRITE commands to specify which values you want to show or modify.

For more information about managing parameters with SYSMAN, see Section 14.7. For more information about managing parameters with SYSGEN, see Section 14.8.

14.1.2 Pages and Pagelets

On VAX systems, the operating system allocates and deallocates memory for processes in units called pages. A page on a VAX system is 512 bytes. Some system parameter values are allocated in units of pages.

On Alpha systems, some system parameter values are allocated in units of pages, while others are allocated in units of pagelets.

A page on an Alpha system can be 8 kilobytes (KB) (8192 bytes), 16KB, 32KB, or 64KB. A pagelet is a 512-byte unit of memory. One Alpha pagelet is the same size as one VAX page. On an Alpha computer with a page size of 8KB, 16 Alpha pagelets equal one Alpha page.

When reviewing parameter values, especially those parameters related to memory management, be sure to note the units required for each parameter. Section 14.7.2 and Section 14.8.2 explain how to show parameter values and their units of allocation.

14.2 Recommended Method for Changing Parameter Values

Many system parameters can affect other parameters and the performance of the system. For this reason, Digital recommends you use the command procedure SYS$UPDATE:AUTOGEN.COM (AUTOGEN) to manage system parameters. For information on AUTOGEN, see Section 14.4.

The System Management utility (SYSMAN) and the System Generation utility (SYSGEN) also allow you to manage system parameters. Although these utilities are not generally recommended for changing parameter values, you can use one of these utilities for the following reasons:

• To display system parameters and their values on a VAX or Alpha system
• To display system parameters and their values for systems in an OpenVMS Cluster environment
• To temporarily modify a single parameter that has little effect on other parameters

Caution

If you change a parameter value with SYSMAN or SYSGEN, the value you set will be overridden or reset to the default value when you run AUTOGEN. To retain the changes when you run AUTOGEN, you must add the parameter value to the AUTOGEN parameter file MODPARAMS.DAT. For more information, see Section 14.5.1.

If you currently use SYSMAN or SYSGEN to change parameters, and you have not added your customized parameter settings to MODPARAMS.DAT, follow the instructions in Section 14.3 before running AUTOGEN.

Digital recommends you use the AUTOGEN command procedure to tune your system. If you use the System Management utility (SYSMAN) or the System Generation utility (SYSGEN) to modify system parameter values, and you do not include these changes in the AUTOGEN parameter file MODPARAMS.DAT, these changes will be overridden the next time you run AUTOGEN.

If you used SYSMAN or SYSGEN to change parameter values in the past, use the following procedure to convert your parameter settings to work with AUTOGEN. This procedure explains how to add your customized parameter settings to MODPARAMS.DAT so they will be retained when you run AUTOGEN.

Before performing this task, you should understand AUTOGEN, feedback, and the AUTOGEN parameter file MODPARAMS.DAT, as explained in Section 14.4.

1. Save the parameter values that the system is now using as follows:

   $ RUN SYS$SYSTEM:SYSMAN
   SYSMAN> PARAMETERS USE ACTIVE
   SYSMAN> PARAMETERS WRITE SYS$SYSTEM:nodename_PARAMS_CURRENT.PAR
   

2. Write a listing of the active parameter values to an ASCII file named nodename_PARAMS.OLD as follows:

   SYSMAN> PARAMETERS SHOW/ALL/OUTPUT=nodename_PARAMS.OLD
   SYSMAN> PARAMETERS SHOW/SPECIAL/OUTPUT=nodename_PARAMS_SPECIAL.OLD
   SYSMAN> EXIT
   $ APPEND nodename_PARAMS_SPECIAL.OLD nodename_PARAMS.OLD
   

   
   You will use this file in step 6.
3. Edit AUTOGEN's parameter file SYS$SYSTEM:MODPARAMS.DAT to define symbols to specify values for the following:
   • Parameter values that are not calculated by AUTOGEN, such as SCSNODE and SCSSYSTEMID. See the AUTOGEN description in the OpenVMS System Management Utilities Reference Manual for a table of the parameters calculated by AUTOGEN.
   • Any parameter values that must be adjusted to suit your system work load, for example, GBLPAGES and GBLSECTIONS.
   
   To specify a value, define symbols using the format MIN_parameter, MAX_parameter, or ADD_parameter rather than specifying an explicit value. For example:

   $ EDIT SYS$SYSTEM:MODPARAMS.DAT
   

   SCSNODE = "MYNODE"  ! Not calculated by AUTOGEN 
   SCSSYSTEMID = 10001  ! Not calculated by AUTOGEN 
   MIN_GBLPAGES = 10000  ! Needed for MCS, BLISS32, and ADA 
   MIN_GBLSECTIONS = 600  ! Needed for MCS, BLISS32, and ADA 
   

   
   To help you track the changes you make in MODPARAMS.DAT, add comments to each line, preceded by an exclamation point (!). For information on defining symbols in MODPARAMS.DAT, see Section 14.5.1.
4. Run AUTOGEN, but do not reboot. Use one of the following commands, depending on your system:
   • If the system has run a typical work load for more than 24 hours since last booting:

     $ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
     

     
     The SAVPARAMS phase collects feedback information about resource use on the running system; this information is used by AUTOGEN. This command creates a feedback report named SYS$SYSTEM:AGEN$PARAMS.REPORT, which tells you about peak resource use.
   • If you want to use a previously collected feedback file:

     $ @SYS$UPDATE:AUTOGEN GETDATA SETPARAMS FEEDBACK
     

     
     If you start from the GETDATA phase, AUTOGEN does not collect current feedback.
   • If this is a new system (that is, it has no feedback) or the system has had little activity since last boot (for example, over the weekend) so there is no valid feedback file:

     $@SYS$UPDATE:AUTOGEN GETDATA SETPARAMS CHECK_FEEDBACK
     

     
     Use the CHECK_FEEDBACK parameter to let AUTOGEN determine whether the feedback is valid.
5. Write a listing of the new parameter values to an ASCII file as follows:

   $ RUN SYS$SYSTEM:SYSMAN
   SYSMAN> PARAMETERS USE CURRENT
   SYSMAN> PARAMETERS SHOW /ALL /OUTPUT=nodename_PARAMS.NEW
   SYSMAN> PARAMETERS SHOW /SPECIAL /OUTPUT=nodename_PARAMS_SPECIAL.NEW
   SYSMAN> EXIT
   $ APPEND nodename_PARAMS_SPECIAL.NEW nodename_PARAMS.NEW
   

6. Compare the old and new parameter values as follows:

   $ DIFFERENCES/PARALLEL/OUTPUT=nodename_PARAMS.DIF/MATCH=5  -
   _$ nodename_PARAMS.OLD nodename_PARAMS.NEW
   

7. Print the differences file you created in step 6 (named in the format nodename_PARAMS.DIF). Print the file on a 132-column line printer to make the output easier to read.
8. Compare the numbers in the two columns following each parameter name column. The left column shows the old value; the right column shows the new value. Figure 14-1 illustrates sample output.

   Figure 14-1 Old and New Parameter Values

   ---

   

   ---

9. Make any adjustments in MODPARAMS.DAT using symbols prefixed by MIN_, MAX_, or ADD_. For example, if AUTOGEN calculated a smaller value for GBLPAGES, you might specify a minimum value for this parameter as follows:

   MIN_GBLPAGES = 10000 
   

   
   If you originally specified a parameter value in MODPARAMS.DAT (in step 3) but the parameter has not been changed, verify the following:
   • The parameter name is spelled correctly and completely (not abbreviated). In MODPARAMS.DAT, AUTOGEN sees parameter names as symbol assignments. AUTOGEN cannot equate a symbol to the corresponding system parameter unless it is spelled correctly. Look in AGEN$FEEDBACK.REPORT for any error messages AUTOGEN might have written.
   • The value is correct: count the digits and make sure no commas are present.
   • The parameter occurs only once in MODPARAMS.DAT.
   • The parameter is not commented out.
   
   For most parameters, if the new value is greater than the old value, you can accept AUTOGEN's setting. If the new value is less than the old value, Digital recommends that you retain the old value because the system may not have been using that resource when running AUTOGEN.
   For example, you might have used SYSMAN to increase GBLPAGES to 10,000 to accommodate layered products, but have not specified that change in MODPARAMS.DAT. AUTOGEN might calculate that the system needs only 5000 global pages. When you reboot after running AUTOGEN, not all of your layered products may be installed, and you might receive the system message GPTFULL, "global page table full," indicating that the system needs more GBLPAGES.
10. Repeat from step 3 until you are satisfied with the new parameter values.
    If necessary, make further changes in MODPARAMS.DAT, run AUTOGEN again, and verify the changes as before. Usually after this second pass of AUTOGEN, the parameter values will be stable and you can then reboot.
11. Reboot. When you reboot, the system will use the new parameter values. Using AUTOGEN to reboot or rebooting right away is not necessary. However you must reboot before the system uses the new parameter values.
    If the system does not boot, perform a conversational boot and use the backup parameter file you created in step 1:

    SYSBOOT> USE SYS$SYSTEM:nodename_PARAMS_CURRENT.PAR
    SYSBOOT> CONTINUE
    

    When you enter the CONTINUE command, the system boots with the parameter values you saved before running AUTOGEN.
    After the system has booted, if you want to use the old parameter values you can enter the following commands:

    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> PARAMETERS USE SYS$SYSTEM:nodename_PARAMS_CURRENT.PAR
    SYSMAN> PARAMETERS WRITE CURRENT
    SYSMAN> EXIT
    

12. Run AUTOGEN using feedback regularly to ensure that the resources of your system match your system work load. For information about running AUTOGEN using feedback, see Section 14.5.

    14.4 Understanding the AUTOGEN Command Procedure

    The AUTOGEN command procedure, SYS$UPDATE:AUTOGEN.COM, is provided on your distribution kit, and runs automatically when your system is installed or upgraded to set appropriate values for system parameters. In addition, Digital recommends you run AUTOGEN when you want to reset values for system parameters or to resize page, swap, and dump files. The new values and file sizes take effect the next time the system boots.

    AUTOGEN only calculates certain significant system parameters. See the AUTOGEN section of the OpenVMS System Management Utilities Reference Manual for a table of system parameters affected by AUTOGEN calculation.

    When to Run AUTOGEN
    

    Digital recommends running AUTOGEN in the following circumstances:

    • During a new installation or upgrade. (This happens automatically as part of the installation or upgrade procedure.)
    • Whenever your work load changes significantly.
    • When you add an optional (layered) software product. See the specific product documentation for installation requirements. Certain layered products might require you to execute AUTOGEN to adjust parameter values and page and swap file sizes. (For information on using AUTOGEN to modify page and swap files, see Section 15.15.1.)
    • When you install images with the /SHARED attribute; the GBLSECTIONS and GBLPAGES parameters might need to be increased to accommodate the additional global pages and global sections consumed.
    • On a regular basis to monitor changes in your system's work load. You can automate AUTOGEN to regularly check feedback and recommend system parameter changes. Section 14.6 describes a batch-oriented command procedure that runs AUTOGEN in feedback mode on a regular basis and automatically sends the feedback report to an appropriate Mail account.
    • Periodically to provide adequate swapping file space. Use the FEEDBACK option and make sure the system has been up long enough (at least 24 hours) and that the load is typical. Also, make sure the SYS$SYSTEM:MODPARAMS.DAT file does not contain a hardcoded SWAPFILE value, which prevents AUTOGEN from correctly sizing the swapping files.

    AUTOGEN Operations
    

    ---

    Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

    ---

    
    

      6017P045.HTM
      OSSG Documentation
      22-NOV-1996 14:22:22.13
    

    Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

    Legal