"Dave Juraschek" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Mark: > > This isn't just user data sets, it's MVS system data sets which are ONLY > touched by IBM programs, utilities, etc. You can't blame user's for > screwing up non-user data sets.
VSAM is VSAM - we don't distinguish between "user" and "system" data sets. And if the user does something that causes the program to terminate abnormally (like cancelling it, hitting PA1 on TSO, etc) then the results will be the same. It's an ACCESS METHOD with NO RECOVERY, just like all the other access methods. If we could "fix" the numbers for system data sets, we could fix it for user data sets too - but we can't do either at this point. The most common cause we've seen for the invalid numbers is an immediate shutdown of CICS, because users don't want to wait for a "normal" shutdown. > > Shouldn't a verify or something fix the file if it is detectable that it > was opened an never closed properly? VERIFY (either an implicit through OPEN or explicit through VSAM) only determines the actual HURBA of the data set and resets it so the data set will be valid for adding records. > As it is, you have to completely > repro off the cluster, delete and re-define it and re-load the cluster to > get the statistics back. Yes, that's correct. Sorry, but that's the way it's been for 30+ years. As I said, apparently a lot of people weren't even aware of this because they didn't read the book. I looked at the possibility of EXAMINE resetting the stats, but there are serialization problems, particularly if the data set is being used by another application while the EXAMINE is running. And the BEST that would happen is the record count would be reset, all other stats would be zero. > Verify returns a RC=0 but changes nothinge either. As mentioned above, VERIFY resets the HURBA if necessary. > > Gary asks if the numbers are fixed with a subsequent close and reopen of > the file. No, they are not. Practically speaking, how would we "fix" the numbers when the record of how many updates, deletes, and adds were thrown away on the abnormal termination? > > Nope. Not a verify. Nothing short of the draconian and drastic steps > above will fix the statistics until they are next screwed up again. > > I agree with John. No statistics are better than bad statistics. I wish everyone else felt that way, but there are some people that want bad statistics. As I said, a rational explanation would help me sleep better at night. > > At least fix VERIFY so that it somehow resets stuff. Can't - as pointed out above. > Fix something. As I pointed out previously what is required, we plan to move in that direction. But it's going to take a while. > But then, as you clearly imply - IBM is perfectly o.k. with this erroneous data > and sees no problem with it. Not true - that's why I changed the listings in IDCAMS to absolutely inform users that the statistics on their data sets were in fact invalid. I can't justify why it wasn't done years ago because I didn't work on IDCAMS, VSAM, or Catalog when these decisions were made. What I find most intriguing are the people that want the numbers - "bad or not" - to make business decisions with, to take online applications down for reorgs, etc. > Nope, IBM sees the user as an idiot for > relying on IBM's bad numbers. I object to that characterization. I explicitly made a change to make people aware. The notification has been there for YEARS that these numbers were invalid. People apparently didn't even think about it until I started putting "INVALID" in the output. Then they felt the sky was falling and they HAD to have the numbers back - something to wrap their hands around and feel comfortable with, even though the numbers were WRONG, WRONG, WRONG. When (and if) you talk to some of those users you can make your own determination as to how YOU want to classify them. 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
