IBM Cobol With DLI/CICS Integrated Translator

A problem/question has come up that I have no answer to.  I'm wondering
if any of you have a creative idea to fix this.

The translator for CICS and DLI commands is one in the same.  When using
the old preprocessor version, one would pass the "XOPTS(CICS)" or
"XOPTS(DLI)" options to control what it would translate.

With the new integrated translator, the XOPTS parm is gone.  Now we have
the CICS/NOCICS option.  So to do DLI translation, one passes the parm
"CICS(DLI,NOLINKAGE)".  And it will also do CICS translation for you.
After all, the CICS parm is on.

My problem is that my shop uses a great number of batch IMS BMP
programs.  When we try to compile a batch program that will interact
with IMS, we have to pass the parm CICS(DLI,NOLINKAGE).

The integrated translator 'assumes' that we are doing CICS as well and
insists that we turn on NODYNAM.  But, since the separate translator
allowed XOPTS(DLI) with DYNAM, we have a huge number of programs that do
"CALL 'pgmname' USING...".

We really do not want to staticly interconnect all of our 58,000
modules.

We also do not want to edit/recompile/migrate a large number of the 58k
modules to convert the CALL '' to CALL varname.

Does anyone have any good ideas?

Joe Zitzelberger wrote:

>A problem/question has come up that I have no answer to.  I'm wondering
>if any of you have a creative idea to fix this.
>
>The translator for CICS and DLI commands is one in the same.  When using
>the old preprocessor version, one would pass the "XOPTS(CICS)" or
>"XOPTS(DLI)" options to control what it would translate.
>
>With the new integrated translator, the XOPTS parm is gone.  Now we have
>the CICS/NOCICS option.  So to do DLI translation, one passes the parm
>"CICS(DLI,NOLINKAGE)".  And it will also do CICS translation for you.
>After all, the CICS parm is on.
>
>My problem is that my shop uses a great number of batch IMS BMP
>programs.  When we try to compile a batch program that will interact
>with IMS, we have to pass the parm CICS(DLI,NOLINKAGE).
>
>The integrated translator 'assumes' that we are doing CICS as well and
>insists that we turn on NODYNAM.  But, since the separate translator
>allowed XOPTS(DLI) with DYNAM, we have a huge number of programs that do
>"CALL 'pgmname' USING...".
>
>We really do not want to staticly interconnect all of our 58,000
>modules.
>
>We also do not want to edit/recompile/migrate a large number of the 58k
>modules to convert the CALL '' to CALL varname.
>
>Does anyone have any good ideas?
>
>
>
The Enterprise COBOL Programming Guide (I'm guessing that might be the
version you're using) says that the separate pre-processor is still
supported, but not recommended (for some valid reasons, but you
susrvived for a long time using the pre-processor, from what your
original post says).

It also says you should use the COBOL3 option, which will insert a CBL
statement containing RENT,NODYNAM,LIB, but that you can defeat this by
using an option NOCBLCARD.  Probably, you did some or all of this
already, before starting to use the integrated pre-processor.

All that said, it appears that IBM does not expect to have the COBOL
compiler see programs which contain EXEC DLI and no EXEC CICS.  And I
freely admit that I'm no CICS expert.  My shop wrote IMS programs (we
were an IMS shop, with a smattering of CICS) using CALL statements.  I
only learned about EXEC DLI when we had to support a little mfg. shop in
the company that had migrated up from VSE.  But I would have recommended
against using EXEC DLI in programs that weren't CICS (in other words,
batch IMS), because that usage made them CICS pre-processor dependent.

Maybe you should look into doing a mass conversion.  Isn't that a happy
prospect?

Also, I feel that you should open a problem with IBM, saying that you
need to be able to compile programs which contain no CICS, but do
contain EXEC DLI.  They'll probably fix the integrated pre-processor in
a future release, so that you can do what you used to do with the
separate pre-processor.

On Fri, 10 Sep 2004 21:35:30 -0400, Joe Zitzelberger
<joe_zitzelberger@nospam.com> wrote:

>A problem/question has come up that I have no answer to.  I'm wondering
>if any of you have a creative idea to fix this.
>
>The translator for CICS and DLI commands is one in the same.  When using
>the old preprocessor version, one would pass the "XOPTS(CICS)" or
>"XOPTS(DLI)" options to control what it would translate.
>
>With the new integrated translator, the XOPTS parm is gone.  Now we have
>the CICS/NOCICS option.  So to do DLI translation, one passes the parm
>"CICS(DLI,NOLINKAGE)".  And it will also do CICS translation for you.
>After all, the CICS parm is on.
>
>My problem is that my shop uses a great number of batch IMS BMP
>programs.  When we try to compile a batch program that will interact
>with IMS, we have to pass the parm CICS(DLI,NOLINKAGE).
>
>The integrated translator 'assumes' that we are doing CICS as well and
>insists that we turn on NODYNAM.  But, since the separate translator
>allowed XOPTS(DLI) with DYNAM, we have a huge number of programs that do
>"CALL 'pgmname' USING...".
>
>We really do not want to staticly interconnect all of our 58,000
>modules.
>
>We also do not want to edit/recompile/migrate a large number of the 58k
>modules to convert the CALL '' to CALL varname.
>
>Does anyone have any good ideas?

Write 'wrappers' with the same names as called programs. A wrapper
program simply issues a dynamic call to the real target program.

Alternatively, put all wrappers in a single program containing lots of
ENTRY statements. Link it explicitly in your compilation job.

Joe,
I have sent a note to one of my "usually reliable" sources for comment on
this, but I don't know how this does (or doesn't) fit in with using the
CICS(EXCI) translator option.

Currently IBM does not *SUPPORT* compiling with CICS(EXCI) and using the
integrated co-processor.  However, it has been reported that (at least in mo
st
cases) it works.  You might want to try compiling with that and DYNAM, and s
ee
what happens.

--
Bill Klein
wmklein <at> ix.netcom.com
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-635570.21353010092004@knology.usenetserver.com...
>A problem/question has come up that I have no answer to.  I'm wondering
> if any of you have a creative idea to fix this.
>
> The translator for CICS and DLI commands is one in the same.  When using
> the old preprocessor version, one would pass the "XOPTS(CICS)" or
> "XOPTS(DLI)" options to control what it would translate.
>
> With the new integrated translator, the XOPTS parm is gone.  Now we have
> the CICS/NOCICS option.  So to do DLI translation, one passes the parm
> "CICS(DLI,NOLINKAGE)".  And it will also do CICS translation for you.
> After all, the CICS parm is on.
>
> My problem is that my shop uses a great number of batch IMS BMP
> programs.  When we try to compile a batch program that will interact
> with IMS, we have to pass the parm CICS(DLI,NOLINKAGE).
>
> The integrated translator 'assumes' that we are doing CICS as well and
> insists that we turn on NODYNAM.  But, since the separate translator
> allowed XOPTS(DLI) with DYNAM, we have a huge number of programs that do
> "CALL 'pgmname' USING...".
>
> We really do not want to staticly interconnect all of our 58,000
> modules.
>
> We also do not want to edit/recompile/migrate a large number of the 58k
> modules to convert the CALL '' to CALL varname.
>
> Does anyone have any good ideas?
>

Joe,
After some private discussion, the question has come up whether it EVER was
supported to compile with
CICS(DLI)
or
XOPTS(DLI)

and the COBOL DYNAM compiler option.

Can you find anywhere that actually documented this as "legal" (which is NOT
 to
say that it might have worked).

http://publibfp.boulder.ibm.com/cgi...p3a00/1.4.5.1.2

certainly seems as if it is saying that the translator *ALWAYS* required NOD
YNAM
"for CICS programs - whatever that means)- although

http://publibz.boulder.ibm.com/cgi-...fsapce3/1.4.2.2

is "silent" on the issue.

Personally, my "perception" is that as the documentation never SAYS that it
illegal to use DYNAM for an EXEC DLI program that is used as a BMP (or batch
)
and that does NOT use the "CICS" option, then I would call  it legal. On the
other hand, if you can find anyplace that says it *is* legal, that might hel
p.

Finally,
http://publibz.boulder.ibm.com/cgi-.../igy3pg20/3.1.2

makes it pretty clear (to me) that AS OF TODAY, if you use the integrated
translator (coprocessor) that you MUST use NODYNAM.  However, if you/we can 
find
someplace that "documents" that the (separate) translator supported DYNAM, w
e
might create a "reasonable" SHARE requirement to add this support (in the
future).

--
Bill Klein
wmklein <at> ix.netcom.com
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-635570.21353010092004@knology.usenetserver.com...
>A problem/question has come up that I have no answer to.  I'm wondering
> if any of you have a creative idea to fix this.
>
> The translator for CICS and DLI commands is one in the same.  When using
> the old preprocessor version, one would pass the "XOPTS(CICS)" or
> "XOPTS(DLI)" options to control what it would translate.
>
> With the new integrated translator, the XOPTS parm is gone.  Now we have
> the CICS/NOCICS option.  So to do DLI translation, one passes the parm
> "CICS(DLI,NOLINKAGE)".  And it will also do CICS translation for you.
> After all, the CICS parm is on.
>
> My problem is that my shop uses a great number of batch IMS BMP
> programs.  When we try to compile a batch program that will interact
> with IMS, we have to pass the parm CICS(DLI,NOLINKAGE).
>
> The integrated translator 'assumes' that we are doing CICS as well and
> insists that we turn on NODYNAM.  But, since the separate translator
> allowed XOPTS(DLI) with DYNAM, we have a huge number of programs that do
> "CALL 'pgmname' USING...".
>
> We really do not want to staticly interconnect all of our 58,000
> modules.
>
> We also do not want to edit/recompile/migrate a large number of the 58k
> modules to convert the CALL '' to CALL varname.
>
> Does anyone have any good ideas?
>

That is a great idea, I'll give that a shot.  Thanks for your help Bill.

I'll also see if I cannot find some documentation on DLI for BMP
supported with DYNAM.  I know we have done it for 10 years with great
results, but I cannot actually say that it was ever 'supported' by IBM.


In article <yRk1d.715527$ic1.74419@news.easynews.com>,
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Joe,
>   I have sent a note to one of my "usually reliable" sources for comment o
n
> this, but I don't know how this does (or doesn't) fit in with using the
> CICS(EXCI) translator option.
>
> Currently IBM does not *SUPPORT* compiling with CICS(EXCI) and using the
> integrated co-processor.  However, it has been reported that (at least in
> most
> cases) it works.  You might want to try compiling with that and DYNAM, and
> see
> what happens.
>
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
> news:joe_zitzelberger-635570.21353010092004@knology.usenetserver.com... 
>
>

Bill,

I can not find anyplace where IBM comes out and says DYNAM with DLI/BMP
is supported.  As far as I have been able to find out, batch BMP regions
(no mention of DLI) are/were supported with DYNAM.  But when using DLI
it becomes quite silent, as you noted.

Every place IBM says they require NODYNAM is qualifed with CICS somehow.

I've tried compiling numerous ways.  That translation seems to go fine,
but there seems to be a totally separate check for the CICS() option
that will always turn on NYDYNAM.  Nothing worked.  I couldn't even get
the EXCI option to run at all.

Do you know of other places impacted by this problem?

Joe,
I have sent a note to one of my "usually reliable" sources for comment on
this, but I don't know how this does (or doesn't) fit in with using the
CICS(EXCI) translator option.

Currently IBM does not *SUPPORT* compiling with CICS(EXCI) and using the
integrated co-processor.  However, it has been reported that (at least in mo
st
cases) it works.  You might want to try compiling with that and DYNAM, and s
ee
what happens.

--
Bill Klein
wmklein <at> ix.netcom.com
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-635570.21353010092004@knology.usenetserver.com...
>A problem/question has come up that I have no answer to.  I'm wondering
> if any of you have a creative idea to fix this.
>
> The translator for CICS and DLI commands is one in the same.  When using
> the old preprocessor version, one would pass the "XOPTS(CICS)" or
> "XOPTS(DLI)" options to control what it would translate.
>
> With the new integrated translator, the XOPTS parm is gone.  Now we have
> the CICS/NOCICS option.  So to do DLI translation, one passes the parm
> "CICS(DLI,NOLINKAGE)".  And it will also do CICS translation for you.
> After all, the CICS parm is on.
>
> My problem is that my shop uses a great number of batch IMS BMP
> programs.  When we try to compile a batch program that will interact
> with IMS, we have to pass the parm CICS(DLI,NOLINKAGE).
>
> The integrated translator 'assumes' that we are doing CICS as well and
> insists that we turn on NODYNAM.  But, since the separate translator
> allowed XOPTS(DLI) with DYNAM, we have a huge number of programs that do
> "CALL 'pgmname' USING...".
>
> We really do not want to staticly interconnect all of our 58,000
> modules.
>
> We also do not want to edit/recompile/migrate a large number of the 58k
> modules to convert the CALL '' to CALL varname.
>
> Does anyone have any good ideas?
>

Joe,
I don't personally know of any other shops impacted by this.  I did find one
thing that *might* be relevant.  At:

http://publibz.boulder.ibm.com/cgi-...fsaptf5/1.5.9.5

it says,  (referring to programs using CALL "CBLTDLI"

"If the COBOL compiler option NODYNAM is specified, you must link edit the
language interface module, DFSLI000, with your compiled COBOL application
program. If the COBOL compiler option DYNAM is specified, do not link edit
DFSLI000 with your compiled COBOL program."

This certainly means that *other* types of IMS programs support DYNAM.

This, along with the fact that using the separate translator and the
CICS(DLI,NOCBLCARD,NOLINKAGE) options allows for DYNAM makes me think this i
s a
VERY reasonable requirement for IBM to "fix".

I suggest creating a SHARE requirement.  Roland already created a requiremen
t
against the integrated coprocessor supporting CICS(EXCI).  He submitted his
requirement against CICS - but there weren't many votes on it.  I would sugg
est
that you create this against COBOL.  Clearly it would require work from BOTH
products development teams.

Also, if you are one of the shops that is lucky enough to have a "marketing"
branch, you can/should create a "REQUEST" for it there.

For the time being, I suggest you just keep using the separate translator st
ep.

--
Bill Klein
wmklein <at> ix.netcom.com
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-E7D665.01090917092004@knology.usenetserver.com...
> Bill,
>
> I can not find anyplace where IBM comes out and says DYNAM with DLI/BMP
> is supported.  As far as I have been able to find out, batch BMP regions
> (no mention of DLI) are/were supported with DYNAM.  But when using DLI
> it becomes quite silent, as you noted.
>
> Every place IBM says they require NODYNAM is qualifed with CICS somehow.
>
> I've tried compiling numerous ways.  That translation seems to go fine,
> but there seems to be a totally separate check for the CICS() option
> that will always turn on NYDYNAM.  Nothing worked.  I couldn't even get
> the EXCI option to run at all.
>
> Do you know of other places impacted by this problem?
>

I've never opened a SHARE requirement -- how do I go about doing that?

I think perhaps it might become a non-issue at my shop.  After some
discussion we have identified ways to prevent unwanted static calls
(e.g. not IMS, MQ, CICS, DB2 stubs) from entering the source control
system.

So it will still be a pain, but it will not be a dangerous pain.

I do get the feeling that IBM is taking something away from us here.
We've use EXEC DLI in BMPs for over a decade.  Though I was not there at
the begining, some of the old-timers have said that it was IBM that
originally suggested we use EXEC DLI in BMPs.

I appreciate your help with all of this.



In article <85G2d.1535724$y4.267902@news.easynews.com>,
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Joe,
>    I don't personally know of any other shops impacted by this.  I did fin
d
>    one
> thing that *might* be relevant.  At:
>
> [url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dfsaptf5/1.5.9.5[/url
]
>
> it says,  (referring to programs using CALL "CBLTDLI"
>
> "If the COBOL compiler option NODYNAM is specified, you must link edit the
> language interface module, DFSLI000, with your compiled COBOL application
> program. If the COBOL compiler option DYNAM is specified, do not link edit
> DFSLI000 with your compiled COBOL program."
>
> This certainly means that *other* types of IMS programs support DYNAM.
>
> This, along with the fact that using the separate translator and the
> CICS(DLI,NOCBLCARD,NOLINKAGE) options allows for DYNAM makes me think this
 is
> a
> VERY reasonable requirement for IBM to "fix".
>
> I suggest creating a SHARE requirement.  Roland already created a requirem
ent
> against the integrated coprocessor supporting CICS(EXCI).  He submitted hi
s
> requirement against CICS - but there weren't many votes on it.  I would
> suggest
> that you create this against COBOL.  Clearly it would require work from BO
TH
> products development teams.
>
> Also, if you are one of the shops that is lucky enough to have a "marketin
g"
> branch, you can/should create a "REQUEST" for it there.
>
> For the time being, I suggest you just keep using the separate translator
> step.
>
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
> news:joe_zitzelberger-E7D665.01090917092004@knology.usenetserver.com... 
>
>