IMO, it is not that easy, because with the batch connections like CAF and RRSAF,
there are additional "special" calls to the DB2 interfaces that are used to
establish and release the connections, and those special calls have to be
supported by the "universal" interface as well. This is different from CICS, IMS
or even TSO; with TSO, the connection to DB2 is established before the DB2
program gets control.
What we did:
we allowed the user to do explicit CAF and RRSAF connections through our
"general" DB2 interface (which now seems to be a precursor to DSNULI), but we
also did some kind of automatic connection establishing, if we found at the
first "normal" call to "our" DSNHLI, that there was no connection already
established. Then we called the appropriate CAF or RRSAF interface to establish
the connection, if we were able to get the needed subsystem and plan information
No matter how you do it: you should take care that the control flow always goes
through the same IBM interface (only one of each kind), and you should not mix
up the different environments. And you should always control the state of your
Feel free to ask me offline if you need more information on this topic.
Am 13.02.2015 um 13:01 schrieb J.M.:
> Why not just build a COBOL program that does a dynamic call to DSNHLI:
> 01 WS-IBM-DSNHLI PIC X(8) VALUE 'DSNHLI'.
> PROCEDURE DIVISION USING L-DSNHLI-PARM.
> CALL WS-IBM-DSNHLI USING L-DSNHLI-PARM.
> Bind this statically to your application program instead of the real DSNHLI.
> Then, using the linkage editor (program binder), create, in two separate
> libraries, a module called DSNHLI, one being a copy of DSNRLI (for RRSAF) the
> other (in the second library) a copy of DSNCLI (for CICS). Next put the library
> holding the DSNRLI copy in front in your //STEPLIB concatenation for the batch,
> the library holding the DSNCLI copy in front in your //DFHRPL in your CICS.
> And Bob 's your uncle.