Hi Greg,
The specific problem I was alluding to probably doesn't affect assembler, so please open a Case.
Packed decimal computations don't overflow in COBOL. On the hardware, there's a mask bit that determines whether overflows will trigger exceptions or not. In a pure COBOL application, this bit is not set (COBOL neither turns it on nor off), so if there's overflow, it's suppressed at the hardware level with no performance penalty. In a mixed application, languages like C++, Java, or PL/I (but not DB2) will turn the hardware overflow bit on, leading to worse performance if an overflow occurs in COBOL, as the hardware will generate an exception, which transfers control to LE. LE suppresses the exception (because COBOL programs don't have decimal overflow exceptions), but there's a performance penalty in going to LE and LE figuring out what to do in the exception handler.
This almost certainly isn't the case in assembler code, unless you specifically turned the overflow mask on, so we'd have to take a look to determine why performance might not be as good between 6.2 and an earlier release for your application.
------------------------------
Mike Chase
Enterprise COBOL Developer
mike.chase@ca.ibm.com------------------------------
Original Message:
Sent: Mon December 21, 2020 10:25 AM
From: Greg Shirey
Subject: COBOL V6.2 performance
Mike, we do not run any DB2 or Java, but might have a bit of assembler utilities called here and there. Thanks.
------------------------------
Greg Shirey
Original Message:
Sent: Fri December 18, 2020 01:59 PM
From: Mike Chase
Subject: COBOL V6.2 performance
Hi Greg, you're welcome! We'd definitely expect COBOL 6.2 to outperform previous releases on a z13, particularly when using ARCH(11), so this is curious and I'd suggest opening a Case. Is your application pure COBOL or are there other languages mixed in, and which ones?
------------------------------
Mike Chase
Enterprise COBOL Developer
mike.chase@ca.ibm.com
Original Message:
Sent: Fri December 18, 2020 01:39 PM
From: Greg Shirey
Subject: COBOL V6.2 performance
Mike, thanks for the response. We are running on a z13s, so we are compiling with ARCH(11), no NUMCHECK. I will check out the performance webinar and see what we might be able to utilize.
------------------------------
Greg Shirey
Original Message:
Sent: Wed December 09, 2020 10:20 AM
From: Mike Chase
Subject: COBOL V6.2 performance
Hi Greg,
Generally, both CPU and elapsed time should be faster when compiling with a newer version of the compiler. However, the compiler is limited in the ways in which it can improve performance; it does the best job at improving programs that spend most of their time in COBOL code, particularly those that do a lot of computation, and it can't do much to improve the performance of applications that spend a majority of their time in middleware calls or on I/O. Your choice of compiler options, particularly if your measurements were done with some of the new options to diagnose invalid data, like NUMCHECK and PARMCHECK, that didn't exist on earlier releases, can also make a difference.
Without knowing any details - what your program does and how it's structured, what options you're using, what OPT and ARCH level, what previous compiler release you're comparing against - it's hard to say anything more specific. I encourage you to join one of our COBOL Performance Tuning webinars (registration at https://ibm.biz/COBOLWorkshopRegistration ), or listen to a previously-recorded session (at https://ibm.box.com/v/COBOLPerformanceWebinars ). Please open a Case if you need us to take a look at your application.
Thanks,
------------------------------
Mike Chase
Enterprise COBOL Developer
Original Message:
Sent: Mon December 07, 2020 04:20 PM
From: Greg Shirey
Subject: COBOL V6.2 performance
IBM says that COBOL V6.2 will perform better than previous COBOL releases. Does that mean I should see reduced CPU or reduced elapsed time?
So far, we have not seen CPU improvements - that is, SMF records show the programs using about the same CPU, but they do appear to run faster. Does the new compiler produce more efficient code so that programs run faster or use less CPU? (Maybe it's both, but which would be more measurable?)
Thanks,
------------------------------
Greg Shirey
------------------------------