>There is an assumption in the OP that the program itself "did it". Maybe it did. But maybe it did not do it directly.
I'm relatively new to the company and am collecting information bit by bit about this Cobol and "decimal overflow mask" problem. It seems this is know to the company since quite some years, but no-one is left knowing the details in-depth. What I've been given is a two pager describing the problem, and advising developers to find where they'd called C code directly (instead of an interface routine resetting the mask). >From that I concluded that the case at hand is the result from such a case. >This is why I was looking for an easier way to find C modules in the dump than >scanning memory (load modules). In the meantime, I have been able to create a >list of modules and language from some development tool I did not know before. >No C module could be identified. Scratching my head until Bill's post. So, yes, Peter, you're absoultely right, it may have been cause by own code or not. From Bill's post mentioning that "Cobol V5 always uses C", I conclude that this must be the case here. I've been reading a lot today to learn more about LE and the mask bits. I now understand that you could never rely on the setting of the bits in a mixed language environment. It was just the case so far that we (our middleware developers) could control this because our Cobol code was calling our Cobol or C code only. A glue glue module solved the issue. The same has been done for XML processing, I understand now from discussing with our middleware people today. It probably was not a good solution as we can see now. Our programs are run with CEEOPTS TRAP(ON). In the initial post have erroneously spoken about an "S0CA", where I should have said "000A program exception. Later I wrote 000A exception. By that I mean to say that the program did *not* suffern from an S0CA abend, because the "environment" (Smart/Restart and LE) trapped the 000A and resumed. Apologies for any confusion this may have caused. The proper solution instead of creating glue routines woud have been to solve the issue with Smart/Restart. We probably now have to do this now. More investigation is due tomorrow. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
