Sometimes EREP data can provide enough to distinguish the stomper from the stompees. Active PSW REGs and a few lines of failing module can be enough to see where it started. If it's vendor code they might have seen it before or know under what conditions it can be caused. The DB/2 folks were particularly adept in my opinion. Had one where all but the last few dumps had been purged for space, but the offender was the first one. Turns out a table had been dropped and recreated. When tried to reload it failed. REG 6? Oh, it had been extended on the fly. Just recreate the table, extend and then do the reload. Oh, OK-it worked. In a message dated 4/15/2014 2:59:41 P.M. Central Daylight Time, [email protected] writes:
In production outages time is usually a more prized commodity than DASD space - educate your operations people. Much has been done to allow disk dumps to run pretty quickly - none of that probably helps on tape. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
