| |
Aufzeichnung der Programm- und Unterprogramm-Aufrufe unter z/OS
z/OS Anwendungen bestehen in der Regel aus einem Geflecht von einigen Hundert Programmen, die sich wechselseitig dynamisch oder statisch aufrufen. Sie werden von Trägersystemen wie CICS oder IMS im voraus geladen (preloaded) oder von Compilerfunktionen im Speicher gehalten. Es ist daher schwierig festzustellen, welches Programm aus welcher Bibliothek von einem anderen aufgerufen wird. Diese Aufgabe löst P-Tracker.
Wer braucht P-Tracker?
Informationen über die Verwendung von Programmen ist in unterschiedlichen Bereichen von Bedeutung.
- Für Verrechnung und Nutzenbewertung der Hard/Softwarekomponenten eines Rechenzentrums ist es wichtig, zu wissen, welche Nutzer oder Nutzergruppen bestimmte Anwendungen wie oft in Anspruch nehmen ("Asset Management").
- Ein
Wartungsprogrammierer möchte wissen, welche Programme ein zu änderndes
Modul aufrufen oder, welche Module "relinkt" werden müssen, weil ein
Submodul geändert wurde.
- Bei
Inventurmaßnahmen ist es von Interesse zu wissen, welche Member einer
Bibliothek seit längerem nicht mehr benutzt wurden. Es gibt also verschiedene Bereiche, die Call-Info benötigen und es scheint deshalb sinnvoll, mit ein und demselben Werkzeug alle Bereiche zu versorgen und damit die Datenhaltung zu optimieren und den CPU-Overhead zu reduzieren.
|
P-Tracker integriert die verschiedenen Aspekte in einem Paket. Er beantwortet viele Fragen mit seinen eigenen Reports und kann andere nachgeordnete Pakete versorgen oder DB2 Tabellen für individuelles SQL erstellen.
Funktionsweise
P-Tracker protololliert bei geringstmöglicher Systembelastung sämtliche Programmaufrufe unter IMS, CICS und Batch. Zu jedem Aufruf werden das rufende Programm, das gerufene Modul und die jeweils zugehörigen Bibliotheken festgehalten.
P-Tracker benutzt zur Verfolgung von Programm-Aufrufen u. a. die SAF-Schnittstelle. Dort wird auf Aktivitäten der Klasse PROGRAM abgeprüft. P-Tracker erhält den TIOT-Offset des rufenden Programms - die TIOT enthält alle DD-Namen des Jobs - woraus sich der Membername und Programmname eindeutig ermitteln lassen. P-Tracker kann individuell angepasst werden, um zum Beispiel nur Aufrufe für bestimmte Bibliotheken zu behandeln.
Unter CICS wird normalerweise nur gesehen, dass CICS ein Programm lädt. Dieser Zeitpunkt kann vom tatsächlichen Verwendungszeitpunkt des Programms abweichen. P-Trackers CICS Interface sorgt dafür, dass die tatsächliche Aufrufreihenfolge festgestellt wird.
Die Started Task P-Tracker sammelt die Informationen in einem Dataspace und leert diesen von Zeit zu Zeit in P-Trackers Call Repository. Ein JOB zur Nachverarbeitung entfernt interne Verwaltungsinformationen, konvertiert die Felder in ein lesbares Format und kopiert die Nutzdaten in eine sequentielle Datei. Diese kann unmittelbar ausgewertet oder zur Auswertung per SQL in eine DB2-Tabelle geladen werden.
Die Stärken des Systems P-Tracker:
- Unterstützt IMS, CICS, Batch
- Geringe Systembelastung
- Liefert beide Modulnamen und beide Bibliotheken
- Gibt verlässlichen Input für Repositories, Inventursysteme und Lizenzverwaltung.
P-Tracker bietet mehr
Dynamische, tabellengesteuerte Aufrufe sind nicht durch Code Analyse feststellbar. Die Anwendungsprogrammierung profitiert von der lückenlosen Aufzeichnung der Call- Sequenzen durch P-Tracker. Ein eventuell vorhandenes Repository wird durch P-Tracker ergänzt bzw. "gefüllt". Fragen wie, welche Programme aus welcher Bibliothek verwenden dieses Modul, können mit P-Tracker zuverlässig beantwortet werden (Baumstruktur der Call- Sequenz). Lizenzverwaltung (Software Asset Management) braucht exakte Angaben zur Nutzungshäufigkeit bestimmter Software. P-Tracker ermittelt, welche Programme wie oft und von wem benutzt werden. Unter OS/390 ist P-Tracker dafür die verlässlichste Quelle. Hin und wieder ist Inventur und Reorganisation nötig. Durch Abgleich der P-Tracker Ausgabe mit den Bibliotheken erhalten Sie die Namen der im Beobachtungszeitraum nie benutzten Programme.
|
|
Plakat als PDF
|
