I should have included the definitions, not just described them. There are no decimal places, it is just two eight-digit integers, and two nine-digit integers:
01 PICS9-8 COMP-3 PIC S9(8). 01 PICS9-8-2 COMP-3 PIC S9(8). 01 PICS9-9 COMP-3 PIC S9(9). 01 PICS9-9-2 COMP-3 PIC S9(9). 01 PICS9-11 COMP-3 PIC S9(11). I think you are confusing sign-rectification with the purpose of the ZAP in that position, which is to ensure, after high-order truncation of the source-field, that any truncated value which is negative zero becomes a positive zero. A zero. However, taking the case of sign-rectification, your suggestion that only the byte with the sign need be ZAPped would be disastrous. Given an even distribution of low-order-digit values, 10% of negative values would become positive. An unsigned value in a signed field, like your example, is of course not numeric. Unless you use NUMPROC(NOPFD) and NUMCLS(NOPFD) (the latter being at installation/customisation). ZONEDATA(MIG) may do part of what you want for V5. I thought I saw something about the possibility of a new compiler option to do a similar thing for packed-decimals. If that were to exist as well, and you used NUMPROC(NOPFD) you'd at the very least be close to NUMPROC(MIG) for V5. I'm not at all sure what you mean by "he ZAPs required for NUMPROC(PFD) to work far outweigh any CPU saving gained by replacing some of the CP instructions with CLC". Perhaps you could clarify and provide some examples demonstrating the point. To my mind, all data should conform to PICture. Then you have a choice. You can used NUMPROC(PFD) or you can still go with some of the... discussion... about NUMPROC and use NOPFD. If your data does not conform to PICture, and you don't want to fix it, or you're afraid that at any moment your data may not conform to PICture an no-one will spot it in testing, then you must use NUMPROC(NOPFD). NUMPROC(MIG) was a fish-nor-fowl migration aid. I doubt anyone will be going from OS/VS COBOL to Enterprise COBOL V5. If the second new compiler option for packed-decimals following on from ZONEDATA(MIG) actually arrives (I could have dreamt it) then you will have decimal compares on all source fields and rectified signs on all target fields, which is I think what you want by using NUMPROC(MIG). Bear in mind that ZONEDATA(MIG) (and perhaps PACKEDSIGN(MIG), my invented option) are probably not intended to be any more permanent than NUMPROC(MIG), so don't be surprised if they up and disappear 30 years from now. On Sunday, 7 February 2016 19:51:36 UTC, Clark Morris wrote: > On 6 Feb 2016 17:30:16 -0800, in bit.listserv.ibm-main you wrote: > > >Posting this to replace a post I made, by accident only in the > >google-something part of the list. Some editing, and additional examples. > > > >MOVE PICS9-9 TO PICS9-8 > >D204 3010 3028 MVC 16(5,3),40(3) PICS9-8 PICS9-9 > >940F 3010 NI 16(3),X'0F' PICS9-8 > >F844 3010 3010 ZAP 16(5,3),16(5,3) PICS9-8 PICS9-8 > The ZAP could be ZAP 20(1,3),20(1,3) PICS9-8 +4 PICS9-8 +4 since > all that is needed is something to force the sign nibble. > > > >MOVE PICS9-11 TO PICS9-9 > >F844 3028 3019 ZAP 40(5,3),25(5,3) PICS9-9 PICS9-11+1 > > > >MOVE PICS9-9-2 TO PICS9-9 > >D204 3028 3030 MVC 40(5,3),48(3) PICS9-9 PICS9-9-2 > MVN 44(1,3),53(3) PICS9-9 +4 PICS9-9-2 +5 is > needed to move the sign nibble from a field with the implied decimal > S9(9)V99 to the integer field S9(9). > > > >MOVE PICS9-8-2 TO PICS9-8 > >D204 3010 3020 MVC 16(5,3),32(3) PICS9-8 PICS9-8-2 > MVN 20(1,3),37(3) PICS9-8 +4 PICS9-8-2 +5 is > needed to move the sign nibble from a field with the implied decimal > S9(9)V99 to the integer field S9(9). > > > > > >Firstly, it is an Enterprise COBOL thing. From the "Enterprise COBOL for > >z/OS, Version 3.4, Compiler and Runtime Migration Guide" (that's the first > >one that came up, I'd suspect it is repeated in other Migration Guide): > > > >"For example, Enterprise COBOL will not generate a negative zero result, > >while OS/VS COBOL could" > > > >It pre-dates Enterprise COBOL, and is introduced in VS COBOL II, due to > >NUMPROC. Prior to COBOL II, all references to packed-decimal data involved > >decimal instructions. With COBOL II, plain MVC and CLC area weapons of > >choice, where possible/meaningful, over ZAP and CLC. The decimal compare, > >CP, treats postive and negative zero as equal (treats them as zero). CLC > >does not (as it doesn't know they are packed-decimal). > > > >The "no negative zero" does not seem to be documented in anything to do with > >COBOL II that I can find, and from the standard documentation set for COBOL > >only appears in the Migration guides. > > As someone who first ran into the issue with a COBOL II program where > a field defined as S9(9) failed the numeric test when it contained the > value of 123456789F instead of 123456789C, this behaviour has been > around for over 20 years. Depending on the original source of the > field, it could have an F zone or sign if the original input field > didn't have a sign, a common case with punched card input or any input > where a sign wasn't supplied. It also could happen if the field were > processed by CSP version 4.1 and so far as I can tell from manuals for > its successors the same is still true. The reason for the gratuitous > F zone forcing by CSP 4.1 and successors escapes me and is just > another reason for my disdain (the COBOL code generated by the CSP > processor choked the Optimizer in COBOL II). NUMPROC(MIG) handled the > 2 issues - F zone and negative zero without exposing the shop to both > abysmal code and the acceptance of A, B, D, and E zones which would be > the case with NUMPROC(NOPFD). In my opinion, the ZAPs required for > NUMPROC(PFD) to work far outweigh any CPU saving gained by replacing > some of the CP instructions with CLC. Unfortunately, given all of the > existing code requiring C zones for all values 0 - plus infinity, the > field is stuck with code. I do not envy shops that have move off > NUMPROC(MIG) and if I were in one of them and going to SHARE, I would > be submitting a requirement to keep NUMPROC(MIG) hoping to get as many > shops as I could to give it a priority 5. So far as I am concerned > NUMPROC(MIG) is superior to NUMPROC(PFD). I know Tom Ross vehemently > disagrees. > > Clark Morris > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
