Anzahl der Host-Variablen geringer als die Ergebniswerte.

[Fuerchau]

Vielleicht hat Birgitta eine Idee. Ggf. kannst du auch mal bei den Exit-Points (WRKREGINF) nachsehen, ob es da welche gibt um SQL-Meldungen abzufangen und zu reagieren.

[BenderD]

Vielleicht hat Birgitta eine Idee. Ggf. kannst du auch mal bei den Exit-Points (WRKREGINF) nachsehen, ob es da welche gibt um SQL-Meldungen abzufangen und zu reagieren.

... zuerst mal Journale, da kann man über den Timestamp der Meldung sehen wer da auf was losgeht (ist ohnehin ein klassischer Kunstfehler, wenn man nicht journalisiert). Database Monitor ginge auch noch, ist aber aufwändiger. Wenn der Job noch läuft, bzw. auf dem Fehler steht, geht auch noch call stack.

D*B

[urrumpel]

OK - Danke. Via Journalen suchen kam mir nicht in den Sinn. Das gehe ich jetzt mal an.
Call stack geht nicht, das das PGM weitergelaufen und nicht auf dem Fehler stehengeblieben ist.

[BenderD]

... aus dem Joblog kriegst Du Jobnummer und Name, mit denen Du beim DSPJRN und nach Zeit eingrenzen kannst. Wenn man die Open close Operationen mit journalisiert (was ich stets empfehle) kriegt man ein ziemlich genaues Bild, was da abgeht.

D*B

[Fuerchau]

Leider werden SQL-Fehler nicht als Escape gesendet, ein Programm bleibt da nicht stehen.
Meist werden Fehler nicht erwartet und nicht erwartete Fehler kann man ignorieren.