I am having trouble to understand your points as well.
BINDTIME is a very old column, timestamp of last REBIND (or BIND
the first time when Package is created or recreated from BIND
again). It should not have been defaulted to anything when you went
to version 10. If you converted Plan DBRMs to Packages, then it
would be set for a new Package created, perhaps that is what you
are getting at, even though this new Package might never have been
used, and LASTUSED would be set to 01.01.0001. BINDTIME could be
reset to any new timestamp by someone deciding to REBIND a whole
lot of Packages for whatever reason, and therefore not a useful
value other than to identify the access path rows etc., but it
should not affect the LASTUSED. So it (BINDTIME) still means very
little in relation to real usage of a Package.
TIMESTAMP is when the Package was first created, which could be
just a new VERSION id or a new CONTOKEN, or new Package at V10
converted from a Plan DBRM. So more useful than the BINDTIME,
as I see it.
For any Packages with LASTUSED 01.01.0001, you can't really tell
if they will ever be used. You could check to see if a previous
version (prev CONTOKEN) was ever used or used in recent years, this
assumes you may have previous versions still there for some
My point was it is much safer to free up previous versions, if
they have not been used for years, because you have a newer version
that might be in use. If newer version has not been used, then
might not be safe to free up an older version used in the last year
Trying to decide whether current versions of Packages will never
be used, is an very difficult, if not quite impossible task.
Therefore I just don't want to do it at all. Wasting my time. If
the underlying objects are gone, so Package cannot be used, O.K.
that is a useless Package. Some sites may have lost the application
programs that a Package was created from. LOL.
I did an experiment once. Collected all Package LASTUSED for
10,000 Packages maybe more. 1 month later collected all
LASTUSED again. I did find some old Packages had been used the 2nd
time that had never been used before, or had not been used for many
years beforehand. This proves the danger of removing them! You just
never know what very obscure functions will be used (at last) for
the first time for that Package Version. The experiment was done
back at V10, since that was when some people were pushing for
a big Package clean-up (even IBM suggested it). We later abandoned
the clean-up idea as being non productive effort. We just accepted
that the DB2 Catalog got bigger for Extended Package
In the modern day with Extended Package Management, the
experiment might be easier. Suppose you find Packages in
SYSPACKCOPY where LASTUSED is '01.01.0001' (last used as a Package
before a REBIND caused it to be a Package Copy) but same Package
key in SYSPACKAGE shows a usage in the last few months. That tells
us that a package may have never been known to be used for a long
time, then at last has been used. Could happen to any Package. Have
we got a crystal ball to predict which package?
We have useless Packages in there? Who cares! If they don't get
used for a long time, then just ignore them! That is my opinion.
REBIND them only if forced to do so. Any Mass REBIND could
generally skip them perhaps, unless REBIND is mandatory for some
DB2 Application Performance Specialist
CPT Global Ltd