SQL liefert im Batch bei sum-Funktion nur 0-Werte

[micha_ms]

Hier (m)ein erstes Posting - daher zunächst der "Hallo-hier-ist-ein-Newbie"-Gruß an die Forumsteilnehmer: Ich bin Programierer im PC-Office-Umfeld und darf meine SQL-Kenntnisse auf eine DB/2 loslassen. "AS/400" war bis vor wenigen Wochen eine lose Aneinanderreihung von Buchstbaben und Zahlen. Sorry...

Zur Sache. Ich beobachte folgende Kuriosität: Eine Tabelle wird über ein SQL-Statement per insert gefüllt. Der Befehl selbst beinhaltet mehrere Felder, die aus einer View stammen und per Join mit anderen Tabellen zusammengefasst werden. Das ganze sieht dann (vereinfacht) etwas so aus: insert into biblio/tabelle (select feld1, feld2, sum(feld3), ....from...)

Dieser SQL-Befehl läuft im Rahmen eines kleinen CL-Programms per Scheduler täglich des Nachts und die Summen-Funktion "sum(feld3)" liefert alle paar Tage ohne erkennbaren Grund für alle in die Zieltabelle geschriebenen Datensätze lediglich eine "0"?! Dieses ist definitiv falsch, da die Ursprungstabellen Werte enthalten und auch die direkte Ausführung des SQLs liefert stets korrekte Werte in die Zieltabelle = die SQL-Syntax ist also defnitiv okay. Zu dem stehen in allen anderen Feldern stets die richtigen Inhalte. Das die "0" geliefert wird, ist nicht reproduzierbar und weder im Intervall wiederkehrend, noch sonst erkennbar beeinflusst. Allerdings tritt das Phänomen alle paar Tage nur bei der zeitgesteuerten Batchausführung (wrkjobscde) auf. Auch eine Änderung der Start-Uhrzeit half hier nichts.
Bitte nicht "veräppelt" fühlen - dies ist wirklich (m)ein reelles Problem...

Dank + Gruß,
Michael aus Münster.

[MKnoll]

Hallo Micha,

kann es vielleicht möglich sein, daß sich der Lauf deines Programms mit anderen Programmläufen (z.B. Nachtverarbeitung) überschneidet, welche das Feld3 in der Ursprungstabelle erst befüllen ?
Soll heißen:
Während Dein SQL läuft ist Feld3 noch leer ...., wenn Du morgens nachschaust aber nicht mehr.

Sonst wüsste ich so ausm Stehgreif auch nichts ...

Gruß Mirko.

[Bernd Wiezroek]

Bei mir liegt es meist am Cl Programm wenn das Sql nicht tut was es soll.
Wie sieht das Cl aus?
Wenn das SQL z.B. über qmqry aufgerufen wird ist die Parameterübergabe manchmal etwas heikel.

[Thimi]

Hi Michael,
schau doch Dein Joblog. Vielleicht gibt es 'ne Fehlermeldung?

Schönes Wochenende und Gruss aus HH
Thierry

[micha_ms]

Hallo und danke für die Hinweise. Leider haben diese das Problem nicht gelöst...

Im Rahmen der Batchverarbeitung werden aus einem "Haupt-CL" diverse einzelnen CLs aufgerufen, die wiederum die eigentlichen SQL-Aufrufe enthalten. Im speziellen Falle ist der Aufruf mittles "STRQMQRY QMQRY(BIBNAME/SQLNAME)" aber eher unspektakulär und ohne Parameter somit auch sicherlich unproblematisch. Die davor und danach kommenden Aufrufe sind ebenfalls von dieser einfachen Struktur.

Ich habe am Wochenende sehr gewissenhaft und ausführlich die Abläufe kontrolliert und kann sicherstellen, das das o. a. feld3 zum Zugriffszeitpunkt korrekt und komplett gefüllt ist und das keines der nachfolgenden SQLs die Zieltabelle wieder auf die 0-Werte abändert.

Dieses Wochenende war es dann aber auch wieder soweit: das beschriebene Fehlverhalten trat auf - das JobLog ist völlig ohne Hinweis oder negativem Eintrag und - oweh - inzwischen beobachte ich selbiges Verhalten auch in einer Verarbeitung mit einer ganz anderen Tabelle und Bibliothek. Scheinbar ein generelles Problem auf unserer Maschine und somit wohl ein Fall für einen IBM-Call?!

Grüße,
micha_ms.

[B.Hauser]

Hallo micha_ms,

prüfe als aller erstes, ob alle PTFs für die Datenbank geladen sind.
Sollten PTFs fehlen, so schnell wie möglich besorgen und installieren!
Ich denke hier liegt das Problem.

Welches Release habt ihr überhaupt?
Habt ihr vielleicht kürzlich einen Release-Wechsel vorgenommen?
Tritt das Problem schon länger auf?

Tritt das Problem auch dann auf, wenn Du das QMQuery interaktiv ausführst?

Birgitta