if you are using any logicals with LIFO sequencing then you cant use reuse as the LIFO depends upon the Relative record number to work...probably a good idea to check this first.

---

I have seen a case were reuse caused problems. A batch program received records from a bisysc line and wrote records to several data files. It would periodically submit other batch jobs to process it's output files. These programs would then process the records and delete them. This created large numbers of deleted records so we changed these files to reuese deleted records. Duplicate records started appearing. We never determined whether duplicates were being wrtten or deletes were failing. We never saw any triplicates or more and duplicates were very rare (one an hour with several thousand an hour being processed.) Changed the files back and the problem dissapeared. This was 4 years ago on a B60 V2 somthing. I have see reuse used extensively on other machines with no problems.

---

When I used it at a client site I didn't think through the ramifications and had problems for a few days until it came to light. The program reads an unkeyed physical file from start to end (by RRN), then deletes all records for the next cycle. Problem turned out to be that records that were loaded in a certain sequence fell out of sequence since the indexes (RRN) went all over the place, so think it out first. BTW, performance did improve for those couple of days. Ever try to do a DSPPFM on a physical whose first record (because of deletes) was in the hundreds of thousands? If not, you have to wait sometimes minutes for the screen to come up.

---

We have used reusedlt since it was introduced on the System/38 with no problems. One of our clients though some times uses relative record number to remove blocks of records added in error. Reusedlt will not work for that.

---

We have used the REUSEDLT(*YES) parameters ever since it was introduced in V2R2. The Database Guide lists the warnings, but I will reiterate some of the more important ones. You cannot specify re-use delete if the physical file has any access path that specifies anything other than default ordering for duplicate keys. All LF38 files have an implicit default ordering of FIFO. So these would have to be created. You should not use EOFDLY on physical files unless you are reading sequentially by key. Any program that relies on new records being added to the end of the file will not work as expected. When we started REUSEDLT we dedicated a weekend for the access path rebuilds. We have had absolutely no problems with it for 6 years. Not even a performance degradation that anyone has noticed. Make sure with Mimx that they support re-use delete before you start it. In 1992, they did not.

---

So long as you have some non-user time available you should be able to REORG the files periodically. I think this reclaims deleted records.

---