Original problem was reported in 2006: COBOL programs getting a S0CA in IMS, even though COBOL semantics are that the overflow should just overflow. The work-around was to catch with ON SIZE ERROR.
It took 15 years and many system dumps and GTF traces before it was explained. (And, IBM couldn't figure it out -- I did.) Status of that issue was to create an Idea to fix the root cause in LE: "Enhance CEEPIPI to reestablish lost condition handling environment" https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-2212 Idea is currently "Under consideration". New problem is that with COBOL 6.2 and ARCH(12), the work-around no longer works around, reported October 2023. They said they're not going to change anything for ARCH(12), it will be fixed at ARCH(13) for the z16. I think this means that the z16 will have instruction changes that allow the vector instructions to catch the overflow without a S0CA. The instruction-overflow mask (IOM)? Since they said it was eventually going to fixed, I didn't submit an Idea for a compiler change. If anyone is curious and would like to see the S0CA for themselves, shoot me an email and I'll send my STAND ALONE JOB (no other members) that reproduces it. There's actually two ways to get it: in a VPSOP and in a VAP. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Steve Thompson Sent: Friday, July 12, 2024 3:34 PM To: [email protected] Subject: Re: Packed Decimal -- Extended(?) I seem to remember this problem you speak of from a few years ago, and that still wasn't fixed except with a large $$$ check and a push pull to apply that PTF? (-: Steve Thompson On 7/12/2024 3:20 PM, Schmitt, Michael wrote: > 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 ---------------------------------------------------------------------- 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
