+EGL, CSP et al may justify restoration of NUMPROC(MIG) was Re: COBOL 5 compile options
On 25 Sep 2014 10:45:43 -0700, in bit.listserv.ibm-main Tom Ross wrote: The one consideration that isn't mentioned is that if shops have files created or updated by CSP, Visual Gen or EGL (the latest incarnation and presumably still sold and supported by IBM), they have data in signed fields (both packed and unpacked) with F zones for positive numbers and D zones for negative numbers. I checked the EGL manual to verify this. While I suspect many here share my disdain for this and the contortions needed for it, it means that NUMPROC(PFD) probably is unwise for all shops with these products. If NUMPROC(MIG) would generate more efficient code than NUMPROC(NOPFD), then these shops would benefit from the return of NUMPROC(MIG). Clark MOrris In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more about signed data to signed data. If you get nonpreferred signs as input data then you need to run with NUMPROC(NOPFD) to make sure you get correct results. I gave a presentation at SHARE about one way to check if you can use NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance. The relevant parts are here: NUMPROC(NOPFD) - NUMPROC(PFD) is faster Performance considerations using NUMPROC: - On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 21% faster to equivalent. Investigate your signed data in External Decimal and Packed-decimal - How can you do that? It is not easy, but if you really want to: If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD 1 Create a sniffer program from existing programs to access all of the data 2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs 3 If 100% NUMERIC, change to NUMPROC(PFD)! * Compile sniffer with NUMPROC(PFD) EXEC SQL SELECT Ext-Dec Packed-Dec INTO :X, :Y END-EXEC If X NUMERIC and Y NUMERIC Then Display Use NUMPROC(PFD)! Move 2 To Return-Code Else Display Sorry, use NUMPROC(NOPFD)! Move 16 To Return-Code* Or call CEE3ABD Stop Run End-If 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
Re: COBOL 5 compile options
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock 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. ??? Perhaps you meant to write Too few ...? As they say, common sense is not so common. Indeed, in today's world common sense seems to be a (the?) prototypical oxymoron. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
Common sense is of course both 1) highly desirable and 2) in short supply. That stipulated, the notion that all programming skills are commonsensical is a dubious one; and it has made much mischief. A good programmer needs to know more and be abler than most people and, in my experience, most COBOL programmers, who are too often without formal analytic skills. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
I feel a little like a Zoroastrian intruding into a discussion among Thomist theologians about whether the archangels in moving from Samarra to Novara pass through the intervening space, but the whole notion of imposing decimal-picture constraints upon binary arithmetic strikes me as absurd. Welcome to absurd-COBOL! The language was designed without regard to hardware, only with regard to dollars and cents, integers and decimals in base 10 arithmetic. Mapping decinmal digits to binary data is and was difficult! How many decimal digits does a fullword hold? :-) Furthermore, the COBOL Standard requiresthat we support truncation to the decimal picture string, so if a user codes PIC 9 BINARY, we must produce a zero result for this math: COMPUTE PIC9BIN = 9 COMPUTE PIC9BIN = PIC9BIN + 1 Now that it is available TRUNC(OPT) has everything to recommend it. It is faster, more accurate, and yields results that are more perspicuous to any but a diseased imagination. If a user changes a compile option and gets different results, there will be unhappy clients somewhere. I learned early on that more accurate results means lookout and test a lot before trying! Any situation in which the twos-complement byte, halfword, and fullword hardware bounds -128 =3D y +127 (-2^7 =3D y =3D +2^7 - 1) (-2^15 - h =3D +2^15 - 1) -32768 =3D h =3D +32767 -2147483648 =3D f =3D +2147483647 (-2^31 =3D f =3D +2^31 - 1) are adjusted implicitly during and following arithmetic operations results in the generation of more (sometimes much more) and sillier code.(Explicit operations that use MAX, MIN, or both are available for performing such operations where, exceptionally, they are appropriate.) Here is where it gets complicated. We have 3 settings for TRUNC and I think bone of them will make you happy :-) TRUNC(STD) : Generate extra code to make sure results a truncated to PICTURE clause TRUNC(OPT) : Generate the minimum amount of code without regard to PICTURE clause TRUNC(BIN) : Generate extra code to use all bits of BINARY data even though binary r data does not map to decimal PICTURE clauses. COBOL V5 gets the same results as earlier compilers, and there is no such thing as a super efficient data type and compiler option combination that will fully exploit binary data on z/OS. For performance we recommend TRUNC(OPT), but in some cases data can be lost, so not all users can use TRUNC(OPT). Usually customer dicsussions are between TRUNC(OPT) and TRUNC(BIN), TRUNC(STD) is rarely used. 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
Re: COBOL 5 compile options
I feel a little like a Zoroastrian intruding into a discussion among Thomist theologians about whether the archangels in moving from Samarra to Novara pass through the intervening space, but the whole notion of imposing decimal-picture constraints upon binary arithmetic strikes me as absurd. Now that it is available TRUNC(OPT) has everything to recommend it. It is faster, more accurate, and yields results that are more perspicuous to any but a diseased imagination. Any situation in which the twos-complement byte, halfword, and fullword hardware bounds -128 = y +127 (-2^7 = y = +2^7 - 1) (-2^15 - h = +2^15 - 1) -32768 = h = +32767 -2147483648 = f = +2147483647 (-2^31 = f = +2^31 - 1) are adjusted implicitly during and following arithmetic operations results in the generation of more (sometimes much more) and sillier code.(Explicit operations that use MAX, MIN, or both are available for performing such operations where, exceptionally, they are appropriate.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
On 9/27/2014 5:58 AM, John Gilmore wrote: I feel a little like a Zoroastrian intruding into a discussion among Thomist theologians about whether the archangels in moving from Samarra to Novara pass through the intervening space, but the whole notion of imposing decimal-picture constraints upon binary arithmetic strikes me as absurd. Now that it is available TRUNC(OPT) has everything to recommend it. TRUNC(OPT) has been available since VS COBOL II R3 or R4, somewhere around 2000 or earlier. -Steve Comstock It is faster, more accurate, and yields results that are more perspicuous to any but a diseased imagination. Any situation in which the twos-complement byte, halfword, and fullword hardware bounds -128 = y +127 (-2^7 = y = +2^7 - 1) (-2^15 - h = +2^15 - 1) -32768 = h = +32767 -2147483648 = f = +2147483647 (-2^31 = f = +2^31 - 1) are adjusted implicitly during and following arithmetic operations results in the generation of more (sometimes much more) and sillier code.(Explicit operations that use MAX, MIN, or both are available for performing such operations where, exceptionally, they are appropriate.) John Gilmore, Ashland, MA 01721 - USA -- 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
Re: COBOL 5 compile options
As my culture hero Justice Holmes noted long ago, it is important to think things and not just words. I am aware that the keyword-argument value TRUNC (OPT) has been available for some time. The code generated by the new compiler when it is specified is, however, significantly different from and very much better than it has been, so much better that I think of it as an essentially new facility, one that makes straightforward C- or PL/I-like -binary-integer arithmetic available, for the first time, in COBOL. Those who have ignored or rejected it in the past should, I believe, rethink their decisions to do so. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
I thought it was earlier. What was the one with the 9672's and trunc(bin) hiccup? Think we missed un upgrade along the way. Lot's of FUD on workloads and direction. Guess Cheryl pointed out that the LSRP's contained no Indexed by Cobol pgms for the midrange 9672's In a message dated 9/27/2014 7:30:09 A.M. Central Daylight Time, st...@trainersfriend.com writes: TRUNC(OPT) has been available since VS COBOL II R3 or R4, somewhere around 2000 or earlier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
Re: COBOL 5 compile options
I've been pondering the TRUNC option since yesterday. Let me ask this question... 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. 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
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 S 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
Re: COBOL 5 compile options
Hey Steve, Your recommendation for defining binary data items and using TRUNC(OPT) does not make the following truncate with COBOL standard rules: 01 sixteen-pdpic 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 + +000123451 +3451 +000123451 +3451 +000123451 TRUNC(OPT) results +00 123451 -21 123451 +51 123451 + +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 S 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
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-pdpic 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 + +000123451 +3451 +000123451 +3451 +000123451 TRUNC(OPT) results +00 123451 -21 123451 +51 123451 + +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 S 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
Re: COBOL 5 compile options
-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-pdpic 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 + +000123451 +3451 +000123451 +3451 +000123451 TRUNC(OPT) results +00 123451 -21 123451 +51 123451 + +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 S 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
Re: COBOL 5 compile options
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-pdpic 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 + +000123451 +3451 +000123451 +3451 +000123451 TRUNC(OPT) results +00 123451 -21 123451 +51 123451 + +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 S 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
COBOL 5 compile options
AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floati= ng-point, so perhaps it doesn't even matter what option we choose. COBOLV 5 will use floating-point registers for fixed point math at higher ARCH levels. in some cases we convert DISPLAY numeric data item to DFP (Decimal Floating Poiint) rather than packed decimal to do the math. On the other hand, we think NOVOLATILE is mostly safe. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes di= splays of negative signed fields easier to read. I agree, DISPLAY output is for humans HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except = for a few COBOL calls assembler routines. Is there anything I should loo= k at in the latter case to make sure NOPRESERVE doesn't cause any issues? This one needs more research. For example, EXEC SQL calls DB2, which could thhen switch to AMODE 64 and change the regs. On the other hand, I did a service search and found a case where DB2 was fixed when it inadvertantly changed the upper halves of some regs. We know for sure that NOPRESERVE is safe, and PRESERVE should be safe, but we need more data! Other than NUMPROC, discussed in my previous post, I think these are the on= ly ones I'm concerned about. In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more about signed data to signed data. If you get nonpreferred signs as input data then you need to run with NUMPROC(NOPFD) to make sure you get correct results. I gave a presentation at SHARE about one way to check if you can use NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance. The relevant parts are here: NUMPROC(NOPFD) - NUMPROC(PFD) is faster Performance considerations using NUMPROC: - On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 21% faster to equivalent. Investigate your signed data in External Decimal and Packed-decimal - How can you do that? It is not easy, but if you really want to: If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD 1 Create a sniffer program from existing programs to access all of the data 2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs 3 If 100% NUMERIC, change to NUMPROC(PFD)! * Compile sniffer with NUMPROC(PFD) EXEC SQL SELECT Ext-Dec Packed-Dec INTO :X, :Y END-EXEC If X NUMERIC and Y NUMERIC Then Display Use NUMPROC(PFD)! Move 2 To Return-Code Else Display Sorry, use NUMPROC(NOPFD)! Move 16 To Return-Code* Or call CEE3ABD Stop Run End-If 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
Re: COBOL 5 compile options
Thanks Tom! For HGPR, don't you mean the reverse of what you said? PRESERVE would always be save because COBOL preserves and restores the high-halves of the registers, right? Safer, but not as efficient? As for NUMPROC, thanks for the info. Seems to me the documentation could be made clearer, though I don't know exactly all. In the end I can't imagine doing what you suggest, even though it's the only way to be sure. So we'll probably, unfortunately, just go with NOPFD. But thanks a lot for the info!! Question about one additional option. We use TRUNC(STD) right now. What would be have to be aware of if we wanted to switch to TRUNC(OPT) (where I assume OPT = optimize)? Is OPT fully compliant with COBOL standard truncation rules? Thanks! Frank FirstBank From: Tom Ross tmr...@stlvm20.vnet.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, September 25, 2014 11:32 AM Subject: COBOL 5 compile options AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floati= ng-point, so perhaps it doesn't even matter what option we choose. COBOLV 5 will use floating-point registers for fixed point math at higher ARCH levels. in some cases we convert DISPLAY numeric data item to DFP (Decimal Floating Poiint) rather than packed decimal to do the math. On the other hand, we think NOVOLATILE is mostly safe. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes di= splays of negative signed fields easier to read. I agree, DISPLAY output is for humans HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except = for a few COBOL calls assembler routines. Is there anything I should loo= k at in the latter case to make sure NOPRESERVE doesn't cause any issues? This one needs more research. For example, EXEC SQL calls DB2, which could thhen switch to AMODE 64 and change the regs. On the other hand, I did a service search and found a case where DB2 was fixed when it inadvertantly changed the upper halves of some regs. We know for sure that NOPRESERVE is safe, and PRESERVE should be safe, but we need more data! Other than NUMPROC, discussed in my previous post, I think these are the on= ly ones I'm concerned about. In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more about signed data to signed data. If you get nonpreferred signs as input data then you need to run with NUMPROC(NOPFD) to make sure you get correct results. I gave a presentation at SHARE about one way to check if you can use NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance. The relevant parts are here: NUMPROC(NOPFD) - NUMPROC(PFD) is faster Performance considerations using NUMPROC: - On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 21% faster to equivalent. Investigate your signed data in External Decimal and Packed-decimal - How can you do that? It is not easy, but if you really want to: If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD 1 Create a sniffer program from existing programs to access all of the data 2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs 3 If 100% NUMERIC, change to NUMPROC(PFD)! * Compile sniffer with NUMPROC(PFD) EXEC SQL SELECT Ext-Dec Packed-Dec INTO :X, :Y END-EXEC If X NUMERIC and Y NUMERIC Then Display Use NUMPROC(PFD)! Move 2 To Return-Code Else Display Sorry, use NUMPROC(NOPFD)! Move 16 To Return-Code* Or call CEE3ABD Stop Run End-If 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
Re: COBOL 5 compile options
DISPSIGN only affects fields in a DISPLAY statement. With your S999 DISPLAY example, let's say field (let.s name it ZONED-FIELD-1) was set to -987. DISPLAY QUOTE ZONED-FIELD-1 QUOTE Output with DISPSIGN(COMPAT): 98P Output with DISPSIGN(SEP): -987 The size of the field is unchanged (it's still signed zoned, 3 bytes). It's just that it's displayed as a 4 character text string. Now we just need DISPDEC(YES) to show the decimal position indicator (the period for a init integer field), e.g.: -987.65 instead of -98765 for a PIC S999V99 (any USAGE) field. Maybe next release! Frank From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, September 24, 2014 8:51 PM Subject: Re: COBOL 5 compile options On 24 Sep 2014 18:27:34 -0700, in bit.listserv.ibm-main you wrote: AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floating-point, so perhaps it doesn't even matter what option we choose. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes displays of negative signed fields easier to read. Since I think this would affect existing record descriptions, I would test before making a decision. If your current display numeric fields (PIC S999 USAGE DISPLAY) do not have the SIGN IS SEPARATE clause this option may force it on recompile which would increase the size of the field by 1 byte. I'm not certain what the valid sign characters would be. Clark Morris HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except for a few COBOL calls assembler routines. Is there anything I should look at in the latter case to make sure NOPRESERVE doesn't cause any issues? Other than NUMPROC, discussed in my previous post, I think these are the only ones I'm concerned about. Thanks, Frank -- 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
COBOL 5 compile options
AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floating-point, so perhaps it doesn't even matter what option we choose. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes displays of negative signed fields easier to read. HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except for a few COBOL calls assembler routines. Is there anything I should look at in the latter case to make sure NOPRESERVE doesn't cause any issues? Other than NUMPROC, discussed in my previous post, I think these are the only ones I'm concerned about. Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
On 24 Sep 2014 18:27:34 -0700, in bit.listserv.ibm-main you wrote: AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floating-point, so perhaps it doesn't even matter what option we choose. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes displays of negative signed fields easier to read. Since I think this would affect existing record descriptions, I would test before making a decision. If your current display numeric fields (PIC S999 USAGE DISPLAY) do not have the SIGN IS SEPARATE clause this option may force it on recompile which would increase the size of the field by 1 byte. I'm not certain what the valid sign characters would be. Clark Morris HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except for a few COBOL calls assembler routines. Is there anything I should look at in the latter case to make sure NOPRESERVE doesn't cause any issues? Other than NUMPROC, discussed in my previous post, I think these are the only ones I'm concerned about. Thanks, Frank -- 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
