On 09/16/2009 05:45 PM, Clark Morris wrote: > On 16 Sep 2009 10:53:02 -0700, in bit.listserv.ibm-main you wrote: > >> In <[email protected]>, on 09/15/2009 >> at 07:31 AM, Howard Brazee <[email protected]> said: >> >>> What am I missing? >> >> The possibility that the application that failed to close the file might >> have had updates it hadn't written out. The fact that "file integrity" >> doesn't mean what you are assuming it means; it just means that the data >> structures on disk are consistent with each other. >> > While I understand the exposure, I wonder how many shops treated 97 > differently than they did 00. For that matter, is there any way to > determine if an IDCAMS verify actually reset the open flag as opposed > to finding the file was successfully closed? >
I can conceive of a case where you might want to distinguish between "97" and "00", but don't know of any programs in our shop doing that. It might make sense if the failure was because of a known ABEND of a re-runnable batch process or if there is a need to just record a possible exposure to lost updates or failure to update VSAM statistics; but, if you know which batch step abended, in all likelihood your problem resolution is going to involve a fix and rerun of that to start with. All the other cases I've seen of "97" was because a online system had terminated "with prejudice" (or because a batch program response to a "97" on OPEN was to ABEND without CLOSE). In the case of a CICS ABEND there is generally no way to regenerate any interactive updates that might be lost or rollback to a consistent prior data state - unless you consider the file important enough to use CICS journalling, in which case CICS can handle some recovery. -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
