On Tue, 23 May 2006 16:04:10 -0400, Craddock, Chris <[EMAIL PROTECTED]> wrote:
>> I would add, use response time goals for everything you can. > >Yes, in general that is the right answer because the target unit (time) >is invariant with respect to platform. Velocity was a bad idea. >Importance alone would have been preferable, or some less obscure way of >saying how much delay protection you wanted for the work, but now "it is >what it is". > >> They are far preferable for batch, IMHO. > >...for <most> batch. If you look at your initiator and batch class >setup, you already have a first cut approximation at the goals. But >don't overdo it. Some things just don't have a goal that you can predict >and in those cases... Im not sure what you mean by that, Chris. Initiator and class setup didn't tell me much. I had to look at typical turn-around times and the number of jobs. As far as not having "A goal that you can predict," are you talking about individual jobs? That's not what you need to think about when setting goals. That's why I suggested using relatively low percentile. If you tell WLM that you want half of your production batch to finish in ten minutes, all jobs that are in that service class will get the same dispatching priority, etc, which will be managed to provide that level of service to the half that finish quickly. > >> Use a relatively low percentile and reasonable goals. Don't be too >concerned about the monster jobs >> that run all night. You probably don't have very many of them. >> You'll probably find, as I did, that the vast majority of your >> important production jobs run in a relatively short time. Maybe a >> goal of 50% complete in less that 30 minutes will cover most of >> your work. The rest will go along for the ride. >> >> And don't forget to put as much as you can into discretionary. >> Maybe even last period TSO. > >Maybe yes, maybe not. Discretionary is just that. If you approach >discretionary from the view that you don't really care whether or how it >runs as long as it eventually finishes, you probably won't be >disappointed. In my experience, there are usually some cycles available for discretionary work, even when you think your CPU is pegged. Discretionary work gives WLM the opportunity to use that last little bit of resources. Without it, you might find that you are unable to effectively use that last percent or two. And if your discretionary isn't running at all, it may be that you have set unattainable goals on some of your other work, and WLM is struggling to meet those goals. > >Otherwise, unless you really have capacity to spare (and keep soft/hard >caps in mind!) you are very likely to find great slabs of the day where >your discretionary stuff does not run at all - and ends up eating an >initiator for each job that's actively going nowhere. In those cases it >is better to have a goal, even if it's a pretty low one. And if you're >not resource-wealthy and don't want to spend so much time dinking around >with your policy, set a low goal and be done with it. Initiators are also resources. WLM can manage them quite nicely in most cases. If you frequently have to fiddle with your policy, you have probably set goals that are too aggressive. > >> >Now would be a good time to move to response time goals for CICS >(before >> >the upgrade). In the mixed environment, the achieved velocities may >vary >> >widely, but the RT goals should be met on either platform. > >I -STRONGLY- agree with Steve Samson's advice above <ps. "Hi Steve, are >you still enjoying retirement?> > ---------------------------------------------------------------------- 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
