Oppolzer - Informatik / Blog

The VERSION is related to the PCTIMESTAMP, which is the time when
the precompile has been done. So you have a 5 hours difference from GMT,
that means that you are on the east coast of the USA, I believe.

So the package with 2004-02-20 is the older version, and the package with
2004-02-29 is the newer one.

The TIMESTAMP, OTOH, is IMO the time when the package BIND has been
done, that is, the BIND for the older version has been done AFTER the BIND
for the newer version - maybe to use the older version again. Because you
use the VERSION parm, you may well have both versions in use at the same
time - depending on the version of the load module.

Kind regards

Bernd



Am 16.07.2013 16:15, schrieb R.C.:
>
> Hi,
>
> As per my obersation the timestamp for VERSION is almost same as the
> TIMESTAMP for any package, however for one of the package i noticed
> that there is around 1 month of difference between the value of
> VERSION and TIMESTAMP,
>
> COLLID NAME TIMESTAMP VERSION
> PCTIMESTAMP
> ABCD PQRTSUV 2004-02-29-21.25.10.960192
> 2004-03-01-02.23.23.900744 2004-02-29-21.23.23.900744
>
> Now consider another version of the same package,
>
> COLLID NAME TIMESTAMP VERSION
> PCTIMESTAMP
> ABCD PQRTSUV 2004-03-01-12.04.52.668235
> 2004-02-20-14.51.04.140787 2004-02-20-09.51.04.140787
>
> Now if i've to ORDER BY VERSION DESC, the VERSION will be the latest
> version of the package, and if i sort on TIMESTAMP DESC,
>
> package with VERSION 2004-02-20-14.51.04.140787 will be the latest one.
>
> I used the below query to get the report(see attached), of which the
> first two rows i have pasted above in same order of output.
>
> SELECT
> COLLID
> ,NAME
> ,HEX(CONTOKEN) AS CONTOKEN
> ,TIMESTAMP
> ,BINDTIME
> ,VERSION
> ,PCTIMESTAMP
> ,TYPE
> ,OPTHINT
> FROM SYSIBM.SYSPACKAGE
> WHERE COLLID='ABCD'
> AND NAME='PQRTSUV'
> ORDER BY PCTIMESTAMP DESC
> WITH UR;
>
>