This entry was originally published on 2014-03-31.

By Michael Dewert.

RTS REORGLASTTIME is set to creation time without REORG ever executed:

RTS tracks the last time when a REORG utility was executed against an table space / partition object in SYSIBM.SYTABLESPACESTATS.REORGLASTTIME. However,after a newly created table space object without any REORG executed against it, SYSIBM.SYSTABLESPACESTATS.REORGLASTTIME indicates the same timestamp as the creation time.

Why is that?

Actually this behaviour is intended and works as designed. The rational behind is that a newly created empty table is considered perfectly reorganised.

That behaviour is also documented in the Db2 documentation about SYSIBM.SYSTABLESPACESTATS.REORGLASTTIME:

The timestamp the REORG utility was last run on the table space or partition, or when the REORG utility has not been run, the time when the table space or partition was created. A null value indicates that the timestamp is unknown.

A value of NULL would indicate an UNKNOWN point in time. One could argue that this theoretically true, no REORG utility was executed against the table space object. However, the other rationale is that Db2 supplied stored procedure DSNACCOX has to identify the need for a REORG based on REORG-INSERT/UPDATE/DELETE values of the SYSIBM.SYSTABLESPACESTATS table. This is basically done based on the SYSIBM.SYSTABLESPACESTATS.UPDATESTATSTIME value and number of SYSIBM.SYSTABLESPACESTATS.REORG-INSERTS/DELETES/UPDATES compared against SYSIBM.SYSTABLESPACESTATS.REORGLASTTIME. So if we would set SYSIBM.SYSTABLESPACESTATS.REORGLASTTIME to NULL during the CREATE time, which means also UNKNOWN, DSNACCOX could not pick on that. In the past we had to run REORG explicitly after create time to enable DSNACCOX.

With that said, there is also an exception to it. APAR PM37511 introduced a change where COPY or RUNSTATS would trigger setting RSYSIBM.SYSTABLESPACESTATSEORGLASTTIME to NULL if the RTS row for the affected object did not exist before. This situation could occur when during CREATE TABLESPACE or CREATE INDEXSPACE time the RTS table space was offline or not accessible. Or when migrating from Db2 UDB for z/OS Version 8.1, the table space was created when the RTS support was disabled.