On Wed, 6 Jul 2005 13:23:13 -0400, Kirk Talman wrote: >7/6/2005 11:32 AM Tom Schmidt wrote >>There is a more fundamental issue here: VSAM keeps its statistics records >>in KEY 8 storage in the address space's private area, ... 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. ... > >... > >>The problem with using interval accounting to try to anticipate the ABENDs >... > >1) One can always do one's own interval accounting by opening and closing >the file periodically.
One can, true enough, but at a rather high cost in performance. Still, if you are picky about the stats this is one way to roll your own. >2) In a prior life about a decade ago I remember that the control block >containing at least some of the statistics was in CSA, where it was much >less likely to be overlaid. With a CSA overlay the devil jumps much >faster and higher and sooner and is easily detected. CSA overlays are still a little too common, although far less so than in my 'youth'. As for "easily detected" - ha!! >It may be that that control block was only in CSA when shroptns=3, which >we used -- an option sane people don't use. The control block was small >and could be easily be put in CSA always with minimal cost in these days >of ubiquitous VSCR. Not really such a minimal cost if one considers the tens of thousands of VSAM files open at any arbitrary point in time in larger shops. >3) Don't "eyecatchers" act as effective canaries to know when an overlay >has occurred? I know we used them extensively in the prior life to know >when we were wounded but not yet informed thereof. No. Overlays can come in very small packages -- a single bit overlay is extraordinarily difficult to detect, especially with an eyecatcher canary. But a single bit overlay can cause big issues if, say, the bit is nearer the left than the right in any given byte (or word). >4) There has been much discussion of the desirability of "bad" statistics. > >If I am using "bad" statistics for billing, I can use reasonability checks >to determine if the basis of the bill is bogus and eat the cost rather >than offend the client. Or in the case of a large basis bill to flag the bill for manual post processing perhaps? >If I am decisioning with possibly "bad" statistics, I can adjust my >algorithm to be tolerant. When I was trained as a physicist, accomodating >error was a standard part of any measurement process. The conclusion can >often be made using "bad" data, even if an automaton is doing the work. >The first paper in Physical Review Letters (~1964 Penzias & Wilson) on the >"big bang theory" showed a graph with very large error on the >measurements. But in that case merely the order of magnitude of the data >points allowed a conclusion to be drawn. Or as one could hear said in the >60's (when the first dinosaur ...) It doesn't take a weatherman to know >which the wind is blowing. ...which WAY the wind is blowing. (Unless you were trying to imply no 'way' in your original sentence?) -- 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
