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

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul D'Angelo
Sent: Wednesday, February 20, 2008 10:54 AM
To: [email protected]
Subject: Re: Fw: COBOL Compiler options

If you are running the CICS Itegrated translator You should be fine. I
ran 
it in a
previous installation and had no problems.
Your Application developers may not like it since it generates different

source code 
that a CICS program compiled with the Translator.
It was my application staff that couldnt adjust to the Intergrated 
translator.




Bill Klein <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List <[email protected]>
02/20/2008 01:47 PM
Please respond to
IBM Mainframe Discussion List <[email protected]>


To
[email protected]
cc

Subject
Fw: COBOL Compiler options






Using the coprocessor is NOT exactly the same as running the
preprocessor
and then the compiler.  As far as I know, there have been NO reports of
"different run-time" results from the two, but there are things that
using
the coprocessor can do that the preprocessor can't (see the Programming
Guide for details) e.g. 
  http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG40/3.1.2.2


I would, however, check you LISTINGS to make certain that all the
"Options
in Effect" are the same with the two methods.  It is possible that one
of
your compiler procs has different settings and this COULD impact
run-time
results.

<[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>
...
> In our shop, for CICS COBOL programs, we run the preprocessor
> DFHECP1$, then
> the compile step IGYCRCTL.
> I thought of bypassing the DFHECP1$ step by running the IGYCRCTL with
> 'CICS' in
> the parm.
> 
> That was fine.
> 
> Except, a co-worker pointed out to me that the generated object code
> differs,
> and, as such, is apprehensive.
> 
> Does anyone know why that is?
> 
> 
> Thanks

----------------------------------------------------------------------
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



*************************** IMPORTANT
NOTE***************************** The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
************************************************************************

----------------------------------------------------------------------
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