> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Phil Sidler
>
> On Fri, 1 May 2009 08:38:59 -0500, Chase, John wrote:
>
> >> Thanks for pointing out the benefit of TRUNC(OPT) to me.
> >
> >But then there's this in the "Notes" for TRUNC in the Installation &
> >Customization Guide:
> >
> >" 2. TRUNC=BIN is the recommended option when interfacing with other
> >products that have S/390-format binary data (such as CICS, DB2,
FORTRAN,
> >and PL/I). This is especially true if there is a possibility of
having
> >more than 9 digits in a fullword or more than 4 digits in a
halfword."
> >
> >So, we're stuck with TRUNC(BIN) in CICS, where arguably we'd want the
> >"best" performance. :-(
>
> I think that if you use the CICS integrated translator then TRUNC()
becomes
> mostly irrelevant in the CICS environment. The integrated translator
will
> use COMP-5 internally. Why IBM didn't choose to use COMP-5 fields
during
> translation before this for COBOL3 I never understood.
We also use Rational Developer for System z (RDz) in conjunction with
the CICS Service Flow Feature to generate "driver" or "wrapper" programs
for Service Flows. Those generated programs contain working storage
fields defined with PIC S9(8) COMP and S9(4) COMP which are untouched by
the CICS translator, integrated or standalone, leaving us "stuck with"
using TRUNC(BIN). I suppose we could manually edit the "obvious"
halfword and fullword fields in the generated source to COMP-5, but "why
should we have to do that?"
-jc-
----------------------------------------------------------------------
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
