Just doing the save won't free up the space or save you time. The SAV* commands do save deleted records. I would do a DSPOBJD of all files in selected libraries and then a DSPFD against those files to find the percentage of deleted records. If it is more than 30% then a reorg should be considered. Anything less won't buy you much. But you could do this to save time. Tonmorrow during normal working hours you can do a SAVLIB *IBM using SAVWHLACT. and a SAV of just the QIBM folder as these don't require a restricted state Then instead of a full save later just do GO SAVE option 23 to save user data which will get everything else. That will save a couple hours at least. In fact a full save once a month and user saves the rest of the time should work as the IBM libraries really only change during OS and PTF upgrades. But still do it at least once a month. ================================================================ A couple things might do more to speed up full system saves than anything else. First, the number of individual objects can be reduced. Nowadays, the largest part of perhaps most systems is held in the /root file system. Reducing deleted records often has little noticeable effect overall because the number of database files is small compared to the number of streamfiles. Cleaning up /root can be a more valuable way to spend your time. Second, your authority scheme should minimize private authorities. One way to judge if your authorities are getting out of line is to run SAVSECDTA to a savefile. This can be done without restricted state, but should be scheduled for times when the system is otherwise quiet. If it's done for a benchmark, you want minimal contention. Then, if you're concerned about how long that one item takes, you could run PRTPRFINT SELECT(*PCTFULL) to see where authorities are distributed. Pay attention to any profiles with higher percentages. If it's a smooth distribution, see how you might start removing private authorities from many profiles and/or many objects. Investigate whether primary group authority might be used. Investigate whether authorities can be moved away from individuals into group profiles. Control at library/directory levels before object levels if private authorities are used. (That might have larger impact if you have database files with many members. Each member duplicates the authorities of the file object, even source files.) None of that should be taken to mean that deleted records make no difference. But if they're a significant issue, they probably ought to be handled through elements such as REUSEDLT(), proper file sizing and normal database management. That will give much better ROI for your time than trying cleanup before full-system or user-library saves. Tom

Just doing the save won't free up the space or save you time. The SAV* commands do save deleted records. I would do a DSPOBJD of all files in selected libraries and then a DSPFD against those files to find the percentage of deleted records. If it is more than 30% then a reorg should be considered. Anything less won't buy you much. But you could do this to save time. Tonmorrow during normal working hours you can do a SAVLIB *IBM using SAVWHLACT. and a SAV of just the QIBM folder as these don't require a restricted state Then instead of a full save later just do GO SAVE option 23 to save user data which will get everything else. That will save a couple hours at least. In fact a full save once a month and user saves the rest of the time should work as the IBM libraries really only change during OS and PTF upgrades. But still do it at least once a month. ================================================================ A couple things might do more to speed up full system saves than anything else. First, the number of individual objects can be reduced. Nowadays, the largest part of perhaps most systems is held in the /root file system. Reducing deleted records often has little noticeable effect overall because the number of database files is small compared to the number of streamfiles. Cleaning up /root can be a more valuable way to spend your time. Second, your authority scheme should minimize private authorities. One way to judge if your authorities are getting out of line is to run SAVSECDTA to a savefile. This can be done without restricted state, but should be scheduled for times when the system is otherwise quiet. If it's done for a benchmark, you want minimal contention. Then, if you're concerned about how long that one item takes, you could run PRTPRFINT SELECT(*PCTFULL) to see where authorities are distributed. Pay attention to any profiles with higher percentages. If it's a smooth distribution, see how you might start removing private authorities from many profiles and/or many objects. Investigate whether primary group authority might be used. Investigate whether authorities can be moved away from individuals into group profiles. Control at library/directory levels before object levels if private authorities are used. (That might have larger impact if you have database files with many members. Each member duplicates the authorities of the file object, even source files.) None of that should be taken to mean that deleted records make no difference. But if they're a significant issue, they probably ought to be handled through elements such as REUSEDLT(), proper file sizing and normal database management. That will give much better ROI for your time than trying cleanup before full-system or user-library saves. Tom