Clark Morris wrote: >Given that IBM CSP and its descendants (IBM VisualAge generator) >generate F signs for positive fields....
My understanding is that the currently supported descendants, i.e. EGL, don't behave this way. Let me see if I can re-thread the use case needle here, Clark, and please correct me if I'm wrong in any of these details. You're pointing out that, if a CSP or VisualAge Generator program needs to be recompiled, with Enterprise COBOL Version 5.1 and above the compiler option NUMPROC(NOPFD) is required since NUMPROC(MIG) is no longer available. NUMPROC(MIG) offered a performance advantage versus NUMPROC(NOPFD) with Enterprise COBOL 4.x and older compilers. You're requesting that the compiler development team consider implementing NUMPROC(MIG) in Enterprise COBOL 5.x. Failing that, technical alternatives include: 1. Using NUMPROC(NOPFD); 2. Using Enterprise COBOL 4.2 only for these cases (when recompiling CSP and/or VisualAge Generator code); 3. Upgrading to IBM EGL. To ask a couple "hard" questions here: A. What would be, in your estimation, the net performance outcome using NUMPROC(NOPFD) with Enterprise COBOL 5.2 versus NUMPROC(MIG) with Enterprise COBOL 4.2, keeping in mind that Version 5.2 should already perform better than Version 4.2, other things being equal? Do you have any measurements suggesting otherwise that you could offer? Then, carrying that estimate forward, what percentage of workload would CSP/VisualAge Generator represent during the peak utilization interval? My informal observation is that there are indeed many shops still running CSP and/or VisualAge Generator code that they haven't yet recompiled using the supported EGL tool chain. (Many recompile when the opportunity arises, when normal code maintenance takes them there.) However, I haven't run into any shop yet where CSP and/or VisualAge Generator programs represent a "significant" fraction of peak utilization workload, most likely because keeping current with EGL already offered performance improvements, even before Enterprise COBOL 5.x. B. Relatedly, how often are customers recompiling CSP and/or VisualAge Generator programs nowadays, and what's your view of the trend? C. This is a rather odd case where there's a pair of compilers, roughly speaking: CSP and/or VisualAge Generator (that generate COBOL source code from the 4GL source), then the COBOL compiler. Thus far IBM has maintained backward compatibility so that customers can upgrade these compilers on different release schedules, and that's still true: there's a functionally correct option in Enterprise COBOL 5.2 technically compatible with unsupported CSP and VisualAge Generator. But did IBM have to do even this? Isn't it "reasonable" that if a customer is going to maintain one unsupported compiler (or code pre-processor, more precisely) in their environment, at some point in the future they might also have to maintain a corresponding older, second compiler as part of the "chain" if they adopt that particular approach to keeping CSP and/or VisualAge Generator? I'm sensitive to the fact the compiler teams undoubtedly have a long list of feature enhancement requests. Support for 64-bit data objects would get my vote, as an example. Given that reality, I'm trying to draw out just how important NUMPROC(MIG) would be. I'm not convinced it's that important yet given what seem to be the facts, but I keep an open mind. -------------------------------------------------------------------------------------------------------- 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
