I'm wondering if state sampling for these non ending transactions are part of
the overall emphasis on the performance of the service class. If these samples
were discarded for non ending, high resource usage transactions as an example,
I could envision some unfavorable results to service class and possibly system
performance...but it is a bit confusing.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Gerhard Adam <gada...@charter.net>
Date: 02/15/2018 1:59 PM (GMT-05:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WLM and response time
Here's an example of why I'm questioning this. This is from a book by Robert
Vaupel. I know he's knowledgeable, but the explanation is confusing.
Using an average response time example he says "The running or in-flight
transactions are also captured in order to make sure that long running and not
ending transactions are used for managing the service class too.".
Why should a transaction that hasn't ended be relevant?
Sent from my iPhone
> On Feb 15, 2018, at 10:34 AM, Allan Staller <allan.stal...@hcl.com> wrote:
>
> IIRC, WLM only uses ended transactions for the policy adjustment cycle.
>
> Further suggested reading SYSTEM Programmers Guide to WLM:
>
> www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gerhard Adam
> Sent: Thursday, February 15, 2018 11:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WLM and response time
>
> I agree. But the question remains. How does WLM manage a response time that
> is longer than the policy adjustment interval? Is it only based on ended
> transactions at that time (which would seem logical).
>
> I've also seen a lot of recommendations from various sources talking about
> short batch, which is what gave rise to the question. Specifically the
> recommendation used 5 initiators as the example.
>
> Also it doesn't matter if it is percentile or average response time. What
> makes me wonder is that it basically tenders the percentile useless.
>
> For example, if I have an average response time of 1 sec, then it is easy to
> see that enough transactions would end in an interval to provide samples to
> evaluate. However let's also say that there are some transactions that will
> experience a response time of 60 seconds (and stay in the same period). In
> fact, this can happen with USS where transactions may show a response time of
> 20 seconds.
>
> Since these end during different policy adjustment intervals, it seems that
> they are only a sporadic effect, because during the interval when none end,
> the average response time would hold. During the intervals when they do end,
> the percentile would be applicable.
>
> Yet wouldn't this cause me to perpetually fluctuate between exceeding goals
> and meeting them? After all during the intervals when I have no long running
> transactions ending, I would show 100% meeting goals and exceed by goal.
>
> Yet I don't recall ever seeing this kind of behavior.
>
> Sent from my iPhone
>
>> On Feb 15, 2018, at 6:17 AM, Allan Staller <allan.stal...@hcl.com> wrote:
>>
>> Response time goals for batch do not (IMO) make any sense.
>>
>> WLM is predicated on having enough samples to make an informed decision. If
>> you only have 1 or 2 samples (ended transactions) in an interval, that is
>> not statistically valid.
>> I would suggest a velocity goal be used in its place.
>>
>> If queue time is needed to be considered, the I would expand the suggestion
>> to include WLM managed initiators. This will change the velocity calculation
>> to include queue time as part of the delay.
>>
>> Suggested reading:
>> ftp://public.dhe.ibm.com/s390/zos/wlm/WLMvelocity.pdf
>>
>> HTH,
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Gerhard Adam
>> Sent: Wednesday, February 14, 2018 9:40 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: WLM and response time
>>
>> Well, this may seem like an obvious answer, but I can't tell if I'm
>> confusing myself or missing something.
>>
>> If I use a long response time (like 10 minutes for batch), then I would
>> think that I only consider that during the Performance Adjustment interval
>> in which the transaction ends. Yet that raises the question that if I have
>> multiple jobs in such a service class, then over what interval must they end
>> to provide a meaningful metric? Assuming they would all end within a 10
>> second window seems implausible, so how can a response time goal
>> realistically be managed at such high values?
>>
>> In addition I recently read that even transactions that haven't ended can be
>> used in the evaluation of goals, but that doesn't make sense since, by
>> definition, they haven't ended. Yet this is what percentile goals are
>> supposed to represent.
>>
>> So I guess my question involves how a policy adjustment interval addresses
>> transaction that run longer than the time between intervals, or is it merely
>> that they are only examined during the interval they actually end in?
>>
>> Adam
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> ::DISCLAIMER::
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> --------------------------------------------------------------------
>> The contents of this e-mail and any attachment(s) are confidential and
>> intended for the named recipient(s) only. E-mail transmission is not
>> guaranteed to be secure or error-free as information could be intercepted,
>> corrupted, lost, destroyed, arrive late or incomplete, or may contain
>> viruses in transmission. The e mail and its contents (with or without
>> referred errors) shall therefore not attach any liability on the originator
>> or HCL or its affiliates. Views or opinions, if any, presented in this email
>> are solely those of the author and may not necessarily reflect the views or
>> opinions of HCL or its affiliates. Any form of reproduction, dissemination,
>> copying, disclosure, modification, distribution and / or publication of this
>> message without the prior written consent of authorized representative of
>> HCL is strictly prohibited. If you have received this email in error please
>> delete it and notify the sender immediately. Before opening any email and/or
>> attachments, please check them for viruses and other defects.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> --------------------------------------------------------------------
>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
