So, erstmal wieder Vielen Dank für die Informationen!

@Fuerchau: Das mit der QAQQINI hört sich interessant an, werde versuchen dies mal umzusetzen. Wenn ich mir andere Jobs anschaue sehe ich eigtl. im Schnitt meist 500-600 open data paths. Eher selten, dass die zahl hier bei 100 oder weniger liegt. Das Problem ist, dass ich nicht genau weiss welches Programm die "Verzögerung" produziert, daher weiss ich auch nicht auf welches Programm ich ein PRTSQLINF machen sollte. Mein Gedanke war ja hier dass ich den Callstack auslese/dumpe um dies herauszufinden.

@holgerscherer: Das Verhalten ist nur in bestimmten Anwendungsbereichen sichtbar. Bei dem betroffenen Anwenderpool betrifft es beispielsweise nur den Order Entry. Alle anderen Funktionen/Abfragen laufen laut Anwender performant. Nur bei der Auftragseingabe kommt es sporadisch zu "unakzeptablen" Verzögerungen. Man kann leider auch nicht sagen dass es ein dauerhaftes problem ist. Es gibt auch zeiten (unregelmäßig) zu denen es akzeptabel läuft.

WRKSYSACT habe ich auch schon öfter mitlaufen lassen. Es besteht zwar häufig eine hohe CPU Last, jedoch meist auch durch BATCH Jobs und nicht INTeraktiv. Es ist mir auch noch nicht aufgefallen dass die CFINT0X jobs versuchen Kapazität zu sperren. Auch im QSYSOPR Log gibt/gab es bisher keine Einträge darüber dass die Interaktive Leistung überschritten wurde. Generell bin ich auch der Meinung, dass eigtl. fast jeder Anwender Performance Probleme haben müsste, wenn das System am Limit mit seinen Resourcen wäre. Es betrifft aber wirklich nur Mitarbeiter welche mit Order Entry beschäftigt sind. Zumindest haben sich bisher noch keine Anwender in anderen Bereichen mit den gleichen Problemen gemeldet.

@jo400: Wenn diese probleme auftreten rufen mich die Anwender meist direkt an. Ich beobachte dann generell den job status. Es kam zwar vereinzelt mal vor, dass der Job ein kurzes Object Lock hatte (LCKW) aber dies war entweder kein Dauerzustand über die ganzen 5-6 Minuten noch habe ich das gefühl, dass mit den "kurz" auftretenden Lockwaits ein wirkiches problem besteht. Normalerweise hat der Job den Status RUN. Wenn ich in das Joblog schaue, sehe ich zum aktuellen Zeitpunkt (also wenn der Job hängt) meist nur den folgenden letzten Eintrag:

Open of member XXX was changed to SEQONLY(*NO).

Das ist meist der einzige Eintrag den ich sehen kann.

Die CPU Auslastung ist oft sehr schwankend, wobei die meiste CPU Zeit von BATCH Jobs mit PRIO > 20 gebraucht wird.

Meine Idee war, dass ich mit Hilfe des Call Stacks das Programm, welches aktuell "arbeitet" herausfinden kann um dann zu prüfen was dieses Programm genau macht und warum die Zeitverzögerung zustande kommt.

Laut Anwender wurde die performance über Monate hinweg immer schlechter.

Auch die Betreuer der Applikation habe ich schon darauf hingewiesen dass es mit BPCS Performance Probleme geben kann, wenn manche Dateien nicht reorganisiert werden. Aber hier hat eine Bereinigung auch nichts gebracht.

Noch eine kleine Info:
Das System wird monatlich IPLed und halbjährlich wird ein RCLSTG gefahren. Die Performance Analyse (Über die Performance Tools) ergab, dass die Disk Arms stark beansprucht sind. Der Systemwert QPFRADJ steht auf 2. Die Plattenplatzbelegung liegt momentan bei ca. 75%.

Danke schonmal + Gruss
Chris