View previous topic :: View next topic
|
Author |
Message |
morpheus007
New User
Joined: 27 Dec 2005 Posts: 58
|
|
|
|
We have a calling program that was non DB2 till now tht calls a DB2 program.Hence in the current JCL we have:
PL(plan name) PR(program name)-->here the main program currently is non DB2 but it calls a program tht has queries hence the plan name.
Now for some performance issues we are adding a COMMIT statement to the main program.We would hence be recompiling it as DB2.
Would a plan be created for including SQLCA and a COMMIT statement or does it need queries with table names to create the plan.
We use endevor for all version control. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
What performance problem(s) do you intend to deal with by placing COMMITs in a non-db2 program? |
|
Back to top |
|
|
morpheus007
New User
Joined: 27 Dec 2005 Posts: 58
|
|
|
|
The called DB2 program is currently being executed 1 time for each record of the Driver file read sequentially in the non DB2 program.We had a DB2 upgrade after which the EDM pool does not get freed during selects.If the EDM is not freed up then for each incremental call to the DB2 program the size increases and causes abends.When we do a COMMIT after the call to the DB2 program in the non db2 program it frees up the EDM space.
This is the issue we are trying to address.
In the current JCL we have a plan name(for the Db2) program.Since we use endevor my assumption is tht when i recompile the non Db2 program it need not necessarily bind to the same plan since the programs belong to diff applications here.
In case a BIND plan does not happen for just SQLCA and 1 COMMIT I could make the code changes and test but in case it does then i might have to also check tht the calling program binds to the same plan name. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
We had a DB2 upgrade after which the EDM pool does not get freed during selects. |
Is this not something that needs to be corrected?
I'd suggest you try by using the same plan in the calling program as the called module - if your system will permit this.
If you introduce these commits, restart/recovery processing needs to be considered also.
I believe the problem should be corrected outside the application rather than needing to introduce restart complexity - fwiw. |
|
Back to top |
|
|
|