I meant if it is a case where ARITH(EXTEND) on a z14 has worse performance than ARITH(COMPAT) at ARCH(11), but that issue is fixed at ARCH(12). Such as, the instructions it uses for ARITH(EXTEND) at ARCH(11) cause the problem but the instructions it can utilize at ARCH(12) are not affected.
This is because we can't use ARCH(12). I mentioned this previously in some other thread, months ago. The problem is there's a way* that decimal overflows will get a S0CA even when "on size error" coded, /if/ you compile with ARCH(12). ARCH(11) in this case ignores the overflow, so it reaches the "on size error" logic to handle the error. I have a case with IBM. The answer is to get a newer machine. * the condition is... - Running in a reusable run-time environment that was established by CEEPIPI - The path from MVS to the application contains a LINK. One example of this is IMS/TM transactions - A program in the transaction contains a call to the z/OS Systems Services XML parser (or generate). It doesn't have to call it - The transaction ends - Possibly more transactions run in the same dependent message processing region - A transaction runs in the same region that has a decimal overflow. Once you know the necessary conditions it is easy to reproduce; you don't even need IMS. I have a test case that is a single job. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Tom Ross Sent: Friday, July 12, 2024 1:33 PM To: [email protected] Subject: Re: Packed Decimal -- Extended(?) >Are there disadvantages to ARITH(EXTEND)? Is the only reason to want interm= >ediate results to be compatible with older code is if you need to match pre= >vious less-accurate results? Is there a performance impact at ARCH(11) or l= >ower? -----Original > >Are there disadvantages to ARITH(EXTEND)? Is the only reason to want interm= >ediate results to be compatible with older code is if you need to match pre= >vious less-accurate results? Is there a performance impact at ARCH(11) or l= >ower? COBOL users normally want the exact same results with a new COBOL compiler after recompiling, or it is a failed migration. ARITH(EXTEND) can give different results than ARTIH(COMPAT) or older compilers. More accurate, but wrong as far as many clients are concerned. ARITH(EXTEND) can be a little bit slower than ARITH(COMPAT), but we have had no complaints from users about this. Now for something completely different (yeah I'm an old Monty Python fan) let's talk about ARCH! "Is there a performance impact at ATCH(11) or lower?" There is not enough info to answer, but I can guess. If you are talking about moving from COBOL V4 to COOBL V6, ARCH(11) would be much faster! If you are asking about moving from COBOL V6 with ARCH(12) to COBOL V6 with ARCH(11), then yes, there is an impact, the programs will be quite a bit slower. Higher ARCH levels give better performance so using lower levels would be a 'performance impact'! If I guessed wrong about what you were asking, please let me know! Cheers, TomR >> COBOL is the Language of the Future! << ---------------------------------------------------------------------- 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
