If I were in the position to decide which option to use, I would clearly vote for MIG.
NOPFD does unnecessary fix-ups in certains cases, which causes some performance penalties, and I personally don't like the use of CLC for the comparison of decimal values, even if the lengths are the same, for the well-known reasons (the sign representation has to be identical on both sides). I would spend this little CPU overhead for CP over CLC for correctness reasons. I don't see a valid reason for providing two options NOPFD and MIG, because IMHO the outcome of the coding below is the same for NOPFD and MIG ... with some performance problems for NOPFD (I guess, even in the case fixup + CLC vs. CP, NOPFD will take more CPU than MIG). Kind regards Bernd Am 21.04.2015 um 19:47 schrieb Frank Swarbrick:
Very good question. Related... Has it been detailed just exactly what the differences between NUMPROC(MIG) and NUMPROC(NOPFD) are? And an even better question, what (if any) differences are there in the end results? >From what I've observed by looking at the pseudo-assembler output. Hopefully I've "observed correctly"! Compare signed to signed (same length) - MIG: CP - NOPFD: CP - PFD: CLC Compare unsigned to unsigned (same length) - MIG: CP - NOPFD: fix-up both, then CLC - PFD: CLC Compare signed to signed (differing lengths) - MIG: CP - NOPFD: CP - PFD: CP Compare unsigned to unsigned (differing lengths) - MIG: CP - NOPFD: fix-up both, then CP (*) - PFD: CP Compare signed to unsigned (any length) - MIG: CP - NOPFD: fix-up unsigned, then CP (*) - PFD: CP (*) Seems to me no fix-up is necessary since CP is being used anyway. Maybe I'm missing some understanding? Frank ----- Original Message ----- From: Timothy Sipples <[email protected]> To: [email protected] Cc: Sent: Tuesday, April 21, 2015 4:13 AM Subject: Re: COBOL's NUMPROC compiler option OK, but what are we talking about here, in performance terms? NUMPROC(MIG) versus NUMPROC(NOPFD) offered some performance benefit in the past, but Enterprise COBOL 5.x offers a performance benefit, too. Basically, is this 2 steps forward 1 step back, or is it 1 step forward 2 steps back? The overall performance outcome is what matters, surely. I assumed that a hypothetical NUMPROC(MIG) would continue to offer some sort of performance benefit with Enterprise COBOL 5.x, but that's not actually a given. The 5.x compiler has a different design, and what was beneficial in the past may be less beneficial now -- or not beneficial at all. Let's just note that assumption for now. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- 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
