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
>
>Enterprise COBOL has to ensure that a negative zero can never be a result of a
>statement. There is no action in Enterprise COBOL that can result in a
>negative zero (except see the list at the bottom).
>
>From the POP for any decimal instruction which can cause an overflow:
>
>"In the absence of overflow, the sign of a zero result is made positive. If
>overflow occurs, a zero result is given the sign of the second operand but
>with the preferred sign code."
>
>A decimal instruction can't, except for overflow, produce a negative zero.
>
>COBOL doesn't mind overflow. It is part of the language that a larger field
>going to a smaller field is simply truncated.
>
>Prior to COBOL II, with decimal instructions for packed-decimal fields, where
>unproblematic overflow occured which happened to create a negative zero, it
>didn't matter since a negative zero in a decimal instruction is just zero
>anyway.
>
>Now the actual generated code. Defining one field with 11 digits, two with
>nine and two with eight:
>
>1.
>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
>
>2.
>MOVE PICS9-11 TO PICS9-9
>F844 3028 3019 ZAP 40(5,3),25(5,3) PICS9-9 PICS9-11+1
>
>3.
>MOVE PICS9-9-2 TO PICS9-9
>D204 3028 3030 MVC 40(5,3),48(3) PICS9-9 PICS9-9-2
>
>4.
>MOVE PICS9-8-2 TO PICS9-8
>D204 3010 3020 MVC 16(5,3),32(3) PICS9-8 PICS9-8-2
>
>
>In 2, a longer field is the source, and ZAP is used, and if the trunction of
>the longer field happened to logically yield a negative zero, the ZAP would
>present the result as a positive zero. If an MVC had been used, offset by one
>byte, a ZAP-to-itself would have been needed to ensure the positive zero if
>that had resulted in a negative zero. So cut to the chase, and just ZAP.
>
>In 3, with two fields of the same size and an odd number of digits, an MVC is
>possible and a ZAP not needed because there can be no truncation resulting in
>a potential negative zero. There is a presumption that the source field is
>valid (not negative zero already).
>
>4 is similar to 3, just with an even number of digits. There is the same
>presumption as in 3, and a further presumption that the leading nybble can
>only be zero.
>
>Now number 1, the original code in the question:
>
>The MVC does nothing with packed-decimal signs, it is just copying a lump of
>data.
>
>The NI is indeed effecting truncation (nothing to do with compiler option
>TRUNC in Enterprise COBOL, although a compiler option of the same name, many
>years ago, was involved in that).
>
>Source is a nine-digit-in-five-bytes. The code shown will ensure that the
>8-digit-in-five-bytes receiving field will have a zero in the high-order
>nybble.
>
>What about the ZAP? It is due to the potential for a negative-zero in the data
>in the source field, which Enterprise COBOL must prevent from infecting the
>result. If the source field was -900000000, then the MVC followed by the NI
>would yield negative zero. So follow the MVC/NI with a ZAP.
>
>You can't just ZAP then NI, because the potential -900000000 would become the
>forbidden negative zero.
>
>The ZAP after a decimal add, subtract, multiply or divide is interesting. It
>is again there for the case of an overflow which has resulted in a negative
>zero but I can't think why it is not preceded by a branch on condition for the
>overflow value in the Condition Code.
>
>Other points raised in the discussion:
>
>Non-preferred signs going into ZAP (or any decimal instruction) will come out
>as preferred signs (C or D). Looking at other code generated with
>NUMPROC(NOPFD) may well show a number of ZAPs-to-itself to rectify the sign
>for comparisons, for instance.
>
>If the source has an invalid sign (0-9) a S0C7 will ensue.
>
>If the source has a non-preferred sign, a preferred sign, equivalent, of
>course, will be produced.
>
>If the source is a negative zero, a positive zero will be produced, allowing a
>CLC to be used, accurately, for comparisons for equality for packed-decimal
>fields.
>
>The code generated, in isolation at least, is not affected by compiler option
>OPT, because it is an Enterprise COBOL thing. If it were not done, you get the
>chance of a negative zero.
>
>There is absolutely no difference in the procedure code generated by OPT(STD)
>and OPT(FULL). The only "extra" in OPT(FULL) is the identification and removal
>from the object of unreferenced storage items. If there are unused fields in
>WORKING-STORAGE or LOCAL-STORAGE, the object will be smaller.
>
>With Enterprise COBOL V5, which has three levels of optimsation (0, 1 and 2,
>and yes, even 0 does some optimisations, clever, eh?) the FULL part of OPT up
>to V4 is replaced by a new option, STGOPT.
>
>Given all the above, what is the potential for any field containing a negative
>zero? Date external to the program (file, DB, LINKAGE SECTION, message,
>whatever), careless use of REDEFINES, careless use of group MOVEs. So
>something to be aware of.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
