Anonym.
Hallo,
ich habe Ungereimtheiten in unserem Katalog gefunden und wollte Euch mal fragen, wie das zustande kommen kann:
COLLID   NAME    Contoken To Timestamp    PCTIMESTAMP       Â
——–++——–++————————–++————————–
Coll1 Â Â DB81B000 Â 2001-10-29-12.20.22.117389 Â 2001-10-29-12.20.22.117389
Coll2 Â Â DB81B000 Â 2001-10-29-12.20.22.117389 Â 2001-10-29-12.20.22.117389
Coll1 Â Â DB60B009 Â 2000-05-17-14.09.35.665233 Â 2000-05-17-14.09.35.665233
Coll2 Â Â DB60B009 Â 2000-05-17-14.09.35.665233 Â 2000-05-17-12.09.35.665233
Coll1 Â Â DB61B009 Â 1999-11-10-12.21.52.737046 Â 1999-11-10-13.21.52.737046
Coll2 Â Â DB61B009 Â 1999-11-10-12.21.52.737046 Â 1999-11-10-11.21.52.737046
Coll1 Â Â DB72B003 Â 1998-04-15-14.53.31.576857 Â 1998-04-15-13.53.31.576857
Coll2 Â Â DB72B003 Â 1998-04-15-14.53.31.576857 Â 1998-04-15-12.53.31.576857
ich habe also Packages, die den gleichen CONTOKEN besitzen aber unterschiedliche PC-TS. Kann es sein, dass BIND, REBIND und/oder COPY PACKAGE den im DBRM enthaltenen Contoken unterschiedlich umrechnen? Oder bzgl. TimeZone auf ggfs. unterschiedliche Maschinenregister zugreifen?
Danke
Alexander
Hallo Alexander,
solche Unterschiede zwischen den Timestamps um genau eine oder zwei Stunden haben wir bei uns im Hause auch regelmäßig. Dies ist ein reines Darstellungsproblem, da die eingestellten Zeitzonen zwischen DB2 Subsystem und dem Rest der Welt nicht passen. Die jeweils dazu gehörigen consistency tokens, und auf die kommt es DB2-intern ja eigentlich an, haben auf jeden Fall den identischen Inhalt.
Tschüß
Christian
Hallo Christian,
dass das was mit den Zeitzonen zu tun hat ist klar. Aber im DBRM ist m.W. nach nur ein Hex-Wert drin, der umgerechnet den CONTOKEN im Katalog bildet. Da Du doch wohl nicht die Packages für verschiedene COLLIDs in unterschiedlichen Zeitzonen erstellst (Paris, London, New York, … Hauptsache die Frisur sitzt  😉 ), muss die Differenz doch irgendwie erklärbar sein…
Ich verstehe ja, dass ein Package, dessen DBRM zentral zur Verfügung gestellt wird und rund um die Erde gebunden wurde in jeder Zeitzone ein anderen PC-TS hat, aber EIN DBRM in EINER Zeitzone sollte immer den gleichen PC-TS bringen.
AAAABER jetzt folgendes:
auf unserer Testmaschine ist neue Software eingespielt worden, u.a. auch eine neue Version der DSNUTILS. Wenn ich mir im DBRM den "PC-TS" suche, ist der mit HEX(CONTOKEN) identisch. Rechne ich den nun (mit meiner Funktion, die bislang auch richtig gerechnet hat) in einen TS um, erhalte ich "1964-02-07-17.22.48.757185". Als PC-TS steht aber im Katalog "0001-01-01-00.00.00.000000".
Wer hat denn dafür eine Erklärung?
Klar, Haupsache es läuft. Aber wenn ich der AE verklicker, der TS aus DBRM und PC-TS aus dem Kat müssen gleich sein … und jetzt das …
Grüsse
Alexander
You must be logged in to reply to this topic.
