On Tue, 30 Oct 2007 12:56:45 -0600, Howard Brazee wrote: >On 30 Oct 2007 11:30:25 -0700, in bit.listserv.ibm-main you wrote: > >>>But why should a program care about block size? >>> >> >>Funny you should ask this; We had a major project implement a couple weeks >>ago. To deal with the number of object moves, many of the libraries were just >>cloned and renamed at implementation time. During this, a couple pretty >>important PDS's were reblocked. A pretty benign change from my point of view. >> >>It turns out a program update process allocates one of these PDS's >>SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this >>PDS that was longer than about 40 lines was corrupted and innaccessible. >> >>That's a reason to care, but probably not the point trying to be made. There >>are code bombs waiting to explode. Even a seemingly benign change can >>trigger one. > >It is absolutely a reason to care - and to demand that the Operating >System do the work. >
I guess I would counter that coding omnipotence into the OS would be expensive from a performance standpoint, it would be a moving target and it's probably not even possible. As things evolve, what was once common practice is no longer. Who would have guessed that something like this would be waiting to cause a problem ??? If you were coding the OS, would you have thought of this one ??? I still don't understand why it was there in the first place. LE seems to want to do a lot of this cross checking stuff, but I'm not so sure I want to be blocked from doing something. Correcting the issue without data loss relied on this functioning equally irrationally both ways - corrupting it with a program and fixing it with a utility. If the utility had been so smart as to block the correction, I would have been recovering this PDS from a backup, losing a lot of updates and hoping I found the problem so the updates could be reapplied. I think this thread tangent concerns fundamental changes in the OS that may uncover some of these issues. I think I'd rather partake in a glacial evolution rather than wholesale change that might frighten users, substantially increase maintenance costs and encourage a migration away from the platform. ---------------------------------------------------------------------- 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
