Oppolzer - Informatik / Blog

I guess that the problem is that by copying DSNRLI to DSNHLI and calling that,
you get two seperate instances of DSNRLI; one that does the initialization and
the other one that routes the SQL calls, and this way it does not work because
the connection is established by the one instance (called from the non-DB2
program), and the other one (renamed DSNHLI) does not know about the connection.

Similar situation, if you use DSNULI. I didn't know about DSNULI, but I read
some information right now:

http://www-01.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/com.ibm.db2z11.doc.apsg/src/tpc/db2z_linkeditdsnuli.dita?lang=en

Long before DSNULI existed, we did the same thing at a site of a former customer
of mine, but: we examined the environment ourselves, and: we took care that only
one instance of every IBM interface exists at any given time, and we route all
calls through this one instance, even the initialization calls (in the case of
the CAF or RRSAF interfaces).

See: http://www.idug.org/p/fo/et/thread=36579

excerpt from here:

<citation>
Re: DB2 exit routine
January 6, 2011 04:55 PM
We do this all the time - checking on first call to "our own" DSNHLI,
if there is already a connection to DB2 and, if not, what kind of connection
is required (TSO, IMS, Batch/CAF, Batch/RRSAF - no CICS here), then
establish the correct connection based on specified or looked-up subsystem
and plan informations, then calling the appropriate IBM language interface.

"Our" DSNHLI replacement is only a little stub which calls the logic that
I described above dynamically (MVS LOAD, entry point statically stored,
module loaded only once).

I'm not allowed to share the code, because it belongs to my customer,
but I'm certainly allowed to tell you about some technical details and
answer questions about it.
</citation>

Kind regards

Bernd



Am 12.02.2015 um 18:25 schrieb J.C.:
>
> I am currently working in a shop that uses RRSAF to attach to DB2 in COBOL.
> The programmers would like to switch to having one load module for both batch
> and CICS, and we were hoping we could do that by somehow using DNSULI.
>
> Unfortunately, we are having trouble getting things to work in our environment.
>
> Here's what we have now:
>
> DB2 batch program compiled with options ATTACH(RRSAF)and DYNAM and linked with DSNRLI.
>
> That program calls a different module -- not a DB2 program -- which calls
> DSNRLI to IDENTIFY, SIGN-ON and CREATE THREAD
>
> DB2 CICS compiled to a second loadlib without ATTACH option and with NODYNAM.
>
> Here's what we would like:
>
> DB2 Batch program is compiled once, without the ATTACH option and linked with
> DSNULI. The program can then be called from CICS or batch.
>
> Right now, when we try to do this, the program works fine in CICS, but we get
> a -927 from the DB2 batch program (not the called program that calls DSNRLI
> program) when running from batch.
>
> I tried copying the DSNRLI module into a different LOADLIB and calling it
> DSNHLI. (Found that in a manual.) That took away the -927 error, and everything
> appears to work. However, no SQL statments get executed, and the DB2 batch
> program doesn't show up in my accounting data.
>
> Hopefully this makes some sense. Any ideas?
>