On 1 May 2009 11:50:24 -0700, in bit.listserv.ibm-main you wrote: >We force Trunc(STD) for all programs in CICS. We have not had any >reported problems.
If TRUNC(STD) which means truncate all binary based on picture doesn't give you any problem, TRUNC(OPT) will work and give you better performance. > >Regards > >Otto Schumacher >Technical Support, CICS > >EDS, an HP Company >Ahold Account >2000 Wade Hampton Blvd. >LC1-302 >Greenville, South Carolina, 29615 > >Tel: 864 987-1417 >Fax: 864 987-4500 >E-mail: [email protected] > >We deliver on our commitments >so you can deliver on yours. > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Rick Arellanes >Sent: Friday, May 01, 2009 12:29 PM >To: [email protected] >Subject: Re: Enterprise COBOL code generation question > >On Fri, 1 May 2009 08:38:59 -0500, Chase, John <[email protected]> >wrote: > >>> -----Original Message----- >>> From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 >>> >>> > -----Original Message----- >>> > From: IBM Mainframe Discussion List On Behalf Of Clark Morris >>> <Snipped> >>> > On 30 Apr 2009 13:00:02 -0700, in bit.listserv.ibm-main you wrote: >>> > >>> > Try TRUNC(OPT). Trunc STD would require the conversion to decimal >>to >>> > guarantee that the data fit the picture. TRUNC(BIN) is known and >>> > documented to generate less than optimal code. >>> >>> Son of a gun, that did it. From half a page of code to six >>> instructions. >>> >>> I will have to test this program with TRUNC(OPT) pretty carefully to >>> make sure it has no other adverse affects. The doc on OPT is pretty >>> clear in its warnings. >>> >>> And the doc on TRUNC(BIN) does have the phrase "... you can avoid the >>> performance overhead of using TRUNC(BIN) ...", implying there is, in >>> fact, a performance penalty for using it. >>> >>> 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. :-( >> >> -jc- >> >It looks like we may have missed an update to the Customization Guide. >Please >see the Programming Guide, which was updated to say: > >Recommendations: TRUNC(BIN) is the recommended option for programs that >use binary values set by other products. Other products, such as IMS, >DB2, >C/C++, FORTRAN, and PL/I, might place values in COBOL binary data items >that do not conform to the PICTURE clause of the data items. You can use > >TRUNC(OPT) with CICS programs as long as your data conforms to the >PICTURE clause for your BINARY data items. > >You might want to read the Enterprise COBOL Version 3 Release 1 >Performance >Tuning Paper at: http://www.ibm.com/software/awdtools/cobol/library/ to >read more about this. It says: > >As long as your usage of all binary (COMP) data items in the application > >conforms to the PICTURE and USAGE specifications, you can use TRUNC(OPT) > >to improve transaction response time. This is recommended in performance > >sensitive CICS applications. If your usage of any binary data item does >not >conform to the PICTURE and USAGE specifications, you can either use a >COMP- >5 data type or increase the precision in the PICTURE clause instead of >using >the TRUNC(BIN) compiler option. Note that the CICS translator does not >generate code that will cause truncation and the CICS co-processor uses >COMP-5 data types which does not cause truncation. If you were using >NOTRUNC with your OS/VS COBOL programs without problems, TRUNC(OPT) on >IBM Enterprise COBOL behaves in a similar way. For additional >information on >the TRUNC option, please refer to the compiler options section of this >paper. > >Rick Arellanes (IBM COBOL Development and Performance) > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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
