>I've been pondering the TRUNC option since yesterday. Let me ask this ques= >tion... Is the only time the TRUNC option come in to effect when one binar= >y 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 fie= >ld the TRUNC(STD) logic is always performed. Specifically, the sending fie= >ld is moved to a temp field, it is then truncated, and then converted to bi= >nary. At least in the examples I've tried.
It affects MOVEs and math, like my example of what happens when I add 1 to 9 in a PIC 9 data item. TRUNC(STD) gets zero, TRUNC(BIN gets 10, and I would >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 the= >re would be no noticeable gain, and too much to lose. I can't think of man= >y cases where someone would move a "large" binary field to a smaller one an= >yway. TRUNC(OPT) would speed up any math with BINARY data items tremendously, with the risk of more accuracy in your math, IE: different results. I think the code for assignments (MOVEs) would not be affected too much. >Personally, I think "picture defined" COMP/BINARY fields should be eliminat= >ed in favor of the COBOL 2002 BINARY-SHORT (halfword), BINARY-LONG (fullwor= >d) and BINARY-DOUBLE (doubleword) data types, which make much more sense in= > the real world anyway. (of course eliminating the legacy data types is ne= >ver going to happen, because its too ingrained.) We agree, it is on our (GIANT) TODO list for COBOL future items. 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
