On 24 Sep 2014 17:31:59 -0700, in bit.listserv.ibm-main you wrote: >On 24 Sep 2014 17:05:51 -0700, in bit.listserv.ibm-main you wrote: > >>As we're going to install IBM Enterprise COBOL 5.1 soon I'm looking to decide >>what default compile options we should use, and if we should perhaps change >>some. Plus we have to decide what the defaults for the new compile options >>should be. We'll just discuss NUMPROC here so-as to not make the post TOO >>long. >> >> >>NUMPROC: To PFD or to not PFD >>Currently we use NUMPROC=MIG, which is no longer even an available option. >> >>Looks like PFD generates more efficient code because it does not do 'numeric >>fixup'. >> >>Do we only need to be concerned with the numeric class test, but not with >>moves and arithmetic? My testing shows the following: >> >>with NUMPROC=PFD >>- unsigned data in signed field: fails NUMERIC test >>- signed data in unsigned field: fails NUMERIC test >> >>with NUMPROC=NOPFD and NUMCLS=PRIM >>- unsigned data in signed field: fails NUMERIC test >>- signed data in unsigned field: passes NUMERIC test >> >This looks like a serious bug which will affect all customers who >still have CSP (Cross System Product) since CSP and probably its >successors VisualGen, VisualAge Gen and Rational Business Developer >forced an 'F' zone for positive numbers in signed fields. I ran into >this in 1995 or 1996 while a contract programmer. Also signed data in >an unsigned field always should be considered NOT NUMERIC. Getting >rid of NUMPROC(MIG) was dumb if Rational Business Developer still >forces 'F' zones for positive numbers.
As a further follow-up, I read the manual for EGL and here also NUM fields have F zones for positive numbers and D zones for negative where NUMC fields have C zones for positive numbers and D zones for negative numbers. If your installation has EGL which generates JAVA, definitely research will be needed before going to COBOL V5.1. Clark Morris > >Clark Morris > >> >>So in either case numeric fails if there is unsigned data (last nibble = f) >>in a field position we've defined as being signed. Since this is already >>"wrong", if we're doing it (and I don't know that we are!), no harm going to >>PFD in this case. >> >>But it appears that we could, with NOPFD, pass a numeric test if the data is >>signed (either positive or negative) but the field is defined as unsigned. >>And this would no longer pass with PFD. So the question is, do we do this? >>Well, I don't know. And I can't imagine looking through maybe tens of >>thousands of numeric tests (or may not that many...) to make sure the data >>matches the definition. >> >>Should we risk it? Has anyone out there ever "migrated" to PFD with "legacy" >>data files? I'm quite certain that we do have at least some cases where one >>program wrote out data defined as signed and other programs read it with the >>same area defined as unsigned. Curse it, but I know I've seen it. I think >>the less likely, but not impossible, situation would be testing it for >>numeric. Mostly we only test for numeric if: >>- We sometimes intentionally store non-numeric (usually low-values; maybe >>spaces sometimes) data in a numeric field in some situations >>- We're getting data from an external source and want to validate it (though >>I imagine we do this far less than we perhaps should!). >> >>Thanks, >>Frank >> >>---------------------------------------------------------------------- >>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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
