On 16 Oct 2015 01:04:34 -0700, in bit.listserv.ibm-main you wrote: >You've made this exact point before about two years ago with Tom Ross >(among others) in the loop.
Visual Age Gen had continued the practice for PAC field of forcing the F zone on positive numbers. From the EGL 7.1 manual: 9.If you are new to mainframe computing, you might not recognize two common types of numeric variables in COBOL: zoned decimal and packed decimal. If you work with these types, your EGL data types must match the format and sign configuration of the data these types contain. Here is a quick overview: EBCDIC represents ordinary positive numbers 0-9 with hex characters F0-F9 (for example, 150 translates to F1F5F0). COBOL also supports ''zoned'' data types that allow signs (in EGL these are NUM and NUMC). The rightmost hex digit carries the sign for the whole number, with a D replacing the F for a negative number. Thus F1F5D0 translates to -150. In the case of NUMC, a C replaces the F for a positive number, rendering positive 150 as F1F5C0. 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. This last statement from the 7.5.1 manual page confuses the h out of me because I would assume positive 150 would be 150C. 7.5.1 was the latest version I could find access to with possible later manuals requiring a login. Also the NUM data type would store positive numbers that would be considered NOT NUMERIC for PICTURE S9(n) fields in COBOL under NUMPROC(PFD). The NUMC data type seems to valid to EGL only in the Visual Age Gen compatibility mode. The COBOL Version 5.2 Programmers Guide states on page 660 that NUMPROC(NOPFD) is less efficient than NUMPROC(PFD). It also states elsewhere that A, B and E zones are also valid sign zones for NUMPROC(NOPFD). In many shops including the ones I worked in, the only valid sign zones are C, D, and F. I suspect most shops do not test data coming from other program for being numeric, especially if it is packed. I happened to be trying to optimize a program in the shop where I worked that did such a test for reasons I not certain that I ever knew. Thus CSP / VAG / EGL idiosyncrasies may never affect them unless a CLC is generated for a compare equal instead of a CP. If most character signed numeric data these days is being entered in sign is separate fields or in a manner that requires special manipulation anyway then for any files not affected by EGL, NUMPROC(PFD) should not be a problem. In an unrelated issue I ran across when researching this, given that 64 bit fixed binary registers have been available for a number of years are the statements on page 653 in the V5.2 COBOL Programmers Guide about the number of digits in a binary number that cause the compiler to convert it to decimal still true? Clark Morris > >To repeat, we have a different compiler now with different technology. You >simply cannot assume that a hypothetical NUMPROC(MIG) in the new compiler >would offer better performance. It did in the past on a different compiler, >but that doesn't matter. This isn't your father's or grandfather's >compiler. THIS IS A DIFFERENT COMPILER TECHNOLOGY with different (better) >performance behaviors. On this compiler a hypothetical NUMPROC(MIG) could >well be worse! I trust the compiler designers' judgment on this performance >question especially since they seem to have reviewed this issue. > >As a reminder, there are no compatibility issues here. CSP, VisualAge >Generator, and EGL programs all work great with the new Enterprise COBOL >5.x compilers. (Another reminder: Upgrade from CSP and VisualAge Generator >to current EGL, please. EGL is IBM supported.) I think we would have heard >a lot of screaming if that weren't true since we're now years into the >Version 5.x series of new COBOL compilers. > >If you have performance benchmarking data that support your assertion that >CSP, VisualAge Generator, and EGL customers must "put up with bad >performance" after migrating to Enterprise COBOL 5.2, please show it. I'm >sure the compiler team would be grateful to receive your data and will >seriously evaluate it. There are no politics here, no hidden agenda, >honestly. Minds are open. But so far as I am aware, IBM would assert the >opposite. If you don't have such performance data, or if your performance >data show something different than what you asserted, it would also be most >welcome to hear that, too. > >It is EXTREMELY common that IBM removes particular former >performance-related parameters as technology and time marches on when those >parameters no longer yield performance benefits, or worse. This is a good >thing! Start with assuming they got this decision right and that they know >a great deal more than either one of us about the performance >characteristics of the new compiler, but go ahead and run some benchmarks >(if you haven't already) and report back. "Trust but verify," as a former >U.S. president famously said. Otherwise this is kind of like complaining >about a vendor who removes a hypothetical ARMSEEK(MIG) performance-related >parameter related to disk arm movement when you're now accessing flash >storage. > >-------------------------------------------------------------------------------------------------------- >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
