My dispute about the dispatching priorities comes from the Type 99 subtype 1
records. I've included the data from a report that shows that the
dispatching priority changes [including the projected changes afterwards]
are all based on the entire service class. In this case, it clearly shows
that WLM is making the assessment and increasing the receiver's dispatching
priority. You can see how WLM took the initial value at dispatching
priority 247 and combined that with 251 to arrive at the new projected
value. Whether SRM is the specific mechanism that makes that change isn't
important here.
167 233 ONLTST 1 1.00 1.27
270 PA - Receiver candidate selected
167 233 SERVERS 1 11.66 2.59
308 PA - Donor period
167 233 SERVERS 1 11.66 2.59
880 PA - Processor donor selected
167 233 ONLTST 1 1.00 1.27
620 PA - Assess moving receiver up to
occupied priority
167 233 ONLTST 1 .96 1.25
750 PA - Increase receiver priority
167 233 SERVERS 1 14.00 2.59
940 PA - Unchanged donor
Priority Table Report: Numbers as indicated are "at priority"
DP After Utilization CPU Samples Wait to Cumulative
Utilization Avg MTTW (SU/sec) Used (SU/sec)
PA Unbunching Init Proj Using Delay Using Ratio Init
Projected Achievable Initial Projected Actual Projected
----------------------------------------------------------------------------
-------------------------------------------------------
192 20.7% 20.7% 6 25 4 134.3%
134.3% .0% 3.6 3.6 8302.1 8302.1
231 3.2% 3.2% 0 1 1 113.6%
113.6% .0% 4.0 4.0 258.1 258.1
233 61.8% 61.8% 45 24 1 110.4%
110.4% .0% 12.7 12.7 5930.0 5930.0
235 .8% .8% 0 0 1 48.6%
48.6% .0% 6.3 6.3 0.8 0.8
237 12.0% 12.0% 4 2 1 47.8%
47.8% .0% 3.1 3.1 3838.9 3838.9
239 3.9% 3.9% 4 4 1 35.8%
35.8% .0% 3.1 3.1 2010.5 2010.5
243 .6% .6% 0 0 1 31.9%
31.9% .0% 3.2 3.2 16.0 16.0
245 .6% .6% 1 0 1 31.3%
31.3% .0% 2.6 2.6 359.4 359.4
247 7.0% .0% 4 5 1 30.7%
30.7% 30.7% 2.7 6.3 2910.4 0.0
251 3.8% 10.8% 11 2 0 23.7%
30.7% 30.7% 12.7 6.7 2013.0 4923.4
253 .1% .1% 0 0 0 19.9%
19.9% 19.9% 9.2 9.2 3.0 3.0
254 10.5% 10.5% 13 1 0 19.8%
19.8% .0% 3.0 3.0 4974.4 4974.4
255 9.3% 9.3% 8 0 0 9.3%
9.3% .0% 1.8 1.8 4215.4 4215.4
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Edgington, Jerry
Sent: Thursday, April 5, 2018 9:09 AM
To: [email protected]
Subject: Re: WLM and Dispatching Priority
SRM is a component of the system control program. It determines which
address spaces, of all active address spaces, should be given access to
system resources and the rate at which each address space is allowed to
consume these resources.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Edgington, Jerry
Sent: Thursday, April 05, 2018 12:06 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: WLM and Dispatching Priority
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.ieaw200/iea3w201112.htm
Dispatching Priority
SRM defines dispatching priority for service class periods. All address
spaces in a service class period have the same base dispatching priority.
Multiple service class periods may have the same base dispatching priority.
After a dispatching priority change, service class periods may be remapped
to different dispatching priorities such that there is an unoccupied
priority between each occupied priority. This process is referred to as
priority unbunching.
The dispatching priority is recorded in the subtype 2 records.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Gerhard Adam
Sent: Thursday, April 05, 2018 12:02 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: WLM and Dispatching Priority
I beg to differ, but do you have documentation that supports what you say?
I have looked at a lot of type 99 records and WLM most certainly assigns the
DP.
Sent from my iPhone
> On Apr 5, 2018, at 8:44 AM, Edgington, Jerry
<[email protected]
<mailto:[email protected]> > wrote:
>
> WLM uses the configuration to determine what SRVCLASS a specific piece of
work should be assigned upon initial job entry. After that, WLM will
recommend to SRM how to adjust the dispatching priorities, based on
information provided in WLM definitions.
>
> WLM doesn't make changes to dispatching priorities, only SRM does that.
Also, SRVCLASS doesn't equal a specific dispatching priority.
>
> SRM still works like it always has and WLM is way of defining "business
rules" to workload versus assigning specific dispatching priorities to the
workload.
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Gerhard Adam
> Sent: Thursday, April 05, 2018 11:37 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: WLM and Dispatching Priority
>
> I don't see the relevance of enclaves or anything else in this. It is the
service class period that matters.
>
> So, if I assigned DB2, enclaves, TSO, and batch to the same service class,
they should still all have the same dispatching priority. Workload Manager
doesn't care what type of work is in the service class, since only the data
related to the service class can be examined.
>
> I would expect to see different dispatching priorities for the small
consumer, or an address space that has been temporarily promoted, but that
should only be short-term. I would also expect to see different dispatching
priorities for the MTTW usage in discretionary.
>
> However, I still don't see how a goal-managed service class period can
have different dispatching priorities. It would render the goal
meaningless.
>
> Adam
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Martin Packer
> Sent: Thursday, April 5, 2018 7:14 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: WLM and Dispatching Priority
>
> There is also DIST and DBM1 in there. The action will be heavily
> geared towards DBM1. (DIST has work in it mostly on Independent
> Enclaves so relatively little of the work therein is at the address
> space's DP.)
>
> Cheers, Martin
>
> Martin Packer
>
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]> with
the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]> with
the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [email protected] <mailto:[email protected]> with the
message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [email protected] <mailto:[email protected]> with the
message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [email protected] <mailto:[email protected]> with the
message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
