For a COBOL program to produce an exotic abend (removing the current record and having a clean run points a pretty big finger at the COBOL program) then it is a storage overlay.
Tiny chance, tiny, tiny, of runtime/compiler problem if you are on V5+. Nice to know, just to know whether to discount it completely. With the COBOL program and the record causing the failure, it would be possible to identify the issue. Of course, it is not always possible to supply these things. Two main things cause storage overlays in COBOL. Wild "subscripts" (which includes reference-modifiers) and parameter mismatches on CALLs. For the first, using compiler option SSRANGE (with LE Runtime option CHECK(ON) if you are before V5) will help. For the CALLs, it is down to "inspection" of the code. Since "pointers" have been available in COBOL, those have to be taken into consideration as well. Look for any "manipulation" of pointers, especially with 'rithmatic, and especially on definitions which are not COMP-5 (or TRUNC(BIN)). I don't look at programs the way a Sysprog does, and that's probably true vice versa. What is easy for me to say and do, is probably as much like moon-dust to you as a lot on this list is to me :-) You're on the right track. Deleting the record shows that. S0CA is interesting, but you don't get many of those in a COBOL program either. Perhaps the same cause? For this type of problem (removing the record "fixes" it) there are two things to look for: what is it about that current record?; is there any "crosstalk" possible with a previous record. Yes, even for a COBOL programmer a SYSUDUMP would help. Oldschool, anyway. Shoot anyone who suggests firing up a debugger :-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
