COBOL Compiler options

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" <wmklein@xxxxxxxxxxxxx> wrote in message
news:<005501c874ac$c8164a00$0200a8c0@WMK>...
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" <jchase@xxxxxxxxx> wrote in message

news:<F255EFE0ECF08C4A9C1DB6AFF4235417062E2DAD@xxxxxxxxxxxxxxxxxxxxxxxxxx>..
.
-----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" <Darren.Gavin@xxxxxxxxxxx> wrote in
message
news:<4356B0B2B2F65D469947983B18967D87A757AF@xxxxxxxxxxxxxxxxx
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 listserv@xxxxxxxxxxx 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.

Relevant Pages

  • Re: COBOL Compiler options
    ... Well I do have DLL programs using the Linkage parm I mentioned before ... So as long as the CICS Loadlib is a PDSE, I think a DLL module should ... (By the way, this is not just coprocessor, it is separate ... we do not document this DLL problem nor have compiler options ...
    (bit.listserv.ibm-main)
  • Re: Exposing bool to non-MS, non-C++ callers
    ... the functions in this DLL accept a structure as an argument. ... The compiler doesn't help catch places where I neglect ... the C++ bool type is defined as one byte. ... depends on whether the Exe caller will push a value larger than 1 byte. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Memory allocation methods
    ... all modules are compiled against the same CRT' DLL with the same compiler. ... that case you restrict yourself to a simple C-based API for the DLL. ... I prefer to use either exceptions (but writing exception-safe code is quite ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Export class from dll
    ... Remember that C++ classes describe not only the general characteristics of ... Only when the DLL ... about the compiler not knowing the details of a CBox, ... How does the compiler know what CBox is? ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: COBOL Compiler for Windows
    ... Until a year ago I had an old IBM compiler (VA Cobol V2.2) that runs ... on an old laptop under Windows NT plus DB2 V7.2, ... The package is aimed at any platform that runs CICS, ... So the V2.2 compiler I have performs two functions, ...
    (comp.lang.cobol)
Loading