Yeah, as I mentioned in a previous email, having a binary data item restricted to "COBOL truncation rules" seems to me to not make a great deal of sense. Leave that to (packed) decimal.
It's certainly possible that we could convert to TRUNC(OPT) and have no problems at all, because no one is silly enough to use binary data in this manner. But do I want to risk it? Not really. Especially if it turns out I have done such a thing! :-( ________________________________ From: Steve Comstock <st...@trainersfriend.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, September 26, 2014 3:16 PM 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. 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
