*Where did you throw it? Or did you mean "throughout". Lulz..*
*"Threw out this whole thread I have not seen a "snippet" of the offending code. But there had been a lot of theoretical discussion."* *On Fri, Sep 16, 2016 at 9:26 PM, Steve <[email protected] <[email protected]>> wrote:* > > > > > > > > * Threw out this whole thread I have not seen a "snippet" of the offending > code. But there had been a lot of theoretical discussion. Steve * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * -----Original Message----- From: "Gibney, Dave" <[email protected] > <[email protected]>> Sent: Thursday, September 15, 2016 3:43pm To: > [email protected] <[email protected]> Subject: Re: Bypassing > s322 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] > <[email protected]>] > On Behalf Of Bill Woodger > Sent: Thursday, > September 15, 2016 10:00 AM > To: [email protected] > <[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] <[email protected]> with the message: > INFO IBM-MAIN > ---------------------------------------------------------------------- For > IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] <[email protected]> with the message: INFO > IBM-MAIN > ---------------------------------------------------------------------- For > IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] <[email protected]> with the message: INFO > IBM-MAIN * > *-- * *Wayne V. Bickerdike* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
