z/OS Workload Management Update for z/OS V1.11 and V1.12

© 2010 IBM Corporation
z/OS Workload Management Update
for z/OS V1.11 and V1.12
Horst Sinram
IBM Germany Research & Development
August 2, 2010

Agenda
• Enclave Enhancements
• Enclave Server Management
• Work-Dependent Enclaves
• WLM Management
• LDAP Support
• Resource Group Enhancements
• Do not always honor Skip Clock in Policy Adjustment
• WLM Reporting
• Extend Number of Report Classes
• Additional Group Capacity Information in RMF
• Externalized IEAOPT Information
• Hyperdispatch APAR
• WLM support for IBM zEnterprise 196
• z/OSMF Workload Management
• WLM support for zManager
• WLM Tools Overview

WLM Enclaves – An Overview
• An enclave is a transaction that can span multiple dispatchable units (SRBs and tasks) in
one or several address spaces and is reported on and managed as one unit
• The enclave is managed separately from the address spaces it runs in
• CPU and I/O resources associated with processing the transaction represented by the
enclave are managed by the transaction’s performance goal
• Storage (MPL level, paging) of the address space is managed to meet the goals of
the enclaves it serves (if enclave server address space) or to the performance goal of
the address space (if no server address space)

WLM Enclave Server Address Spaces
A Short Retrospective
• An address space becomes an enclave
server when
• An enclave SRB issues SYSEVENT
ENCASSOC
• A TCB of the address space joins an
enclave, and does not specify
ENCLAVESERVER=NO (which is typically
not the case)
• Assumption (Programming Model)
• All work being executed within the address
space is related to enclaves
• That means
• There is no significant amount of work (TCBs)
executing in such address spaces which is not
related to enclaves
• CPU and I/O DP is derived from service
class of most important enclave
• Meaning: No CPU and I/O management exists
for these server address spaces
• Storage management is done to meet the
served enclave‘s goals

WLM Enclave Server Management
Is There a Possible Problem?
• What if the programming model does not hold true?
• What happens if there is significant work running in
TCBs not associated with enclaves?
• Example: Garbage collection for a JVM (WAS)
• Example: Common routines which provide service for the
enclave TCBs
• Is it sufficient to manage this work in the same way as
the enclaves?
• What happens if no enclaves are running in server
address spaces ?? (this applies to queue servers only)
• And the address space is swapped out?
• A mechanism exists to swap in the address space but this
mechanism assumes that the swap in is only for a queue
server task which wants to select a unit of work and then
joins the enclave. If no enclave is joined, the address space
is again swapped out
• And even if the address space stays swapped in?
• The TCBs running within the address space just stay with
the DP and IOP from the last enclave being associated with
the address space
• No CPU or I/O adjustment is perfomed

WLM Enclave Server Management
Changes with z/OS 1.12
• New IEAOPT Parameter
• ManageNonEnclaveWork = {No|Yes}
• Default: No (no change to previous
releases)
• Causes everything in the address space,
which is not associated to an enclave, to be
managed towards the goals of the external
Service Class to which the address space has
been classified to
• Advantages
• Enclave (Queue) server address spaces in
which no enclave is running will be managed
as usual address spaces
• The importance and goal of the service class
for the address space now has a meaning
• Note: With ManageNonEnclaveWork =Yes the
importance and goal of the service class for the
address space is more important than it used to
be
• Verify goal settings for server address spaces

Work-Dependent Enclaves
• Background
• zIIPs allow middleware components to run a certain percentage of their work
“offloaded” from regular processors
• The offload percentage is an attribute of the enclave under which the unit of work runs
• The offload percentage is defined by the middleware component via a (not generally
published) WLM interface
• Limitations
• It is not possible to specify different offload percentages for different units of work
running under the same enclave
• Intended Use Case
• DB2/DDF wants to specify different offload percentages for the different units of work
of a parallel query,
• AND still wants to maintain the transactional context to run the units of work under the
same “SRM Transaction” (enclave)

DB2
Address Space
Independent Enclave
zIIP Offload = X %
Work-Dependent Enclave
zIIP Offload = Y %
Work-Dependent Enclave
zIIP Offload = Z %
create
create
Managed as one transaction, represented by Independent Enclave
• Solution
Implement a new type of enclave named “Work-Dependent” as an extension of an
Independent Enclave. A Work-Dependent enclave becomes part of the Independent
Enclave’s transaction but allows to have its own set of attributes (including zIIP offload
percentage)

Reporting in SDSF Enclave Panel and RMF Monitor III

Enclave Enhancements: Availability
Function z/OS
V1.12
z/OS
V1.11
z/OS
V1.10
Older
Releases
Non Shell Server
Management +
Work-dependent Enclaves
+ + OA26104
OA26104
 z/OS 1.8
• Non Shell Server Management
• New OPT Parameter ManageNonEnclaveWork=YES/NO.
Default is NO, meaning the function is not yet enabled
• New function available with WLM APAR OA26104
• DB2 exploitation with APAR PK76676
• SDSF support with APAR PK74125
• RMF support with z/OS 1.11

WLM Management: LDAP Subsystem is
supported
• Work requests include all work processed by the z/OS LDAP
server
• Supported Work Qualifiers
• Subsystem Instance (SI)
The z/OS LDAP server‘s job name. Needed to distinguish
between different LDAP servers
• Transaction Name/Job Name (TN)
The z/OS LDAP server‘s enclave transaction name.
“GENERAL“ for all LDAP work that is not assigned a user-
defined exception class. Any transaction name that is also
defined in the configuration file of the directory server
• For further information see
z/OS IBM Tivoli Directory Server Administration and Use
for z/OS (SC23-5191-XX )

WLM Management:
Subsystems supported by the WLM Administrative Application
Not relevant anymore Latest supported subsystems

WLM Management:
Do Not Always Honor “Skip Clock”
• What is the skip clock ?
• If WLM cannot help a service class it sets a skip clock to not assess
it in the next 3 policy adjustment cycles
• This is done for efficiency reasons and to help other work
• Is this always a good thing to do ?
• Usually yes!
• But if only very few service classes miss their goals it is not beneficial to no
longer assess a service class for 3 consecutive policy adjustment cycles
• Especially when it might be possible to help the work with IRD Weight
Changes. In this event the situation on another LPAR can change and
might make it possible to help a service class in the next policy
adjustment cycle
• Solution introduced with z/OS 1.11
The skip clock will no longer be honored if 5 or less service class periods do not
meet their performance objectives.

WLM Management
Availability

Agenda
• Enclave Enhancements
• WLM Management
• LDAP Support
• Resource Group Enhancements
• Do not always honor Skip Clock in Policy Adjustment
• WLM Reporting
• Additional Group Capacity Information in RMF
• Extend Number of Report Classes
• Externalized IEAOPT Information
• Hyperdispatch APAR
• WLM support for IBM zEnterprise 196
• z/OSMF Workload Management
• WLM support for zManager
• WLM Tools Overview

Group Capacity: Summary
• Is based on defined capacity
• Each partition obtains information for the other partitions of the group from PR/SM
• Calculates the group consumption and whether the group should be capped
• If the group becomes subject to capping
• The partition calculates whether it is above or below of its entitlement
• If it is above its entitlement the partition must apply capping (phantom weight or cap pattern)
• The entitlement of a partition is its share based on its weight within the group (named target MSU)
• In addition if not all partitions use their entitlement the partition can obtain unused MSUs
• The partition can always use its target MSU value assuming the overall LPAR definitions allow it
• Group Capacity and Defined Capacity can be combined
• The z/OS system will always honor the smaller of both capacity limits
• It is possible to define multiple capacity groups on a CEC
• A partition can only belong to one group
• Working with IRD CPU Weight Management
• Defined and Group Capacity work with IRD but Weight Changes are only possible for partitions
which are not being capped (or subject to capping)
• Restrictions: Defined and Group Capacity
• A partition must not be defined with dedicated processors
• The partition must be defined with shared processors and WAIT Completion = NO
• Initial Capping must not be defined
• z/OS must not run as a VM guest
• PR/SM capping works within ±3.6% from the defined capping value

Group Capacity: Demo Scenario
Actual MSU values
0
20
40
60
80
100
120
140
19:03
(45)
19:23
(49)
19:43
(53)
20:03
(57)
20:23
(61)
20:43
(65)
21:03
(69)
21:23
(73)
21:43
(77)
22:03
(81)
22:23
(85)
22:43
(89)
23:03
(93)
23:23
(97)
23:43
(101)
00:03
(105)
00:23
(109)
00:43
(113)
01:03
(117)
01:23
(121)
01:43
(125)
02:03
(129)
02:23
(133)
02:43
(137)
03:03
(141)
03:23
(145)
03:43
(149)
04:03
(153)
04:23
(157)
04:43
(161)
05:03
(165)
05:23
(169)
05:43
(173)
06:03
(177)
06:23
(181)
06:43
(185)
07:03
(189)
07:23
(193)
07:43
(197)
08:03
(201)
08:23
(205)
08:43
(209)
09:03
(213)
09:23
(217)
09:43
(221)
10:03
(225)
10:23
(229)
IRD4 IRD3 IRD5
IRD5 gets
24-25 MSU
IRD3 gets
7.6-9 MSU
IRD4 gets 16.5-
18.3 MSU
High demand all partitions CPU demand only on IRD3 and IRD4
IRD5 uses less than 3 MSU
and donates 22 MSU
IRD3 gets 16-19 MSU
(additional 8 MSU)
IRD4 gets 30-32 MSU
(additional 14 MSU)

Capacity Group Example
-200
-150
-100
-50
0
50
100
150
200
250
300
350
400
450
500
550
600
650
700
750
800
850
900
950
1000
1050
00:20:03
01:10:03
02:00:03
02:50:04
03:40:04
04:30:04
05:20:04
06:10:04
07:00:04
07:50:04
08:40:04
09:30:04
10:20:04
11:10:04
12:00:04
12:50:04
13:40:04
14:30:04
15:20:04
16:10:04
17:00:04
17:50:04
18:40:04
19:30:04
20:20:04
21:10:04
22:00:04
22:50:04
23:40:04
00:30:04
01:20:04
02:10:04
03:00:04
03:50:04
04:40:04
05:30:04
06:20:04
07:10:04
08:00:04
08:50:04
09:40:04
10:30:04
11:20:04
12:10:04
-200
0
200
400
600
800
1000
SYS1_Uncapped SYS1_Capped SYS2_Uncapped SYS2_Capped SYS3_Uncapped SYS3_Capped
SYS4_Uncapped SYS4_Capped SYS5_Uncapped SYS5_Capped GroupLimit AvgUnused (4HRAVG)
Group Capacity: Customer Example
 Group Limit: 875 MSU
 5 Systems on CEC and in Group
 Capping of Group is active when
4HRAVG of group is below 0
MSU

RMF z/OS 1.11 Enhancements for Group
Capacity…
Field Heading Meaning
CAPPING WLM% Percentage of time when WLM considers to cap the partition
CAPPING ACT% Percentage of time when capping actually limited the usage of processor
resources for the partition

WLM Capping
Cap Pattern vs. Phantom Weight
Capping with Cap Pattern (when Soft Cap > MSU@LparWeight)
Capping using a Phantom Weight (when Soft Cap < MSU@LparWeight)
Soft Cap MSU @ LPAR Weight MSU with Phantom Weight

RMF z/OS 1.11 Enhancements for Group Capacity…
Capping WLM% versus ACT%
•Capping WLM% = SMF70NSW * 100 / SMF70DSA
• SMF70NSW is incremented for each sample with the WLM-capped flag ON. The
flag is ON if the LPAR was capped via Diagnose 0304.
•Capping ACT% = SMF70NCA * 100 / SMF70DSA
• SMF70NCA is incremented for each sample which indicates an actual-MSU-
consumption below the MSU-at-weight factor
• The pricing management adjustment weight of the LPAR (aka phantom weight) is added to
the total of all active-logical-partition weights to compute the fraction of processor resources
that the LPAR may use (MSUatWgt)
• The actual MSU consumption of the LPAR is computed from the total dispatch time
measured between two Diagnose samples
• Following calculations done in RMF:
Current LPAR weight * CPC capacity in MSUs
MSUatWeight = ---------------------------------------------
Total weight + PMA weight
Dispatch time delta * 3600 * 16
ActualMSU = ---------------------------------------
Time range * Phys CPU adjustment factor
If ActualMSU >= MSUatWeight-5% Then LPAR is actually capped

Field Heading Meaning
AVAILABLE Long-term average of CPU service units which would be allowed by the limit of the capacity group
but are not used by its members. If the value is negative, this capacity group is subject to capping.
RMF z/OS 1.11 Enhancements for Group
Capacity…

RMF z/OS 1.11 Enhancements for Group Capacity…
Monitor III CPC report in Monitor III Data
Portal displays the projected remaining
time until image/group capping in the report
header
Average available capacity for
the group during last 4 hours

Group Capacity: Availability
Function z/OS
V1.12
as previewed 2/2010
z/OS
V1.11
z/OS
V1.10
Earlier
Releases
Group Capacity plus
OA24096 Enhancements + + OA24096
OA23230
OA24096
OA23230
(z/OS 1.8)
RMF Reporting Enhancements
for Group Capacity + +
z/OS Capacity Provisioning + + OA20824
• OA24096
• Changes the behavior when then group limit is changed according to the behavior for an individual defined
capacity limit
• OA23230
• Corrects a storage overlay which will occurs when SMF 99 data is collected and a partition is dynamically
activated via HCD
• Short Comings of the existing Group Capacity Report
• Reporting was not sufficient to understand capping of partitions within a group
• Resolved with z/OS 1.8 RMF Reporting Enhancements
• Related z/OS Functions
• z/OS Capacity Provisioning allows to activate additional CPU capacity via OOCoD in a controlled manner.

WLM Reporting: Extend Number of Report
Classes
• The WLM-supported maximum on the number of defined report classes (999)
has become insufficient for large installations
• Solution
• Extend number of report classes in multiple steps:
• First Step (z/OS 1.11):
• Extend to 2047 Report Classes
• Expand internal data structures to be able to deal with 4095 report classes
• Remarks
• New WLM functionality level in z/OS 1.11: LEVEL023
• For Service Definitions in XML format, the corresponding XML namespace is
http://www.ibm.com/xmlns/prod/zwlm/2009/09/ServiceDefinition.xsd

Extended Number of Report Classes
Availability

New Programming Interface for Monitors
Control Block: IRARMCTZ
• New extension to SRM Control Table (PI) for information which is of
interest for externalization
• For example all information related to RMF‘s Monitor II OPT report is included
in this table
CVTOPCTP ... +254
IRARMCT
...
RMCTX3 ... +178

New Programming Interface for Monitors:
Availability
Control Block: IRARMCTZ
Function z/OS
V1.12
as previewed 2/2010
z/OS
V1.11
z/OS
V1.10
Earlier
Releases
RMF Monitor II OPT Display + +
WLMOPT Tool (bundled with
WLMQUE Tool)
No longer extended
Still bundled with WLMQUE but on z/OS 1.10 level + Since z/OS 1.8
IRARMCTZ + OA31201 OA31201
• RMF Monitor II OPT Display
• Replaces WLMOPT Tool
• Bundled with WLMQUE Tool but no longer extended (remains on z/OS 1.10 level)
• WLMQUE Tool is still valid (see also WLM Tools summary)
• New data interface for Monitors
• Introduced with z/OS 1.12, Rollback to z/OS 1.10

Hiperdispatch: WLM APARs
APAR Description Close
Date
Remark
OA31733 Corrects calculation of capacity for
medium processors
04/2010 Affects larger configurations

WLM Support for IBM zEnterprise 196
• IBM zEnterprise 196 (z196)
• STSI instruction no longer returns the alternate CPU capability
• CPU adjustment factors are now calculated based on the Model Capacity
Ratings by the machine
• CSRSI does no longer provide alternate CPU capability
• Supplies additional information about speed changes
• WLM
• uses the new MSU values to calculate pricing adjustment factors
• introduces message IWM064I to explain the reason for a processor speed change
• makes new HW information available via public data areas IRARCT, IRARMCT,
IRARMCTZ and via SYSEVENT QVS

New Pricing Adjustment Factors
• z196 provides MSU values instead of the alternate CPU capability together with MP
factors table as base for pricing factors
• WLM uses the new MSU values to calculate pricing adjustment factors on z196
• Add more granular new pricing adjustment factors RCTPCPUA_actual and
RCTPCPUA_nominal plus a scaling factor RCTCPCPUA_scaling_factor
• Maintain existing RCTPCPUA for compatibility
• Values are also available in SMF30 and SMF89
• SMF30_RCTPCPUA_xxxxxx, SMF30_Capacity_F…
• SMF89_RCTPCPUA_xxxxxx

New Message IWM064I
• Depending on the reason for the speed change one of the following message
accompanies
IWM063I WLM POLICY WAS REFRESHED DUE TO A PROCESSOR SPEED CHANGE
• IWM064I THE SYSTEM IS RUNNING AT NOMINAL CAPACITY.
• IWM064I THE SYSTEM IS RUNNING AT NOMINAL CAPACITY; MODEL
CONVERSION OCCURRED.
• IWM064I THE SYSTEM IS RUNNING WITH REDUCED CAPACITY BECAUSE
OF A MANUAL CONTROL SETTING.
• IMM064I THE SYSTEM IS RUNNING WITH REDUCED CAPACITY BECAUSE
OF A MACHINE EXCEPTION CONDITION.
OF A NON-EXCEPTION MACHINE CONDITION.
OF AN EXCEPTION CONDITION EXTERNAL TO THE MACHINE.

Enhanced API
• Query Virtual Server interface can be used to query a server’s capacity status
• Called by Sysevent QVS (assembler interface) or IWMQVS (C interface)
• The Output is mapped by IRAQVS (assembler mapping) or IWMQVS.H (C header file)
• New data field QvsCecCapacityStatus has been added to indicate if the machine
is running at nominal or reduced capacity
• Version QvsVer has been incremented to QvsVer2

Extended Data Areas
• IRARMCTZ
- RMCTZ_Capacity_Change_Time
- Time when the capacity was last changed
- RMCTZ_Capacity_Adjustment_Indication
- When zero, the indication is not reported. When in the range 1-99, some amount of reduction is
indicated. When 100, the machine is operating at its normal capacity. Primary CPUs and all
secondary-type CPUs are similarly affected
- RMCTZ_Capacity_Change_Reason
- Indicates the reason which is associated with the present value contained in
RMCTZ_Capacity_Adjustment_Indication
- RMCTZ_CAI_IPL
- Capacity adjustment indication at IPL
- RMCTZ_CCR_IPL
- Capacity change reason at IPL
- RMCTZ_nominal_CPMP
- Nominal CPU adjustment factor (similar to RMCTCPMP but for nominal speed)
• IRARCT
• IWMWRCAA
- RCAAADJCCPU CPU adjustment factor
- RCAAADJCCPUNOM nominal CPU adjustment factor
- RCAAADJCCEC CEC adjustment factor

Availability
Function z/OS
V1.12
z/OS
V1.11
z/OS
V1.10
z/OS
V1.9
New message, API
enhancements OA30968 OA30968 OA30968
Support for new MSU
computation/reporting OA30968 OA30968 OA30968 OA30968

Temporary Capacity Reporting via
SYSEVENT REQLPDAT
 SYSEVENT REQLPDAT was changed to return capacity information
about IBM z10 (and later) capacity settings:
• permanent capacity information
• The base capacity of the machine
• temporary capacity data
• Replacement Capacity: Capacity Backup (CBU), or Planned Event
(CPE)
• Additional Capacity: On/Off Capacity on Demand (OOCoD)
• The differentiation is relevant for potential license cost or entitlement impact

Temporary Capacity Reporting via SYSEVENT
REQLPDAT
 IRALPDAT new data fields
• LPDATMODELCAPIDENT
• The 16-character EBCDIC model-capacity identifier of the configuration.
• LPDATMODEL
• The 16-character EBCDIC model identifier of the configuration. If not valid, field
LPDatModelCapIdent represents both the model-capacity identifier and the
model.
• LPDATMODELPERMCAPIDENT
• The 16-character EBCDIC model-permanent capacity identifier of the
configuration.
• LPDATMODELTEMPCAPIDENT
• The 16-character EBCDIC model-temporary capacity identifier of the
configuration.
Permanent+OOCoD + (CBU+PE)
H/W model
Permanent configuration
Permanent + OOCoD

Overview
 IRALPDAT new data fields
• LPDATMODELCAPRATING
• When non-zero, an unsigned integer whose value is associated with the model
capacity as identified by the model-capacity identifier. There is no formal
description of the algorithm used to generate this integer.
• LPDATMODELPERMCAPRATING
• When non-zero, an unsigned integer whose value is associated with the model-
permanent capacity as identified by the model-permanent- capacity identifier
• LPDATMODELTEMPCAPRATING
• When non-zero, an unsigned integer whose value is associated with the model-
temporary capacity as identified by the model-temporary- capacity identifier.
Permanent+OOCoD + (CBU+PE)
Permanent configuration
Permanent + OOCoD

REQLPDAT Sample with
Active Temporary Capacity
 Example output
LPDatModelCapIdent : 714
LPDatModel : E26
LPDatModelPermCapIdent : 709
LPDatModelTempCapIdent : 711
LPDatModelCapRating : 00000473
LPDatModelPermCapRating : 00000324
LPDatModelTempCapRating : 000003B0
 Meaning
• The base model is 709
• This model has active OOCoD capacity
• It temporarily has a capacity like a model 711
• This model also has active CBU capacity
• In total it temporarily has a capacity like a model 714

z/OSMF Workload Management
The new WLM Control Center in z/OSMF V1.12
• Policy editor
• Simplified creation and editing of WLM policies supported by best practice
checks
• Support for review and investigation of WLM policies
• Policy repository
• WLM policies are stored in a repository integrated in the z/OSMF file system
• Policies can be exported to the local workstation or a host data set as well as
imported from a file or a host data set
• Policies or best-practice recommendations can be printed for further study
• Integrated operation history makes manual tracking superfluous
• Installation and activation of WLM policies
• Monitoring of the WLM status in the sysplex
• Administration and operation tasks can be performed simultaneously
• Simplified migration: Policy elements can be copied from one service definition to
another
• Simplified operation: You can start to edit a policy, interrupt the editing to activate
a policy, and then continue with the editing without loosing the context
• z/OSMF Workload Management synchronizes automatically with z/OS WLM

Service Definition Repository
Click to view,
edit, print,
install a
service
definition
Store all service definitions in one
repository
• Integrated repository for
service definitions
• Service definitions can be
• Imported
• Exported
• Printed
• Viewed or edited
• Created or Copied
• Installed on the
sysplex
• Indications
• If service definition is
installed and active
• If service definitions
are being viewed or
edited
• If messages exist for a
service definition

Editing Service Definitions
Best-practice hints
help to optimize
service definitions
Click to
check where
the element
is used
Click to copy
element on
clipboard for
insertion into
another service
definition
• Simplified creation,
modification and review
of service definitions
• Policy elements are
presented in tables
• Tables can be filtered
and sorted
• Direct editing of policy
elements within tables
• Best-practice hints are
displayed
automatically while
specifying policy
elements
• Several service
definitions can be
opened simultaneously
• Cut, Copy, Paste of
policy elements
between service
definitions

The new WLM Control Center in z/OSMF V1.12
A complete overview is presented in session
Manage your Workloads and Performance with z/OSMF
Tuesday, 4:30 PM-5:30 PM

WLM support for zManager
Introduction
• The zEnterprise Unified Resource Manager (zManager) introduced
with z196 provides zEnterprise platform management
• zManager enables you to install, monitor, manage, optimize,
diagnose, and service resources and workloads from a single point of
control while extending System z qualities of service across the entire
infrastructure
• zManager is controlled by a platform workload management policy:
• Specified at the HMC
• Defines Workloads which are groups of partitions or virtual servers that
support the same business application(s)
• (not to be confused with Workloads defined in the WLM policy)
• Defines Service Classes with platform wide performance goals of
Workloads
• The guest platform management provider (GPMP) is the interface
between the zManager and the z/OS Workload Manager

GPMP – WLM Interaction
• GPMP
• passes to WLM information about the platform wide performance goals of workloads
in which the z/OS is participating
• sends data provided by WLM to the HMC for platform performance monitoring
• Server configuration and high level performance statistics collected on z/OS
• Aggregated transaction response time and resource data for the ARM-
instrumented applications
• WLM
• supports GPMP configuration and management by new WLM service definition
options, commands, and messages
• manages the GPMP address space (start, stop, and restart)
• displays GPMP status information
• collects and aggregates performance measurements for GPMP

Service Definition Enhancements for GPMP
• z/OS V1R12 introduces WLM functionality level LEVEL025 to support zManager and
GPMP
• zManager Service Classes can be classified to WLM service and report classes by
specifying classification rules for subsystem EWLM
• Work qualifier ETC (EWLM transaction class name) is no longer supported
• Work qualifier type ESC (EWLM service class name) is used to correlate
zManager service classes with WLM service or report classes
• Although z/OS V1R12 simply disregards ETC classification rules, you have to delete
them the next time you modify the EWLM subsystem type classification rules
• Message IWMAM726 ETC is not a recognized qualifier type
is displayed when pressing F3=Exit
• Rows with ETC rules have to be deleted before F3 becomes successful

Service Definition Enhancements for GPMP
To configure GPMP
1) Select option 11 on the
Definition Menu
2) Specify Guest Platform
Management Provider
settings
Specifies whether
you want to start
the GPMP address
space
automatically when
a WLM policy is
activated
Specifies the
systems in the
sysplex on which
the GPMP should
not be started
automatically
After GPMP
settings defined,
functionality
level changes to
25

GPMP Configuration and Management
• On policy activation
• WLM checks whether the service definition has valid GPMP settings
• If activate=yes and system name not specified on excluded-list, GPMP is started
automatically
• Also, you can use the MODIFY WLM command
• To start the GPMP on a system
• To stop the GPMP on a system
• Intended for recovery actions. Recommended is to manage GPMP through WLM
• Once you stopped the GPMP manually, the GPMP switches into “manual mode”. It is
not automatically restarted even if a WLM policy with a valid GPMP configuration gets
activated
• Status maintained until next IPL

GPMP related Commands
• Use the MODIFY WLM,GPMP command to start, stop, and modify the guest
platform management provider:
• F WLM,GPMP,START
• Indicates that you want to start the GPMP
• F WLM,GPMP,STOP
• Indicates that WLM stops the currently active GPMP instance
• F WLM,GPMP,TRACE=NONE|LOW|MEDIUM|HIGH,DEST=FILE|
MEMORY
• Enables you to change the GPMP internal tracing level “on the fly” and
to change the destination of the trace (file or memory)

• DISPLAY WLM command extensions:
To display system and
GPMP status information,
enter:
D
WLM,SYSTEMS,GPMP
To display whether ARM
is enabled or disabled,
enter:
D WLM,AM

• The existing MODIFY WLM,AM=DISABLE|ENABLE command is not changed, but
the logic for DISABLE/ENABLE changed in the following way:
• Disabling ARM (Application Response Measurement) will terminate a running
GPMP
• Manually starting the GPMP (using the MODIFY WLM,GPMP,START command)
when ARM is disabled will result in message IWM078I
• Activating a WLM policy that contains valid GPMP settings will not result in the
start of a GPMP instance, if ARM is disabled
• The state of the GPMP will be displayed as “DISABLED”, if ARM is disabled
• If ARM is enabled again, the state of the GPMP will change to “STOPPED”. To
start the GPMP again, it has to be started manually

GPMP Installation
• GPMP must be authorized to run as a trusted started task
• Sample job HVEENV provided in SYS1.SAMPLIB to
• define the GPMP security setup (see STEP01)
• configure the execution environment for the GPMP (see STEP02)
• Modify following variables according to your specific environment:
• Run the JCL from an authorized user with UID=0
• STEP01 must be modified when running GPMP in a SECLABEL
environment
• Example provided in Chapter 15 of the WLM Planning Guide
Variable Description
DATA_ROOT Directory on UNIX where the GPMP stores the configuration and diagnostics data
JREBIN_ROOT Directory on UNIX where the Java executable is located
LOGFILE_ROOT Directory where the GPMP startup related diagnostics messages will be stored
MCA_USER The user created in STEP01 of the JCL. It is recommended to keep HVEMCA1 as the user name.
MCA_GROUP The group created in STEP01 of the JCL. It is recommended to keep HVEMCA as the group name.
MCA_JAVADUMPS Optional USS directory where GPMP Java, Heap, SNAP, CEE dumps will be created
ENV_PROFILE The UNIX profile to be used by the GPMP. This should contain environmental information, for example, TimeZone,
Locale.

Prerequisites
• Hardware
• z196 with zEnterprise Unified Resource Manager
• Guest platform management provider on z/OS cannot be started on pre-z196
servers
• If started on pre-z196 servers, message
IWM078E GUEST PLATFORM MANAGEMENT PROVIDER CANNOT BE
STARTED, FUNCTION NOT AVAILABLE
is issued on the console
• Software
• z/OS V1R12 and OA30928
• For z/OS V1R10 and V1R11: OA30928

WLM Tools: A Summary
Tool Name Description Content Support
SVDEF Service
Definition
Formatter
Uses output from WLM
Administrative Administration to
display content of service definition in
a workstation spreadsheet
Excel/workstati
on
Not updated
anymore but still
available on WLM
Tools page
WSE Service
Definition
Editor
Allows to create, modify, retrieve
and install WLM service
definitions
Java program
on
workstation
YES!!
Available
WLMQUE Application
Environme
nt Viewer
Allows to monitor WLM
Application Environments
ISPF Tool YES!!
Available
WLMOPT OPT
Display
Display WLM/SRM OPT Parameters IPF Tool No!!
Obsoleted by RMF
in z/OS V1.11
http://www-03.ibm.com/servers/eserver/zseries/zos/wlm/tools/

WLM Tools
Service Definition Editor

WLM Tools
Display WLM/SRM OPT Parameter (WLM Tool, supported up to R10)

WLM Tools
Display WLM/SRM OPT Parameter (RMF Monitor II OPT Report)

WLM Tools
WLMOPT – WLM Application Environment Viewer

z/OS Workload Management Update for z/OS V1.11 and V1.12

Related slideshows

More Related Content

z/OS Workload Management Update for z/OS V1.11 and V1.12