>IOC . . . . . . . . . . . . . 1.0 (0.0-99.9)
IBM, and others, has recommended this be set to 0.5, to maintain the old
relationship when they were 10 & 5.
The reason for the change to 1.0 was to do with the fact that resource classes
deal only with CPU service units (unnormalised, IIRC).
Aimee Houghton wrote:
Here is my service class for TSO:
Base goal:
CPU Critical flag: NO
# Duration Imp Goal description
- - -
1 800280% complete within 00:00:00.300
2 4Execution velocity of 40
W
On Tue, 1 Apr 2008 15:55:24 -0500, Diehl, Gary wrote:
>
># Duration Imp Goal description
> - - -
> 1 15000 290% complete within 00:00:01.000
> 2 12 350% complete within 00:00:08.000
> 3 450% complete wi
Aimee,
We watched the SCPER report from RMF and tweaked TSO periods and goals
until our "TSONORM" was performing well for all periods across all
systems during all types of workloads short of "system overload".
# Duration Imp Goal description
- - ---
I was just now looking at this thread and didn't see where anybody mentioned
the SDCs (Service Definition Coefficients). It seems like people were
comparing duration as if they meant the same thing in every location.
That's not so. A duration of 100, 1000, or 1 could mean the same amount
of w
Thanks everyone's patience, I think I understand more now.
We do have an only one Service class for TSO, and in the classification
rule for TSO and with default SC is TSO.
WLM recognizes the workload from subsystem,too... All I thought was the
*Selection rule* inside is a MUST, because I thought
IBM Mainframe Discussion List wrote on 03/27/2008
10:27:40 AM:
> Thanks Tom,
>
> yes, I can see the same thing in my shop,too.
> But, when I "Browse" the rule, there's nothing inside. Take "JES" as
> example, when I browse it inside, there will be rules, I know, they are
for
> different type o
March 27, 2008 2:50 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM and TSO
>
> I don't really see where the problem is here. If there is only one
TSO
> service class, then no selection rules are needed, the default service
> class needs to be specified, but no sel
mailto:[EMAIL PROTECTED] On
> Behalf Of Cobe Xu
> Sent: Thursday, March 27, 2008 9:28 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM and TSO
>
> Thanks Tom,
>
> yes, I can see the same thing in my shop,too.
> But, when I "Browse" the rule, there's noth
half Of Cobe Xu
> Sent: Thursday, March 27, 2008 9:28 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM and TSO
>
> Thanks Tom,
>
> yes, I can see the same thing in my shop,too.
> But, when I "Browse" the rule, there's nothing inside. Take "JES&
-2814
|-Mensagem original-
|De: IBM Mainframe Discussion List
|[mailto:[EMAIL PROTECTED] Em nome de Cobe Xu
|Enviada em: quinta-feira, 27 de março de 2008 11:28
|Para: IBM-MAIN@bama.ua.edu
|Assunto: Re: WLM and TSO
|
|Thanks Tom,
|
|yes, I can see the same thing in my shop,too.
|But
> > -Original Message-----
>
> > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
>
> > Behalf Of Cobe Xu
>
> > Sent: Thursday, March 27, 2008 4:35 AM
>
> > To: IBM-MAIN@bama.ua.edu
>
> > Subject: Re: WLM and TSO
>
> >
>
>
) 760-7632
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Cobe Xu
> Sent: Thursday, March 27, 2008 4:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM and TSO
>
> >
> > hi list,
>
>
>
m: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Cobe Xu
> Sent: Thursday, March 27, 2008 4:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM and TSO
>
> >
> > hi list,
>
>
>any one is willing to answer a rookie's question:
&
>
> hi list,
any one is willing to answer a rookie's question:
How WLM recognize TSO's workload? like trivial TSO transaction, because I
can not see there's a *classification rule* defined for TSO.
like batch, stc, they have a rule...
--
Boy Dave, you are aggressive with your TSO goals. Here we have them set
as follows. I do like your third period though. If they are doing
something in TSO that takes that much service than put them in never
never land.
Duration Imp.Description
800 2 80% complete within
ilto:[EMAIL PROTECTED] On
> Behalf Of Aimee Houghton
> Sent: Tuesday, March 25, 2008 10:01 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: WLM and TSO
>
> I am no performance expert and I am basically mostly using Cheryl
Watson
> quickstart (or whatever it is called). We are only using o
On Tue, 25 Mar 2008 14:42:46 -0500, Mark Zelden wrote:
>... This is really easy to test.
>Define a batch service class with 3 periods. P1 with a DUR of 2 and
>P2 with a DUR of 20001. Then submit a job that you know will run for at least
>a few minutes. You should be able to see via SDSF th
Thanks for the update
>
>One more question. Are the durations cumulative or per period? i.e.
if
>I
>setup as follows, does a transaction fall to period three after 5000
>service
>units or 7500? I looked in the redbook "System Programmer's Guide to:
>Workload Manager" but couldn't find the
On Tue, 25 Mar 2008 13:56:53 -0500, Staller, Allan <[EMAIL PROTECTED]>
wrote:
>IIRC the durations are cumulative (and inclusive).
>
>e.g. Per 1 dur 1000
> per 2 dur 1 (includes the previous 1000)
> per 3 (unending)
>
That is not correct. It may not be in the Redbook, but it says thi
On Tue, 25 Mar 2008 14:13:48 -0500, Staller, Allan <[EMAIL PROTECTED]>
wrote:
>After 5000..
>
>
>One more question. Are the durations cumulative or per period? i.e. if
>I
>setup as follows, does a transaction fall to period three after 5000
>service
>units or 7500? I looked in the redbook "Syst
On Tue, 25 Mar 2008 13:50:16 -0500, Aimee Houghton wrote:
>One more question. Are the durations cumulative or per period?
>From Planning:Workload Management:
"Duration is the amount of service that period should consume before going on
the next goal."
--
Tom Marchant
After 5000..
One more question. Are the durations cumulative or per period? i.e. if
I
setup as follows, does a transaction fall to period three after 5000
service
units or 7500? I looked in the redbook "System Programmer's Guide to:
Workload Manager" but couldn't find the answer.
# Duration
just realized I never put in the "as follows" stuff.
One more question. Are the durations cumulative or per period? i.e. if I
setup as follows, does a transaction fall to period three after 5000 service
units or 7500? I looked in the redbook "System Programmer's Guide to:
Workload Manager" bu
-
As a "carrot" I would also sit down with operators and determine what changes
could be made with the batch service classes to keep them from moving things around.
Considering that operators tend to look only at the near term and not always
realise t
On Tue, 25 Mar 2008 12:26:10 -0500, Aimee Houghton wrote:
>
>We have talked a little bit about WLM managed initiators and may wind up
>doing that.
It's really easy to do. And if you have problems, it's just as easy to go
back.
One consequence is that you can't see what's happening on the SDSF
IIRC the durations are cumulative (and inclusive).
e.g. Per 1 dur 1000
per 2 dur 1 (includes the previous 1000)
per 3 (unending)
IOW, PER 1 (and associated characteristics will last for the 1st 1000
SU's
PER 2 (and associated characteristics will last for the next 9
>As a "carrot" I would also sit down with operators and determine what changes
>could be made with the batch service classes to keep them from moving things
>around.
Considering that operators tend to look only at the near term and not always
realise that their 'helpful' changes usually cause m
One more question. Are the durations cumulative or per period? i.e. if I
setup as follows, does a transaction fall to period three after 5000 service
units or 7500? I looked in the redbook "System Programmer's Guide to:
Workload Manager" but couldn't find the answer.
Thanks again.
Aimee
--
WOW. I REALLY appreciate all the feedback. I signed up for this listserv
quite a long time ago and then promptly forgot about it for the most part.
Not a lot happening in our shop mainframe-wise and I haven't had to think
about much for awhile. This WLM thing has been an intermittent problem ov
Matthew Stitt wrote:
In your case, the correct solution would be to set up SDSF command security
to prevent the operators from changing the service classes. Of course this
will probably become a management political hot potato. As a "carrot" I
would also sit down with operators and determine wh
In your case, the correct solution would be to set up SDSF command security
to prevent the operators from changing the service classes. Of course this
will probably become a management political hot potato. As a "carrot" I
would also sit down with o
Thanks for the quick and informative response. I will look into your
suggestions. I am a little leery about putting TSO above hot batch as well.
Part of the problem is that the operators pretty much open the flood gates
at about 10 pm and let all the batch comp
On Tue, 2008-03-25 at 10:59 -0500, Mark Zelden wrote:
> 100 service units for P1 and 99% complete?!What percentage
> of your transactions actually fall into P1?
00.00.00.150 98.6
00.00.00.180 98.9
00.00.00.210 99.0
00.00.00.240 99.2
00.00.00.270 99.3
00.00.00.300 99.4
00.00.00.330 99.4
00.00.0
David Andrews wrote:
Guess I'll contribute my $.02. Tiny (2096-G01) uniprocessor.
1 100199% complete within 00:00:00.300
2 14000 190% complete within 00:00:02.000
3 3Execution velocity of 10
Hey! This is fun! (2096-L03)
# Duration Imp Goal descrip
On Tue, 25 Mar 2008 11:38:23 -0400, David Andrews <[EMAIL PROTECTED]> wrote:
>1 100199% complete within 00:00:00.300
>2 14000 190% complete within 00:00:02.000
>3 3Execution velocity of 10
>
100 service units for P1 and 99% complete?!What percentage
of
> Here is my service class for TSO:
>
> Base goal:
> CPU Critical flag: NO
>
> # Duration Imp Goal description
> - - -
> 1 800280% complete within 00:00:00.300
> 2 4Execution velocity of 40
Unless you'
Yes, WLM managed initiators can be your best friend. When the machine gets
saturated, WLM will bring the work under control.
Also a good starting point would be to back off the goals for batch. It's
better if the work is over-achieving rather than under-achieving.
On Tue, 25 Mar 2008 10:38:59 -
If they are running batch that is causing resource contentions with
itself, it's not good. If their batch is done in time to have 4 idle
hours at the end of their shift, you don't have a performance problem.
If you are paying measured usage rates on a high-cpu value that happens
AT NIGHT, it's
In your case, the correct solution would be to set up SDSF command security
to prevent the operators from changing the service classes. Of course this
will probably become a management political hot potato. As a "carrot" I
would also sit down with operators and determine what changes could be mad
a good day!
Bret
Bret Hoesly
Senior Systems Administrator - Mainframe
Telephone & Data Systems, Inc.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Aimee Houghton
Sent: Tuesday, March 25, 2008 10:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: R
On Tue, 2008-03-25 at 10:20 -0500, Rugen, Len wrote:
> 1 1500 280% < 2 sec
> 2 5000 380% < 15 sec
> 3 4vel+IO ? 10%
On Tue, 2008-03-25 at 11:24 -0400, Dave Thorn wrote:
> Duration Imp. Description
>
Thanks for the quick and informative response. I will look into your
suggestions. I am a little leery about putting TSO above hot batch as well.
Part of the problem is that the operators pretty much open the flood gates
at about 10 pm and let all the batch compete. That is a whole different
bat
On Tue, 25 Mar 2008 10:00:39 -0500, Aimee Houghton <[EMAIL PROTECTED]> wrote:
>I am no performance expert and I am basically mostly using Cheryl Watson
>quickstart (or whatever it is called). We are only using one service class
>for TSO users. For the most part it works fine but during batch wind
and delete this e-mail from your system.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Aimee Houghton
Sent: Tuesday, March 25, 2008 11:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: WLM and TSO
I am no performance expert and I am basically mo
I have 3 periods, adjusted to your imp's, they would be something like
this:
# Duration Imp Goal description
- - -
1 1500 280% < 2 sec
2 5000 380% < 15 sec
3 4vel+IO ? 10%
I suspect your dur
QDF (quick dirty fix) is to set TSO period 2 to importance 3.
This should change things from intolerable to manageable
If you want "no further calls" for ever and ever, Set TSO period 2 to
importance 2. This will place TSO ahead of PRODHI. (be careful!).
RMF SYSRPTS(WLMGL) provides a wealth of i
I am no performance expert and I am basically mostly using Cheryl Watson
quickstart (or whatever it is called). We are only using one service class
for TSO users. For the most part it works fine but during batch window we
have times when the operators let a bunch of stuff run in high priority
batc
48 matches
Mail list logo
