Turns out that there is actually a restriction (currently undocumented).
The following is what I got back from my "usually reliable source".  Note
however, that this is a case (as I suspected) that using EITHER the
preprocessor or the coprocessor will fail:

"Bill,

Looks like uncharted territory...we certainly cannot support compiling a
CICS program 
with the DLL option, just like we can't with DYNAM, for the same reason: it
changes the
calls to CICS. (By the way, this is not just coprocessor, it is separate
translator as well) 

However, we do not document this DLL problem nor have compiler options
conflicts.

However, you CAN call a DLL from a CICS program, using the example in the
COBOL PG Chapter 26: Example: calling DLLs from non-DLLs

Will look into what we should do about this...I have a feeling the user is
actually trying to use
DYNAM with coprocessor. DYNAM is also not supported in CICS separate or
coprocessor, 
we just can't catch it in the separate translator case, while we do diagnose
it in integrated
coprocessor case."

(FYI, that last statement about "not catching" is probably the case for DLL
as well.  You can get a "clean compile" with 
  NOCICS,DLL
if you compile a preprocessed source code. However, run-time results are
unsupported - because it  will try and make the CALLs to "FD...." DLL rather
than "standard" calls.

"Bill Klein" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> John,
>   I can't find anything at that page that restricts the use of DLL's with
> the integrated translator.  
> 
> FYI, 
>   *both* the COBOL "CICS" and "DLL" compiler options require the NODYNAM
> compiler option, so that can't be it.
> 
> Can you point me to the text on that page (or anywhere) that restricts the
> use of DLL's with the integrated translator (for cases where it is valid
if
> you pre-translate the code)?
> 
> Sorry to be "obtuse" - but I just don't see this restriction in either the
> CICS or COBOL documentation.
> 
> "Chase, John" <[EMAIL PROTECTED]> wrote in message
>
news:<[EMAIL PROTECTED]>..
> .
> > > -----Original Message-----
> > > From: IBM Mainframe Discussion List On Behalf Of Bill Klein
> > > 
> > > Darren,
> > >   That WOULD sound like a good SHARE requirement if it were 
> > > true, however I see no indication at:
> > > 
> > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 
> > > 
> > > to support this claim.  (Nor could I find it elsewhere in the 
> > > current Enterprise COBOL documentation).  Can you point me to 
> > > something supporting this view?  I went back thru some of the 
> > > older bookshelves and couldn't find this restriction ever being true.
> > > 
> > > "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in 
> > > message 
> > > news:<[EMAIL PROTECTED]
> > > te.or.us>...
> > > > The integrated translator does not support DLL mode 
> > > compiles at all as 
> > > > it completely overrides that option.  It forces certain compile 
> > > > options to be set that can interfere with using some of Cobol's 
> > > > advanced features.  It still has a ways to go.
> > > > 
> > > > Darren
> > 
> > Perhaps this will clarify (from the CICS TS 3.2 CICS Application
> > Programming Guide):
> > 
> >
>
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/2.1.1.1
> > 
> > Note that the COBOL option NODYNAM "must be in effect" for use of the
> > Integrated Translator.  Perhaps that's one of the "overrides" that is
> > repugnant to "DLL mode compiles"?
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to