> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Steve Comstock > Sent: Friday, September 26, 2014 2:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 5 compile options > > On 9/26/2014 2:25 PM, Frank Swarbrick wrote: > > Hey Steve, > > > > Your recommendation for defining binary data items and using > > TRUNC(OPT) does not make the following truncate with COBOL standard > > rules: > > I didn't say it did: only TRUNC(STD) is guaranteed to truncate with COBOL > standard rules. But the COBOL standard rules are not very useful, I think. > > Of course, in either case, you still have to know your data, and define your > fields appropriately. If I'm going to be moving 123451 to a binary field (or > if a > calculation could possibly result in such a value), I need to plan for my > target > to be a fullword, pic s9(9). > > Programmers still need to be cognizant of the limits of the fields they work > with. Too many programmers, in my opinion, understand the boundaries of > half word and full word (and double word) field values.
Don't you mean too FEW > > > As they say, common sense is not so common. > > -Steve > > > > > > 01 sixteen-pd pic 9(16) packed-decimal. > > > > 01 binaries usage binary. > > 05 bin-var-1 pic s99. > > 05 bin-var-2 pic 9(6). > > 05 bin-var-3 pic s9(4). > > 05 bin-var-4 pic s9(9). > > > > [...] > > move zeroes to bin-var-1 > > move 123451 to bin-var-2 > > sixteen-pd > > display bin-var-1 space bin-var-2 > > move bin-var-2 to bin-var-1 > > display bin-var-1 space bin-var-2 > > move sixteen-pd to bin-var-1 > > display bin-var-1 space bin-var-2 > > > > move zeroes to bin-var-3 > > move 123451 to bin-var-4 > > sixteen-pd > > display bin-var-3 space bin-var-4 > > move bin-var-4 to bin-var-3 > > display bin-var-3 space bin-var-4 > > move sixteen-pd to bin-var-3 > > display bin-var-3 space bin-var-4 > > exit. > > > > > > TRUNC(STD) results > > +00 123451 > > +51 123451 > > +51 123451 > > +0000 +000123451 > > +3451 +000123451 > > +3451 +000123451 > > > > TRUNC(OPT) results > > +00 123451 > > -21 123451 > > +51 123451 > > +0000 +000123451 > > -7621 +000123451 > > +3451 +000123451 > > > > > > > > > > > > > > ________________________________ > > From: Steve Comstock <st...@trainersfriend.com> > > To: IBM-MAIN@LISTSERV.UA.EDU > > Sent: Friday, September 26, 2014 12:06 PM > > Subject: Re: COBOL 5 compile options > > > > > > On 9/26/2014 11:31 AM, Frank Swarbrick wrote: > >> I've been pondering the TRUNC option since yesterday. Let me ask > >> thisquestion... Is the only time the TRUNC option come in to effect > >> when one binary field is moved to another, smaller, binary field? > >> Because it appears if a packed-decimal or zoned decimal field is > >> moved in to a smaller binary field the TRUNC(STD) logic is always > >> performed. Specifically, the sending field is moved to a temp > > field, > >> it is then truncated, and then converted to binary. At least in the > >> examples I've tried. > > > > TRUNC(STD) indicates to the compiler that results of MOVEs or > > calculations into BINARY fields should be truncated to the precision > > of the PICTURE (this conforms to ANSI standards) > > > > Consider: > > > > 05 FLDA PIC S99 COMP. > > > > if you code MOVE +125 TO FLDA the result should be '25' > > (x'0019') in FLDA - truncation to the number of 9's in the picture - > > with TRUNC(STD). > > > > With TRUNC(BIN) the result is '125' (x'007D') - the whole result is > > included as long as it fits into physical size (halfword in this case) > > of the target field. > > > > With TRUNC(OPT) the compiler will choose the instruction path that is > > fastest; might be a MVC, might be LH / STH, etc.; it > > depends. IBM has never documented the rules, claiming they are > > 'proprietary' or at least subject to change from release to release. > > > > Recommend: binary fields should be defined with the maximimum number > > of nines (such as PIC S9999 for halfword) and compile with TRUNC(OPT). > > > > -Steve Comstock > > > > > >> > >> If that's the case I think I'll just stay with TRUNC(STD) since > >> situations where TRUNC(OPT) would come in to play would be rare > >> enough anyway that there would be no noticeable gain, and too much to > >> lose. I can't think of many cases where someone would > > move a "large" binary field to a smaller one anyway. > >> > >> Personally, I think "picture defined" COMP/BINARY fields should be > >> eliminated in favor of the COBOL 2002 BINARY-SHORT (halfword), > >> BINARY-LONG (fullword) and BINARY-DOUBLE (doubleword) data types, > >> which make much more sense in the real world anyway. (of course > >> eliminating the legacy data types is never going to happen, because > >> its too ingrained.) > >> > >> Thanks, > >> Frank > >> > >> > >> > >> ________________________________ > >> From: Tom Ross <tmr...@stlvm20.vnet.ibm.com> > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Sent: Friday, September 26, 2014 10:51 AM > >> Subject: Re: COBOL 5 compile options > >> > >> > >>> Thanks Tom! > >>> For HGPR, don't you mean the reverse of what you said? PRESERVE > >>> would alwa= ys be save because COBOL preserves and restores the > >>> high-halves of the regi= sters, right? Safer, but not as efficient? > >> > >> Ooops, at least I was 100% wrong :-) Yes, PRESERVE is safer, > >> although NOPRESERVE might be safe for most as well. > >> > >>> As for NUMPROC, thanks for the info. Seems to me the documentation > >>> could b= e made clearer, though I don't know exactly all. In the > >>> end I can't imagin= e doing what you suggest, even though "it's the > >>> only way to be sure". So w= e'll probably, unfortunately, just go > >>> with NOPFD. But thanks a lot for the= info!! > >> > >> Yes, I was aware that my idea was kind of crazy, and eve asked at > >> SHARE if anyone > > could ever do such a thing. On the other hand, if you did not find > > out > >> if your data has preferred signed and chose PFD, you could get silent > >> death ;-) > >> > >>> Question about one additional option. We use TRUNC(STD) right now. > >>> What w= ould be have to be aware of if we wanted to switch to > >>> TRUNC(OPT) (where I a= ssume OPT =3D "optimize")? Is OPT fully > >>> compliant with COBOL standard trun= cation rules? > >> > >> TRUNC(OPT) does not result in any code generated to truncate. it is > >> NOT COBOL Standard conforming and neither is TRUNC(BIN). You could > >> get more accurate results with TRUNC(OPT) (along with much better > >> performance) but I know that for many customers 'more accurate' = > >> 'different' = BAD :-) > >> > >> Cheers, > >> TomR >> COBOL is the Language of the Future! << > >> > >> --------------------------------------------------------------------- > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> > >> --------------------------------------------------------------------- > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > > > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
