Some more news, but unfortunately not good news. The conviction I wrote in the second paragraph below does no longer hold true. IBM LE support told us that there are cases where LE's condition handling may lead to LE cancelling the ESTAE before issueing an ABEND. Since Smart/Restart registered its ESTAE after LE, it will be S/R's ESTAE that will be cancelled in those cases inadvertantly. LE manuals document that "you should not make use of MVS ESTAE and ESPIE.....since this might interfere with LE's condition handling". So running S/R with ESPIE(OFF) is also not a fool proof solution. In fact, there currently is none.
-- Peter Hunkeler Remember, I was posting a couple of times about the 00A program checks that started to cause us trouble late last year? For those interested here comes some insight I gained so far. - We run Smart/Restart with the default options ESTAE(ON) and ESPIE(ON). This made us belive that the 00A program checks will be intercepted by S/R's ESPIE exit. Therefore we thought that exit needs to properly handle 00A's from Cobol, namely by retrying. After long, it turned out that S/R is actually RESETting the ESPIE when ESPIE(ON) is specified, and not registering its own exit. This in fact *cancelles* LE's ESPIE exit that was established by LE because we run with LE option TRAP(ON,SPIE). Umhh... - We are currently convinced that we should run S/R with ESPIE(OFF); we cannot imagine why on earth S/R would need an ESPIE exit at all. But we're still in discussion if there is any drawback of this. With S/R ESPIE(OFF), LE's ESPIE exit will gain control for program checks and will properly handle the Cobol 00As. - Why are we seenig those 00As more often recently? It seems to turn out that Cobol V5.2 is generating a completely different instruction stream for certain MOVE instructions that involve moving numbers, especially fractions parts. Cobol up to V5.1 was generating instruciton streams that could not raise a decimal overflow; Cobol V5.2 is. It is making use of the SRP (shift and rund decimal) instruction, and this is where our applications are generating the 00As. - My modification of the IGZCFCC and IGZXFCA1 Cobol runtime module succeded (remember the "binder" questions I had). I was able to see that running job using the IBM debugger, the decimal overflow mask was not get turned on as long as only Cobol V4.2 code was running. But as soon as some Cobol V5.2 code was being called, the mask was set. However, strangely enough, the problem did not occur if the same Cobol V5.2 code was being called when *not* running under the debugger. Also, I was able to trace a job where Cobol V4.2 and V5.2 modules were heavily being used intermixed. To my astonishment, the decimal overflow mask was seen to be turne ON after about 2000 CALLs to both Cobol V4.2 and V5.2 modules. Still investigating, but with lower priority, since I'm convinced the solution is runinng S/R with ESPIE(OFF), as explained above. Not finished yet, but at least big steps forward. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
