Re: Setting up a service class for DDF
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 and ONLY ONE service class period [snip] We found that as DDF transactions moved from period to period, [snip] An extra item I'd like to point at is the type of DDF thread (Active vs. InActive modes) affects your goal choice/achievement. To quote the SysProgs guide to WLM RedBook (SG24-6472), In Active mode the enclave is classified when it starts. If the enclave is reused by different work with different goals, all work is assigned to the goal of the enclave; that is, it is classified using the characteristic of the first work joining the enclave. and Because threads that are always active do not terminate the enclave and thus do not reset the performance period to the first period, a long-running thread always ends up in the last performance period. Any new business units of work that use that thread will suffer the performance consequences. This makes performance periods unattractive for long-running threads. For always active threads, therefore, use velocity goals and use a single-period Service Class. 'course, *we're* still using Active DDF threads here; likely for historical reasons. However, the next time the DBAs clients complain of response problems when some MS-Access thread decides to join draw-down 15 entire tables, my first response will start, Well, you know we could change our threads and ... *grin* (The 2nd idea will be for them to decide which plans/packages should be moved to less aggressive Service Classes.) -- signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- 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
Re: Setting up a service class for DDF
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 and most effective has been to code a HI/MED/LOW setup with three service classes, each with ONE and ONLY ONE service class period each, based on a percentile/time goal like 80% complete in 0.500 seconds that very closely matched our CICS transaction goals in importance and %/t goal. We found that as DDF transactions moved from period to period, their response times dropped dramatically. Why put it in HI if it's just going to end up LOW? Our customers screamed when the systems got busy, and their transactions started running longer, and began to traverse to LOW. So for us, HI means HI, end of story. We also found, in post processor reports, that multi-period DDF caused transactions that traversed all periods to use about 5% MORE service units than when they stayed in one period. We didn't have the head room to allow for this kind of inefficiency. Your mileage may vary. Try something based on your business goals. Monitor and tune from there. %/t goals are great in that they give you all the facts of what happened in black and white, and are easy to tune from. Best luck, Gary Diehl MVS Support The glass is neither half full or half empty; the engineer who designed the glass simply allowed for a 100% increase in fluid storage. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL big snippage 7. Monitor. Analyse. Tune. Rinse. Repeat. -- 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
Re: Setting up a service class for DDF
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 taking approximately 10% of the production LPAR during prime shift. Most of this work is our Online Banking and Online Teller applications making direct requests to DB2 on the z/OS system, so it is an important workload. We want to pull DDF out of NEWWORK and give it its own service class. Does anyone have any recommendations as to how to set up a service class for DDF, or can you point me to some good documentation on the subject? Thanks for any help you can give. Someone (I think Tom Moulder) recently posted about WLM / DB2 and included a link to a paper / recommendations. Cheryl Watson has also published things, but I'm not sure if it is on her web site. Here starter policy is though. Here is what I do: I have DDF work classified as production vs. test/development just like other workloads (I have 3 levels). The first 2 (high and med) both have 2 periods with the first period having a response time goal / duration and the 2nd period having a velocity goal at a lower importance. The 3rd srvclass (default, catch all, used for batch processes) has 3 periods. The 2nd period has a very long duration (20) and the 3rd period is discretionary. The highest one is importance 1 and is only used for WebSphere created enclaves (no DB2 data sharing in this environment and WAS runs on a separate LPAR). I used (and still do use) RMF post processor and RMF III to monitor the distribution between periods and to help come up with a good cut off. Don't use response time goals if THREADS=ACTIVE or RELEASE(DEALLOCATE). HTH, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Setting up a service class for DDF
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 it a decent classification. Shane ... On Fri, 2008-02-15 at 10:23 -0600, Kelman, Tom 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 taking approximately 10% of the production LPAR during prime shift. Most of this work is our Online Banking and Online Teller applications making direct requests to DB2 on the z/OS system, so it is an important workload. We want to pull DDF out of NEWWORK and give it its own service class. Does anyone have any recommendations as to how to set up a service class for DDF, or can you point me to some good documentation on the subject? Thanks for any help you can give. -- 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
Re: Setting up a service class for DDF
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 first was set up to consume the equivalent of 0.1 seconds of CPU, and had a response goal of 90% 0.5 seconds. This figure is site dependent. b. The second was set up with an importance just lower than P1. 3. Set up many report classes for each id. We classified by id, because each id was attributable to an application. 4. Turn off the SQL governor -- they're just going to resubmit when a transaction abends. 5. Assign the high (business) priority work to number 1. 6. Assign the other work to #2. 7. Monitor. Analyse. Tune. Rinse. Repeat. - Too busy driving to stop for gas! -- 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
