"Juraschek, David F" <[EMAIL PROTECTED]> wrote in message news:<OF28FF1D46.703B3284-ON85257030.00596139-85257030.005 [EMAIL PROTECTED]>... > > If IBM can devote the time and attention to releases of the OS, one would > think that they are capable of fixing this problem - a long, long time ago > when they were first aware of it. > > Doesn't this bother anyone else but me?
Well, I'm glad you brought this up. Apparently you haven't read the section "Closing Data Sets" in the DFSMS "Using Data Sets" manual which has said for many, many years: "When you issue a temporary or a permanent CLOSE macro, VSAM updates the data set's catalog records. If your program ends with an abnormal end (ABEND) without closing a VSAM data set the data set's catalog records are not updated, and contain inaccurate statistics. " It has been this way since the very beginning of time for VSAM. This is because many of the blocks that contain VSAM information are in the user key (since record management needs to access and change them), and on an abnormal termination there is no way to determine that those values are correct - they could have been overlaid by a user program. This includes information about extents that exist, RBA ranges, index levels, configuration information about the data set, etc. Would you prefer that we blindly write out the data and break your data set? I suppose not, so we don't. The statistics are also a by-product of this. Even though the statistics have never been updated since the beginning of VSAM for an abnormal termination, the issue has apparently NEVER COME UP because prior to this IDCAMS did not flag the statistics as invalid. Only when we did (as a warning to the user community), did people start to realize "oh my gosh, this data is BAD!". Most of the users have said "oh cool, that's why my numbers don't match". However there's another group of people that still want to use this invalid data to make business decisions. They don't care the numbers are invalid, they want to use them. Even if they're orders of magnitude off (and in some cases they are). If you can give me a rational explanation for that decision it would help me sleep at night. We thought telling them the data was invalid would be enlightening - apparently it wasn't. Until VSAM record management has the ability to protect the control blocks from user overlays (which means running in a different key), this problem cannot be fixed. That's a goal we're working towards, but it's going to take a while to do. It's a very simple problem called "resources". On the grand scale of problems, invalid statistics are pretty close to the bottom of the list. Realize that NONE of the data management access methods have recovery, or blocks that are protected. It's been that way for performance reasons since the beginning. Because of that small group of people that wanted the numbers (even though they were invalid) we have changed the output and now list the numbers (APAR OA11927) with the indication they're invalid. What comfort these invalid numbers will give people is unknown, but because they wanted the invalid data, they've now got it. 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
