HRDRFREA has had at least part of its "executable code" overwritten. That has caused a branch, directly or indirectly (through more than one branch), to somewhere close to where it abended. As soon as it branches out of the COBOL program, the information is irrelevant for problem determination without a "full" dump.
HRDRFREA looks to be six CALLs deep. ZTVXXX00, HRDEFREA or any of the other modules involved in that specific chain, or any other module that has been CALLed previously in that run-unit, has caused the overwriting. One particular record "causes" the issue. Bear in mind that this may not be so. The issue may be there every day (overwriting) but only some combination of conditions prompted by that record presents the busted code for execution, or in a similar way but only on a few days, or only on that day - those conditions can be from other records, external data relating to those other records (DB or other reference data), previous program state. Or it may directly be that record causing, and suffering from, the overwriting. But that may be directly, or relying on previous state, as above. Without at least a dump containing the executable code of HRDRFREA it is "difficult" to establish what has happened. The investigator (singular - if you have multiple people looking at it, each should work singly) must be aware of the many possibilities, and be open to others. They have to be completely open - preconceptions will lead astray. After working for a period of time, take a break from looking at it. You've probably already missed it. Clear new preconceptions. You start with that record. That record is going to get you there. You have to conceptualise how that record becomes an abend. The "short-cuts" will usually get you there, or on the road. You find a mismatch in parameters, now you have to say "how does that cause the problem"? You may just be noticing another "issue", with no connection to the one at hand. Same with subscripting, reference-modification and the use of pointers. Don't just jump on the first error, fix, recompile and then go with it. Even if the run then completes, it may only be because now something less significant (for that run) has been overwritten, simply through the changed code from the fix (the overwriting only needs to move by one byte to have a different, even benign, result). Until the failure can be fully explained by what is discovered, it cannot be resolved. Suggested explanations should also be tested against "and why doesn't it fail every day" and similar. Yes, it's easier with a full dump, but sometimes you don't have a full dump. If the issue is sufficiently important, then "escalation" may allow some way to get sufficiently more information. "We absolutely need this, and the only way we can get it is by doing that", followed by "signatures of power" may be a possibility. Also, of course, and you probably already are, review the exact use of the tools for cases like this (when the far-from-usual happens). 99% of the time a formatted dump is going to be sufficient. The other 1% consumes 99.9999999% of abend-solving time (for COBOL application programs). Figures are invented, but intended to be indicative. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
