MVSFORUMS.com

[issac1029]

Hi all,

I've see so many post about this problem,but their answer have not describe clearly,more things I want to know is that:

assume there is a calling pgm A and a called pgm B(a pgm with sql)
all call db2 interface are static,It was said in other post that if A call B,then A must compile by adding

[kolusu]

issac1029,

It depends on the language in which the program is coded. The language interface modules required in each environment are as follows:

[issac1029]

kolusu,

Thanks for you quick reply,

it assume the enviroment is cobol,I'm not concern about which link card I should use.Actual I want to know is whether DSNELI'adding are result from the db2 code in calling pgm or the called pgm.

[kolusu]

issac1029,

It does not matter if your main program or sub program is using DB2. To enable your application to interface with the DB2 subsystem, you must use a link-edit procedure that builds a load module.

So if your program is accessing DB2 you need to link edit with the approriate language interface modules depending on the language being used.

Hope this helps....

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[issac1029]

kolusu,

Somebody says DSNELI is alias of DSNHLI,so I think include syslin(xxx) is to find DSNHLI to resolve the code 'call DSNHLI' which exec sql code are translted into.
So your meaning is that between program and db2,It's actually a dynamic call relationship even though it's wrote as static format?

[Manas Biswal]

issac1029,

I will try to provide an all-encompassing answer to your question. Let us know if you still have doubts.

DSNHLI is the actual routine that is called when you do an EXEC SQL. It is the run time call module for all SQLs. The following are the modules that provide an entry point to DSNHLI and you have to use according to what is appropriate for your environment -
DSNALI - CAF
DSNCLI - CICS
DSNELI - TSO
DSNRLI - RRSAF
DFSLI00 - IMS

Any address space can have only one of these environments active at a time. So, if you are running a calling and a called program in the same address space (say your TSO region), you have to link-edit the same module to both the programs.

But say, a program running in CICS is calling a DB2 stored procedure running on WLM or DB2 SPAS, then the calling program (running on the CICS address space) and the called stored procedure (running on WLM or SPAS address space) are running in two different address spaces. So, you can link-edit different modules to the calling and called programs. The calling CICS program will be linked to the DSNCLI module and the called DB2 stored procedure will be linked to the DSNRLI module.

[issac1029]

Manas Biswal,

Thanks very much
It also solved another question of mine.

[CZerfas]

We experienced yet another phenomena in this context. Starting our program preparation process without this explicit link statement, in the resulting load module the db2 interface was placed AFTER the object deck of the compiled source module. That gave us a runtime error.

By explicitely placing the INCLUDE statement in the link step BEFORE the object deck is performing in the desired way: it works!

regards
Christian

[issac1029]

CZerfas:

Which object deck cause this problem?Why must place it before object deck?

[CZerfas]

With "obejct deck" I mean the result of the compile of an application program. This product of the compilation can not be executed but has to be enriched with system routines into an executable load module.

Why the placement of the routines in the resulting load module is important I don't have a clue, but doing it one way doesn't work and going the other way produces a usable load module.

regards
Christian

[Manas Biswal]

CZerfas,

There is a particular order in which you include all the interface modules on the SYSLIN of the Link-edit steps. Depending on what modules you are including, they need to be placed before or after the object deck in the concatenation order.
See the following link for the order to be followed for different interface modules -

http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts.doc/dfhp3/dfhp3b0069.htm

Why is it so?. I don't know. It was probably designed like that.

Regards,
Manas
_________________
There is no path to peace. Peace is the path.
- Mahatma Gandhi (1869-1948)

[Cogito-Ergo-Sum]