|
Scotty, Syd made some good points, as did other people point out stuff to be aware of. I think the most important thing is that your programmer doing the deletions is familiar with the applications. Before changing REUSEDLT you need to talk to the folks who wrote the software. When I found out about REUSEDLT, I called my vendor in a rage to ask why their files not setup that way, then they explained stuff that I had not understood, which meant that I left their software as is. We also have an application in which it reads records based on a sequence # ... if we delete records that we no longer need that leads to the sequence #s jumping so they no longer consecutive, there are programs that read 1 2 3 4 5 then when they hit something that aint there they quit reading, not realizing there may be 9 10 11 out there that need to be processed ... we have programs that go through files to resequence because that is simpler than locating & fixing all the programs that are that way, but we can't do this with all files, because sometimes there are other files that link in which using the sequence # is part of the index. The key here is that the programmer needs to know the application well enough, to know when it is safe to delete & when it is not, and when there is stuff out there with implications like the sequence # significance. If a file has a lot of members (some of our files have hundreds), & logicals (I think 50 or so is the most we have), and if you have all the source code to recreate this, a reorg can go a lot faster if you selectively eliminate some stuff before the reorg & then rebuild it, but you do need to know how to deal with excess members vs. what a logical can contain, and be absolutely sure you do have all the source code. When you do the reorg, you have the choice of changing the sequence of what is in the physical file so that it agrees with some logical. If you know the application well enough you might be able to predict what sequence is used by most people. If you get it right, this can improve later performance. I like Fiona's suggestion. I intermittently need to do this on clusters of related files. I can be doing other work on other files while waiting on the reorg. If there are a bunch of files needing similar service on a regular basis, I might like to have an architecture in which when a reorg of a file is done it sends a message to a particular message Q to say that file is now reorged so we launch this from some prompt screen ... send reorg of this & that file to JOBQ ... give us list of files getting this done, let us know as each one gets done MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.