"Dave Juraschek" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > I guess what really peeves me is not that the stats are invalid - although > that is certainly disturbing to say the least. > That is clear (to me now). > > What really is unconscionable is Mark's admission that IBM has known this > for 30+ years and has not cared or bothered to fix it yet. Mark's response > (whether he likes to admit is or not) and IBM's response seems to be "shame > on you for using our bogus [for John] numbers", and never "shame on us for > knowing about this for so long and just not giving a rip". A lousy > disclaimer in one paragraph of one manual is hardly notification to end- > users who might need this kind of information that what IBM is providing > them is ... um, again ... bogus. Not having fixed this in 30+ years > (according to Mark) is both arrogant and sloppy on IBM's part.
I am truly sorry you are offended. However, if you understood the evolution of this operating system better you would recognize that none of the access methods since the beginning have had recovery routines. Back in the days when processors were slow and memory was limited, customers screamed about performance. Every instruction counted. Adding recovery routines to access methods for EVERY SINGLE I/O request would have killed the system. And blocks that generally need to be updated during a request obviously had to be in user key, since there was no simple way back in the old days to update these blocks if they were in protected storage. VSAM is a particularly complex access method, much more so than the others. Obviously we expect that people start learning VSAM by reading the manuals, learning the macros, understanding the processes, etc. There are many warnings and notices in the manuals that need to be read and understood, but you're not the only one that doesn't read them. We regularly run into these scenarios and we have to explain the limitations of the components to customers. It's unfortunate, but that's life. Everything is not perfect. How do we fix the problem? Well, there are several ways, but the major problem hinges on resources. Resources - you know, those things that give you new function in every release? And the emphasis by most customers is "gimme something new and improved in each release", not "can you go fix these statistics"? So guess where most of the resources go? Statistics for VSAM files should be a NIT; let me say that again - a NIT. Most people seriously misuse the statistics. They look at split counts and take down major applications to reorg files because they think that "helps" performance. There's enough information out there to prove that this is not true. Ask Ron Ferguson who preaches "don't reorg based on split counts", or check out the VSAM Demystified Redbook. Or do your own studies. Which is better - downtime for a major application, or reorging a file that doesn't need it? As a result of this change to IDCAMS I've had discussions with several customers who were SHOCKED to discover they didn't need to reorg. They quietly said "thank you" and changed their processes. Had I worked in VSAM for 30+ years I'd have made this change a long time ago and this issue would never have been so contentious. But I've only been working directly in VSAM for a couple of years now so I apologize for not publicizing this sooner. And as several users have pointed out, invalid data is invalid data - and how can you make business decisions on invalid data? If your checking statement said you had $3,127.47 but next to it in parentheses it said "(but this amount is invalid)", would you go out and try to spend the money? No, I think you'd be kinda cautious so you didn't get arrested for fraud. I wonder how businesses can make decisions on the same invalid data. We do have plans to correct the problem, but it's dependent on resources, and time. Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development ---------------------------------------------------------------------- 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
