Hier eine interessante Diskussion zum Thema "DB2 Plans". Die Frage, die viele von uns beschäftigt: "Wie organisiert man DB2 Zugriffspläne in einem DB2 Subsystem?" wird hier  kompetent von IBM-Spezialisten diskuttiert.

Wir bedanken uns für die Zusendung durch Herrn R. Loeben vom IBM Software Support!

Unique Plan (DB2 FORUM appended at 11:06:24 on 99/01/08 GMT)

Die Frage:
Customer started having serious problems when a unique plan (one for online and one for batch) was implemented on the installation. They used to have one  DBRM plan by aplication and they changed to one collection by aplication and one plan with all the collections. Can anyone tell me what are the advantages and desavantages of having a unique plan ?
Leonor Azevedo,IBM Portugal

Mike an Lenor:
Leonor, what sort of problems? It is my belief (without concrete evidence) that using a plan with a long list of entries, either specific packages or  collid.*, is detrimental to performance.
I recommend a short list, max 3 items, using collid.*. There seems to be less overhead in having a single collection with many packages. An application I worked with used  one collection for online, approx 1500 members, one for batch, approx 500 members, and one for subroutines, approx 500 members.
We used a single online plan which referenced the online and subroutine collections  and a plan for each batch program which used the batch and subroutine collections.
Mike Bracey (ISC UK)
 

Hari an Mike:
The analogy I would make is that having one plan for everything is like having everyone in the world named John Smith.  It makes it very easy to remember a persons name, but there is a lack of granularity in reporting, monitoring and problem resolution. Telling me John Smith knows DB2PM or John Smith robbed a bank isn't very useful, but it is simple, easy and standard.
Things like DB2 traces, RLF, WLM, DB2PM use planname as constraints. If I had to do performance work at a site I'd want to have a separate plan for each online transaction and each batch program.  I want to be able to map from CICS transaction xyz23 to the specific plan so I can see what is happening for that particular work.  And I don't want one CICS transaction that does all the work. The value of granularity applies across the board.
At the DB2 panel at the 98 DB2 Tech Conference a customer said something like: they have one plan for all CICS transactions and it is hard to do performance monitoring and problem resolution since the tools tend  to operate at a plan level (that's my biased recollection, the audio tape would tell you what was actually said). I recall the response as indicating there wasn't much you could do.
Hari Shanmugadhasan

Martin an Hari:
Do you mean "1 package per tran" as Classes 7 and 8 relate to packages? Martin Packer/UK/IBM

Dougie an Martin:
I mean 1 plan (composed of n packages) per tran. (Compare with IMS where psbname=plan, but one psb can service n transactions and each of n  transactions could run with a seperate package.) Most of the troubles with CICS stem from txid being 4-bytes but pgmname/plan can be 8-bytes. The RCT is effectively the look-up table for txid to plan.
Dougie Lawson, IBM Basingstoke, UK.

Hari an Martin und Dougie:
To give a context to the trade-offs involved, how much effort does it take to update the RCT?  Say you wanted to add a batch of 20 new  CICS transactions each with its own plan for a new application which is in the process of being developed.  Does it take 1 hr, half a day, a day?
Hari Shanmugadhasan

Dougie an Hari:
Hari,it isn't the time. It's the change management controls that are the bigger problem.
When I worked at ......., it could take 1/2 a day to work  through the change manangement process for a five minute change. If the change needed any sort of outage, add a week of lead time to that so the users could be informed. This was the case even if the change would be  implemented during the quiet hours. But change management is a necessary evil or the system programming dept will tend towards anarchy. (Or worse making "cowboy" changes - "It won't affect DB2!"  (famous last words).)
CICS RDO support of DB2 RCT definitions should be shouted from the roof tops.
It is the best change that CICS development have come up with since they took ownership of the DSN2xxxx code.
Dougie Lawson, IBM Basingstoke, UK.

Roger an alle:
I guess I can't resist.  One plan for a CICS region is workable if you have a very homogeneous situation - not much need for monitoring, not many  packages, not too high a transaction rate or a lower need for availability. One of our people who worked on CICS attach estimated that we are talking 2% to 4% of our customers, the ones who can trade for simplicity  at the expense of performance, manageability and availability. The cpu you save with thread reuse is wasted and then some for the larger numbers of items in every chain. The storage picture is worse, especially in  EDMPOOL when you have a large number of packages that are run infrequently.  The combination of release(deallocate) with a single plan and large numbers of packages can mean hundreds of megabytes in EDMPOOL.  Then you start on the downward spiral, too little memory, more cpu, excessive paging and IO, ...
The worst issue is the inability to manage, and there are about a dozen aspects of monitoring, determining  ownership,          and tuning that become more difficult to impossible. This will compound memory, IO and cpu issues. Having a plan for every transaction is the other end of the spectrum.  When I coded applications, we had groups of programs, naming standards and grouped applications. This way you might have a plan for ten or twenty transactions in an application.  You can't separate everything with just a plan, but your time to change the RCT or CICS tables is reduced.  Analyzing the groups of transactio ns together might even make sense, especially if they use the same tables and modules.
Roger Miller

Dave an Roger:
Roger and others have made valid points about the pros and cons of having a single plan for a transaction, application, or region. Hopefully the main  point that has come across is that there is no one answer for everyone.
>>> Some folks have had great success by having a single plan for a CICS region. They have minimal administration of >the RCT  and corresponding DB2 authorizations.  They also have minimal granularity from DB2 security and accounting.
>>>Some folks had great disasters by condensing plans too quick and too much causing  EDMPOOL overflows, loss of  needed accounting or other controls.
One thing was not stated quite right. You do not have to change the RCT to add a new transaction/plan entry.  It is true that we added the ability to do this dynamically in CICS TS 1.2. Unfortunately, knowledge of this seems to be reinforcing the myths that you must do this if you have unique plans.
Changing the RCT involves a DB2 outage for the CICS region. The pool running a dynamic plan exit can sufficiently handle new
transactions and plans as needed.  The dynamic plan exit can be changed without  stopping the connection, or be designed to read from storage.  Changes to the RCT should only be necessary to specify unique parameters for performance, security, or accounting.  The dynamic plan exit should be very tight code since it will be called once at the beginning of most units-of-work in transactions.
Dave