Most DBA's on DB2 for z/OS gets nervous when RUNSTATS has been executed on the central tables of their most performance heavy systems. After a RUNSTATS you have to decide if you want to run a REBIND on the packages accessing those tables. If the access path has changed it may have huge impact on performance. This is the reason why many installations do not execute a REBIND after RUNSTATS.

It would be very handy to know the new access path before you actually execute any REBIND. Unfortunately there is no REBIND EXPLAIN(ONLY) option for the REBIND command, but on an IDUG conference I was introduced to the idea of executing a BIND COPY to a dummy collection. I think this is a fantastic idea which I now will pass on to you.

BIND COPY creates an almost exact copy of the package you copy from in another collection. During the copy process the new package passes through the same process as is performed during REBIND and the final result is that the new copy gets the access path that the original one would have obtained after a REBIND. All you have to do now is to compare the access path of the original and the new package. If they are identical there is no need to REBIND. If there are differences you have to evaluate the new access path compared to the old one and decide whether to REBIND or not.