On 19 Apr 2015 22:10:22 -0700, in bit.listserv.ibm-main you wrote: >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.
If I understand the EGL site correctly, if you are intelligent and don't use PACF, the sign nibble is C or D. http://www-01.ibm.com/support/knowledgecenter/SSMQ79_9.1.1/com.ibm.egl.lr.doc/topics/regl_core_num_type.html seems to have an error in the second bullet in point 9 where it says "The repeated F characters may seem redundant to those unfamiliar with EBCDIC. Packed decimal data types (represented in EGL by DECIMAL, MONEY, and PACF) eliminate the redundancy. The packed decimal version of -150 is 150D. Positive 150 is 150, except in the PACF format, where it would be 150F." I think it should say Positive 150 is 150C except in the PACF format where it would be 150F. For those shops on CSP or Visual Gen, the issue is not the programs generated by those products but rather all of the other programs that use the data generated by those products. The programs that use CSP or Visual Gen generated numeric data are forced to use either NUMPROC(NOPFD) or NUMPROC(MIG) in order to obtain correct results. The ideal solution for those shops is to migrate to EGL changing all programs to use either DECIMAL or MONEY for packed fields and run a clean up set of programs for all files/databases updated by those programs. Until all of the CSP/Visual Gen programs at a site are eliminated by some type of migration, NUMPROC(MIG) is a valuable option for dealing with data created or updated by those programs. I suspect most application programming management will find this discussion arcane techy stuff and "just systems programmer headache". Clark Morris > >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
