On 18 Apr 2015 16:24:30 -0700, in bit.listserv.ibm-main you wrote: >>Mr. Ross, >> >>Is there going to be a corresponding PACKCHECK compiler option? It is=20 > >We have no plans for one, but we are very open to suggestions. I have >wondered for years how a customer could actually migrate from NUMPROC(NOPFD) >to NUMPROC(PFD), and something like that would help. Please submit an >RFE (Request for Enhancement) at >https://www.ibm.com/developerworks/rfe/?PROD_ID=698 > >>very difficult to locate all of the assembler code that took liberty in=20 >>fixing positive pack decimal fields with a sign of "F" instead of=20 >>determining if the result field was signed or not. After all everybody=20 >>would use a hardware internal decimal instruction (AP, CP, DP, MP, SP,=20 >>and ZAP etc.) to access/process a pack decimal field! Who would have=20 >>ever guessed that one of the future compilers would be smart enough to=20 >>make a determination/assumption that you could just use a compare=20 >>logical character instruction (CLC) to determine equality between two=20 >>pack decimal fields? > >Or even that we might avoid packed-decimal instructions completely for >processing packed-decimal data! (we use DFP instructions when more efficient) > >>Or, should we just take the performance hit and use NUMPROC(NOPFD) for=20 >>the life of COBOL? > >NMost cusotmers use NUMPROC(NOPFD) and it is not much of a hit for most. > >>Maybe we could petition for the reinstatement of NUMPROC(MIG) > >You could ask, and we would most likely say no. NUMPROC(MIG) was >supposed to be a temporary solution for customers migrating from >OS/VS COBOL to VS COBOL II in the 1980s...
Given that IBM CSP and its descendants (IBM VisualAge generator) generate F signs for positive fields this means that all sites afflicted with these products are having the most efficient way of handling the packed and display numeric fields given the contortions of these products. > >>I guess we are all wondering just how much anguish=20 >>NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial=20 >>to some of us and less overhead than NUMPROC(NOPFD). If I remember=20 >>correctly NUMPROC(MIG) only fixed signs "on input" and NUMPROC(NOPFD)=20 >>does additional sign fixing. I suspect that most sites have not done that much research into the 3 options and don't realize the effects of each. I fell into finding out by accident when I tried NUMPROC(PFD) back in the 1990's and promptly got a NOT NUMERIC on a packed field that had an F sign. Since this was production data it instantly became apparent that NUMPROC(PFD) was a non-started in that environment. The shop also had and used CSP 4.2 (compiles of the generated COBOL code had to be done NOOPTIMIZE because of the prolific GO TO statements among other problems). > >We have had only a handful of complaints, and several customers were >embarrassed to discover that they were using NUMPROC(MIG) and only >really thought about it when migrating to COBOL V5. They say they are >going to go through the effort to migrate to NUMPROC(NOPFD). Most application management doesn't understand the technical tradeoffs and wouldn't understand why they would be taking a performance hit going to NUMPROC(NOPFD) from NUMPROC(MIG). Clark Morris > >Cheers, >TomR >> COBOL is the Language of the Future! << > >---------------------------------------------------------------------- >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
