Hi Dave, It's very difficult to tell you where the bottlenecks are when I can't see the values for myself, but generally, you can get away with some things in a lake than you can in a swimming pool. The velocities are all relative, so 90 is still 90, just like if you were using the old IPS/ICS, where you were dealing in dispatching priorities, the numbers are meaningful relative to themselves. As long as the system doesn't still "think" it has 20% more than it actually does (i.e. still thinks it has 15) :)
When you downgraded, did you have (and do you still have) any specialty processors? They continue to run full speed even after the downgrade. Since you have a 5-way, is it possible that not every one of the processors was downgraded equally? I'm pretty sure you can check it in RMF to be sure. One of our clients had a 6 way z13 that was downgraded and there was an error that resulted in 4 REALLY slow processors and 2 (much) faster ones. Luckily it was an error we discovered in the benchmarking, but IBM had already left for the day. (we called them back in:)) Strangely enough, we didn't discover the error until multiple really heavily loaded tests were started. Assuming IBM got better at the process by now, but you never know. Anyway, if Adabas is at 90/1 and I assume that your com-plete (or CICS) follows closely behind (Maybe 85 or 80/1?), and any brokers and/or natural servers are (at least) higher than production and/or normal batch, and of course your TSO users are also lower than the SAG stuff, then things should be okay. It also could be something simple like you have things losing the thread before they were ready and you end up re-doing a lot of work when they come back in. Is the slowdown apparent in just the on-lines or is it noticeable across the whole system? Does batch also seem to be affected (i.e. you dropped 20% of the system, but how badly was batch affected? You can compare some jobs from before and after the downgrade that are fairly constant to tell. Your weekly Adabas backups would be a good indicator of the batch processing effects. The way to "fix" things could be wildly different if depending on who is affected and how. It could be that you had REALLY BIG buffers defined for Adabas and when you had a lot of extra capacity it didn't matter, but maybe now it's spending more time shuffling things around and reading really far ahead for tasks that just won't be able to take advantage of it, so more busywork ends up happening than actually productive work. Again, it's really hard to tell without more information. Sometimes what happens is that people keep running SQL queries and pound the system just as hard as they would when you had the capacity to spare. Maybe they didn't get the word that they have 20% less to work with. It helps if you can limit them by splitting them away from the normal "good guy" regular Joe users. Can you tell who the big users are that are getting you? Do you run REVIEW or TRIM so that you can see who is causing the (most) overhead? If you want to contact me offline, please feel free to do so. I'll try to help you all I can. Brian On Tue, 13 Oct 2020 21:27:30 +0000, Gibney, Dave <[email protected]> wrote: >It has been quite some time since I had to worry about my WLM policy. We've >had ample capacity since 2007. Now, as We begin to wind down, we have reduced >our contracted MSU capacity. >We dropped from 15 to 12 on an 5 way z13S-N05. My WLM policy, last seriously >adjusted in 2007 when we moved to a z9-L03 has velocities ranging from a high >of 90 (Adabas, Imp 1) down to 5 (BATCH Imp 5) >We are experiencing just a minor amount of performance pain. It strikes me >that perhaps some of my higher velocity goals (90, 70, 60, 50) may be >unattainable under the now reduced capacity. > >What is the high end for possible, single threaded (Adabas) velocity here? Or, >where should I be reading in current manuals. I was better at this 15 years >ago. > >Dave Gibney >Information Technology Services >Washington State University > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
