DB2 Stored Procedures

Our DBAs recently upgraded our AIX based DB2 database to version 8.2.  Due to business limitations, we are accessing the system using V6 clients.  All stored procedures built prior to the ugrade function perfectly under this arrangement, but new procedures built using either the V7 client or the V8.2 client fail to run producing the following error message:

Error: SQL0444N  Routine "*nQualSum" (specific name "SQL050217160054980") is implemented with code in library or path "...nQualSum", function "DBAWD001.SP0600AdminQualSum" which cannot be accessed.  Reason code: "4".  SQLSTATE=42724
 (State:42724, Native Code: FFFFFE44)

If we build and run the SP using only V8.2 clients the work, but if we build on V8.2 the will not run for V7 and V6, and if we build using V7 client they will not run on any of the clients.  If cannot upgrade the clients to V8.2, does anybody have a solution for this?
LVL 3
spekeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ghp7000Commented:
Generally speaking, SQL0444n return code 4 is equivalent to the blue screen of death in Windows, very difficult to diagnose and correct. It relates to the compiler settings, more specifically the export path of the stored procedure, or the fact that prior to the upgrade, the stored procedure relied upon certain MS dll's to be present in the system in order to function and perhaps those clients are expecting those function calls to be resolved.
Since V8.2 no longer requires the external MS compiler, I would ask this question directly to IBM support, as there are just way too many variables involved with stored procedures.

You may get a clue as to what is wrong exactly by looking at the db2diag log, if there is an internal return code there, it can be deciphered for help in solving this problem.
I would also try setting the dbset parameters for the compiler settings that were used prior to the upgrade.
Another way perhaps is to distribute the SP with the put command.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
JackOfAll1Commented:
Were the binds run for each of the different client versions against the UDB?

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DB2

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.