• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 624
  • Last Modified:

Bind issue?

I have my code in two environments-integration and test and where my subsystem ids for db2 are db2t and db2s respectively.Now my code is the same in both environments but when I bind the code to production dbrm lib,the storesd procedure abends but when I bind it to the intg dbrmlib it works fine.
The table layouts in both the subsytems are the same.What can be the possible reason for this.One of the SP's return -470 sqlcode.But when bound to intg dbrmlib it works fine.Please advise
  • 2
1 Solution
what do you mean - bind to the dbrmlib ?
once you bind the package in db2, the dbrm are not used anymore

when someone works as you describe
test the application in integration and then move it to production without recompiling the code, there are 2 things you can do in order to take care of the pacakge
1) copy the package from integration to production
2) bind the integration dbrms in the production db2

can you please elaborate on :
1) where do you compile the code
2) where did the production system load modules came from ? where did the packages came from ?
NigelleAuthor Commented:
I use endevour for compiling the code.Actaully the problem is like this
The program is already there in production env  and intg env and I need not actually do the first step fo copying the package to production.
My problem is this
My db2 subsytem for integration is db2s and that for stage 2 test is db2t,Now the bind used in intg is the production dbrm bound to the intg db2.This is abending though the code is the same.It was moved to production and integration via stage2 of test env.Now when the integration db2 is  bound to the stage2 dbrm lib that is NDVRPROD.MINTG.**.**.DBRMLIB ,it works fine but when it is bound to the intg dbrmlib(actually the prod dbrm lib)
NDVRPROD.CPROD.**.**.DBRMLIB,the stored procedure abends.

Hope I am clear

STAGE1 -->                                             STAGE2----->                                       ISTAGE
                                                                                                                            PRODUCTION(DB21) Q3

Now when I bind the prodcution db2 to the sytem test dbrm it works fine
but when I bind the production db2  to the production dbrm  it doesn't work.Both the codes are the same
help !!!
Kent OlsenData Warehouse Architect / DBACommented:
Hi Nigelle,

An SQL code of -470 indicates at an input parameter is NULL, but the procedure does not support NULL as an argument.  Keep in mind that the error may be returned by any procedure or function that your SP calls, so it might not be a parameter to your stored procedure that is the problem.

Several things come to mind that might cause this.

--  Data issues.  The data affecting the stored procedure is different on your test/production systems, causing a different result.
--  Library issues.  The library modules are different, causing different results.  You indicate that binding to one library works, but binding to another library fails.  I would look very hard at the differences in the libraries.
--  System differences.  Make sure that the operating systems on your servers are at the same patch levels.  Also make sure that DB2 is at the same levels on all systems.

I'm pretty sure that the difference lies in one of those areas.  Checking the operating system and DB2 patch levels is quick and easy -- Start there.

Checking for data issues is as complicated as is your data.  If the data used by the SP is fairly small, check that the underlying SQL generates similar results on all systesm.

If all of that passes, you'll need to resolve the library differences.  This may be "a challenge".

Good Luck,

db2 create a dbrm when ever you compile the code
in order to be able to run the code with the correct package, you must use the dbrm that you got when you compiled your code
so what i'm asking is - where did you compile the code and how did you get so many versions of the dbrm file ?

you can do 2 things:
1) compile in test system, then copy the load module to prodcution and copy the dbrm to the production dbrmlib and then bind the dbrm from there
2) compile in test system, and then , compile in the productions server,
this way you will get 2 version of the same dbrm, each one will be good for the version of the load module

the dbrm version is determined among other thing by the timestamp

Featured Post

[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now