Ah. Well. Preferred signs. The thing is, preferred signs are not a problem as output from a "decimal instruction", because no matter what goes in (as long the sign is A-F, else Bang!) then only C or D can come out. No enforcing is necessary, it is just the way it happens.
Calculations in COBOL only generate C or D, and if the required result is to be unsigned, code is generated by the compiler to "clobber" the sign to an F. COBOL cannot generate a non-preferred sign (A, B, E) and there is no compiler-generated code to modify any potential production of same (if someone wants to get picky about F, then they can just pretend that I qualify correctly everywhere a correct qualification would apply). There has to be compiler-generated code to allow for the initial generation, by "multiply", or by truncation, of a "negative zero". So they are different there. You *can still get* negative zeros in a COBOL program. There is no check on "source" to prevent a negative zero being involved (specifically as a negative zero). Thus, an incoming record or other incoming data, especially from an "external" source, but even from a non-COBOL source, could contain a negative zero and things could go badly. Another way is by screwing up with REDEFINES or group-MOVEs or LINKAGE SECTION definitions. Which takes us to non-preferred signs, where basically the culprits are the same, but also adding COBOL generation where the same "data" is defined in different ways (signed and unsigned) in different places. But yes, "character compares" (faster) over "decimal compares" does require that actual equivalence exists where logical equivalence exists, if your data doesn't "conform to PICture" (if it can contain "non-preferred" signs, and yes, for a signed field, that includes an F). So character compares require conformance to PICture, and that is what you promise with compiler option NUMPROC with sub-option PFD. For NOPFD, the compiler has to either generate code to clobber (rectify) the signs in a temporary-stoage copy of the data, for comparisons, or to use the decimal instructions. Then there was NUMPROC(MIG). An old "migration" setting, to have COBOL II for data with non-preferred signs behave more like OS/VS COBOL. However, since MIG was "faster" than NOPFD, and less hated than PFD (contentious), MIG survived a long time, until it disappeared with V5. Its disappearance caused angst. However, there is "good" news. The code generated by NOPFD has been improved (PTF) and NOPFD is now much more comparable to what MIG was, and closer in performance to PFD. So if you have sloppy data, by accident or design, there is less of a performance hit. There is not (as far as I'm aware) less of a "data hit". By this I mean the capability of NOPFD to take "bad data" and make it look good, which is extended over what is possible with PFD. NOPFD does use CLCs at times. PFD does use CP at times. I am writing of up to V4.2, heaps of things have changed for V5+ and anything could be different. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
