When WLM was set up in this shop about 5 years ago the DDF workload was
extremely low. The person that set up WLM assigned DDF to "NEWWORK".
Over the past year DDF processing has growing considerably to where it
is now taking approximately 10% of the production LPAR during prime
shift. Most of th
On Fri, 15 Feb 2008 10:23:45 -0600, Kelman, Tom
<[EMAIL PROTECTED]> wrote:
>When WLM was set up in this shop about 5 years ago the DDF workload was
>extremely low. The person that set up WLM assigned DDF to "NEWWORK".
>Over the past year DDF processing has growing considerably to where it
>is now
If this is a production LPAR and all the DDF work coming in is
production, classify it as such.
As Mark said, you'll need to keep an eye on it of course.
We saw some awful effects when DDF first came into use. And if you are
already seeing 10% consumption, you might be in for a shock when you
give
>If this is a production LPAR and all the DDF work coming in is production,
>classify it as such.
I can tell you what we did.
1. Set up a high velocity service class with an importance just below
production online (IMS, CICS, etcf).
2. Set up a transaction class with two periods:
a. The firs
I'm with Ted on this one.
We also started years ago with one or two DDF service classes, and they
quickly became woefully inadequate. We tried a variety of
configurations, from a 5-level priority system with multi-periods, to
one or two with single periods. In our environment, the most efficient
At 2008-03-04 10:01, Gary Diehl <[EMAIL PROTECTED]> wrote about
"Re: Setting up a service class for DDF" to IBM-Main:
> We also started years ago with one or two DDF service classes, [snip]
> most effective has been to code a HI/MED/LOW setup [snip] each with
> ONE a
6 matches
Mail list logo