LOGRBA umrechnen in ein Timestamp Format

Ansicht von 11 Beiträgen - 1 bis 11 (von insgesamt 11)
  • Author
    Posts
  • 1. April 2009 um 7:59 Uhr #4029

    Anonym
    Inaktiv

    HAllo zusammen

    weiß jemand wie man eine LOGrba (bsP:04678EEF9B65)
    in einen Timestamp umrechnen kann ?

    Danke

    Zefrim

    1. April 2009 um 11:49 Uhr #4199

    Anonym
    Inaktiv

    Hallo zefrim,

    eine LOGRBA kannst Du nicht umrechnen, weil die unabhängig vom Datum ist.

    Was Du umrechnen kannst ist die START_RBA bzw LRSN ( die z.B. in der SYSIBM.SYSCOPY abgespeichert werden )

    1. April 2009 um 14:38 Uhr #4326

    Anonym
    Inaktiv

    Hallo,

    gibt es etwa Funktionen im DB2, die mir einen X-String in TS umwandeln?? Dann hätte ich mir meine Funktionen ja sparen können 🙁

    Die sagt mir, dass 04678EEF9B65 einer Uhrzeit von 02.38.11.431021 (Zulu) entspricht …

    Alexander

    2. April 2009 um 8:00 Uhr #4418

    Anonym
    Inaktiv

    S ELECT TIMESTAMP(X’C3F3567F9C83′ || X’0000′) FROM SYSIBM.SYSDUMMY1;

    wandelt eine LRSN/START_RBA in den dazugehörigen Timestamp um.

    Aber wie bereits gesagt, eine LOG-RBA hat keinen Bezug zum Datum. Die kannst Du ja relativ beliebig bei einem ColdRestart setzen.

    2. April 2009 um 12:53 Uhr #4476

    Anonym
    Inaktiv

    wofür stehen denn die beiden senkrechten Striche? Die kann ich zwar eingeben, aber können nicht interpretiert werden…

    2. April 2009 um 17:33 Uhr #4505

    Anonym
    Inaktiv

    Hi Alex,

    || oder auch !! stehen für die Funktion CONCAT, eine Verkettung von 2 Strings also.

    Gruß
    Gernot

    PS: Eine Funktion zur Umrechnung des DBRM-Timestamps ist übrigens unter https://ruban.de/DB2_for_z_OS/z_OS_Code/DB2_z_OS_Code_-_Detail_View/db2_z_os_code_-_detail_view_6.html zu finden.

    3. April 2009 um 6:50 Uhr #4527

    Anonym
    Inaktiv

    @ Alexander:

    Du kannst auch einfach

    S ELECT TIMESTAMP(X’C3F3567F9C830000′) FROM SYSIBM.SYSDUMMY1;

    schreiben. Die andere Schreibweise war nur, um die RBA ( 6 Stellen) von den zwei übrigen Stellen abzugrenzen

    3. April 2009 um 9:39 Uhr #4540

    Anonym
    Inaktiv

    ähm, also !! hab ich schon mal gesehen, aber gestern hat das irgendwie nicht hingehauen *schäm*

    liegt auch offensichtlich daran, dass die LRSN/START_RBA einen anderen Aufbau im Format bzw. eine andere Umrechnung benötigen, als der PC-Timestamp im DBRM…

    bei X’C3F3567F9C830000′ macht meine Funktion nämlich die Grätsche, weil der String umgerechnet 20 Stellen Dec gross ist und damit Cobol nicht mehr arbeiten und DB2 nicht mehr rechnen kann (interne Formate) kann. Die REXX-Prozedur hat einen TS im Nov2773 berechnet …

    @Gernot, so eine REXX-Funktion haben wir natürlich auch. Wir haben aber kürzlich "Ungereimtheiten" bzgl. TS im DBRM und dem PC-Timestamp festgestellt (DBRM-TS <> PC-TS und trotzdem kein -812). Und da wollte ich eine Funktion, die mir im DB2 den CONTOKEN in einen TS umwandelt. (Zumal die REXX-Proc, die hier schon Jahre vor meiner Zeit verwendet wurde auch einen Fehler in der Berechnung hat)

    Eine Funktion, die den CONTOKEN in ein TS wandelt, gibts aber doch nicht, oder??

    Zu den Ungereimtheiten später mehr… will die Experten da auch noch ins Grübeln bringen.

    Grüsse
    Alexander

    3. April 2009 um 10:56 Uhr #4545

    Anonym
    Inaktiv

    Alexander wrote:
    (DBRM-TS <> PC-TS und trotzdem kein -812)

    -812 würde mich wundern. Du meinst wohl -805 oder -818 ?

    3. April 2009 um 11:08 Uhr #4547

    Anonym
    Inaktiv

    *grml* natürlich… Und eigentlich meine ich auch, dass der TS im Load <> zu dem PC-TS im Package war und es trotzdem lief …

    ist schon ganz schön warm heute 😎

    3. April 2009 um 18:55 Uhr #4549

    Anonym
    Inaktiv

    Hallo Alex,

    das kann ich mir beim besten Willen nicht vorstellen. Wäre es nicht möglich, dass das Package mit einer anderen VERSION und dem gesuchten Consistency Token existiert?

    Halt uns auf dem Laufenden!

    Ciao
    Gernot

  • Author
    Posts
Ansicht von 11 Beiträgen - 1 bis 11 (von insgesamt 11)

You must be logged in to reply to this topic.