>A Devil's Advocate might be tempted to say just because you don't ABEND does >not mean that a user did not overlay or incorrectly modify VSAM control >blocks that are in user key. How can you ever trust the stats? >Bill Fairchild
Note: CICS, recovering an application abend (via DTB) does not have to Close a VSAM file, since the in-flight work is backed out, and the CIs that are "frozen" (enqueued) are released at sync-point rollback. This lets other transactions continue against that VSAM file. Closing during/after DTB is irrelevant. DB2 and IMS are careful users of VSAM also. Another thread on this list is discussing "destructive" moves, etc. Why mention it? The point is this. In higher level languages one has to be particularly lax as a programmer to cause VSAM control block overlays and destructive (when unintended) moves. So it is assembler that can bite the unwary yet diligent programmer. But if you are coding assembler in the first place, it is because you need some function that should be denied to Joe programmer. This language imposes a stiffer testing methodology and (dare I say) greater knowledge about how things work on the developer. TRUST is inherent in a (debuged) language and (debuged) OS, since the hardware will do exactly what it is told... no more, no less. What user? We're talking programmer. What programmer? Using his native language? Perhaps there should be a "TRUST" quotient assigned to each program based on the author's skill and care and test time, divided by the language complexity and factored by its size and host of the program (CICS, batch, Websphere, etc). If you want VSAM to make the stats trustworthy, write trustworthy programs. At least acknowledge the probability of a failure and plan for it. (I'll not debate the imagined solution of user-written ESTAEx and the problems of having an FFR, VSAM under SRB, VSAM in a Plex under RRS in the CCF, distributed LUWs, etc) -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ---------------------------------------------------------------------- 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
