>Thinking a bit more, even though there may be parts, bits and pieces of C/C++ >code to do with the COBOL program (and supporting routines) anything in the >COBOL program is of course "COBOL" and any "COBOL routines" I'd imagine would >also be treated as "COBOL" by LE.
This matches my current understanding, strengthened from reading the links you provided yesterday. LE treats the case right in that it resumes the Cobol code from the ESPIE routine. The Cobol code would not know the 000A exception has happened, it will find out if an overflow occurred by testing the condition code, it this is needed for the Cobol statement being executed. The drawback of running Cobol code with the decimal overflow mask bit on is shown by Tom Ross ins his 2014 Share presentation "Coding in COBOL for optimum performance". The code can use significantly more CPU time due to the 000A handling in the ESPIE routine, which would not be triggered when the mask is off. But the code runs no different from a logical perspective. >So I think it reasonable to postulate that the problem only arises with >user-written C/C++ code, and that the "first" C/C++ user-written code gets the >mask set, as described. With LE TRAP(ON) the issue just may not be apparent. Almost, at least as long a not other "low level helper package" (Smart/Restart) also installs error handling code. This code receives the 000A as well, and thinks the applpication failed. It does a roll-back, which causes certain things to be "closed" (data sets under its control, DB2 cursors, etc.). This is the real problem which then is seen as a weird S0C1 or S0C4 later when the Cobol code tries to work with closed "items" it does assume to be "open". I'll have to did deeper into Smart/Restart and what it does and does not do. I'm convinced the longterm, stable solution lies there. >Perhaps an initial deliberate CALL to a C/C++ program which uses CEE3SPM to >turn off that in the mask? LE fires it up as a "new language", sets the mask >bit, transfers control to the C/C++ program, which then immediately turns it >off and simply returns to the COBOL caller. As each new C/C++ program is >CALLed, the mask bit is off, and remains unchanged. >I think that should work, whatever Smart/Restart is doing. I'll give this a tought, but only as an interim solution. The next case modifying the program mask will surely wait around the corner :-) Thanks everybody for the very good and informative discussion so far. It helped me a lot to get a deeper understanding. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
