View Full Version : Anzahl der Host-Variablen geringer als die Ergebniswerte.
Hallo.
Im JOBLOG sehe ich
Anzahl der Host-Variablen geringer als die Ergebniswerte.
Leider sehe ich nirgends von welchem Programm das verursacht wird.
F1 dann F9 auf die MSG bringt QSQRUN2.. was mir nicht weiter hilft.
Gibt es eine Möglichkeit, das 'zuständige' PGM zu ermitteln?
Und die gleiche Frage stellt sich für die Nachricht
Indikatorvariable erforderlich.
Nein, das gibt es leider nicht. Hier hilft wirklich nur der Debugger. Wenn man seine Anwendung kennt, "weiß man" halt wo man suchen muss.
Danke. Das ist nicht schön. Das PGM ruft X Programme und 1000e von Daten auf. Dann gehe ich mal ans einkreisen.
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.
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
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.
... 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
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.
RobertMack
13-04-21, 15:26
Anzahl der Host-Variablen geringer als die Ergebniswerte.
Das riecht irgendwie nach einem Select * from GeänderteDatei into FestCodierteDS ...
Das riecht irgendwie nach einem Select * from GeänderteDatei into FestCodierteDS ...
... auch das ein Kunstfehler. Alle SQL Zugriffe gehen ausschließlich auf Views, die sich nie ändern und stets mit select * unter Verwendung externer Datenstrukturen. Zusätzliche Felder o.ä. werden in neuen Views sichtbar - voila.
D*B