A couple of ideas ... if you can use ARCH(13) and Cobol v6.3 then it may handle the overflow bits differently. As for doc on what ON SIZE ERROR should do, it does specify " If the ON SIZE ERROR phrase is specified and a size error condition occurs, the value of the resultant identifier affected by the size error is not altered; that is, the error results are not placed in the receiving identifier." ... possibly what you see violates that specification (in the Cobol v6 manual) by altering the resultant identifier.
On Fri, Feb 23, 2024 at 3:05 AM Schmitt, Michael <[email protected]> wrote: > I'm in discussion with IBM on a issue with the COBOL 6 compiler at ARCH > level 12. I think it is generating incorrect code, Development says "but > generating correct code would make it less faster!". I want to see what you > think. > > The issue is related to overflows, such as a packed-decimal overflow. > COBOL /ignores/ overflows, unless you code ON SIZE ERROR, which catches > them. By "ignores" I mean it just lets the field overflow. > > But at the machine level, a doing an AP instruction that causes an > overflow (or any other instruction) will case a program check, depending on > the setting of the decimal-overflow mask in the PSW. Therefore Language > Environments sets the bit off to ignore overflows. > > BUT, C semantics are that it needs to actually raise an exception or > something when there is an overflow. When a COBOL program calls a C > program, LE sets the overflow bit on so now overflows actually get a > program check (which may be caught by an ESPIE). Upon return from C, LE > doesn't set the bit back to off. Instead, LE catches the overflows and > ignores them. > > Note that this isn't just an application COBOL program calling an > application C program. It also include use of services written in C. For > example, the mere inclusion of XML PARSE or XML GENERATE in a COBOL program > will drive LE to initialize the C interface, setting the overflow mask on. > > That's how it is supposed to work. > > But, sometimes after LE changes the bit to on, LE loses its conditional > handlers. The result is that a COBOL program *will* get a program check for > an overflow. How can this happen, you ask? One way involves reusable > run-time systems established by CEEPIPI. (I have an Idea open about this > issue.) > > The work around for that problem is that if you code ON SIZE ERROR, COBOL > will catch the overflow. I say this means "catch the overflow WITHOUT A > PROGRAM CHECK", Development says "show us the doco that says it must catch > it!". > > Anyway, at arch levels 11 lower, a COBOL program will not get a program > check when there is an overflow in a statement that has ON SIZE ERROR. The > *way* it prevents this is it generates code that performs the operation > using fields that are large enough that no overflow can occur, then it > tests to see if it overflowed into the larger field. For example, if you > are adding a 1 digit field to a 3 digit field, then the COBOL compiler does > the add using a 4 digit field, and then checks if the high digit is not 0. > If it is, then it goes into the ON SIZE ERROR logic. So, no program check, > because at a machine level there was no overflow. > > The difference with arch level 12 is that the IBM Enterprise COBOL for > z/OS v6 compiler will exploit the vector decimal instructions. These > instructions have PSW bits that control whether they will fire a > program-check for overflows. > > And that's where we hit the issue. If we're in the situation where COBOL > is using C (such as, XML PARSE or GENERATE), so LE has changed the PSW to > no longer ignore the overflows, and LE has lost its condition handler, and > the COBOL code has an overflow, and ON SIZE ERROR was coded, you still get > a program check. For example, a S0CA in a VAP or VPS instruction. But > unlike arch 11 and below, there's no work-around. > > Development doesn't want to add the "use larger fields" logic to the > generated vector instructions, like they do for the non-vector generated > code, because if they did, the generated vector code wouldn't be as fast as > the code that is generated that allows the program check with ON SIZE ERROR. > > I say, "but COBOL semantics require code in ON SIZE ERROR to not > overflow". They say I need to prove that. > > There solution is to a) don't use arch(12), or b) make your fields larger > so they don't overflow, or c) add logic around every possible overflow that > calls an assembler program to save and restore the overflow mask bits. > > What do you think? Am I crazy to think that the compiler should generate > the vector decimal instructions to not do a program check when ON SIZE > ERROR is coded? > > ---------------------------------------------------------------------- > 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
