ANALYSE DES AUFRUFSTAPELS

 

Falls Sie F9 in der "Job Performance Summary"-Auswertung drücken und dabei den Cursor auf einen

Job positioniert haben der viele Resourcen verbraucht hat, wird eine Auswertung ähnlich der Folgenden erscheinen. Sie zeigt u.a. für jeden HotSpot (ganz links wird Datum/Zeit dargestellt) die letzten 5 Programme/Module im Aufrufstapel.

Am interessantesten ist wahrscheinlich die Zeile ganz unten in pink, mit der Prozentdarstellung, wie oft jedes Programm in einer Datensammlung aktiv war. Hier sehen wir, dass in 30% der Fälle QDBPUT (= nicht geblockte Schreibzugriffe) und in 25% QWCCCHVC gefunden wurde. Aber was ist QWCCCHV? Positionieren Sie den Cursor auf den Namen und drücken Sie F4, schon erscheint der Objekttext in der Nachrichtenzeile!

 

GiAPA - CALL STACK S

 

Manche Zeilen teilen uns mit, dass kein Aufrufstapel verfügbar war - dies passiert, wenn der Job "unter dem MI Level" arbeitet, typischerweise wenn SQL oder Querys laufen. Die Job Funktion zeigt uns aber

für diese Zeilen, dass der Query einen Index erstellt (und somit potentielle Einsparungen durch das

Erstellen eines permanenten Index, der für den Query oder SQL geeignet ist).

Falls wir F14 drücken, werden die Daten generiert um die pinkfarbene Zeile in grafischer Form zu zeigen.
 

GiAPA - CALL STACK P

 

Als wir in den Programmcode schauten schien es, als ob die Data-Area-Updates (QWCCCHVC) die

"Local Data Area" modifizieren - der Entwickler dachte, dass dies keine Schreibzugriffe auf die Platte verursachen würde. GiAPA konnte dokumentieren, dass diese Annahme falsch war - es wurde hier eine Optimierung von rund 25% möglich, nur durch die Verwendung eines speicherresidenten User-Space anstatt der LDA.

Weiterhin entdeckten wir, dass man beim Schreiben der Ausgabedatei das Blocking erzwingen könnte, sodass QDBPUTM (M für multiple) dann QDBPUT ersetzt. Im Gesamten konnten wir rund ¾ der hier dokumentierten Gesamtlaufzeit einsparen.

Um eine Analyse zu bekommen wie oft die unterschiedlichen Aufrufstapel gefunden wurden, geben wir ganz oben "*" in der oberen Auswertung ein und drücken die DATENFREIGABE. Hier das Ergebnis:

 

GiAPA - CALL STACK A

 

Wir sehen, dass uns der Aufrufstapel QWCCCHVS 30 Mal anzeigt. Weil QWCCCHVC nur einmal gelistet ist, wird es immer vom selben Programm aufgerufen. Um zu sehen wie der gesamte Stapel aussieht, positionieren wir den Cursor und drücken F11 um die nächste Auswertung zu sehen:

 

GiAPA - CALL STACK ALL

 

Unser Programm PAY381R macht die Data Area Updates im Statement 43. GiAPA sagt Ihnen nicht "Ändern Sie Statement 43 von xxxxx zu yyyyy" - aber ganz sicher zeigt es Ihnen exakt, welches Statement, innerhalb welchen Programms, die Resourcen verbraucht. Entwickler sollten keine Probleme haben zu erkennen das, falls das Statement durch etwas effizienteren Code ersetzt werden könnte,

dann …

Falls es sich um einen multi-threaded Job handelt (typisch für JAVA), wird der Aufrufstapel nicht sofort angezeigt: Hier muss man zuerst den Thread auswählen für den man den Stapel sehen will.

 

GiAPA - CALL STACK M

 

Thread 16 verbraucht bei weitem die meisten Resourcen, deshalb selektieren wir diesen Thread mit C für (chronologisch) und bekommen eine Auswertung ähnlich der obigen:

 

GiAPA - CALL STACK C

 

Falls wir die Ergebnisse der pink dargestellten Zeile in einem Balkendiagramm sehen möchten, drücken wir F14 um die Daten vorzubereiten und rufen das Chart mit der Option 27 aus dem GiAPA Menü auf.

 

GiAPA - CALL STACK B

 

(Programme, die weniger als 2 % benutzt wurden, werden als Gruppe *OTHER angezeigt.)