New in this edition

WLM A.03.02.02 supports HP-UX 11i v3 (B.11.31).

WLM A.03.02.02 supports the logical CPU (Hyper-Threading) feature, which is available starting with HP-UX 11i v3 (B.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. Each core with Hyper-Threading enabled can contain multiple logical CPUs. WLM supports the Hyper-Threading feature for PSET-based groups. 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 prior to 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 override the default Hyper-Threading state of cores assigned to a specific PSET group; you can also modify the Hyper-Threading state of the system. (Modifications to the Hyper-Threading state should not be made while WLM is running.) For more information, see “Specifying workload groups (optional)” and wlmconf(4).

When referring to hardware, CPUs are now referred to as cores in the documentation and in WLM displays or data reports. A core is the actual data-processing engine within a processor. A processor might have multiple cores, and a core might support multiple execution threads through Hyper-Threading. The term “CPU” is still used when referring to concepts such as “CPU resources” or “CPU utilization”; whenever the number of physical processing devices is reported by WLM or discussed by the documentation, the number will be stated explicitly in terms of cores. Note also that PSET sizes and Instant Capacity (iCAP) partitions are now expressed in terms of cores.

	NOTE: With Hyper-Threading disabled, each core is seen as a CPU. With Hyper-Threading enabled, each core can be seen as multiple, logical CPUs.

The wlminfo par and wlminfo host commands now explicitly display core statistics, such as in the following display for the wlminfo par command:

Hostname Intended Cores Cores Cores Used Interval

The wlminfo group command now displays memory utilization of all groups in the current deployed configuration. In addition, this command now supports the -v option to display each group’s gmincpu, gmaxcpu, gminmem, and gmaxmem values, if they are available in the current deployed configuration. This new option is ignored if live data is not being displayed (for example, when the -o option is being used). If memory management is not being used, a dash (-) instead of a zero is displayed in the ‘Mem Shares’ column. If a group’s gmincpu, gmaxcpu, gminmem, or gmaxmem value is not assigned in the current configuration, a dash (-) is displayed in the corresponding column.

For more information, see wlminfo(1M) or “Monitoring WLM with the wlminfo command”.

WLM supports the use of Extended Regular Expressions (EREs) for defining alternate names for application records. This support requires that PRM C.03.02 or later is running on the same system. For more information, see “Assigning applications to workload groups (optional)” and “Pattern matching for renamed application processes”.

WLM supports placement of processes and assignment of user access based on Unix groups. You can assign Unix groups to workload groups by defining the uxgrp record in the prm structure. Processes whose effective group ID (GID) matches a Unix group record will run in the associated workload group. WLM supports Unix group records only if PRM C.03.02 or later is running on the system. For more information, see “Assigning Unix groups to workload groups (optional)”.

Temporary Instant Capacity (TiCAP) activates capacity in a temporary “calling-card fashion,” such as in 20-day or 30-day increments (where a day equals 24 hours for one core). With Temporary Instant Capacity on the system, any number of Instant Capacity cores can be activated as long as your prepaid temporary capacity time has not expired. By default, if 15 or fewer processing days are available, WLM stops activating Temporary Instant Capacity. Beginning with this release of WLM, you can change this default by setting the WLM global arbiter utility_reserve_threshold keyword.

The Pay per use Toolkit (PPUTK) and the utilitydc command are no longer supported and have been removed from the product. Please use the simpler and more robust Temporary Instant Capacity/Pay per use solution available with wlmpard.

The WLM installation script no longer detects whether the correct version of the Java™ Runtime Environment (JRE) is running or whether the correct version of PRM is running. To run the WLM GUI (wlmgui) and the wizard (wlmcw) requires JRE version 1.4.2 or later. For PRM-based configurations, PRM C.03.00 or later is required. To take advantage of the latest updates to WLM, use the latest version of PRM (C.03.02.02 or later).

You can use WLM and PRM to manage resources on the same system at the same time if the PRM configuration uses FSS groups only (no PSET-based groups) and the WLM configuration is strictly host-based. For more information, see “WLM and Process Resource Manager (PRM)”.