Hi Johnny,
One of the best things about z/OS and the System z is that it is
designed to run at 100% busy! What you describe sounds like something
that can be improved dramatically by updating your WLM Policy.
If you setup TSO with a reasonable response time goal and an importance
higher than batch and run batch as lower importance with a low velocity
or my preference a discretionary goal then you will find that you can
sustain the added test batch workload without impacting the TSO/ISPF
user productivity.
My test batch service class used here places almost everything that runs
in TSTBATLO save a few quick turn jobs which get TSTBATMD. TSTBATHI is
assigned on request by operations when users request priority.
Class Per Imp Type Goal Goal% Duration Description
TSTBATHI 1 5 VELOCITY 35 High Priority Test
Batch
TSTBATLO 1 DISCRET Low Priority Test
Batch
TSTBATMD 1 5 VELOCITY 20 Medium Priority Test
Batch
I like percentile goals for TSO but even second period TSO is still
getting better service than any test batch.
TSO
Class Per Imp Type Goal Goal% Duration Description
TSOPRD 1 2 PERCENT 0.180 90% 500 TSO Users
. 2 4 VELOCITY 30 .
Review your WLM policy and see what goals you have established for TSO
and batch service classes that are active. Consider to review RMF I
reports or RMF Monitor III or whatever MVS monitoring you have to see if
the cause of the delay to TSO at this time is just CPU delay. You may
find other resources that are tied up by this test batch workload as
well though CPU is a good starting point from what you describe. If you
need some help with any of this I expect you can get it here on
IBM-MAIN.
Best Regards,
Sam Knutson, GEICO
System z Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
Excellent firms don't believe in excellence Only in constant improvement
and constant change.
Tom Peters
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Johnny Luo
Sent: Sunday, July 15, 2007 12:31 PM
To: [email protected]
Subject: Re: Links to decent 'why the mainframe thrives' article
Sorry for a newbie to jump in here...
But I have a question: why IBM doesn't increase the clock of mainframe
CPU?
There is no need or there are some technical problems?
I'm now working at one customer's site and every day's afternoon is a
terrible time for all developers working on their development system: we
just cannot use TSO/ISPF! You must wait 4 or 5 seconds for a response
and
sometimes you just hang there. The cause is that most teams will do
their
batch tests at that time thus eating all of CPU cycles. I guess they
might
need a more powerful CPU? (This situation has last for three months
since I
came here)
--
Best Regards,
Johnny Luo
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
