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" <gib...@wsu.edu>
Sent: Thursday, September 15, 2016 3:43pm
To: IBM-MAIN@LISTSERV.UA.EDU
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:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 10:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to