On Wed, 6 Jul 2005 06:57:38 EDT, Bill Fairchild wrote: > >In a message dated 7/6/2005 5:22:42 A.M. Central Daylight Time, >Bob Richards writes: > >> In the case of an ABEND or CICS "close immediate" situation, what >information would you like Mark to write to the file? And where is this >>information supposed to come from? > >I think you are assuming there is only one way to "fix" this problem. >E.g., in the case of SMF data the solution is called interval >accounting. Every X minutes SMF records are written to reflect the >activity during the last X minutes. The VSAM statistics in question >could be updated on intervals. You will miss all the activity that >occurs during the last partial interval just before a system crash. >Application programs or even access methods (e.g., at OPEN time) could be >enhanced to add ABEND recovery routines that invoke a new >service which would add the last partial interval's stats into the proper >buckets. This assumes the stats are kept in storage that was not trashed >as part of the error leading to the ABEND. If the operator FORCEs the >job or the system crashes, there is no hope. But for most abnormal ends >there are ways to "fix" the stats. The information comes from the same >place where it comes from now in the case of normal CLOSE. The minimum >we would need is a new service which the user would invoke to update >stats. > >Bill Fairchild
There is a more fundamental issue here: VSAM keeps its statistics records in KEY 8 storage in the address space's private area, since it normally runs as an extension to the application program code. Those statistics records can, and often are in the case of a storage overlay, subject to corruption and/or destruction because of that inherent lack of protection. VSAM (and other access methods perhaps) needs to have a protected area for such apparently customer-important data as statistics. Anything less is a band-aid. VSAM could move the statistics to a data space, either owned by the application address space or perhaps owned by the system (somewhere). But it would probably still end up being a KEY 8 data space since it is still an extension of the application program code... so it would be 'security by obscurity' and not iron-clad. That should still offer a marked improvement over the private area. But it would also introduce performance concerns in the middle of an obvious performance path. Sticky detail. The problem with using interval accounting to try to anticipate the ABENDs is that storage overlays do not always (or even often) inflict the fatal damage on the first strike. The statistics records could, possibly, be the first storage to be overlaid (or worse, partially overlaid) and the result would be difficult to see... certainly difficult for poorly written LISTCAT automation to see. Again, this introduces a (smaller? maybe not) performance concern by pushing out excess SMF records in the middle of the I/O (performance) path. A problem with having the access method inflict its own recovery during ABENDs would be the new conflict(s) that would result, for example which percolates to which and how could the access method get control "first" ... should the access method REALLY get control first? LE would probably vote 'no' and other products (or applications) might vote similarly... then what? Even if VSAM's shiny new recovery intercept got control at the ABEND who is to say that its statistics data wasn't already overlaid? Too late. As for why it took IBM so long to address the issue... I personally don't blame IBM for taking so long, since the statistics were always (as far as I know) documented to be an indicator and there was (as is obvious by this thread) a huge misunderstanding in the customer (and vendor) community over the scope and impact of the problem, if any. There was documentation warning against use of LISTCAT as a programming interface that goes back to (at least) 1981 ... caveat emptor. I commend Mark for taking the issue in hand and trying to implement a long term solution, and for raising it to the level where it is discussed so that the appropriate awareness is reached, but Mark doesn't need my commendation for job satisfaction. Say what you want about IBM but its people are still among the best architects of software around. This issue is convoluted at best. -- Tom Schmidt Madison, WI ---------------------------------------------------------------------- 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
