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




*-- *

*Wayne V. Bickerdike*

----------------------------------------------------------------------
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