From: Frank Swarbrick on
Hi Andreas,

I asked a similar question on the ibm-main listserv just the other day. A
reply I got seems quite similar to your idea:

"This can be solved by writing a COBOL routine named DSNHLI that does
nothing but call DSNHLI dynamically. Link this routine statically into all
of your
application programs. At runtime, the //STEPLIB needs to concatenate the
library containing the stub of the corresponding environment.
A similar approach should work for EZASOKET."

I don't actually have DB2 for z/OS yet (we are considering migrating from
VSE to z/OS, but we haven't purchased DB2 for z/OS yet), so I can't test it.
Are saying that you have in fact tested it and it in fact does work? If
so, that is good news indeed.

Still I have to wonder why IBM doesn't address this issue directly. It
seems to me that, even if you stick with static calls of the DSN stub in the
Cobol program, that stub should simple dynamically call the correct module.
Which is exactly what this workaround seems to be doing.

In any case, I look forward to trying this solution when the time comes.

Frank


n 11/26/2008 at 1:37 PM, in message
<14102947-7263-4caf-bf63-e155606d804b(a)y18g2000yqn.googlegroups.com>,
<plastiksprengstoff(a)googlemail.com> wrote:
> in 2006 i post this question - i dont beleve that see also
> http://groups.google.de/group/comp.lang.cobol/browse_thread/thread/46b66
> a92066f7241/d6302fd446c27054?#d6302fd446c27054
> :
>
> Hello all
>
> System: z/OS and LE for MVS
>
> Why is it possible to compile a COBOL/CICS/DB2 program with the
> options:
>
> NODYNAM . . . ?????
>
> nowerdays thats not the state of the art, because:
>
> IMS could be called dynamic
> COBOL and ASSEMBLER could be called dynamic
>
> why not inside of a CICS environment
>
> I asked this question, because i mus used the same sources in two
> environments:
>
> DB2 Batch (IMS/DSN) - one compile and link
> DB2 CICS - a second compile and link
>
> i have to manage two sources inside a revision environment!!!
>
> The first source could be compiled with the option: DYNAM for batch -
> and all calls are managed by COBOL and MVS
>
> in CICS, the precompiler sets the COBOL options to NODANM. Therefore i
> need a second source to manage the environment. I must use the
> CICS-link library to link the DSNHLI and i can NOT use the same module
> in IMS/TSO, because they need different HLI's: for IMS propagator
> DSNHLI from IMS for DSN propagator DSNHLI from DB2.
>
> I would link a DB2 module without a specific DSNHLI.......
>
> Is DFHECI unable to be called dynamic? IMS module DFSLI000 could.
>
> Why does DB2 precompiler generate calls like: CALL 'DSNHLI' USING
> PLIST-x, instead of CALL DSNHLI USING PLIST-x, where DSNHLI ist
> defined as a variable inside the working-storage section?
>
> I am not pleased about this situation.
>
> I hope, that you could follow my intention... :-)
>
> i am not so stable in english
>
> Einen schoenen Tag
> Andreas Lerch
>
> but today - i have a solution.....
>
> inside the cobol program i use this:
>
> end program main.
> id division.
> program-id. DSNHLI.
> data division.
> working-storage section.
> work-dsnhli pic x(8) value 'dsnhli'.
> linkage section.
> 01 link-dsnhli pic x(1)
> procedure division using link-dsnhli.
> call work-dsnhli using link-dsnhli end-call
> goback.
> end program dsnhli.
>
> now i can use the NODYNAM option within the compiler to call the
> propagator dsnhlin within the application dynamicly...
>
> cics --> DSNHLI of cics
> ims --> DSNHLI of ims and any more
>
> cool
>
> einen schoenen tag
> Andreas Lerch
From: Frank Swarbrick on
I think his point is that the SQL precompiler generates CALL 'DSNHLI' and
not CALL DSNHLI, so he would create a dummy DSNHLI object that dynamically
calls the real DSNHLI load module.

One could probably use REPLACE ==CALL 'DSNHLI'== BY ==CALL DSNHLI== insead,
though.

Then again, is it really needed? If you have a CICS program you are (most
likely) not going to run it in batch, so you can just link in the CICS
version of DSNHLI. Only for a batch subroutine that will also be called
under CICS would this be an issue. And there you could, I think, just use
the DYNAM compiler option.

Frank
--

Frank Swarbrick
Senior Systems Analyst - Mainframe Applications
FirstBank Data Corporation
Lakewood, CO USA


n 12/4/2008 at 1:36 AM, in message
<sEMZk.90183$786.16767(a)fe11.news.easynews.com>, William M.
Klein<wmklein(a)nospam.ix.netcom.com> wrote:
> Are you aware that under CICS when you use the NODYNAM compiler option
> you can
> still use the
> CALL identifier
> rather than
> CALL "literal"
>
> format so all CALLs to *YOUR* application subprograms are dynamic? In
> that
> case, only the CICS/IBM supplied subroutines must be link-edited (bound)
> into
> your load module.
>
> I can't remember when this was first supported, but I know it has been
> possible
> for over a decade and a half.