On 10 Apr 2015 17:21:10 -0700, in bit.listserv.ibm-main you wrote: >Whilst pondering our migration to Enterprise COBOL 5.2 I've come upon the >situation that our current compiler option for NUMPROC, the MIG option, is no >longer available. Now we have to decide if we wish to use the more compatible >option NOPFD or the better performing but possibly less compatible option PFD >(preferred!).
If your organization has any program that affects files such that an F sign nibble can be in a signed numeric field (CSP, Visual Gen and subsequent iterations come to mind), you are stuck with NUMPROC(NOPFD). I strongly recommend that NUMPROC(MIG) be reinstated because not allowing a F sign nibble serves little useful purpose other than allowing use of CLC rather than CP for equal compares. For many reasons including IBM provided code generators such as the CSP family, NUMPROC(MIG) is much better for many shops than NUMPROC(PFD). I found this true a number of years ago. NUMPROC(MIG) will treat a signed field with a F sign as numeric where NUMPROC(PFD) won't. Elimination of NUMPROC(MIG) in 5.2 would be a show stopper for me. Clark Morris > >The (5.2) manual has the following to say: >NOPFD >Repairs signs on input. After repair is performed, the signs meet the criteria >for NUMPROC=PFD. > >PFD >Optimizes the generated code, especially when a non-zero OPTIMIZE level is >specified. No explicit sign repair is performed. Note that NUMPROC=PFD has >stringent criteria to produce correct results. To use NUMPROC=PFD: > * The sign position of unsigned numeric items must be X'F'. > * The sign position of signed numeric items must be either X'C' if > positive or zero, or must be X'D' if negative. > * The sign position of separately signed numeric items must be either '+' > if positive or zero, or '-' if otherwise. >Elementary MOVE and arithmetic statements in Enterprise COBOL always generate >results with these preferred signs; however, group MOVEs and redefinitions >might produce nonconforming results. The numeric class test can be used for >verification. With NUMPROC=PFD, a numeric item fails the numeric class test if >the signs do not meet the preferred sign criteria. >Performance consideration: Using NUMPROC=PFD generates significantly more >efficient code for numeric comparisons. For most references to COMP-3 and >DISPLAY numeric data items, using NUMPROC=NOPFD generates extra code because >of sign "fix-up" processing. This extra code might also inhibit some other >types of optimizations. Before setting this option, consult with your >application programmers to determine the effect on the application program's >output. > >The COBOL 4.2 manual says this about MIG: > >Use NUMPROC(MIG) to aid in migrating OS/VS COBOL programs to Enterprise COBOL. >When NUMPROC(MIG) is in effect, the following processing occurs: > * Preferred signs are created only on the output of MOVE statements and > arithmetic operations. > * No explicit sign repair is done on input. > * Some implicit sign repair might occur during conversion. > * Numeric comparisons are performed by a decimal comparison, not a logical > comparison. > >Several questions: > >- What is "on input" as described under NOPFD? >- Which allowed behavior of COBOL 5.2 is closer to MIG: NOPFD or PFD? > >In order to answer the last question I've written the following program and >tested it with each of the 3 options supported by COBOL 4.2: > > identification division. > > program-id. numproc2. > data division. > working-storage section. > 01 groups usage packed-decimal. > 05 grp-1. > 10 signed pic s9(3). > 05 grp-2. > 10 unsigned pic 9(3). > 01 display-fields usage display. > 05 disp-signed pic 9(3)+. > 05 pic x value spaces. > 05 disp-unsigned pic 9(3)+. > > procedure division. > move -123 to signed > move grp-1 to grp-2 > display signed space unsigned > move signed to disp-signed > move unsigned to disp-unsigned > display display-fields > if signed = unsigned > display 'equal' > else > display 'not equal' > end-if > if signed < unsigned > display 'signed lt unsigned' > else > display 'signed nlt unsigned' > end-if > if unsigned is numeric > display 'numeric' > else > display 'not numeric' > end-if > display signed space unsigned > move signed to disp-signed > move unsigned to disp-unsigned > display display-fields > goback. > > end program numproc2. > > >NUMPROC(MIG)12L 12L >123- 123+ >equal >signed nlt unsigned >not numeric >12L 12L >123- 123+ > > >NUMPROC(NOPFD)12L 12L >123- 123+ >not equal >signed lt unsigned >not numeric >12L 12L >123- 123+ > > >NUMPROC(PFD) >12L 12L >123- 123+ >equal >signed nlt unsigned >not numeric >12L 12L >123- 123+ > >The first thing to realize is that while the NOPFD behavior in a way "seems >more correct", is it really? Essentially this is invalid COBOL program, so I >imagine the COBOL standard doesn't say how it should work. But one simply >should not treat a signed field as an unsigned field, or vice versa, and >expect any particular behavior from it. My great (and perhaps greatly naive) >hope is that we do not have any programs that do anything remotely like this >example. > > >This seems to me to show that PFD behavior is the same (in this case) as MIG, >while NOPFD does sign repair so that the sign is "massaged" so match the COBOL >PICTURE string. See the generated psuedo-assembler for each option: > > >MIG >000022 IF > > 0004CA GN=33 EQU * > > 0004CA 5820 912C L 2,300(0,9) BLW=0 > > 0004CE F911 2000 2002 CP 0(2,2),2(2,2) SIGNED > UNSIGNED > 0004D4 58B0 C008 L 11,8(0,12) PBL=1 > > 0004D8 4770 B116 BC 7,278(0,11) GN=5(0004F2) > > >PFD >000022 IF > > 0004CA GN=33 EQU * > > 0004CA 5820 912C L 2,300(0,9) BLW=0 > > 0004CE F911 2000 2002 CP 0(2,2),2(2,2) SIGNED > UNSIGNED > 0004D4 58B0 C008 L 11,8(0,12) PBL=1 > > 0004D8 4770 B116 BC 7,278(0,11) GN=5(0004F2) > > >NOPFD >000022 IF > > 0004CA GN=33 EQU * > > 0004CA 5820 912C L 2,300(0,9) BLW=0 > > 0004CE D201 D100 2002 MVC 256(2,13),2(2) TS2=0 > UNSIGNED > 0004D4 960F D101 OI 257(13),X'0F' TS2=1 > > 0004D8 F911 2000 D100 CP 0(2,2),256(2,13) SIGNED > TS2=0 > 0004DE 58B0 C008 L 11,8(0,12) PBL=1 > > 0004E2 4770 B120 BC 7,288(0,11) GN=5(0004FC) > > >NOPFD has two extra instructions. One to move the field to a temporary field, >and another to force the sign to 'F' (unsigned). The compare (CP) is then >done against this "repaired" field. > >The NUMERIC check generates the same code for all three options, and in all >cases this check returns false (which is correct because of the sign not >matching the picture). > >Anyway, my takeaway from this is that MIG is at least closer to PFD than it is >to NOPFD, so it might be safe to go directly to PFD. But without knowing >where MIG differs from PFD I don't know what else to look for. > >Any thoughts? > > >Thanks, >Frank Swarbrick >Applications Development Architect >Mainframe Applications Development >FirstBank - Lakewood, CO USA > >---------------------------------------------------------------------- >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
