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
