Re: REUSEDLT(*NO) vs. REUSEDLT(*YES)

Here are a few of the issues that I am aware of REUSEDLT(*YES) will...


- Cause arrival sequence processing to require attention.

If you are using SQL, this is not an issue

- SQL cursors without an ORDER BY will give data in seemingly random order according to the SQE's implementation of the
request (don't ask how we were bit by this :))

If your SQL needs a specific order, you should include an order by clause. There is no guaranteed order when you do not include that. The SQL optimizer will return the records in the best order. Just adding a new where clause could change the order you get records back. And just because you are getting records in arrival sequence today, there is no guarantee that it won't change with a PTF that updates the optimizer.

- May cause problems concerning access path maintenance, thus potentially impacting performance (as of V5R4, this did
not appear to be an issue any longer?).

Never had an issue with this.

- Modernizing the DB to DDL (from DDS) will result in tables that are REUSEDLT(*YES) by default as the CREATE TABLE SQL
does not have provision for restricting deleted row reuse.

This has always been the SQL default, it reduces the need for RGZPFM.

- Does not completely exclude the need for periodic RGZPFM to be run on the tables.

If not completely, dang close. Only files that are trending to fewer active records will need RGZPFM, and if it is a seasonal thing, then they probably don't need it anyway as the deleted records will be used up again next busy season.

The question is... with enhancements to the SQE in V7R1 and such...will REUSEDLT(*YES) provide a significant lessening of the
need for RGZPFM (perhaps annually or monthly versus weekly on select tables) without a performance problem over time?

You shouldn't need RGZPFM at all if you are using REUSEDLTRCD(*YES).

Mark Murphy