I have maintained many sites with Adabas and I have found common several factors tend to make it slow down. If it's fast sometimes and slow others, then it's almost always going to be a WLM problem.
You have to have a common hierarchy in the system, A site with Adabas is going to "normally" be one where adabas needs to be higher than almost everyone else including any other applications you are running, if you are running Com-Plete (SAG's tp monitor) it needs to be higher than TSO because TSO is a single person, Com-Plete can be hundreds or thousands. Think of Com-Plete as being like CICS. Putting a batch job that uses Adabas at a better position within WLM than Adabas is highly counter-productive.
One other big factor is the processor complex you are running on. Adabas likes a big fast CPU and while having multiple CPU's is helpful so that Adabas can monopolize one for itself, when it comes to Adabas, vertical capacity is much better than number of CPUs.
These numbers I'm about to mention are going to be relative to the rest of your system so keep in mind that 35 to one site might be like 95 at some other site, so just take them as general guidelines. When it comes to WLM, Adabas needs to be at a constant velocity setting, all in one period with an importance of '1'. For instance if Adabas is a velocity of 65, then Com-Plete would be 55. TSO should have a goal to complete with something like 80% in the first 0.6 seconds and then the second period you can go to a velocity of something low like 15. BATCH adabas jobs (those that use Natural and Adabas directly should be somewhere in the vicinity of a velocity of 25 for the first period with a duration of around 1000 with a second period of a straight velocity of something like 10. Don't put them in periods that swap out, and Adabas should never, ever, ever, ever be swapped out.
Most of the work is performed by the Adabas region on behalf of the batch jobs, with the batch jobs pretty much just doing the moving of field around that Adabs provides so they should not have a higher dispatiching priority or importance than Adabas itself, never, ever, ever.
As far as Adabas is concerned, NEVER put your Asso and DATA on the same volume, at least not for production. Assuming you are on a raid dasd box, it doesn't really matter where you place most things because they are all likely striped across the same physical volumes anyway, but Adabas does lots of things based on where he "thinks" things will be the most efficient.
Adabas needs a LOT of buffers for everything, if you think you have enough, you don't, until you see the shutdown stats and see how close you came to running out.
Make sure you have 64bit i/o turned on and that you are using large pages if possible. If you have not turned on large paging, turn it on and re-ipl your LAPR to make it available to Adabas, it's a noticeable difference. Adabas should be also ALWAYS be set to region=0M. Make sure your ECSA is VERY large, Adabas aware of how much you have and will throttle itself so as not to run out. It's all pageable, so make it big.
Depending on the version of Adabas, and how good (or not) that the installer was, you could be running with a lot of default parms as delivered by SAG, which are really great for initial testing but completely suck when it comes to day to day production response.
Also, in general, your tuning needs to be approached with some sort of goal in mind. Is Adabas access and performance the #1 priority? If not, it should be, because whether you run CICS or Com-plete as the tp monitor, if Adabas slows down, they will as well. Also you have to remember that your processor is a finite resource, you can only get so much out of it and when you hit 100.x% busy, something else has to give, and you don't want that to EVER be Adabas.
You have to make a list of everything you run and put it in order by importance to the site, and then remember that if something needs some other regions resources, then the "other" region is by definition more important. Everyone needs Adabas at most sites that run it, but Adabas doesn't really need VTAM or TCP, or BATCH, or TSO, or CICS or Com-PLETE, and having great VTAM or TCP throughput is silly when all of your users need Adabas to get anything done.
Programmers are the first to complain about this kind of thing, they tend to feel that they need to be higher than production, and there are even system programmers who feel that they have to have their TSO ID the highest priority in the system because they need to "get in" if something goes wrong. I hear that a lot and it still makes me laugh every time.
If you post your WLM settings here, we can all help you tune you system as an exercise. We probably won't all agree on things, but I would expect that your settings are poorly written right now and all help would probably be beneficial for you.
Just don't think you have to do all of this quickly, the process of going from bad to good is more iterative than you might first think. You have to make some guesses at first, and then monitor to see how it's going and react to that, so it might take you a week or so to get things going in the right direction, and even then you will still need to tweak things from time to time. There is always something that you didn't think about that comes up to hit you in the face, you just need to react to it and not overreact. Overreacting is counter-productive because it will mask true issues and normally exacerbates the problem you were trying to respond to in the first place
After all, tuning is really (unless you can order an upgrade) a balancing act to get the most out of your box. You have to have favorites, and you have to have things that you are willing to sacrifice support for in order to service your favorites.
If you want to do this off list, I'm okay with that as well, but I think it really would be better for you to get the opinions of a lot of different people on tuning. No one is completely right, and I would expect that (mostly) no one is completely wrong with their opinions of how things should be set up. Every site is different and has different priorities. Adabas sites and DB/2 sites will disagree about a lot of things, but generally the approach is the same.
A good first step would be to go to you WLM panels, print your current settings and post it here, or email it to me and I'll go over them with you. Tuning is something that everyone should know how to do, and unfortunately, not too many people do that any more. A lot of sites take the Watson&Walker quickstart samples and run them without any changes. It's a really, really good place to start, but it's just a start and a lot of people seem to miss that.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN