wlmconf man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

wlmconf(4)							    wlmconf(4)

NAME
       wlmconf - HP-UX Workload Manager (WLM) configuration file

DESCRIPTION
       The  Workload  Manager  (WLM)  configuration  file  is the primary user
       interface for controlling WLM. It is an ASCII file that specifies  ser‐
       vice-level  objectives  (SLOs), tuning parameters, and Process Resource
       Manager (PRM) settings. The syntax is free-form, allowing  white	 space
       to  be  used  freely in formatting the file. Comments are preceded with
       the hash mark (#) and continue to the end of the line.

       The WLM configuration file has the following components:

       WLM parser version
	      The keyword, placed at the beginning of  a  configuration	 file,
	      ensures  that WLM uses the correct version parser for a configu‐
	      ration file.

       Request for notification of `Instant Capacity needed'
	      The keyword has WLM set an EMS resource to inform you  when  the
	      activation  of  Instant Capacity resources might help meet SLOs.
	      (Instant Capacity was formerly called iCOD.) This is only	 noti‐
	      fication--no  changes  to resource allocations are made based on
	      your use of this keyword. For information on how WLM  can	 actu‐
	      ally  make changes to resource allocations, refer to the section
	      "HOW TO USE wlmpard TO OPTIMIZE TEMPORARY INSTANT	 CAPACITY  AND
	      PAY PER USE SYSTEMS" in the wlmpard(1M) manpage.

       Name of host running the WLM global arbiter
	      The  keyword specifies the host name for the system that is run‐
	      ning WLM's global arbiter, which provides WLM's  cross-partition
	      management as well as its management of Temporary Instant Capac‐
	      ity resources (v6 or later) and Pay per use (v4, v7,  or	later)
	      resources.  The  global arbiter can run on any HP-UX system that
	      has network connectivity to the partitions being managed by WLM.

       System-wide settings
	      The and keywords allow you to set various values for a host when
	      you manage partitions.

       structure
	      Use  this structure if you plan on managing FSS groups or PSETs.
	      If you plan on  managing	only  virtual  partitions  or  nParti‐
	      tions--with  no  FSS  groups  or PSETs inside them, you need not
	      specify this structure.  If you plan on running  WLM  on	an  HP
	      Integrity	 Virtual Machines (Integrity VM) Host, do not use this
	      structure. WLM  will  not	 run  with  FSS	 groups	 or  PSETs  on
	      Integrity VM Hosts where an Integrity VM (guest) is running.

	      The  structure defines the PRM configuration, which includes the
	      workload groups, the application records, the user records,  the
	      Unix  group  records, the compartment records, the process maps,
	      and the disk bandwidth shares. This structure does not  allocate
	      CPU  shares  or  memory  shares for workload groups, although it
	      does allow you to specify lower and upper bounds on the CPU  and
	      memory usage by processes in the groups.

       structures
	      The  structures specify service-level objectives and assign pri‐
	      orities to those objectives.

       structures
	      The structures allow you to tune metrics and SLOs.  In  particu‐
	      lar,  structures	allow you to specify data collectors to gather
	      data on your applications, the frequency at which WLM checks for
	      new data, and how aggressively WLM converges on a new CPU shares
	      allocation, among other features.

ACCEPTABLE CHARACTERS
       In your WLM configuration file, you can use the characters below in the
       names that you supply.

	      ·	 Uppercase letters (A-Z)

	      ·	 Lowercase letters (a-z)

	      ·	 Digits (0-9)

	      ·	 The underscore character (_)
		 Do  not begin a name with an underscore; names beginning with
		 underscores are reserved for WLM use.

	      ·	 The plus character (+)

	      ·	 The hyphen character (-)

	      ·	 The forward slash (/)
		 Do not use slashes in the names of structures or metrics.

	      ·	 The period (.)

	      ·	 Quoted characters
		 You can use any printable character (except white  space,  <,
		 >,  &, ', ", \, and =) by enclosing them in quotes (for exam‐
		 ple: groups = "my@group":2;). You cannot use the slash	 char‐
		 acter	(/)  in	 the names of structures or metrics, even when
		 quoted.

       The hash character (#) comments out the rest of the line, unless quoted
       as part of a name.

       An unquoted number can never be a name.

USING THE WLM CONFIGURATION WIZARD OR THE WLM GUI
       If  you	prefer not to work directly with a configuration file, you can
       use the:

	      ·	 WLM Configuration Wizard

		 Be sure to set your environment variable before invoking  the
		 wizard.

		 Invoke the wizard using the following command:

		 The  wizard  requires	Java Runtime Environment (JRE) version
		 1.5 or later, and for PRM-based configurations,  PRM  C.03.00
		 or  later.  The wizard does not provide all the functionality
		 available through a configuration file, but it	 does  greatly
		 simplify  the process of creating a configuration. After cre‐
		 ating a configuration file using the wizard, you can view the
		 file  to  learn, and become more comfortable with, the syntax
		 and possibly create more complex configurations.

	      ·	 WLM Graphical User Interface (GUI)

		 Be sure to set your environment variable before invoking  the
		 WLM GUI.

		 Invoke the GUI using the following command:

		 allows	 you  to create, modify, and deploy WLM configurations
		 both locally and remotely. In addition, it provides  monitor‐
		 ing capabilities.

		 You can run on a system where WLM is running or on any remote
		 system with the appropriate JRE  (Java	 Runtime  Environment)
		 version  installed.   (JRE  version  1.5 or later is required
		 where WLM is running or on any remote system. For JRE version
		 requirements, refer to the the wlmgui(1M) manpage.)

		 The  version  of must match the version of the WLM configura‐
		 tion it will manage. You can install multiple versions of  on
		 a Microsoft Windows PC.

		 Also,	on  the	 system being managed by WLM, requires the WLM
		 communications daemon to be running as well as PRM C.03.00 or
		 later.	 (To  take  advantage of the latest updates to WLM and
		 the GUI, use the latest version of PRM available.)  For  more
		 information,  see  the	 wlmgui(1M) manpage or the wlmcomd(1M)
		 manpage.

PARSER VERSION
       Place the optional keyword at the beginning of your configuration  file
       to  specify  which  version of the WLM configuration file parser to use
       with that particular configuration. This keyword is useful when	future
       versions of the parser are not able to maintain backward-compatibility.
       However, WLM will be able to parse  all	configuration  files  properly
       once the correct parser version is known. By using the keyword, you are
       telling WLM which parser to use for the configuration file.

       The default and only valid value is 0:

       Specify the keyword at most once in any configuration, at the beginning
       of the configuration, outside all and structures.

NOTIFICATION OF INSTANT CAPACITY NEEDED / PPU OPTIMIZATION
       Instant	Capacity (formerly known as iCOD), offers the ability to acti‐
       vate reserve CPU (core) capacity that is already on  your  system.   (A
       core  is	 the actual data-processing engine within a processor, where a
       processor might have multiple cores.) You do not pay  for  the  Instant
       Capacity cores until they are activated. You would activate the Instant
       Capacity cores either to increase the active cores on the system or  to
       replace	the  cores  of	a  failing processor on that system. In either
       case,  action  can  be  taken--with  no	waiting	 for  new   cores   to
       arrive--because the Instant Capacity cores are already on the system.

       If you plan on using Instant Capacity in combination with WLM's virtual
       partition management, use vPars version A.03.01 or later.

       Also, HP offers a Pay per use (PPU) feature. PPU provides the  capacity
       to  support peak anticipated demand, but with payment for the HP server
       based on actual usage of that capacity. WLM integrates with PPU v4  and
       v7.   On systems with PPU v4, capacity can be increased or decreased by
       whole cores--as needed, with billing determined by the number of active
       cores.  Beginning with PPU v5, all cores on a PPU system are active and
       billing is based on your percentage usage  of  those  cores.   Starting
       with PPU v7, which includes the features of PPU v5, billing can also be
       based on the number of active cores on the system, with WLM  activating
       only those cores that are needed.

       If you have WLM on either an Instant Capacity system (using any version
       of Instant Capacity) or a PPU system (v4, v7, or later), you  can  con‐
       figure  WLM  to let you know that SLOs are failing and the reserves are
       needed. WLM only notifies you of the situation; you must manually acti‐
       vate  the  reserves if you feel it is appropriate. (Independent of this
       keyword though, you can use to automate activation of these reserves.)

       WLM notifies you using the EMS resource This resource can take the val‐
       ues or

       To enable this notification, use the keyword in your WLM configuration.
       Specify this keyword outside all and structures. The syntax is:

       icod_thresh_pri = integer;

       where

	      Is an optional keyword.

	      integer	Is an integer value greater than or  equal  to	1.  If
			Instant	 Capacity  reserves  exist  (formerly known as
			iCOD reserves), they are  considered  needed  whenever
			SLOs with a priority from 1 to integer (inclusive) are
			failing. If an SLO with a priority in  this  range  is
			failing,  notification	that Instant Capacity reserves
			are needed is sent using an EMS resource.

	      Based on the value, you can have EMS notify you so you can acti‐
	      vate Instant Capacity reserves if you feel it is appropriate.

	      When  using you can also use another global keyword that must be
	      outside all and structures. The syntax is:

	      icod_filter_intervals = integer;

	      where

		     Is an optional keyword. It allows you  to	ignore	short-
		     term fluctuations in
			       the conditions that affect the EMS resource.

		     integer   Is an integer value greater than or equal to 1.
			       This value indicates the number of  consecutive
			       WLM   intervals	over  which  Instant  Capacity
			       reserves must be needed before the EMS resource
			       is  changed  to	Similarly, it is the number of
			       intervals over which Instant Capacity  reserves
			       are  not	 required  before  the EMS resource is
			       changed to

	      WLM uses a data collector named to provide  this	EMS  resource.
	      You may see it in error messages. This collector provides only a
	      single metric. This metric is named _icod_valid_config. You  may
	      see  it  in the statistics log file /var/opt/wlm/wlmdstats or in
	      output.

HOST OF GLOBAL ARBITER
       You can run WLM within and across virtual partitions  and  nPartitions.
       You  can even have WLM manage virtual partitions inside nPartitions, as
       discussed in the WLM User's Guide  (/opt/wlm/share/doc/WLMug.pdf).  WLM
       provides a global arbiter that can take input from the WLM instances on
       the partitions. The global arbiter then moves cores across  partitions,
       if  needed,  to better achieve the SLOs specified in the WLM configura‐
       tion files that are active  in  the  partitions.	 (Given	 the  physical
       nature  of  nPartitions, WLM only simulates core movement--as described
       in the wlmparconf(4) manpage.)

       In each partition, you activate a WLM configuration that indicates  the
       host  name  for	the partition running the WLM global arbiter. Indicate
       the host of the global arbiter as follows, specifying this keyword out‐
       side all and structures.

       primary_host = hostname [ : port_number ] ;

       where

	      Is an optional keyword that identifies the host name of the sys‐
	      tem
			running the global arbiter.

	      hostname	Is the name or IP address  of  the  host  running  the
			arbiter,  which	 can be any HP-UX system that has net‐
			work connectivity to the partitions being  managed  by
			WLM.

	      port_number
			(Optional)  Is a port number greater than 0 indicating
			the port that the global arbiter is to monitor. If you
			specify a port number in a WLM configuration file on a
			partition, you must specify the same  port  number  in
			the  WLM  global arbiter configuration file and in the
			WLM configuration file in each partition.

			For information on how a port is chosen, refer to  the
			wlmparconf(4) manpage.

       If a configuration includes the keyword, it automatically uses absolute
       CPU units. As a result, 100 represents  a  single  core,	 and  any  CPU
       shares  you  specify  are out of 100 multiplied by the number of cores.
       For example, on an 8-core system, 200  represents  2  cores.  For  more
       information on absolute CPU units, refer to the section on the tunable.

       You  can specify the keyword and define workload groups in the same WLM
       configuration.

       For more information on the global arbiter and its configuration	 file,
       see the wlmpard(1M) and wlmparconf(4) manpages.

SYSTEM-WIDE SETTINGS
       Use  one	 or  more  of the following keywords outside all structures in
       your configuration to set values for the host (typically a virtual par‐
       tition or nPartition).

   hmincpu
       To  specify  the	 minimum number of CPU shares a host receives, use the
       keyword and the following syntax:

       hmincpu = min;

       where

	      Is an optional keyword.

			You cannot use this keyword in	a  configuration  that
			includes a structure.

	      min	Is the host's minimum number of CPU shares.  The value
			must be an integer between 0  and  the	host's	value,
			inclusive.

			min  is	 out  of the total CPU resources, which is 100
			multiplied by the number of cores (absolute CPU	 units
			are implied). The default value is 0.

       For information on the effect of this keyword in passive mode, refer to
       the section PASSIVE MODE VERSUS ACTUAL WLM  MANAGEMENT  in  the	wlm(5)
       manpage.

   hmaxcpu
       To  specify  the	 maximum number of CPU shares a host receives, use the
       keyword and the following syntax:

       hmaxcpu = max;

       where

	      Is an optional keyword.

			You cannot use this keyword in	a  configuration  that
			includes a structure.

	      max	Is the host's maximum number of CPU shares.  The value
			must be an integer between the host's  value  and  the
			system's  total CPU, inclusive.	 Total CPU is 100 mul‐
			tiplied by the number of cores (absolute CPU units are
			implied).

       For information on the effect of this keyword in passive mode, refer to
       the section PASSIVE MODE VERSUS ACTUAL WLM  MANAGEMENT  in  the	wlm(5)
       manpage.

   hweight
       The  larger  a  host  CPU  weight value you assign a host, the more CPU
       resources it receives when not enough CPU resources  are	 available  to
       satisfy	all  requests  at  a  given  priority level. A larger host CPU
       weight value also gets a host more CPU resources when all SLOs  can  be
       satisfied and excess CPU resources are available for distribution.

       To  specify a host's CPU weight, use the keyword and the following syn‐
       tax:

       hweight = wt;

       where

	      Is an optional keyword.

			You cannot use this keyword in	a  configuration  that
			includes a structure.

	      wt	Is the host's CPU weight. The value must be an integer
			greater than or equal to 1. The default weight	for  a
			host is 1.

STRUCTURE FORMATS
       The WLM structure formats are discussed in the following sections.

   prm structure
       If you plan on managing only virtual partitions or nPartitions--with no
       FSS groups or PSETs inside them, you need not specify a structure.  You
       can  go immediately to the next section, which discusses the structure.
       Likewise, if you plan to run WLM on an HP  Integrity  Virtual  Machines
       (Integrity VM) Host, you can go immediately to the next section. To run
       WLM on an Integrity VM Host, WLM must use a strictly host-based config‐
       uration	(a  WLM	 configuration for moving CPU resources (cores) across
       nPartitions or activating Temporary Instant Capacity  or	 Pay  per  use
       cores;  WLM does not run with FSS groups or PSETs on Integrity VM Hosts
       where an Integrity VM runs).  You can run WLM within  an	 Integrity  VM
       (as guest), but WLM does not support Instant Capacity, Pay per use, and
       vPar integration within VMs.  (However, guests will take	 advantage  of
       cores  added  to	 the  VM  host	by Instant Capacity, Temporary Instant
       Capacity, and Pay per use.) For other restrictions  pertaining  to  WLM
       use with Integrity VM machines, see wlmpard(1M) or wlm(5).

       Use  a  structure  to define the PRM configuration. The structure takes
       the following format:

       prm {
	   groups = { FSS_group_def | PSET_group_def [: LCPU = { ON | OFF }  ]
	   [, ...];
	   [ users = user : init_group [alt_group1 alt_group2 ...] [, ...]; ]
	   [ uxgrp = uxgrp_name : group [, ...]; ]
	   [ apps = group : application [alt_name1 alt_name2 ...] [, ...]; ]
	   [ scomp = compartment : group [, ...]; ]
	   [ procmap = group : PID_finder [, ...]; ]
	   [ disks = group : volume ent [, ...]; ]
	   [ gmincpu = group : min [, ...]; ]
	   [ gmaxcpu = group : max [, ...]; ]
	   [ weight = group : wt [, ...]; ]
	   [ gminmem = group : min [, ...]; ]
	   [ gmaxmem = group : max [, ...]; ]
	   [ memweight = group : wt [, ...]; ]
       }

       where

       FSS_group_def has the syntax:
	      group : group_ID

       PSET_group_def has the syntax:
	      group : PSET [: LCPU = { ON | OFF } ]

       Here is an example structure:

       prm {
	  groups = finance : 2,
		   sales : 3,
		   marketing : PSET;

	  users = jdoe : finance,
		  pdoe : sales,
		  admin : finance sales marketing;

	  uxgrp = treasurer : finance,
		  forecaster : sales;

	  apps = finance : /bin/dbase "dbase*Finance",
		 sales : /bin/dbase "dbase*Sales";

	  procmap = finance : /bin/env/ UNIX95= /bin/ps -C pid_app -o pid=,
		    sales : /scratch/pidsbyapp salespid_app,
		    marketing : /scratch/pidsbyapp mrketpid_app;

	  gmincpu = finance : 20,
		    sales : 10;

	  gmaxcpu = sales : 20;

	  gminmem = finance : 30,
		 sales : 10,
		 marketing : 20;

	  disks = OTHERS : /dev/vg01 1,
		  finance : /dev/vg01 35,
		  sales : /dev/vg01 35;
       }

   groups
       A workload group can be one of two types: FSS or PSET.

       An  FSS	group  is  allocated CPU resources by the Fair Share Scheduler
       (FSS) in the HP-UX kernel. WLM can automatically adjust the CPU alloca‐
       tion for an FSS group based on the group's progress toward an SLO.

       A  PSET group is based on a processor set. A PSET group's CPU resources
       are determined by the number of cores assigned to the PSET  group.  WLM
       can  automatically  adjust the number of cores assigned to a PSET group
       based on its progress toward an SLO. WLM supports  the  Hyper-Threading
       feature	for  PSET-based	 groups.  See  the discussion of the attribute
       below.

       Processes in either  type  of  group  have  equal  access  to  the  CPU
       resources  allocated to their group. Within a group, the HP-UX standard
       scheduler is used.

       Define groups using the required keyword and the following syntax:

       groups = { FSS_group_def | PSET_group_def [: LCPU = { ON | OFF } ] } [,
       ...];

       An FSS_group_def has the following syntax:

       group : group_ID

       where

	      group	Is  the	 workload  group name. The name should be less
			than eight characters long for proper display  by  the
			command. It cannot start with an underscore (_).

			The  group  is	the default group for processes run by
			the root user.	You can specify it  as	an  FSS	 group
			(group_ID  must be 0) and use it with the and keywords
			in a structure. You cannot, however, use it  with  the
			or keywords, in an structure, or as a PSET group.

			Use  only as needed. Do not load processes into indis‐
			criminately.

			The group is the default group for users who  are  not
			assigned  to  groups. It is also the default group for
			applications that are not assigned to  groups  or  are
			started	 by users who do not have assigned groups. You
			can specify as an FSS group (group_ID must be 1),  but
			not as a PSET group. It does not require an structure,
			but you can create one or more for it if you wish.

			If you specify or for any group in your configuration,
			be  sure  to  specify  a  for any group, including for
			which 1% of the memory is not sufficient for its users
			and  applications  (or	if the tunable is enabled, for
			which 0.2% of the memory is not sufficient).

			After WLM allocates CPU resources to groups with SLOs,
			by default receives any remaining CPU resources.

			For any other FSS group you define, you must define an
			structure that references that group.

	      group_ID	Is the workload	 group	ID  and	 must  be  a  uniquely
			assigned integer value between 0 and 63 (inclusive) or
			starting with HP-UX 11i v2 Update 2, between 0 and 255
			(inclusive).

			ID  0  is  reserved for the system group, If it is not
			specified, it is created automatically.

			ID 1 is reserved for the user  default	group  If  the
			group is not specified, it is created automatically.

       A PSET_group_def has the syntax:

       group : PSET [: LCPU = { ON | OFF } ]

       where

	      group	Is  the	 workload  group name. The name should be less
			than eight characters long for proper display  by  the
			command. It cannot start with an underscore (_).

			group cannot be either the group.

			If you specify or for any group in your configuration,
			be sure to specify a  for  any	group,	including  for
			which 1% of the memory is not sufficient for its users
			and applications (or if the tunable  is	 enabled,  for
			which 0.2% of the memory is not sufficient).

			With  PSET  groups,  you can define one or more struc‐
			tures per group, but it is not required.

	      PSET	Indicates the group is to be based on a PSET.

	      LCPU = { ON | OFF }
			Specifies the optional logical	CPU  (Hyper-Threading)
			state  for  cores assigned to the specified PSET-based
			group, where:

			LCPU = ON
			       Explicitly enables Hyper-Threading

			LCPU = OFF
			       Explicitly disables Hyper-Threading

			The logical CPU (Hyper-Threading) feature is available
			starting  with	HP-UX  11i  v3	(11.31) for processors
			designed to support the	 feature  and  that  have  the
			appropriate  firmware  installed.  A logical CPU is an
			execution thread contained within a core. With	Hyper-
			Threading enabled, each core can contain multiple log‐
			ical CPUs. WLM automatically sets the  Hyper-Threading
			state  for  the	 default PSET to optimize performance.
			(The default PSET, also known as PSET 0, is where  all
			FSS  groups  reside.) When new PSETs are created, they
			inherit the Hyper-Threading state that the system  had
			before	WLM was activated (inheritance is based on the
			system state before WLM	 activation  because  WLM  may
			change	the  Hyper-Threading  setting  for the default
			PSET to optimize performance).	 Cores	can  be	 moved
			from  one  partition  to  another and will take on the
			Hyper-Threading state of their destination PSET.

			You can modify the Hyper-Threading state of the system
			by  using  the	command. For example, to enable Hyper-
			Threading on the system, use the following command:

			For more  information  about  this  command,  see  the
			kctune(1M) manpage.  Do not use this command to modify
			a PSET while WLM is running. Whenever possible use WLM
			to control PSETs.

			You can override the default Hyper-Threading state for
			cores assigned to a specific PSET-based group by using
			the LCPU attribute.  The LCPU attribute is based on an
			attribute value that you  can  also  examine  and  set
			using  the  option with the command. For more informa‐
			tion about this command, see the  psrset(1M)  manpage.
			Do  not	 use the command to modify a PSET while WLM is
			running. Whenever possible, use WLM to control PSETs.

			The PRM configuration generated by the WLM  configura‐
			tion   file   reflects	the  per-PSET  Hyper-Threading
			attribute currently specified for the  affected	 work‐
			load groups.

       You  can define workload groups (FSS and PSET-based) and use WLM's par‐
       tition management (by specifying the keyword) in the same WLM  configu‐
       ration.	Certain software restrictions apply to using PSET-based groups
       with HP-UX Virtual Partitions (vPars), Instant Capacity,	 and  Pay  per
       use.   For   more   information,	  refer	  to  the  WLM	Release	 Notes
       (/opt/wlm/share/doc/Rel_Notes).

       It is possible to create a WLM configuration that has  more  PSET-based
       workload	 groups	 than the underlying system has cores. However, if all
       the groups are active at the same time, some  groups  will  necessarily
       not  have  a  core assigned and their processes would be placed in Fur‐
       thermore, if there are more PSET-based groups than cores and is not set
       to  1,  the  allocation	of  cores  to the PSET-based groups will never
       change. As a result, the extra groups do not add any value as they will
       never get any CPU resources.

   users
       To  specify  the	 workload groups in which users' processes can run and
       that users can access, use the keyword and the following syntax:

       users = user : init_group [alt_group1 alt_group2 ...]  [, ...];

       where

	      Is an optional keyword that can appear, at most, once in a  con‐
	      figuration.

	      user	Is  either an individual user's login name or a string
			that begins with the plus (+) character followed by  a
			netgroup  name,	 such as +netgroup_name. Netgroups are
			defined in /etc/netgroup.  WLM	ignores	 any  line  in
			/etc/netgroup  that  has an empty user field. For more
			information on netgroups, refer to netgroup(4).

	      init_group
			Is the name of the initial workload group for the user
			or  netgroup.  This is the group selected when launch‐
			ing the user's login shell.

			For information on a user's group placement  when  the
			user  belongs  to  multiple  netgroups,	 refer	to the
			Process	    Resource	 Manager     User's	 Guide
			(/opt/prm/doc/PRM.ug.pdf).

	      alt_group1 [alt_group2 ...]
			(Optional)  Is	the  name  of  the  alternate workload
			groups for the user or netgroup. Alternate groups  are
			groups	other than the initial group in which the user
			or netgroup members are allowed to run processes. Move
			existing  processes  to,  or  start  new processes in,
			alternate groups  using	 the  or  commands.  For  more
			information, refer to prmmove(1) and prmrun(1).

       If  you	assign processes that would typically run in to another group,
       be sure that group has sufficient resources. (For example, if  you  are
       using memory records, be sure the group gets enough memory.)  Take par‐
       ticular care when creating user records for root as such	 records  will
       move essential system processes, such as

       A  process  may start in a workload group other than its assigned group
       due to its inheriting the group of the process that  started  it.  How‐
       ever, WLM will eventually move the process to the workload group speci‐
       fied in its users record.

       When determining the workload  group  assignment	 for  a	 process  that
       matches	multiple  records, WLM gives highest precedence to assignments
       defined in process maps (or to assignments made using the or commands).
       The  precedence given to the various records that define workload group
       placement is described in the section "Precedence of records for	 group
       assignments" below.

   uxgrp
       When  the  number of users in an organization or enterprise is substan‐
       tial, users might be assigned to Unix groups  to	 simplify  permissions
       assignments  and	 other management tasks. You can assign Unix groups to
       workload groups.	 Processes whose effective group ID  (GID)  matches  a
       Unix  group  record will run in the associated workload group. WLM sup‐
       ports Unix group records only if PRM C.03.02 or later is	 installed  on
       the system.

       You can assign a Unix group to one workload group only; however, multi‐
       ple Unix groups can be assigned to the same workload group. If  a  user
       should  be  given  access  to more than one workload group, it might be
       simpler to use the user record instead of  the  Unix  group  record  to
       assign users to workload groups.

       Place  Unix  groups  in	workload groups by defining the keyword in the
       structure. The keyword can appear, at most, once in a configuration.

       To assign Unix groups to workload groups, use the following syntax:

       uxgrp = uxgrp_name : group [, ...];

       where

	      uxgrp_name
			Is the name of a Unix group.

	      group	Is the name of the workload group in  which  the  Unix
			group  should  be placed. A Unix group can be assigned
			to one workload group only.

       A process may start in a workload group other than its  assigned	 group
       due  to	its  inheriting the group of the process that started it. How‐
       ever, WLM will eventually move the process to the workload group speci‐
       fied in its Unix group record.

       When  determining  the  workload	 group	assignment  for a process that
       matches multiple records, WLM gives highest precedence  to  assignments
       defined	in  process  maps  (or to assignments made using the or prmrun
       commands). The precedence given to  the	various	 records  that	define
       workload	 group	placement  is  described in the section "Precedence of
       records for group assignments" below.

   apps
       Each workload group defines a workload. One or more applications can be
       assigned	 to  the  workload  group.  WLM then dynamically allocates CPU
       shares or whole cores to a workload group to achieve the goal specified
       in the workload group's SLO.

       The system is polled every 30 seconds to ensure that processes are run‐
       ning in the appropriate workload groups. If a process forks child  pro‐
       cesses  and  immediately exits, the polling will likely miss the parent
       process. As a result, the parent process is never placed in  its	 work‐
       load group. When the child processes are found during polling, WLM will
       not be able to determine the parent of the processes. Then, instead  of
       being  placed  in  the parent's assigned group, the child processes are
       placed in the group of the invoking user or in the group. To avoid this
       condition,  be sure parent processes exist for at least 30 seconds (the
       default polling interval). In various shells, you can use  the  command
       in a script to prevent the process from exiting immediately. (Placement
       of a process family can take up to two polling  intervals:  The	parent
       process is moved to its assigned group in the first interval, while the
       child processes are moved to the group in the second interval.)

       Specify the application's group assignment using the  keyword  and  the
       following syntax:

       apps = group : application [alt_name1 alt_name2 ...]  [, ... ];

       where

	      Is an optional keyword that can appear, at most, once in a
			configuration.

	      group	Is the name of the workload group (that is, PRM group)
			in which the application should run.

	      application
			Is the full pathname of the application, starting with
			a  slash  (/).	 The  pathname	must be to a binary or
			shell/interpreter.

			For information on how to specify scripts in an state‐
			ment, refer to the section SCRIPT EXAMPLE below.

			Wildcards  and	pattern	 matching  in application file
			names

			You can use wildcards ([,],?,*) to  specify  the  file
			name,  but not the directory name. If using wildcards,
			enclose the full pathname in  quotes.  Beginning  with
			WLM  A.03.01,  you  can use wildcards in both the file
			name and the alternate name in	a  single  application
			record.	  For  more information on wildcards, refer to
			the PATTERN MATCHING NOTATION section in regexp(5).

			File names are expanded to their complete names when a
			PRM  configuration is loaded by WLM. Explicit applica‐
			tion records take precedence over application  records
			that  use  wildcards.  If  an  application  without an
			explicit record is matched by several records that use
			pattern	 matching, the record closest to the beginning
			of the configuration file is used.

	      alt_name1 [alt_name2 ...]
			(Optional) Is an alternate  name  the  application  is
			assigned  when	executed.  For	example, a program may
			rename itself causing its process  name,  as  seen  in
			ps(1)  output,	to  be different from the file name of
			the program. Alternate names allow you to place such a
			program	 into  different  workload groups based on its
			process names, even though the executable file name is
			the same.

			With  shell  scripts,  the alt_name is the name of the
			script, and the shell/interpreter is the  application.
			For  an	 example  showing how to specify scripts in an
			statement, refer to the section SCRIPT EXAMPLE below.

			For an example showing how to specify  an  application
			that  renames  itself,	refer  to  the section RENAMED
			APPLICATION EXAMPLE below.

			Wildcards and pattern matching in alternate names

			You can use wildcards ([,],?,*) when specifying alter‐
			nate  names.   Beginning with WLM A.03.01, you can use
			wildcards in both the file name and the alternate name
			in  a  single application record.  If using wildcards,
			enclose the alternate name in quotes.  For more infor‐
			mation	on  wildcards,	refer  to the PATTERN MATCHING
			NOTATION section in regexp(5).

			Beginning with WLM A.03.02, when it  is	 running  with
			PRM  C.03.02  or  later,  you can use Extended Regular
			Expressions (EREs) for the alternate name field in the
			application  record  (see the EXTENDED REGULAR EXPRES‐
			SION section in regexp(5)). However, note that such  a
			regular	 expression must be the only alternate name in
			that particular record and  should  be	within	single
			quotes.	 For  an example of an ERE used for the alter‐
			nate name field in  an	application  record,  see  the
			RENAMED APPLICATION EXAMPLE section below.

			Other  records	can still have non-ERE alternate names
			for the same  application.  Note  that	while  non-ERE
			alternate  names are matched against non-dash command-
			line  arguments,  ERE  alternate  names	 are   matched
			against	 the  entire available command line. Note also
			that commas within  an	ERE  are  not  separators  for
			alternate names; they must match commas in the command
			line.  If an ERE alternate name and a  non-ERE	alter‐
			nate  name  both  exist	 for the same application, the
			non-ERE alternate name takes priority. If multiple ERE
			alternate  names  match,  the  "first" record to match
			takes precedence.

			If there are multiple application records with	alter‐
			nate  names  that  match  an  application  name due to
			redundant  pattern  matching  resolutions,  the	 first
			record to match the application name takes precedence.
			For example, the application abb matches both  of  the
			following application records:

			apps = GroupA : /opt/foo/bin/bar "a*",
			       GroupB : /opt/foo/bin/bar "*b";

			Because the *b record is first (based on ASCII dictio‐
			nary order), the application abb would be assigned  to
			the workload group GroupB.

       A  process  may start in a workload group other than its assigned group
       due to its inheriting the group of the process that  started  it.  How‐
       ever, WLM will eventually move the process to the workload group speci‐
       fied in its application record.

       When determining the workload  group  assignment	 for  a	 process  that
       matches	multiple  records, WLM gives highest precedence to assignments
       defined in process maps (or to assignments made	using  the  or	prmrun
       commands).  The	precedence  given  to  the various records that define
       workload group placement is described in	 the  section  "Precedence  of
       records for group assignments" below.

       To place a script in a workload group using an statement:

	      1. Specify the full path of the shell or interpreter used in the
		 script as the application.

	      2. Specify the name of the script (just the  name--no  path)  as
		 the alt_name.

		 Because  the  full pathname is not required for the script, a
		 rogue user can get access to workload groups--that would oth‐
		 erwise not be accessible--by using the name of the script for
		 new scripts or wrappers.

	      3. Ensure	 the  shell  or	 interpreter  is  listed   in	either
		 /etc/shells or /opt/prm/shells.

       For   example,	for   a	  perl	script	named  myscript.pl  and	 using
       /opt/perl/bin/perl, the statement to place the script  in  group	 would
       be:

       apps = scripts_grp : /opt/perl/bin/perl myscript.pl;

       To place a renamed application in a workload group using an statement:

	      1. Specify the full path of the application as the application.

	      2. Specify the new name the application takes once it is running
		 as the alt_name.

       For example, here is an statement  for  an  Oracle  database  with  two
       instances:

       apps = Finance : /opt/oracle/bin/oracle "ora*Finance",
	      Sales : /opt/oracle/bin/oracle "ora*Sales";

       The  Oracle database executable is the same in both cases; however, the
       alternate names specify different patterns to match. (Given the use  of
       wildcards,  the	alternate names are quoted.) The patterns are based on
       the instance names. Consequently, processes  starting  with  'ora'  and
       ending with ´Finance´ are placed in the workload group. Similarly, pro‐
       cesses matching the pattern ´ora*Sales´ go into the workload group

       Here is an example showing the use of an ERE with the alternate name in
       the application record:

       apps = Finance_Sales : /opt/oracle/bin/oracle 'ora.*(Finance|Sales)';

       The  ERE expression is enclosed in single quotes.  Any processes begin‐
       ning with the string  'ora.'  followed  by  any	strings	 that  include
       'Finance' or 'Sales' are placed in the workload group.

   scomp
       The  HP-UX  feature Security Containment, available starting with HP-UX
       11i v2, provides "secure compartments," which allow you to isolate pro‐
       cesses  and  files.  You can place one or more secure compartments in a
       single workload group to manage the resource allocation for your secure
       compartments.  To place secure compartments in workload groups, use the
       keyword and the following syntax:

       scomp = compartment : group [, ...];

       where

	      Is an optional keyword.

	      compartment
			Is the name of a secure compartment you	 have  already
			created	   using    Security	Containment--or	   the
			/opt/prm/bin/srpgen utility.

	      group	Is the name of the workload group in which compartment
			should be placed.

       A  process  may start in a workload group other than its assigned group
       due to its inheriting the group of the process that  started  it.  How‐
       ever, WLM will eventually move the process to the workload group speci‐
       fied in its compartment record.

       When determining the workload  group  assignment	 for  a	 process  that
       matches	multiple  records, WLM gives highest precedence to assignments
       defined in process maps (or to assignments made	using  the  or	prmrun
       commands).  The	precedence  given  to  the various records that define
       workload group placement is described in	 the  section  "Precedence  of
       records for group assignments" below.

   procmap
       Use  this  keyword  to define process maps. A process map is a powerful
       and flexible tool that allows you to establish your  own	 criteria  for
       how  processes  are  placed  in workload groups rather than using WLM's
       default criteria (apps, or records).

       To specify process maps, use the keyword and the following syntax:

       procmap = group : PID_finder [, group1 : PID_finder1",...];

       where

	      Is an optional keyword that can appear, at most, once in a
			configuration.

	      group	Is the name of the PRM workload	 group	in  which  the
			processes identified by PID_finder should run.

	      PID_finder
			Is  the	 absolute  path to a script or command and its
			arguments that gathers and outputs the process identi‐
			fiers (PIDs) of processes meant to be placed in group.
			The command line can specify, for example, a  command,
			Oracle script, or SAP script. To separate arguments in
			the command line, use white space. Use	double	quotes
			to  form  single  arguments to an option or when using
			special characters such	 as  commas,  semicolons,  and
			pound  (#)  characters.	 For an example showing how to
			specify the command line in the PID_finder  statement,
			refer to the section PID FINDER EXAMPLES below.

			   In  conjunction  with HP Serviceguard Extension for
			   SAP (SGeSAP), the HP-UX  WLM	 SAP  Toolkit  (SAPTK)
			   provides  a	script (wlmsapmap) that identifies SAP
			   processes and uses WLM's process map (procmap) fea‐
			   ture	 to  place  them  in specific workload groups.
			   SAPTK is part of the freely available  product  WLM
			   Toolkits (WLMTK) available at /opt/wlm/toolkits/.

			The  expected  output  is  a  list  of PIDs, separated
			either by a space or newline  delimiter.  WLM  gathers
			the  PID_finder stdout and places the processes in the
			group in the order defined by PID_finder.  Any	stderr
			is  ignored. Note that processes invoked by PID_finder
			run in by default.

			The command or script is spawned periodically, at  the
			interval  defined by the application manager's current
			polling interval (by  default,	30  seconds).	Ensure
			that  the operation completes in a short time relative
			to this interval.

			You can specify more than one PID_finder for a	group,
			but  you  must	specify	 each PID_finder in a separate
			group : PID_finder statement.

			There is no expansion of wildcards  specified  in  the
			PID_finder string.

	      The  PID_finder is a single command. Pipes are not directly sup‐
	      ported unless embedded in a shell command (see the third example
	      provided in the section PID FINDER EXAMPLES below).

	      A	 process may start in a workload group other than its assigned
	      group due to its	inheriting  the	 group	of  the	 process  that
	      started it. However, WLM will eventually move the process to the
	      workload group specified in its process map.

	      Process maps take precedence over WLM's  standard	 criteria  for
	      process  placement.  That	 is, if a PID listed by the PID_finder
	      script matches an or record,  the	 process  map  determines  the
	      placement	 of  the  process.  If	a PID is specified by multiple
	      PID_finder commands or scripts, the process's  assignment	 might
	      change  from group to group with each successive spawning of the
	      PID_finder.

	      To follow are examples showing three different ways  to  specify
	      PID_finder,  from	 the  most  desirable method to the least. All
	      three PID_finder specifications provide similar functionality.

		     1. Run the	 command  in  an  appropriate  environment  to
			gather	PIDs  matching	the application named pid_app.
			This method  of	 specifying  PID_finder	 is  the  best
			because	 it  does  not mask the functionality and does
			not fork additional shells.

			procmap = sales :
			/bin/env UNIX95= /bin/ps -C pid_app -o pid=;

		     2. Gather PIDs inside an external script named pidsbyapp.
			This  is  less	desirable  than	 the preceding example
			because it masks the functionality of  what  is	 being
			run;  however,	you might find this method more useful
			because it facilitates specifying multiple or  complex
			PID selection criteria.

			procmap = sales : /scratch/pidsbyapp pid_app;

		     3. Run  a command with a pipeline inside a shell. This is
			least desirable because it spawns multiple shells.

			procmap = sales :
			/usr/bin/sh -c "ps -efxP | grep pid_app | awk '{print $3}'";

   Precedence of records for group assignments
       When determining the workload  group  assignment	 for  a	 process  that
       matches	multiple  PRM  records,	 WLM gives precedence (from highest to
       lowest) to the assignments as follows:

	      1. Process maps

	      2. Compartment records

	      3. Application records

	      4. User records

	      5. Unix group records

       Thus, if a PID specified by a PID_finder script defined	in  a  process
       map  matches  that of a process associated with a compartment, applica‐
       tion, user, or Unix group record, the process map determines the place‐
       ment of the process.

       A  process  may start in a workload group other than its assigned group
       because it inherits the group of the process that started it.  However,
       WLM will eventually move the process to the workload group specified in
       its record. For information  on	process	 placement  for	 inactive  FSS
       groups  and  PSET-based	groups,	 refer to the "Placement of processes"
       sections in the discussion of structures below.

       If you use the or command to place a process in a workload group,  that
       assignment  takes precedence over any of the assignments defined by the
       PRM records.

   disks
       WLM does not dynamically allocate  disk	bandwidth  to  volume  groups.
       However,	 to ensure that a workload group receives a guaranteed minimum
       amount of disk bandwidth for  a	specified  volume  group,  it  can  be
       assigned disk bandwidth shares. You can specify shares for a given log‐
       ical volume group, managed by HP's Logical Volume Manager (LVM).

       Specify the disk bandwidth shares for workload groups using the keyword
       and the following syntax:

       disks = group : volume shares [, ...];

       where

	      Is an optional keyword that can appear, at most, once in a
			configuration.

	      group	Is the workload group name.

			You cannot specify a PSET group in a statement.

	      volume	Names  a logical volume group.	volume must begin with
			/dev/v to be recognized.

	      shares	Is an integer  value  greater  than  or	 equal	to  0.
			shares	translates  to	a percentage of the disk band‐
			width when dividing it by the number of disk bandwidth
			shares	assigned  to  all  the workload groups for the
			given volume group.

       If one FSS workload group has disk shares for a volume group, then  all
       FSS workload groups must have disk shares for that volume group.

       For  example,  consider	a system with two volume groups: /dev/vg01 and
       /dev/vg02. Assume the group needs shares on both volume	groups.	 As  a
       result, all the groups get shares on both volume groups:

	  disks = OTHERS : /dev/vg01 1,
	       finance : /dev/vg01 50,
	       sales : /dev/vg01 49,

	       OTHERS : /dev/vg02 1,
	       finance : /dev/vg02 60,
	       sales : /dev/vg02 39;

   gmincpu
       To  specify  the minimum number of CPU shares a group receives, use the
       keyword and the following syntax:

       gmincpu = group : min [,group1 : min1, ...];

       where

	      Is an optional keyword.

	      group	Is the workload group name.

	      min	Is group's minimum number of CPU  shares.   The	 value
			must  be  an  integer between 0 and the group's value,
			inclusive.

			min is out of the total CPU resources,	which  is  100
			multiplied by the number of cores (if you set the tun‐
			able to 1 or it is implied by other elements  in  your
			configuration)--or just 100 by default.

			To  have a minimum of 2 cores on an 8-core system with
			enabled, you would specify:

			For more information on absolute CPU units,  refer  to
			the section on the tunable.

			If  you	 specify  a  min  greater  than	 the total CPU
			resources, WLM treats it as equal  to  the  total  CPU
			resources.

			By  default, the minimum CPU allocation for a workload
			group with no active SLOs is the min  value.  If  this
			value  is  not set, the group gets the minimum alloca‐
			tion possible. For FSS groups, this value is 1% of the
			default	 PSET  (the  default  PSET consists of all the
			processors  that  are  not  assigned  to  other	  PSET
			groups).  If  the  tunable is set to 1, the minimum is
			0.2%. The default minimum allocation for a PSET	 group
			is  one	 core.	If the keyword is set to 1, FSS groups
			with no active SLOs are deleted and therefore  use  no
			resources;  the minimum CPU allocation for PSET groups
			becomes 0 (or the value of if  defined	and  resources
			are   available).   However,  groups  associated  with
			process maps always remain active even if  the	groups
			have no active SLOs.

			If you specify a min value that is less than 1% of the
			total CPU resources, an FSS group receives 1%  of  the
			CPU  resources	in the default PSET; if the tunable is
			enabled, the group  receives  0.2%  (with  incremental
			allocations of 0.1%).  For example, in the WLM config‐
			uration on an 8-core system, the  system's  total  CPU
			resources can be divided into 800 shares (100 for each
			core), assuming	 is  enabled.  With  disabled  and  no
			PSETs,	a min value of 7 would be less than 1%, so WLM
			would automatically allocate at least 8 shares of  CPU
			resources to the group.

			With  enabled in this scenario, the minimum allocation
			value would be 6.4 or 7.2, which are the  two  nearest
			multiples of .8.

			For  information  on the effect of the keyword in pas‐
			sive mode, refer to the section	 PASSIVE  MODE	VERSUS
			ACTUAL WLM MANAGEMENT in the wlm(5) manpage.

			If  the sum of all the values is greater than the sys‐
			tem's total CPU resources, the values are  treated  as
			CPU  requests  that  are  to  be  met before any other
			requests are considered.  values do apply.

			When configuring WLM on a partition, be sure to select
			a  value for min that makes sense in terms of the lim‐
			its  placed  on	 the  partition	 when  it   was	  cre‐
			ated--namely its minimum and maximum number of cores.

       This minimum is a hard lower limit; group receives less than this mini‐
       mum only if it has no active SLOs and is set to 1. (However,  if	 group
       is  associated  with  a process map, it remains active and continues to
       receive the minimum even if it has no active SLOs.)  This hard limit is
       different  from the value in structures, which merely specifies a lower
       bound on the CPU request generated by that SLO.

   gmaxcpu
       To specify the maximum number of CPU shares a group receives,  use  the
       keyword and the following syntax:

       gmaxcpu = group : max [,group1 : max1, ...];

       where

	      Is an optional keyword.

	      group	Is the workload group name.

	      max	Is  group's  maximum  number  of CPU shares. The value
			must be an integer between the group's value  and  the
			system's total CPU, inclusive.	Total CPU resources is
			100 multiplied by the number of cores (if you set  the
			tunable	 to  1	or  it is implied by other elements in
			your configuration)--or just 100 by default.

			If you specify	a  max	greater	 than  the  total  CPU
			resources,  WLM	 treats	 it  as equal to the total CPU
			resources.

			To have a maximum of 4 cores on an 8-core system  with
			enabled, you would specify:

			For  more  information on absolute CPU units, refer to
			the section on the tunable.

			When configuring WLM on a partition, be sure to select
			a  value for max that makes sense in terms of the lim‐
			its  placed  on	 the  partition	 when  it   was	  cre‐
			ated--namely its minimum and maximum number of cores.

       This  maximum is a hard upper limit; group will never receive more than
       this maximum, as opposed to the value in structures, which merely spec‐
       ifies  an  upper	 bound	on the CPU request generated by that SLO. (The
       group may receive more than its if other groups have received their and
       there are still CPU resources left.)

       There  is  no default value for a group. If you do not specify a value,
       WLM takes the system's total CPU resources, in shares, as the value.

       For information on the effect of this keyword in passive mode, refer to
       the  section  PASSIVE  MODE  VERSUS ACTUAL WLM MANAGEMENT in the wlm(5)
       manpage.

   weight
       The larger a weight value you assign a group, the more CPU resources it
       receives	 when  not  enough  CPU resources are available to satisfy all
       requests at a given priority level. A larger weight value also  gets  a
       group  more CPU resources when all SLOs can be satisfied and excess CPU
       resources are available for  distribution.  To  enable  the  extra  CPU
       resources  to  go  to your workload groups, you must set the tunable in
       your configuration file. If you do not set this tunable, all the excess
       CPU resources go to the default workload group

       To specify a group's CPU weight, use the keyword and the following syn‐
       tax:

       weight = group : wt [,group1 : wt1, ...];

       where

	      Is an optional keyword.

	      group	Is the workload group name.

	      wt	Is group's CPU weight. The value must  be  an  integer
			greater	 than or equal to 1.  The default weight for a
			group is 1.

       Weighting a group is beneficial only if the group is going to  have  an
       active SLO.

       When  resources	are insufficient to satisfy a demand at a given prior‐
       ity, WLM uses weighting to determine how to  distribute	CPU  resources
       among the requests at that priority. WLM attempts to allocate resources
       so that the weight-to-allocation ratio is the same for all the  groups.
       However,	 to determine the CPU allocations, WLM first observes the fol‐
       lowing constraints:

	      A group's CPU allocation must not exceed the SLO request	unless
	      all SLOs at the same priority are satisfied.

	      Any  CPU allocation mandated by a group's higher-priority SLO is
	      always retained (it is never reduced  to	achieve	 a  weight-to-
	      allocation  ratio	 equal to that of the other groups at the same
	      priority level, as sought under normal circumstances).

       This policy for determining allocations also applies to CPU demand that
       is not a direct result of a prioritized SLO, such as values and distri‐
       bution of excess (when the tunable is set). The ultimate consequence of
       this  policy  is	 that,	in  the absence of other SLO requests, any two
       requests at the same priority level that are not fully  satisfied  will
       have  the  same	ratio  between their respective allocations as between
       their respective weights (in other words, the ratio of group A's	 allo‐
       cation  to group B's allocation equals the ratio of group A's weight to
       group B's weight).

       For an example demonstrating this policy for distributing CPU resources
       based  on  weight,  refer  to the HP-UX Workload Manager's User's Guide
       (/opt/wlm/share/doc/WLMug.pdf).

   gminmem
       When specifying a workload group's minimum memory, be very  careful  of
       resource interactions, which are explained in the section "How resource
       allocations interact" in the  HP-UX  Workload  Manager's	 User's	 Guide
       (/opt/wlm/share/doc/WLMug.pdf).	In  particular,	 be  sure the workload
       groups get the memory they need. (When setting values  for  and	ensure
       that the groups get sufficient memory even when all groups are active.)

       To  specify  the minimum percentage of memory a group receives, use the
       keyword and the following syntax:

       gminmem = group : min [,group1 : min1, ...];

       where

	      Is an optional keyword.

	      group	Is the workload group name.

			If you specify or for any group in your configuration,
			be  sure  to  specify  a  for any group, including for
			which 1% of the memory is not sufficient for its users
			and  applications  (or	if the tunable is enabled, for
			which 0.2% of the memory is not sufficient).

			You cannot specify the group in a statement.

	      min	Is group's minimum percentage  of  memory.  The	 value
			must  be  an  integer between 1 and the group's value,
			inclusive.

			The default min value is 1.

       This minimum is a hard lower limit; group receives less than this mini‐
       mum  only if it has no active SLOs, is set to 1, and group is not asso‐
       ciated with a process map.

   gmaxmem
       When specifying a workload group's maximum memory, be very  careful  of
       resource interactions, which are explained in the section "How resource
       allocations interact" in the  HP-UX  Workload  Manager's	 User's	 Guide
       (/opt/wlm/share/doc/WLMug.pdf).	In  particular,	 be  sure the workload
       groups get the memory they need. (When setting values  for  and	ensure
       that the groups get sufficient memory even when all groups are active.)

       To  specify  the maximum percentage of memory a group receives, use the
       keyword and the following syntax:

       gmaxmem = group : max [,group1 : max1, ...];

       where

	      Is an optional keyword.

	      group	Is the workload group name.

			You cannot specify the group in a statement.

	      max	Is group's maximum percentage  of  memory.  The	 value
			must  be an integer between the group's value and 100,
			inclusive.

			The default max value is 100.

       This maximum is a hard upper limit; group will never receive more  than
       this  maximum. (The group may receive more than its if all other groups
       have received their and there is still memory left.)

   memweight
       The larger a memory weight value you assign a group, the more memory it
       receives when there is not enough memory to satisfy all requests.

       To  specify  a group's memory weight, use the keyword and the following
       syntax:

       memweight = group : wt [,group1 : wt1, ...];

       where

	      Is an optional keyword.

	      group	Is the workload group name.

			You cannot specify the group in a statement.

			Assigning a to a PSET workload	group  is  not	useful
			because	 WLM grants the group memory when the configu‐
			ration is activated,  but  never  adjusts  its	memory
			allocation.

	      wt	Is group's memory weight. The value must be an integer
			greater than or equal to 1.  If you do not  specify  a
			memory	weight, WLM uses the group's CPU weight, which
			defaults to 1 if not specified.

       Consider the following example. We have four groups, with one  being  a
       PSET  group. The serves as an allocation (Alloc) for the groups because
       each group gets the amount of memory represented by its value.

	   Group       Alloc (gminmem)	     Weight	  Final alloc
	   ───────────────────────────────────────────────────────────────
	   A (PSET)	     10		  Unspecified	      10
	   B		     30		       3	      42
	   C		     20		       2	      28
	   OTHERS	     20		       1	      20

       First, A gets its because it is a PSET group. That leaves  90%  of  the
       memory  to  distribute. Next, is granted its memory. It has a of 1, and
       the sum of the values is 6. As a result, gets 1/6 * 90,	or  15%.  How‐
       ever,  15  is  less than its so it gets its of 20 instead. Now there is
       70% left. However, WLM guarantees the for the  groups  and  30  and  20
       respectively.  So,  there  is  only  20%	 to distribute between the two
       groups and This 20% is distributed so that the  groups'	final  alloca‐
       tions are proportional to their weights.

   slo structure
       Use  structures to specify the service-level objectives and assign pri‐
       orities to those objectives.

       The structure takes one of the two following forms. Both forms  require
       a priority. The first form may or may not have a goal.

       slo slo_name {
	   pri = priority;
	   [ entity = PRM group group_name; ]
	   [ mincpu = lower_bound_request; ]
	   [ maxcpu = upper_bound_request; ]
	   [ goal = goal_expression; ]
	   [ condition = condition_expression; ]
	   [ exception = exception_expression; ]
       }

       The second form of an structure uses the statement. This statement can‐
       not be used with a statement.

       slo slo_name {
	   pri = priority;
	   [ entity = PRM group group_name; ]
	   [ mincpu = lower_bound_request; ]
	   [ maxcpu = upper_bound_request; ]
	   cpushares = value { more | total } [ per metric met [  plus	offset
	   ]];
	   [ condition = condition_expression; ]
	   [ exception = exception_expression; ]
       }

       slo_name must not contain any slashes or start with an underscore (_).

       Here  are  several  example  structures.	 These	first two examples are
       strictly host-based, which means there are no PSETs or FSS groups being
       managed on the host.

       slo buying {
	  pri = 1;
	  mincpu = 50;
	  maxcpu = 200;
	  goal = metric stock_price_1 < 50;
	  condition = 09:00 - 16:00;
	  exception = Sat - Sun;
       }

       slo selling {
	  pri = 1;
	  mincpu = 50;
	  maxcpu = 300;
	  goal = metric stock_price_2 > 75;
	  condition = 09:00 - 16:00;
	  exception = Sat - Sun;
       }

       These next two examples are based on PRM groups. They use statements to
       indicate the associated PRM groups.

       slo analyzing {
	  pri = 2;
	  mincpu = 10;
	  maxcpu = 20;
	  entity = PRM group analyze;
	  goal = usage _CPU 75 90;
       }

       slo developing {
	  pri = 3;
	  entity = PRM group developers;
	  cpushares = 2 more per metric developer_count plus 10;
       }

   pri
       Each SLO must have a priority so WLM can determine CPU allocation  when
       the combined CPU requests of all SLOs exceed 100%.

       Specify an SLO's priority using the keyword and the following syntax:

       pri = priority;

       where

	      Is a required keyword.

	      priority	Is  an integer greater than or equal to 1. The value 1
			represents the highest priority. Multiple SLOs can  be
			assigned the same priority.

   entity
       If you plan on managing only virtual partitions or nPartitions--with no
       FSS groups or PSETs inside, the keyword is not needed.

       SLOs govern workloads that are based on workload groups. Each  workload
       group  must,  therefore,	 be  assigned an SLO. Specify the PRM group to
       which the SLO applies using the keyword and the following syntax:

       entity  = PRM group group_name;

       where

	      Is a required keyword when managing PSETs or FSS groups.

	      Is the mechanism used to control the resource allocation to
			the workload groups. Currently, is the only  supported
			mechanism.

	      Is  the  part of the control mechanism that represents the work‐
	      load group
			and can be individually controlled via resource	 allo‐
			cation. Currently, is the only supported attribute.

	      group_name
			Is  the	 name  of  the	PRM  group  to	which this SLO
			applies.

			You cannot specify in an structure.

   mincpu
   maxcpu
       WLM automatically changes CPU share allocations to enforce SLOs.	  How‐
       ever,  you  can limit allocations by specifying a minimum share alloca‐
       tion and a maximum share allocation for an SLO.	Specify	 these	values
       using the following syntax:

       mincpu = lower_bound_request;

       maxcpu = upper_bound_request;

       where

	      lower_bound_request
			Is  an	integer	 value	from 0 to upper_bound_request,
			inclusive.  lower_bound_request is the minimum	number
			of CPU shares the SLO is allowed to request, while the
			SLO is active.

			If an SLO does not  also  contain  a  statement	 or  a
			statement,  the	 lower_bound_request  value is used as
			the SLO's shares request. If an SLO does not contain a
			statement,   0	 is   used   as	  the	SLO's	shares
			request--although a value or value may keep the	 allo‐
			cation from actually being 0 shares.

			lower_bound_request is out of the total CPU resources,
			which is 100 multiplied by the number of cores (if you
			set  the  tunable  to 1 or it is implied by other ele‐
			ments in your configuration)--or just 100 by default.

			To have a minimum request of 2 cores on an 8-core sys‐
			tem with enabled, you would specify:

			If  you specify a lower_bound_request greater than the
			total CPU resources, WLM treats it  as	equal  to  the
			total CPU resources.

			When configuring WLM on a partition, be sure to select
			a value for lower_bound_request that  makes  sense  in
			terms  of  the	limits placed on the partition when it
			was created--namely its minimum and maximum number  of
			cores.

			The  lower_bound_request  value	 is  not a hard limit:
			Higher priority SLOs  may  consume  all	 CPU  resource
			before	all  SLOs are granted CPU resources.  However,
			the associated workload group's value is a hard limit.
			It  serves  as the group's minimum CPU allocation when
			it represents more CPU resources than the values  used
			in  the group's SLOs. The value is also used to deter‐
			mine the group's minimum CPU allocation in  SLOs  with
			statements  but	 no statements. For information on the
			default value, refer to the  discussion	 above.	 Simi‐
			larly, described above, is a hard limit for allocation
			to a host.

			For information on the effect of this keyword in  pas‐
			sive  mode,  refer  to the section PASSIVE MODE VERSUS
			ACTUAL WLM MANAGEMENT in the wlm(5) manpage.

	      upper_bound_request
			Is  an	integer	 value	greater	 than  or   equal   to
			lower_bound_request.  upper_bound_request is the maxi‐
			mum number  of	CPU  shares  the  SLO  is  allowed  to
			request, while the SLO is active.

			upper_bound_request is out of the total CPU resources,
			which is 100 multiplied by the number of cores (if you
			set  the  tunable  to 1 or it is implied by other ele‐
			ments in your configuration)--or just 100 by default.

			If you specify an upper_bound_request greater than the
			total  CPU  resources,	WLM  treats it as equal to the
			total CPU resources.

			To have a maximum request of 3 cores on an 8-core sys‐
			tem with enabled, you would specify:

			When configuring WLM on a partition, be sure to select
			a value for upper_bound_request that  makes  sense  in
			terms  of  the	limits placed on the partition when it
			was created--namely its minimum and maximum number  of
			cores.

			An  upper_bound_request	 may be ignored if the associ‐
			ated workload group's CPU resources are	 already  lim‐
			ited  by  the  group's value. In the case of SLOs with
			statements but no statements,  the  group's  value  is
			still  used  to limit CPU allocation.  For information
			on the default value of refer to the discussion above.
			Similarly,  described  above, can limit CPU allocation
			to a host.

			For information on the effect of this keyword in  pas‐
			sive  mode,  refer  to the section PASSIVE MODE VERSUS
			ACTUAL WLM MANAGEMENT in the wlm(5) manpage.

       For more information on absolute CPU units, refer to the section on the
       tunable.

   goal
       An  SLO	can have a goal that it attempts to achieve.  Specify an SLO's
       goal using the keyword and the following syntax:

       goal = goal_expression;

       where

	      Is an optional keyword. If neither the
			nor the keywords are specified, the SLO	 is  allocated
			resources according to its setting.

			You cannot specify both a statement and a statement in
			the same SLO. Similarly, you cannot  have  a  workload
			group  with  one  SLO that has a statement and another
			SLO that has a statement that includes

	      goal_expression
			Indicates either a usage goal or a metric goal. Use  a
			usage goal to ensure a workload group's utilization of
			its allocated CPU  falls  within  a  given  percentage
			range.	Usage goals are especially beneficial when you
			have a workload that cannot provide performance	 data.
			Usage goals are relatively easy to implement. WLM mon‐
			itors CPU utilization and can detect when applications
			are  busy  or  idle. Metric goals are based on perfor‐
			mance data and require	understanding  of  that	 data.
			Because	 you  can  implement  usage  goals immediately
			without prior knowledge of  workload  performance,  HP
			recommends  using  them	 instead of metric goals.  For
			details specific to metric goals, refer to the section
			"ADVANCED  WLM USAGE: CONFIGURATION DETAILS FOR METRIC
			GOALS" below.  Also, refer to the appendix in the  WLM
			User's	Guide (/opt/wlm/share/doc/WLMug.pdf), entitled
			"Advanced WLM: Using performance metrics."

       The syntaxes for these expressions are described below.	With  a	 usage
       goal,  WLM  adjusts a workload group's number of CPU shares to keep its
       CPU utilization within a certain range.	For  example,  if  a  workload
       group's processes are using 20 CPU shares and have a 50 CPU share allo‐
       cation, the group's utilization is 20/50 or 40%. WLM attempts to keep a
       workload group's utilization between a low and high bound.

       Typically,  you	should set to 5 when your WLM configuration contains a
       usage goal.

       Specify a usage goal as follows:

       low_util_bound high_util_bound

       where

	      low_util_bound
			Is an integer less than or equal  to  high_util_bound,
			but  greater  than or equal to 0. WLM attempts to keep
			the utilization percentage above this threshold value,
			which  is  50  by default.  It does so by reducing the
			number of shares requested whenever utilization	 drops
			below this value.

			Setting	 low_util_bound	 at or near 0 can result in an
			SLO that never reduces its number of requested shares.
			This  results  in  the	SLO  not  giving up its unused
			shares.

	      high_util_bound
			Is an integer greater than or equal to low_util_bound,
			but  less  than	 or equal to 100. WLM attempts to keep
			the utilization percentage under this threshold value.
			It   does  so  by  increasing  the  number  of	shares
			requested whenever utilization surpasses  this	value.
			When  not specified, this value defaults to the speci‐
			fied low_util_bound; when both are not specified, this
			value defaults to 75.

			Setting	 high_util_bound  at or near 100 can result in
			an SLO that never requests  a  larger  number  of  CPU
			shares.

       When WLM requests a change in the number of shares, the request is pro‐
       portional to how far the current utilization is below low_util_bound or
       above  high_util_bound.	 Use or in a structure with _CPU_group_name as
       the metric value to adjust the proportion, causing the  utilization  to
       move  into  the	desired	 range	more quickly or slowly. For example, a
       value of 10 will cause the utilization to move  in  larger  jumps  than
       will a value of 0.1.

       For  an	idea  of  how such a structure would look, consider a workload
       group named buy. Its structure would look like the following:

       tune _CPU_buy {
	  cntl_kp = 0.1;
       }
       You can specify metric goals if performance data is available.	Metric
       goals  are  based on performance data and require understanding of that
       data. For each metric goal, you select a performance metric (such as  a
       response-time  goal)  to	 measure the extent to which the goal is being
       met, exceeded, or underachieved.	 You also select how  the  performance
       data is collected for WLM.  For more information on metric goals, refer
       to the section "Specifying a metric goal in an SLO" below.

   cpushares
       An SLO can directly express a request for CPU shares using the keyword.
       For  more  information,	refer to the section "Specifying a shares-per-
       metric request in an SLO" below.

   condition
   exception
       Specify when an SLO is active by using the and keywords and the follow‐
       ing syntax:

       condition_expression;
       exception_expression;

       where

	      Is an optional keyword that specifies an expression that must be
	      true
			for the SLO to be active.

			Do not create a statement that attempts to detect pro‐
			cesses	in  a  transient  group using tools such as or
			Whenever the group is deleted (FSS group) or  assigned
			zero  CPU resources (PSET-based group), it is impossi‐
			ble for the system to place processes  in  the	group.
			The  condition will then never detect the processes it
			is looking for.

	      Is an optional keyword that specifies an expression that must be
	      false
			for the SLO to be active.

	      condition_expression

	      exception_expression
			Is  a Boolean expression containing logical statements
			that specify one or more of the following components:

			·  metric met > numeric_value

			·  metric met < numeric_value

			·  metric met

			·  A date

			·  A date range

       Combine Boolean expressions by using the && (AND), || (OR), and ! (NOT)
       operators.  The	order of precedence for these operators is: !, &&, and
       ||. Parentheses can be used to alter the order of  evaluation.  Example
       combinations follow.

       In  this	 example,  the	SLO is active only if the day is a Monday or a
       Friday:

       condition = Mon || Fri;

       Here, the SLO is active only if there are more than 5 active  processes
       and it is between 8pm and 11pm:

       condition = (metric process_count > 5) && (20:00 - 22:59);

       The met value must have an associated structure. The numeric_value must
       be a floating-point value, either positive  or  negative.  The  "metric
       met"  expression	 is  false  if met equals 0. For all other values, the
       expression is true.

       Specify a date using the following syntax:

			    where

		     Is the name of the weekday: Mon, Tue, Wed, Thu, Fri, Sat,
		     or Sun.

		     Is the date that takes
			       values  1-12,  values 1-31, and values as four-
			       digit years.  An asterisk (*) can  be  used  in
			       place  of  or to indicate that all valid values
			       are accepted.

		     Is the time and represents the hours  and	minutes	 on  a
		     24-hour clock.
			       An  asterisk  (*) can be used in place of or to
			       indicate that all valid values are accepted.

       A date range is specified by a start-date and an end-date separated  by
       a  dash	character (-). There are 10 valid date formats in a range, and
       both start and end dates must use the same format.  Those  formats  are
       shown below with examples:

	      01/07/2000 -- The author's 39th birthday.

	      15:30 -- Every day at 3:30pm.

	      Mon -- Every Monday.

	      01/07/2000 08:30 -- January 7th, 2000 at 8:30am

	      Mon 08:00 -- Every Monday at 8:00am.

	      01/07/* -- Every January 7th.

	      */15/* -- The 15th of every month every year.

	      *:00 -- Every hour at the top of the hour.

	      01/07/* 08:30 -- Every January 7th at 8:30am.

	      */07/* 11:30 -- The 7th of every month every year at 11:30am.

   tune structure
       Use structures to specify the data collector and its command-line argu‐
       ments for SLOs, set the WLM daemon's  interval  for  checking  for  new
       data,  distribute excess CPU resources to your defined workload groups,
       enable automatic log file trimming, and to set various controller vari‐
       ables.

       There are three types of structures. They are given below, ordered from
       most generic to most specific. Note that many of the elements are  com‐
       mon among the three different types of structures.

       Global structure
	      This structure applies to all metrics and SLOs. It does not ref‐
	      erence the name of any metric or SLO. It can  be	specified,  at
	      most, once in the configuration file.

	    tune {
	       [ wlm_interval = number_of_seconds; ]
	       [ absolute_cpu_units = { 0 | 1 }; ]
	       [ distribute_excess = { 0 | 1 }; ]
	       [ extended_shares = { 0 | 1 }; ]
	       [ transient_groups = { 0 | 1 }; ]
	       [ wlmdstats_size_limit = number_of_megabytes; ]
	       [ coll_argv = data_collector_and_arguments; ]
	       [ coll_stderr = file; ]
	       [ cntl_smooth = smoothing_value; ]
	       [ cntl_avg = { 0 | 1 }; ]
	       [ cntl_kp = proportional_term; ]
	       [ cntl_convergence_rate = number_of_shares; ]
	       [ cntl_margin = margin_value; ]
	       [ cntl_base_previous_req = { 0 | 1 }; ]
	    }

       Metric-specific structure
	      This  structure  applies to all SLOs that use the specified met‐
	      ric.  It can be specified, at most, once per metric.

	    tune metric {
	       [ coll_argv = data_collector_and_arguments; ]
	       [ coll_stderr = file; ]
	       [ cntl_smooth = smoothing_value; ]
	       [ cntl_avg = { 0 | 1 }; ]
	       [ cntl_kp = proportional_term; ]
	       [ cntl_convergence_rate = number_of_shares; ]
	       [ cntl_margin = margin_value; ]
	       [ cntl_base_previous_req = { 0 | 1 }; ]
	    }

       Metric/SLO-specific structure
	      This structure applies to the specified metric/SLO pair.	It can
	      be specified, at most, once per metric/SLO pair. Its syntax is:

	    tune metric slo_name {
	       [ cntl_kp = proportional_term; ]
	       [ cntl_convergence_rate = number_of_shares; ]
	       [ cntl_margin = margin_value; ]
	       [ cntl_base_previous_req = { 0 | 1 }; ]
	    }

       In  cases  where	 two or more structures could apply, the more specific
       structure type takes precedence.

       Here are some example structures:

       tune {
	  wlm_interval = 30;
	  distribute_excess = 1;
	  extended_shares = 1;
	  transient_groups = 1;
       }

       tune fin_app.query.resp_time {
	  coll_argv = /opt/fin_app/finance_collector -a 123 -v;
	  cntl_kp = 0.8;
       }

       tune sales_app.resp_time {
	  coll_argv = /opt/sales_app/monitor -threshold 2 -freq 30 ;
	  cntl_kp = 2.0;
	  cntl_margin = 0.2;
       }

       tune reports_app.resp_time {
	  coll_argv = wlmrcvdc /opt/reports_app/rptmon;
	  cntl_kp = 1.5;
       }

   coll_argv
       Valid in: global and metric-specific structures

       Whenever you use a metric in your WLM configuration, you need to supply
       a  value	 for  that  metric. The statement launches a data collector to
       gather values for a metric. You can specify a data collector in a  met‐
       ric-specific  structure	to gather values for that one metric. For more
       information, see the section "Specifying a data	collector  in  a  tune
       structure" below.

   wlm_interval
       Valid in: global structures

       The  WLM	 daemon	 periodically checks for new performance data from the
       data collectors. It also	 automatically	adjusts	 CPU  shares  on  that
       interval.  The  default	interval  is  60 seconds, however, that can be
       altered using the following tuning construct. Specify the WLM  interval
       using the tunable and the following syntax:

       wlm_interval = number_of_seconds;

       where

	      Is an optional tunable.

	      number_of_seconds
			Number	of  seconds,  ranging from 1 to 86400 (1 day),
			that the WLM daemon waits before checking for new data
			from  the  data collectors and adjusting CPU shares if
			needed.

			Typically, number_of_seconds should be 5 when your WLM
			configuration contains a usage goal.

			When  generating  audit	 data  (with the option), num‐
			ber_of_seconds should be no more than 60 to ensure the
			audit data sampling rate is sufficiently frequent to:

			·  Minimize  the  amount of audit data lost if the WLM
			   daemon exits unexpectedly

			·  Minimize the effect of changes  in  the  number  of
			   available cores (due to WLM's management of virtual
			   partition, nPartition, Instant Capacity,  Temporary
			   Instant Capacity, and Pay per use cores)

			If you are running WLM within an Integrity VM (guest),
			specify an interval length greater  than  60  seconds.
			This  helps  ensure a fair allocation of CPU resources
			for FSS groups.

       The tunable is valid only in global structures.

   absolute_cpu_units
       Valid in: global structures

       With the tunable, you can control whether the CPU  units	 used  by  the
       following keywords/tunables are absolute or relative:

	      ·

	      ·

	      ·

	      ·

	      ·

	      ·

	      ·

       With  absolute  CPU units enabled (absolute_cpu_units = 1), you specify
       CPU units in terms of 100, where 100 represents an entire core  of  CPU
       resources. So, if you want a of half a core, you would specify:

	  mincpu = 50;

       If you want a of two cores, you would specify:

	  maxcpu = 200;

       Absolute CPU units are used when the number of active cores changes due
       to WLM's management of Instant Capacity,	 Temporary  Instant  Capacity,
       Pay  per use, Virtual Partition, or nPartition resources. Regardless of
       the number of active cores, the absolute CPU units represent  the  same
       amount of cores. HP recommends using absolute CPU units.

       With relative CPU units the units you specify represent a percentage of
       the system's total CPU resources (cores) and are consequently  relative
       to the number of active cores. For example, the following statement:

	  mincpu = 50;

       is  50%	of  the	 system's CPU resources, which is 50% of one core on a
       system with only one active core, but is eight cores on a  system  with
       16 active cores.

       Relative	 CPU  units is the default. To set it explicitly, use the fol‐
       lowing statement:

	  absolute_cpu_units = 0;

       Several conditions involving can cause your WLM configuration  file  to
       be invalid:

	      · Setting equal to 0 and setting

	      · Setting	 equal	to  0  in a configuration that does not have a
		structure

	      · In a configuration with a structure:

		* Setting equal to 0 and specifying a PSET group

	      · In a configuration without a structure:

		* Setting equal to 0 and setting

		* Setting equal to 0 and setting

		* Setting equal to 0 and setting

   distribute_excess
       Valid in: global structures

       By default, if any CPU resources remain after satisfying all SLOs,  the
       remainder is given to the group. To distribute this excess to the work‐
       load groups you have defined, set the tunable to 1 in a	global	struc‐
       ture:

       tune {
	  distribute_excess = 1;
       }

       Only workload groups with active SLOs receive the excess CPU resources.

       This distribution is based on balancing the weight-to-allocation ratios
       for the workload groups. These ratios  are  discussed  in  the  keyword
       description in this manpage.

       The  distribution  is subject to the group CPU maximum values specified
       by the keyword. If the excess CPU is not fully distributed  because  of
       group  CPU  maximum  values,  the  excess  is  given  to	 the  group as
       usual--even if giving this excess places it over its value.

       The default value for is 0.

   extended_shares
       Valid in: global structures.

       By default, allocations to FSS groups are based on 100 shares per  core
       of  CPU resources.  The minimum allocation to groups with inactive SLOs
       is one share or 1% of a core. If you are using WLM  memory  management,
       the  group  receives  1% of memory.  You can refine the granularity for
       minimum allocations by setting the tunable to  1	 (true)	 in  a	global
       structure:

       tune {
	  extended_shares = 1;
       }

       In this way, CPU minimum allocations are based on 1000 shares per core.
       This requires that you use absolute CPU units,  which  is  also	recom‐
       mended (set to 1). Minimum allocations of memory are also based on 1000
       units instead of 100.

       With enabled, the minimum allocation for a group with  no  active  SLOs
       (assuming  is  disabled) decreases from 1/100 core or 1% to 2/1000 core
       or 0.2%.	 Granularity for minimum allocations  can  be  based  on  0.1%
       increases (for example, 0.3%, 0.4%, 0.5%).  With enabled,  WLM can sup‐
       port 256 groups starting with HP-UX 11i V2 Update 2 (the 64-group limit
       is still in effect on HP-UX 11i V1).

       The default value for is 0.

       Enable if:

	      ·	 You  want finer granularity of allocation to FSS groups. This
		 might be preferred when the number of FSS groups or cores  is
		 large.

	      ·	 You want to use more than 63 FSS workload groups.

       Enable instead of if you want to prevent groups from being removed when
       they become inactive, while providing smaller  minimum  allocations  to
       these groups.

       Regardless of the value of all configuration file values and all values
       that are output by are based on hundredths  (when  using	 absolute  CPU
       units).	Enabling affects the granularity for all allocations and makes
       possible smaller minimum allocations.

   transient_groups
       Valid in: global structures

       By default, all workload groups are always present--even those with  no
       active  SLOs. An FSS group with no active SLOs still requires 1% of the
       total CPU resources for FSS groups (if the tunable is enabled,  an  FSS
       group  requires 0.2%).  A PSET-based group with no active SLOs requires
       at least a whole core.  However, if the value requests  more  than  the
       minimum	allocation required for the group, the group receives the num‐
       ber of CPU resources specified by that value.  Similarly,  if  you  are
       using  WLM's  memory  management,  the  workload	 with  no  active SLOs
       receives 1% of the memory (or 0.2% of the  memory  if  the  tunable  is
       enabled), unless the workload has a value requesting more.

       If  you	prefer	groups	with no active SLOs to go away temporarily (as
       long as they have  no  active  SLOs)  and  consume  no  CPU  or	memory
       resources, set the tunable to 1 in a global structure:

	  tune {
	     transient_groups = 1;
	  }

       Setting	equal  to  1 in a configuration that does not have a structure
       results in an invalid configuration.

       With the keyword set to 1: FSS groups with no active SLOs  are  deleted
       and  therefore  use  no	resources; the minimum CPU allocation for PSET
       groups becomes 0.  However, groups associated with process maps	always
       remain active even if the groups have no active SLOs.

       Using  the keyword does not throttle the resource usage of processes in
       transient groups that  are  inactive.  In  fact,	 those	processes  are
       moved--possibly	to  groups where they get more resources, as discussed
       in the "Placement of processes" sections below.

       The group is never removed, regardless of its number of active SLOs.

       If an FSS workload group has been temporarily removed, its  and	values
       (if any) are ignored.

       To  prevent  groups from being removed when they become inactive, while
       providing them smaller minimum allocations, enable the tunable  instead
       of the tunable.

       Do  not create a statement that attempts to detect processes in a tran‐
       sient group using tools such as or Whenever the group is	 deleted  (FSS
       group)  or assigned zero CPU resources (PSET-based group), it is impos‐
       sible for the system to place processes in the  group.	The  condition
       will then never detect the processes it is looking for.	With if an FSS
       workload group, say  has	 no  active  SLOs,  but	 does  have  processes
       assigned	 to  it	 by  user  records,  Unix  group  records, application
       records, or compartment records, WLM moves its processes to a temporary
       group  named  This  group has only the minimum CPU and memory resources
       and can greatly restrict the progress of a  process.  When  has	active
       SLOs again, the processes placed in by records are moved back to

       If  a process is not assigned to a group by a record, it is moved to or
       if its current group is removed. The process remains in	or  even  when
       the  group  has	active	SLOs  again. For this reason, be cautious when
       using only or to place a process in an FSS group that may  be  removed.
       Using  user  records,  Unix group records, application records, or com‐
       partment records for  processes	that  go  into	transient  FSS	groups
       ensures	those  processes  return to the desired groups when the groups
       return.	However, note that groups associated with process maps	always
       remain active even if the groups have no active SLOs.  (For information
       on how WLM determines which group assignment takes precedence when  the
       same  process  matches multiple records, see the "Precedence of records
       for group assignments" section.)	 The placement of processes in a PSET-
       based  group depends on whether the group has CPU resources assigned to
       it. With the group can have 0 cores if you request it or if  the	 group
       has no active SLOs.

       Assume  a PSET-based workload group, say has no cores. Any processes in
       the group when its last CPU is taken away, as well as processes you try
       to  place in the group using or when the group has no cores, are placed
       in the group.

       To minimize the number of processes moved to assign at least  one  core
       to PSET-based groups that have running processes.

       When  has CPU resources again, the processes placed in by user records,
       Unix group records, application records,	 or  compartment  records  are
       moved  back  to	Similarly, any processes you attempted to place in the
       group with or are moved to the group.   (For  information  on  how  WLM
       determines  which  group	 assignment  takes  precedence	when  the same
       process matches multiple records, see the "Precedence  of  records  for
       group assignments" section.)  When WLM is managing PSETs, do not change
       PSET settings by using the command. Whenever possible, use WLM to  con‐
       trol PSETs.

   coll_stderr
       Valid in: global and metric-specific structures

       Use the tunable to capture the stderr of your data collectors. For more
       information, refer to the  section  "Capturing  your  data  collector's
       stderr" below.

   cntl_smooth
       Valid in: global and metric-specific structures

       Use  the	 keyword to get a running average of a metric from a data col‐
       lector, smoothing out dips and spikes in the metric before it  is  used
       by  WLM.	  For more information, refer to the section "Smoothing metric
       values" below.

   cntl_avg
       Valid in: global and metric-specific structures

       Use the tunable to control averaging in usage controllers. By  default,
       averaging  is  enabled  With  averaging	disabled  only the most recent
       interval's usage data is used for a usage metric.

       This tunable is ignored for metrics that are not CPU usage metrics.

   wlmdstats_size_limit
       Valid in: global structures

       Use  the	 tunable  to   enable	automatic   trimming   of   the	  file
       /var/opt/wlm/wlmdstats,	which  is created when you use the option. The
       syntax is:

       wlmdstats_size_limit = number_of_megabytes;

       where

	      Is an optional tunable. Specify this tunable in a global
			structure.

	      number_of_megabytes
			Is an integer value from 0 to 2048. Once a file's size
			is  greater  than  number_of_megabytes,	 the  file  is
			trimmed. The default value is 0, which disables	 auto‐
			matic  trimming.  The  wlmdstats  file	is  trimmed by
			renaming it wlmdstats.old. Then a new  wlmdstats  file
			is  started. The wlmdstats.old file includes a line at
			the end of the file indicating that the file has  been
			automatically trimmed.

   cntl_kp
       Valid in: global, metric-specific, and metric/SLO-specific structures

       The  tunable  allows  you  to tune a workload group's convergence on an
       SLO. You can also tune convergence with the tunable  discussed  in  the
       next  section. The tunable, which uses normalization to arrive at a new
       CPU allocation, is typically easier  to	use--requiring	less  analysis
       than

       WLM  starts  a  performance controller for each goal-based SLO. It also
       starts a usage controller for each usage goal. Each  controller	calcu‐
       lates  new CPU shares requests if the reported data indicates the work‐
       load group is overachieving or underachieving its goal. The  controller
       then  requests the new number of CPU shares. To determine the new allo‐
       cation (number of CPU shares), the controller effectively  performs  an
       algorithm that, when plugging in (as opposed to cntl_convergence_rate),
       is represented as follows:

       New CPU allocation = (Allocation last interval) + cntl_kp * P

       WLM calculates P based on the goal type, as indicated below:

       Metric goal with met < value:

	      P = met - value

	      where, as defined in the goal_expression, met is some metric for
	      the workload and value is a goal value for the metric.

       Metric goal with met > value:

	      P = value - met

       Usage goal:

	      P = Actual utilization - Target utilization

	      Target  utilization is either low_util_bound or high_util_bound.
	      If actual utilization is below low_util_bound, then

	      P = Actual utilization - low_util_bound

	      If actual utilization is above high_util_bound,

	      P = Actual utilization - high_util_bound

       Specify the proportional term of the controller's expression using  the
       tunable and the following syntax.

	cntl_kp = proportional_term;

       where

	      Is an optional tunable. NOTE: Although this tunable is optional,
	      you
			should fine-tune each controller to  the  characteris‐
			tics of its workload.

	      proportional_term
			Is  a  floating-point  value  between  0 and 1,000,000
			(inclusive) used on the proportional term in the  con‐
			troller's expression. The default value is 1.

			Change this value according to how sensitive the SLO's
			associated workload is to changes in its  CPU  alloca‐
			tion and based on the magnitude of the goal being mea‐
			sured.

			Recall the  formula  for  determining  new  allocation
			requests:

			New CPU allocation = (Allocation last interval)
					      + cntl_kp * P

			If  P is typically large, say 10 or 100 or higher, use
			a smaller cntl_kp to scale down the cntl_kp * P result
			so  it does not overcorrect. Similarly, for very small
			values of P (less than 1), use cntl_kp to scale up the
			cntl_kp * P result.

			If  WLM	 changes allocations too rapidly, resulting in
			instability,  decrease	proportional_term.    If   WLM
			changes	  allocations  too  slowly,  increase  propor‐
			tional_term.

			With  absolute	CPU  units   enabled,	your   propor‐
			tional_term  maintains	more predictable behavior from
			your workload regardless of the	 number	 of  available
			cores.	Without	 absolute  CPU	units, the effect of a
			given  proportional_term  depends  on  the  number  of
			available   cores,  which  could  produce  undesirable
			effects. HP recommends using absolute CPU units.

			A proportional_term equal to 0, when  applied  to  the
			formula for determining new allocations:

			New  CPU  allocation  =	 (Allocation  last interval) +
			cntl_kp * P

			results in the formula:

			New CPU allocation = (Allocation last interval)

			which leads  to	 no  change  in	 an  SLO's  allocation
			request.

       For  more  information on how to tune, refer to the white paper "Tuning
       HP-UX Workload Manager" at /opt/wlm/share/doc/howto/tuning.html.

   cntl_convergence_rate
       Valid in: global, metric-specific, and metric/SLO-specific structures

       The tunable allows you to tune a workload  group's  convergence	on  an
       SLO.  You  can  also tune convergence with the tunable discussed in the
       previous section. (If is not zero, it is used instead of Using the tun‐
       able  changes the allocation algorithm to take the goal value into con‐
       sideration, effectively normalizing the result by the goal's magnitude.
       Given  the normalization that provides, as well as the greater analysis
       required to fine-tune the tunable, you may want to use first.  In  many
       cases,  setting	will  provide  the  desired  convergence and meet your
       needs.

       For each performance and usage goal, WLM must determine the appropriate
       number  of CPU shares needed to achieve that goal. To do this, WLM cre‐
       ates a controller for each such goal.

       To determine the new CPU shares allocation, each controller effectively
       executes	 an  algorithm that, when plugging in (as opposed to cntl_kp),
       is represented as follows:

       New CPU allocation = (Allocation last interval) +
			     (cntl_convergence_rate / 0.10) * (P / goal)

       P is the deviation from the goal and is calculated as shown in the pre‐
       vious  section.	There are two special cases to consider in the formula
       above:

	      ·	 For goal = 0, "(P / goal)" becomes "P"

	      ·	 For  usage  goals,  goal   becomes   the   average   of   the
		 low_util_bound and high_util_bound values:
		 "(low_util_bound + high_util_bound) / 2"

       As  a  tunable, can be specified in a global, metric-specific, and slo-
       specific structure. Its value is inherited from a higher	 level	struc‐
       ture if you do not specify it at a given level. Its syntax is:

       cntl_convergence_rate = number_of_shares;

       where

	      Is  a tunable parameter for the controller indicating the number
	      of CPU
			shares by which to adjust a workload  group's  alloca‐
			tion when it differs from its goal. It is specified in
			the WLM configuration file.  NOTE: Although this  tun‐
			able is optional, you should fine-tune each controller
			to the characteristics of its workload.

	      number_of_shares
			Is a floating-point value that represents  the	number
			of  shares  (either  absolute  or relative) by which a
			workload group's CPU allocation is adjusted  when  its
			service	 level	differs from its goal by 10%. When the
			difference is less than 10%, the adjustment is propor‐
			tionally  smaller  than	 number_of_shares.  Similarly,
			when the difference is greater than 10%,  the  adjust‐
			ment is proportionally larger than number_of_shares.

			The  larger  number_of_shares  is,  the	 larger	 WLM's
			adjustments to the  workload  group's  CPU  allocation
			are.   This  generally	produces faster convergence on
			the SLO goal.

			If WLM changes allocations too rapidly,	 resulting  in
			instability,   decrease	  number_of_shares.    If  WLM
			changes	 allocations   too   slowly,   increase	  num‐
			ber_of_shares.

			With absolute CPU units enabled, your number_of_shares
			maintains more predictable behavior from your workload
			regardless  of	the number of available cores. Without
			absolute  CPU  units,  the  effect  of	a  given  num‐
			ber_of_shares  depends	on  the	 number	 of  available
			cores, which could  produce  undesirable  effects.  HP
			recommends enabling absolute CPU units.

   cntl_margin
       Valid in: global, metric-specific, and metric/SLO-specific structures

       Specify	the  margin  of	 error	in attaining the specified metric goal
       using the tunable and the following syntax.

       cntl_margin = margin_value;

       where

	      Is an optional tunable.

	      margin_value
			Is a floating-point value between 0 and 1  (inclusive)
			indicating  a  percentage distance away from the SLO's
			goal.  The default value is 0.1, representing 10  per‐
			cent.

			WLM uses this value to re-target the goal it is trying
			to converge on. For example, with  a  margin_value  of
			0.1  and  a  goal  of  X,  the re-targeted goal is X -
			(0.1*X). The controller adjusts the goal  up  or  down
			(based on whether the goal is > or <) by this percent‐
			age to create a buffer zone. This adjustment  prevents
			small  fluctuations  in the service level from causing
			SLO violations.

       For more information on how to use the  tunable,	 refer	to  the	 white
       paper  "Tuning HP-UX Workload Manager" at /opt/wlm/share/doc/howto/tun‐
       ing.html.

   cntl_base_previous_req
       Valid in: global, metric-specific, and metric/SLO-specific structures

       By default, this keyword is set to 1, which can be beneficial when  you
       are  using WLM's global arbiter to manage virtual partitions or nParti‐
       tions or when your WLM configuration has at least one PSET-based	 work‐
       load group with an SLO.

       WLM  creates a controller for each structure that has a statement. Con‐
       trollers make requests to the WLM arbiter for shares allocations.  Set‐
       ting  can  result  in  some  controllers	 requesting CPU resources more
       aggressively; however, the distribution of  CPU	resources  may	become
       unfair due to artificially high resource requests.

ADVANCED WLM USAGE: CONFIGURATION DETAILS FOR METRIC GOALS
       This  section  includes miscellaneous information about configuring WLM
       to use performance metrics and to satisfy  metric  goals.  You  provide
       metric data to WLM so that it can:

	      · Determine  new	resource  allocations,	allowing  the workload
		groups to achieve their SLOs

	      · Set shares-per-metric allocations

	      · Enable or disable SLOs

   Sources for metric data
       Sources for metric data include:

	      · Existing metrics (from log files,  scripts,  or	 commands  you
		already have in place)

	      · ARM-instrumented applications

	      · GlancePlus

	      · Oracle databases

	      · C source code modified to use the WLM API

       For more information on these sources as well as background information
       on metric collection, refer to the wlm(5) manpage or  the  appendix  in
       the  WLM User's Guide (/opt/wlm/share/doc/WLMug.pdf) entitled "Advanced
       WLM: Using performance metrics." For information on how to provide met‐
       rics  to	 WLM,  refer  to the section "Specifying a data collector in a
       tune structure" below.

   Specifying a metric goal in an SLO
       Specify a metric goal in an SLO as follows:

       met relation value

       where

	      met	Is the text string naming the metric to	 be  used  for
			the  SLO.  The metric string must also be specified in
			a structure that indicates the path to the  data  col‐
			lector	executable  providing  the metric.  met cannot
			contain the slash (/) character, start with an	under‐
			score (_), or be more than 255 characters.

	      relation	Is if met is supposed to be less than value, or if met
			is supposed to be greater than value.

	      value	Is a numeric goal value, either	 an  integer  (greater
			than  or  equal	 to 1) or a floating-point number, not
			expressed in exponential notation.

   Specifying a shares-per-metric request in an SLO
       An SLO can directly express a request for CPU shares  in	 the  form  "x
       shares  of  CPU	resources  for	each  metric  y."  To define an SLO to
       request CPU shares in this way, specify the keyword, using the  follow‐
       ing syntax:

       cpushares = value { more | total } [ per metric met [ plus offset ]];

       where

	      Is an optional keyword for making a CPU shares request.
			Using  the  variables  in  the	syntax statement shown
			above,	  a    request--which	  we	 will	  call
			request_value--equates to one of the following forms:

			value
			value * met
			value * met + offset

			A request is additive when using the keyword and abso‐
			lute when using the keyword. You must  specify	either
			or with the keyword.

			You cannot specify both a statement and a statement in
			the same SLO. Similarly, you cannot  have  a  workload
			with one SLO that has a statement and another SLO that
			has a statement that includes

	      value	Specifies the number of CPU shares to request for  the
			associated  workload  group.  This  value is either an
			integer or a floating-point number, not	 expressed  in
			exponential notation.

	      Makes additive shares requests by adding the
			request_value  (discussed  in the keyword description)
			to other additive requests at the same priority and to
			any  requests  from higher priority SLOs. If there are
			no higher priority SLOs, the request is added  to  the
			workload  group's  value,  which is 1% of the system's
			total CPU resources by default.	  If  the  tunable  is
			enabled (absolute_cpu_units = 1), the workload group's
			value is 0.2% of the system's total CPU	 resources  by
			default.

			request_value  is  bounded by the SLO's and values, if
			specified.

			If the workload group can get a larger	allocation  of
			shares	from an SLO with an absolute shares request at
			that priority, it does so. This absolute  request  can
			come  from  an	SLO that uses with or from an SLO that
			uses only the and keywords.

	      Makes absolute shares requests starting from 0. The  request  is
	      exactly
			equal  to  request_value  (discussed  in  the  keyword
			description), within the bounds formed	by  the	 SLO's
			and values, if specified.

			If  the	 associated  workload  group  can get a larger
			allocation of shares from higher priority SLOs or from
			other SLOs at the same priority making absolute shares
			requests, it does so.

	      Is an optional clause.
			Using includes the result of multiplying value by  the
			metric	met in request_value (discussed in the keyword
			description).

	      met	Is the text string naming the metric to be used.   The
			metric	string	must  also be specified in a structure
			that indicates the path to  the	 data  collector  exe‐
			cutable	 providing the metric.	met cannot contain the
			slash (/) character, start with an underscore (_),  or
			be more than 255 characters.

	      Is an optional clause, for use only with the
			clause,	 that  allows  you to increase or decrease the
			number of CPU shares to be requested as	 part  of  the
			request_value,	which  is  discussed  in  the  keyword
			description.

	      offset	Is a floating-point value (either  positive  or	 nega‐
			tive)  specifying  the	number	of shares to use as an
			offset in the request_value (discussed in the  keyword
			description).

       Here  are  some	request_value expressions and the corresponding state‐
       ments:

       request_value = 25
       cpushares = 25 total;

       request_value = 10 * X + 30
       cpushares = 10 total per metric X plus 30;

       Consider the following example of an additive shares request:

       slo additive_example {
	       pri = 1;
	       mincpu = 0;
	       maxcpu = 50;
	       entity = PRM group App1;
	       cpushares = 5 more per metric application_procs;
       }

       Assume this is App1's only SLO at this priority. Also assume is 20  and
       application_procs (the number of processes the application has running)
       is 3. The SLO requests 35 CPU shares: 5 shares for each of the  3  pro‐
       cesses the application has running plus 20 shares from

       The  next  example  shows an absolute shares request. It is the same as
       the additive example above--except it uses in place of

       slo absolute_example {
	  pri = 1;
	  mincpu = 0;
	  maxcpu = 50;
	  entity = PRM group App1;
	  cpushares = 5 total per metric application_procs;
       }

       Again, assume application_procs is 3. This time, because it is an abso‐
       lute  request,  the  request  starts  from  0,  not the previous shares
       request. Consequently, the request is 5 CPU shares for each  of	the  3
       application  processes  in  workload group App1 for a total of 15. How‐
       ever, the request is ignored as the group already has 20 shares because
       of its setting.

   Specifying a data collector in a tune structure
       Whenever you use a metric in your WLM configuration, you need to supply
       a value for that metric. To gather values for a specific metric, launch
       a  data collector in a metric-specific or global structure by using the
       statement. This statement is valid in global and metric-specific struc‐
       tures.	If  multiple  metrics use the same command, such as to collect
       values, you can specify the command in a global structure,  instead  of
       specifying  it  separately  for	each metric in its own metric-specific
       structure.

       The syntax is:

       coll_argv = data_collector_and_arguments;

       where

	      Is a required keyword if the SLO has a metric goal.

	      data_collector_and_arguments
			Is the absolute path to a  data	 collector,  plus  any
			arguments.  Separate  arguments	 with white space. Use
			double quotes to form single arguments to an option or
			when using special characters.

			Data  collectors are spawned when the configuration is
			activated by

			stdout and stderr for each data collector are sent  to
			/dev/null;  however,  you  can	capture	 a collector's
			stderr using the tunable.

			There is no expansion of wildcards in the data_collec‐
			tor_and_arguments string.

			WLM  provides  a data collector named You can use with
			to feed data you collect to WLM.  You can also use  to
			send  metrics  from  GlancePlus,  Oracle,  and various
			other products to WLM. For more information, refer  to
			wlmrcvdc(1M). For an example using see the one below.

			Data  collectors  invoked  by  WLM run as root and can
			pose a	security  threat.   Hewlett-Packard  makes  no
			claims of any kind with regard to the security of data
			collectors not provided by  Hewlett-Packard.  Further‐
			more,  Hewlett-Packard	shall  not  be	liable for any
			security breaches resulting from the use of said  data
			collectors.

       Here  is	 a  partial  WLM  configuration showing the use of in a global
       structure.

       # Global wlmrcvdc to collect any metric values sent in via wlmsend:
       tune {
	       coll_argv = wlmrcvdc;
       }

       # Collector to use instead of the global wlmrcvdc to get values
       # for the metric order_transaction_time:
       tune order_transaction_time {
	       coll_argv = /home/orders/data_collector;
       }

       # Value of metric analysis_application_running given to WLM by wlmsend
       # through global wlmrcvdc
       slo analysis {
	       ...
	       condition = metric analysis_application_running;
	       ...
       }

       # Value of metric job_count given to WLM by wlmsend through
       # global wlmrcvdc
       slo batch_processing {
	       ...
	       cpushares = 2 more per metric job_count;
	       ...
       }

       # Uses metric value given by collector in metric-specific tune structure
       slo order_processing {
	       ...
	       goal = metric order_transaction_time < 10.0;
	       ...
       }

       If you are using WLM with Serviceguard, you might consider using	 in  a
       global structure with to check the status of all the Serviceguard pack‐
       ages  on	 the  current  system.	For   more   information,   refer   to
       sg_pkg_active(1M).

   Capturing your data collector's stderr
       Because	data  collectors  are started by a daemon process, they do not
       have a stderr on which to communicate errors. The tunable allows you to
       capture	these  errors.	You can specify in a metric-specific or global
       tune structure. Use the following syntax:

       coll_stderr = file;

       where

	      Is an optional tunable with a default value of /dev/null.	 Spec‐
	      ify this
			tunable in global or metric-specific structures.

	      file	Is  either  (which corresponds to syslog on the system
			through the command) or the full path to a  file.  For
			example:

			tune num_users {
			   ...
			   coll_stderr = syslog;
			   ...
			}

			tune load_average {
			   ...
			   coll_stderr = /logs/load_average.stderr;
			   ...
			}

			There  are no restrictions on the file specified. How‐
			ever, specifying system	 files	or  files  created  by
			applications   on   your   system   (such   as	 WLM's
			/var/opt/wlm/msglog and /var/opt/wlm/wlmdstats) is not
			recommended as it can damage the files.

   Smoothing metric values
       To  get	a running average of a metric from a data collector, smoothing
       out dips and spikes in the metric before it is used  by	WLM,  use  the
       keyword	in  a  metric-specific	or global structure. Use the following
       syntax:

       cntl_smooth = smoothing_value;

       where

	      Is an optional tunable that provides exponential smoothing.

	      smoothing_value
			Is a floating-point value ranging from 0 to 0.999. The
			default	 value is 0, resulting in no smoothing. Values
			closer to 1 result in more smoothing.

			For example, assume your workload generates  the  met‐
			rics  1,  7,  and  8--in  that	order.	With a smooth‐
			ing_value of 0.4, the values WLM gets are 1, 4.6,  and
			6.64.  With  a	smoothing_value of 0.8, the values are
			more smoothed, with WLM getting 1, 2.2, and 3.36.

       Do not use for metrics that are expected to equal zero in  SLO  expres‐
       sions. For example, do not use smoothing globally if your configuration
       uses the collector to indicate a Serviceguard package is active (1)  or
       inactive (0).  You  could  use  in metric-specific structures in such a
       configuration, as long as those structures are not for Boolean metrics.

       Smoothing occurs only in WLM intervals in which a new metric  value  is
       received.

       The metric value reported in the log file /var/opt/wlm/wlmdstats is the
       smoothed value.

AUTHOR
       was developed by HP.

FEEDBACK
       If you would like to comment on the current HP-UX WLM functionality  or
       make suggestions for future releases, please send email to:

       wlmfeedback@rsn.hp.com

FILES
       Workload Manager daemon

       Workload Manager global arbiter daemon

       optional statistics log

SEE ALSO
       wlmd(1M), wlmpard(1M), wlm(5), wlmcw(1M), wlmgui(1M), wlmsend(1M), wlm‐
       rcvdc(1M),  libwlm(3),  netgroup(4),  wlmparconf(4),  prmrun(1),	  prm‐
       move(1), prm(1)

       HP-UX Workload Manager User's Guide (/opt/wlm/share/doc/WLMug.pdf)

       HP-UX Workload Manager homepage (http://www.hp.com/go/wlm)

								    wlmconf(4)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net