I'm looking for the original five people who submitted DCR/MR (Design Change Request/Marketing Requirement), customers who added their names as interested parties, and anyone else who has a vested interest in having this change implemented. Please email me. I am going to the lab in three weeks to discuss.
I have applications on the same data sharing group requiring both. These came to light only when DESCSTAT was turned to YES and applications went down; the applications depended on NO. Unfortunately, all future development requires YES. To further complicate the matter, third party products require the 15 DB2 'Metadata' packages (DSNASPCC.*) at DESCSTAT=YES.
Currently to keep everything running, a spare member is brought up with DESCSTAT=YES, the 15 DSNASPCC.* packages are bound there, and new packages/stored procedures (automatically routed to a DESCSTAT=NO member by default), are manually rebound on the spare member. The inherent risk here is rebind. As there are over 400k packages, autorebind is a risk, but due to the volume, has to be on.
The ideal solution is DESCSTAT as a bind parameter and the implementation, to my understanding, is not complicated.
This solution has an additional benefit, that of not increasing SPT01. ZPARM DESCSTAT=YES will increase the size of all packages and stored procedures. If it's a BIND parameter, the increase in SPT01 can be controlled. As a significant portion of OLTP is still COBOL/CICS, there's no reason to set DESCSTAT=YES for these objects, increase the package size, and all associated overhead handling it. While compression helped with SPT01, the size increase caused by DESCSTAT can be diminished, almost eliminated, if DESCSTAT is a BIND parm.
Let me know. Thanks, Linda
IDUG DB2 Tech Conference * Prague, Cz * 14-18 Nov 2011 * http://IDUG.ORG/EMEA
International DB2 User Group (IDUG) - Independent, not-for-profit, User Run
Your only source for independent, unbiased, and trusted DB2 information