Re: COBOL's NUMPROC compiler option
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 sipp...@sg.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU 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: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
In 8918505894176310.wa.m42tomibmmainyahoo@listserv.ua.edu, on 04/20/2015 at 03:11 PM, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu said: It is easy for us to fault the designers of System/360 and OS/360 for not considering the future requirement for more than 16 MB. Especially if you were familiar with other vendors, who were ahead of IBM is several ways. I was certainly appalled by the S/360 limitations, except that I failed to identify the limited number of channels as a choke point. In 1964, that seemed like plenty of addressable memory. Not to me. Storage capacities of more than the commonly available 32,000 words would be required. Other vendors were using addresses larger than 15 bits. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
In 7935647633061500.wa.paulgboulderaim@listserv.ua.edu, on 04/20/2015 at 09:39 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: I'm a skeptic about Postel's Principle. Google for MBZ. Your point on F zones is well taken, but given the card heritage IBM may effectively not had a choice there. I'll even go so far as to say that if the original s/360 had raised an addressing excption when bits 0-7 of a base or index register were nonzero, transition from 24-bit to 32-bit addressing would have been much facilitated. Big time. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
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 sipp...@sg.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU 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: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On Mon, 20 Apr 2015 11:46:57 -0500, Paul Gilmartin wrote: Had bit 0 not been pervasively exploited as a flag, 32-bit addressing could have been accomplished easily. If there had been no reason to run old code in AMODE 24, 32-bit addressing could have been accomplished easily. That was the hope when the System/360 Model 67 was designed. It proved to be difficult to eliminate all use of AMODE 24. It is easy for us to fault the designers of System/360 and OS/360 for not considering the future requirement for more than 16 MB. In 1964, that seemed like plenty of addressable memory. In their 1964 document, Architecture of IBM System/360, Amdahl, Blaauw and Brooks wrote that the design had to provide a dependable base for a decade of customer planning and customer programming and that Storage capacities of more than the commonly available 32,000 words would be required. The System/360 was IBM's first family of computers, spanning a wide range of capabilities. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On Mon, 20 Apr 2015 13:09:14 +0800, Timothy Sipples 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. I'm a skeptic about Postel's Principle. Rather, I believe that hardware or software as appropriate should enforce preferred values for otherwise uncommited fields in instructions, data, and control blocks lest overly inventive programmers exploit them to smuggle a few bits of data through whatever interface. I'll even go so far as to say that if the original s/360 had raised an addressing excption when bits 0-7 of a base or index register were nonzero, transition from 24-bit to 32-bit addressing would have been much facilitated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
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
Re: COBOL's NUMPROC compiler option
On Mon, 20 Apr 2015 11:24:51 -0400, John Gilmore wrote: The transition was from 24- to 31-bit addressing. Apart from this quibble, Paul is right here. Unused fields should be initialized innocuously and, usually, marked as reserved. (From time to time there is of course a case for making user fields available in control blocks.) My use of 32- rather tnan 31- was quite deliberate. Had bit 0 not been pervasively exploited as a flag, 32-bit addressing could have been accomplished easily. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
The transition was from 24- to 31-bit addressing. Apart from this quibble, Paul is right here. Unused fields should be initialized innocuously and, usually, marked as reserved. (From time to time there is of course a case for making user fields available in control blocks.) --John Gilmore, Ashland, MA 01721, USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
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: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On 18 Apr 2015 16:24:30 -0700, in bit.listserv.ibm-main you wrote: Mr. Ross, Is there going to be a corresponding PACKCHECK compiler option? It is=20 We have no plans for one, but we are very open to suggestions. I have wondered for years how a customer could actually migrate from NUMPROC(NOPFD) to NUMPROC(PFD), and something like that would help. Please submit an RFE (Request for Enhancement) at https://www.ibm.com/developerworks/rfe/?PROD_ID=698 very difficult to locate all of the assembler code that took liberty in=20 fixing positive pack decimal fields with a sign of F instead of=20 determining if the result field was signed or not. After all everybody=20 would use a hardware internal decimal instruction (AP, CP, DP, MP, SP,=20 and ZAP etc.) to access/process a pack decimal field! Who would have=20 ever guessed that one of the future compilers would be smart enough to=20 make a determination/assumption that you could just use a compare=20 logical character instruction (CLC) to determine equality between two=20 pack decimal fields? Or even that we might avoid packed-decimal instructions completely for processing packed-decimal data! (we use DFP instructions when more efficient) Or, should we just take the performance hit and use NUMPROC(NOPFD) for=20 the life of COBOL? NMost cusotmers use NUMPROC(NOPFD) and it is not much of a hit for most. Maybe we could petition for the reinstatement of NUMPROC(MIG) You could ask, and we would most likely say no. NUMPROC(MIG) was supposed to be a temporary solution for customers migrating from OS/VS COBOL to VS COBOL II in the 1980s... Given that IBM CSP and its descendants (IBM VisualAge generator) generate F signs for positive fields this means that all sites afflicted with these products are having the most efficient way of handling the packed and display numeric fields given the contortions of these products. I guess we are all wondering just how much anguish=20 NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial=20 to some of us and less overhead than NUMPROC(NOPFD). If I remember=20 correctly NUMPROC(MIG) only fixed signs on input and NUMPROC(NOPFD)=20 does additional sign fixing. I suspect that most sites have not done that much research into the 3 options and don't realize the effects of each. I fell into finding out by accident when I tried NUMPROC(PFD) back in the 1990's and promptly got a NOT NUMERIC on a packed field that had an F sign. Since this was production data it instantly became apparent that NUMPROC(PFD) was a non-started in that environment. The shop also had and used CSP 4.2 (compiles of the generated COBOL code had to be done NOOPTIMIZE because of the prolific GO TO statements among other problems). We have had only a handful of complaints, and several customers were embarrassed to discover that they were using NUMPROC(MIG) and only really thought about it when migrating to COBOL V5. They say they are going to go through the effort to migrate to NUMPROC(NOPFD). Most application management doesn't understand the technical tradeoffs and wouldn't understand why they would be taking a performance hit going to NUMPROC(NOPFD) from NUMPROC(MIG). Clark Morris Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL's NUMPROC compiler option
Mr. Ross, Is there going to be a corresponding PACKCHECK compiler option? It is=20 We have no plans for one, but we are very open to suggestions. I have wondered for years how a customer could actually migrate from NUMPROC(NOPFD) to NUMPROC(PFD), and something like that would help. Please submit an RFE (Request for Enhancement) at https://www.ibm.com/developerworks/rfe/?PROD_ID=698 very difficult to locate all of the assembler code that took liberty in=20 fixing positive pack decimal fields with a sign of F instead of=20 determining if the result field was signed or not. After all everybody=20 would use a hardware internal decimal instruction (AP, CP, DP, MP, SP,=20 and ZAP etc.) to access/process a pack decimal field! Who would have=20 ever guessed that one of the future compilers would be smart enough to=20 make a determination/assumption that you could just use a compare=20 logical character instruction (CLC) to determine equality between two=20 pack decimal fields? Or even that we might avoid packed-decimal instructions completely for processing packed-decimal data! (we use DFP instructions when more efficient) Or, should we just take the performance hit and use NUMPROC(NOPFD) for=20 the life of COBOL? NMost cusotmers use NUMPROC(NOPFD) and it is not much of a hit for most. Maybe we could petition for the reinstatement of NUMPROC(MIG) You could ask, and we would most likely say no. NUMPROC(MIG) was supposed to be a temporary solution for customers migrating from OS/VS COBOL to VS COBOL II in the 1980s... I guess we are all wondering just how much anguish=20 NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial=20 to some of us and less overhead than NUMPROC(NOPFD). If I remember=20 correctly NUMPROC(MIG) only fixed signs on input and NUMPROC(NOPFD)=20 does additional sign fixing. We have had only a handful of complaints, and several customers were embarrassed to discover that they were using NUMPROC(MIG) and only really thought about it when migrating to COBOL V5. They say they are going to go through the effort to migrate to NUMPROC(NOPFD). Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
Clark Morris wrote: I read the APAR and Tom Ross's SHARE presentation and have the following question. I must have missed that SHARE presentation, but will search again later for this. For now, for what version of COBOL is this applicable? For installations that have CSP or its descendants, NUMPROC(MIG) is a useful performance enhancement because it gives better performance than NUMPROC(NOPFD). CSP and the last descendant I checked (VISUAL GEN I think) for some reason lost in time insist on forcing F zones for positive numbers in signed fields. While I would agree with any derisive comments made about this and the expensive and convoluted coding required for this, the fact remains that this is a problem for users of the IBM CSP family. It could be a problem, but IBM COBOL manual said, you must *only* use NUMPROC(PFD) if all your data agrees exactly with IBM system standards as listed in NUMPROC chapter in Enterprise COBOL for z/OS Programming Guide. Any (good, bad, ugly) comments about this part (from Enterprise COBOL for z/OS Programming Guide) ? ... However, using REDEFINES and group moves could change data so that it no longer conforms [to system standards]. What will the performance impact be if your data format is changed? What about NUMCLS option? Does that SHARE presentation also mention this? (I'm still searching for it at this moment...) Just curious, if you don't mind please. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL's NUMPROC compiler option
Mr. Ross, Is there going to be a corresponding PACKCHECK compiler option? It is very difficult to locate all of the assembler code that took liberty in fixing positive pack decimal fields with a sign of F instead of determining if the result field was signed or not. After all everybody would use a hardware internal decimal instruction (AP, CP, DP, MP, SP, and ZAP etc.) to access/process a pack decimal field! Who would have ever guessed that one of the future compilers would be smart enough to make a determination/assumption that you could just use a compare logical character instruction (CLC) to determine equality between two pack decimal fields? Or, should we just take the performance hit and use NUMPROC(NOPFD) for the life of COBOL? Maybe we could petition for the reinstatement of NUMPROC(MIG). I guess we are all wondering just how much anguish NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial to some of us and less overhead than NUMPROC(NOPFD). If I remember correctly NUMPROC(MIG) only fixed signs on input and NUMPROC(NOPFD) does additional sign fixing. Thank you for your time -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On 13 Apr 2015 14:52:00 -0700, in bit.listserv.ibm-main you wrote: I read the APAR and Tom Ross's SHARE presentation and have the following question. 05 FIELD-CSP PIC S999 PACKED-DECIMAL. If FIELD-CSP contains x'123f', for NUMPROC(PFD),ZD(MIG) will FIELD-CSP be NUMERIC in an IF NUMERIC test? So far as I can tell CSP and its descendants will generate this data for signed packed decimal fields. ZONEDATA only affects Zoned Decimal items, not Packed-decimal, thus the attempt at making the compiler option name specific. In any case, NUMPROC(PFD) says that 'F' will not be used as a sign for signed fields, in zoned decimal (Numeric DISPLAY) and in packed-decimal, so your example would be NOT NUMERIC. For installations that have CSP or its descendants, NUMPROC(MIG) is a useful performance enhancement because it gives better performance than NUMPROC(NOPFD). CSP and the last descendant I checked (VISUAL GEN I think) for some reason lost in time insist on forcing F zones for positive numbers in signed fields. While I would agree with any derisive comments made about this and the expensive and convoluted coding required for this, the fact remains that this is a problem for users of the IBM CSP family. Clark Morris Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL's NUMPROC compiler option
- What is on input as described under NOPFD? That is on input to a statement, before a statement starts operating on the data. - Which allowed behavior of COBOL 5.2 is closer to MIG: NOPFD or PFD? It depends on what behavior you mean, but for preferred sign correction you need NNUMPROC(NOPFD). If you have all preferred signs already, you can use NUMPROC(PFD). We do not test invalid COBOL as in your example, so the behavior for us is rather unknown. We are coming out with a new option to help customers find if they have invalid zoned decimal (numeric DISPLAY) data, and that is a new compiler option called ZONECHECK. It is similar to SSRANGE in that it tells the compiler to generate code to validate the data for every reference to numeric DISPLAY data items that are input to a statement. The method used is the NUMERIC Class Test. This option could be used to determine if your zoned decimal data items are using valid signs on input. Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
I read the APAR and Tom Ross's SHARE presentation and have the following question. 05 FIELD-CSP PIC S999 PACKED-DECIMAL. If FIELD-CSP contains x'123f', for NUMPROC(PFD),ZD(MIG) will FIELD-CSP be NUMERIC in an IF NUMERIC test? So far as I can tell CSP and its descendants will generate this data for signed packed decimal fields. ZONEDATA only affects Zoned Decimal items, not Packed-decimal, thus the attempt at making the compiler option name specific. In any case, NUMPROC(PFD) says that 'F' will not be used as a sign for signed fields, in zoned decimal (Numeric DISPLAY) and in packed-decimal, so your example would be NOT NUMERIC. Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
Take a look at ZONEDATA(MIG) to see if it's relevant. ZONEDATA(MIG), introduced this past January (2015), addresses at least some of the use cases involving NUMPROC(MIG). Refer to APAR PI31403. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com Mobile/SMS: +65 8526 7454 or +372 5322 0545 Telephone: +1 213 222 6397 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On 11 Apr 2015 04:30:06 -0700, in bit.listserv.ibm-main you wrote: Take a look at ZONEDATA(MIG) to see if it's relevant. ZONEDATA(MIG), introduced this past January (2015), addresses at least some of the use cases involving NUMPROC(MIG). Refer to APAR PI31403. I read the APAR and Tom Ropss's SHARE presentation and have the following question. 05 FIELD-CSP PIC S999 PACKED-DECIMAL. If FIELD-CSP contains x'123f', for NUMPROC(PFD),ZD(MIG) will FIELD-CSP be NUMERIC in an IF NUMERIC test? So far as I can tell CSP and its descendants will generate this data for signed packed decimal fields. Clark Morris Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com Mobile/SMS: +65 8526 7454 or +372 5322 0545 Telephone: +1 213 222 6397 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL's NUMPROC compiler option
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!). 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 groupsusage packed-decimal. 05 grp-1. 10 signedpic s9(3). 05 grp-2. 10 unsigned pic 9(3). 01 display-fieldsusage display. 05 disp-signed pic 9(3)+. 05pic 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
