Call Stack Dump/Log

[Fuerchau]

Wenn das Programm aktiv ist, dann hilft ggf. der Callstack überhaupt nicht weiter.
Du musst ggf. die Anzahl Dateizugriffe beobachten (DSPJOB->Auswahl 14).
Ich habe es schon erlebt, dass Programme zigtausende Sätze verarbeiten müssen um irgendeine Prüfung durchzuführen.
Bei kleineren Systemen kann dies schon mal einige Zeit in Anspruch nehmen.

Ist die Anwendung in SQL geschrieben ?

Dann könnten die SQL's ggf. nicht sehr performant laufen (fehlende Zugriffswege).

API's helfen da auch nicht immer weiter.
Zumal du ja das API zum Sammeln der Daten auch mehrfach aufrufen musst.

Sicherlich gibts auch Tools dafür.

Aber beobachte einfach mal in einer solchen Situation den Job (Auswahl 14) und die Anzahl Dateizugriffe (F5).

[ChrisX]

Erstmal vielen Dank für die Info.

Ich habe den aktuellen Job eines Anwenders bei dem häufig diese Probleme auftreten mal angeschaut mit der Auswahl 14. Bei Open data paths stand dort 676. Ich werde aber sobald das problem erneut auftritt nochmals nachschauen. Leider weiss ich nicht ob dies eine kritisch hohe Zahl ist oder nicht.

Die Anwendung ist in SQL geschrieben und ich habe auch schon den database monitor laufen lassen. Die Auswertung wurde auch bereits an das applikations team geschickt. Dort wurde die Erstellung von einigen Zugriffspfaden empfohlen. Soweit ich aber weiss müsste ich dann bei dem entsprechenden Job auch sehen dass er einen index aufbaut, dies war jedoch nicht der Fall, oder irre ich hier?

Zum auslesen des Call stacks gibt es shareware tools, ich wollte jedoch vom Einsatz solcher programme absehen ^^

Mein Problem ist letzenendes, dass ich nicht genau weiss was in den 5-6 Minuten während der Anwender auf den nächsten Bildschirm warten muss passiert. Ich suche nun nach einem Weg relativ genau herauszufinden was sich während dieser Zeit abspielt, da das Applikationsteam behauptet es wäre kein Fehler ihrer Seite.

Danke nochmal für weitere Tips und Anregungen.

Gruss
Chris

[Fuerchau]

676 geöffnete Dateien sind ja doch schlicht der Hammer.

Wenn SQL im Spiel ist, dann kannst du eine QAQQINI erstellen und die Joblog-nachrichten analysieren.

Control queries dynamically with the query options file QAQQINI

Das Attribut MESSAGES_DEBUG schreibt dann entsprechende Nachrichten.

Indizees werden nicht immer aufgebaut oder verwendet, wenn z.B. eine Join-Beziehung keinen Index erlaubt (z.B. Typänderungen).

Da hilft nur tatsächlich eine Anpassung der Anwendung.

Ggf. hilft mal ein PRTSQLINF des jeweiligen Programmes.

Dann sieht man die SQL's und kann sie mal per STRSQL im Debug-Modus ausprobieren.