Temporary Tables - Performance Issue

[Yordaman]

To avoid large amounts of linkage in our mainframe system, we have employed the use of temporary tables. We prototyped this and found comparable performance with permanent tables, so we went ahead.

Now that serious testing is being performed on the full system, we are getting major performance issues. We have switched back to permanent tables, and the performance improves dramatically. We're at a loss as to why this should be the case.

Our prototyping didn't reveal a problem before - so why now? Scale of system (240 COBOL modules) in the run unit? Recent implementation of V7.0 (is this tuned right?)

Any suggestions welcome.

 

[Yordaman]

I also should have mentioned that we recently went to Language Environment as well. I have no idea if this will have been the cause, or partial cause, but I'm hoping some bright spark out there can use this information to help diagnose the problem.

 

[PruSQLer]

When you say temporary tables, do you mean table expressions or something else? What are you running V7.0 on, AIX? OS 390?

 

[Yordaman]

By 'temporary tables' I mean tables declared within the application - 'Declared Global Temporary Tables' is the correct expression.
We're running v7.0 on OS/390.
Some of our people think that 'incremental binds' is causing the problem - our application runs over 200 modules, many of which are performing DB2 access to these tables. Therefore, each has a runtime 'bind' to perform prior to access, causing an overhead. They consider that 200 times this overhead is causing the high CPU times, and that our application simply isn't cut out to use DGTTs.
If this is true, it would nice to have it confirmed. If it isn't, and there's something we can do to improve performance, it would be equally nice to know what.
Thanks.