The Cobol of 1981 is not the Cobol of today. Absolute statements regarding behavior 35 years ago are almost unprovable. Except maybe some Herculean effort :)
> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Bill Woodger > Sent: Thursday, September 15, 2016 10:00 AM > To: [email protected] > Subject: Re: Bypassing s322 > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
