Die Datenverarbeitung, seit Jahren ein wichtiger Bestandteil der Wirtschaft, steht im Budget der Anwender auf der Kostenseite. Für die Berechnung und die Verteilung der entstehenden Kosten auf Kostenträger braucht man zunächst Informationen über den Ressourcenverbrauch der einzelnen Benutzer, die man dann zur Verrechnung der Kosten 'sinnig' verteilt, bzw. für andere Aspekte wie zum Beispiel Kapazitätsplanung geeignet anordnet (Workloads). Seit Jahrzehnten werden bei z/OS Mainframes zu diesem Zweck die SMF/RMF Daten ausgewertet. Die dafür verwendeten Programme sind "in die Jahre gekommen" und weisen naturgemäß einige Altersschwächen auf.  Sie sind teuer. Zu teuer hinsichtlich der Lizenzkosten und zu teuer in der Anwendung. Die Umstellung auf neue Programm-Versionen bindet Mitarbeiter, die ständige Pflege erfordert zu viel Aufmerksamkeit. Aus heutiger Sicht ist ihr Ansatz viel zu breit ausgelegt. Tausende von Variablen werden täglich, monatlich durchfräst, um dann zu einer Ausgabe zu führen, für die ein Bruchteil des Aufwandes auch ausgereicht hätte. Dabei sind die Schnittstellen zur Datenübergabe immer noch unzureichend, siehe das Thema, 'Integration Mainframe mit dem Rest der Welt'. Ihre graphischen Fähigkeiten sind beschränkt oder wenn sie ausreichend sind, teuer erkauft. Die Laufzeiten für die täglichen, monatlichen Jobs sind enorm lang. Mit anderen Worten, der Berg kreißt und gebiert ein Mäuslein, Monat für Monat.
Bei der Entwicklung des Trackers verfolgten wir folgende Ziele: - Das Nötige liefern, das Unnötige weglassen.
- Einsatz moderner, effizienter Mittel: C Programme zur Extraktion der Daten aus den SMF/RMF-Dumps, DB2 Tabellen zur Speicherung der relevanten Daten, SQL/REXX zur Datenverwaltung, direkte grafische Ausgabe auf PC.
- Geringer Wartungsaufwand, geringe Systembelastung, Schnelligkeit
- Geringe Lizenzkosten.
Tracker gibt es als SMF-, RMF- und IMF-Tracker. So umfangreich die täglichen Dumps dieser Protokolldaten auch sind, nicht alle Fragen können mit ihrer Hilfe beantwortet werden. So ist der Bereich "Asset Management", d. h. Fragen: Wie häufig und von wem, in welcher Version, werden bestimmte Applikationen benutzt, mit SMF kaum zu beantworten. Auch das verwandte, mehr technische Thema "Inventory" , also die Frage, welche Module in den vielen Bibliotheken werden wirklich aufgerufen, d. h. sind noch aktiv, kann mit SMF nicht beantwortet werden. Zur Behandlung der Schwerpunkte "Asset Management" und "Inventur" sowie verwandter Fragestellungen gibt es den Programm-Tracker, kurz P-Tracker. Über die SAF-Schnittstelle des z/OS erkennt P-Tracker Programmaufrufe und protokolliert sie in DB2-Tabellen mit Attributen wie Programm-Name, Bibliothek (PDS), Anzahl der Aufrufe seit, usw. Das vorliegende Dokument behandelt nur die Themen SMF, RMF und IMF. Informationen zu P-Tracker erhalten sie über Ihren Distributor.
Funktionen des Trackers
Zur Optimierung des Mitteleinsatzes muss sichergestellt werden, dass Größe und Leistungsfähigkeit der verwendeten Rechner, der zu bewältigenden Arbeitslast (Workload) entspricht. Die Messung der Arbeitslast und die Ermittlung der Auslastung der Anlagen ist Grundlage für die Kapazitätsplanung.
Unter dem Betriebssystem z/OS liefert Tracker die benötigten Daten für Kostenverrechnung (Accounting) und Kapazitätsplanung und hilft bei der Auswertung, Interpretation und Darstellung dieser Daten.
Die Roh-Daten werden aus "System Management Facility (SMF)", "Resource Management Facility (RMF)" und verschiedene Logs, die teils von Anwendungssystemen selbst, teils von speziellen Monitoren (IMF) geschrieben werden, extrahiert. Diese Quelldaten haben meist eine komplexe Satzstruktur und benutzen die unterschiedlichsten Feldtypen zur Zeiterfassung und -messung: CPU-Zeit in sec, millisec, nanosec, timestamp, etc.
Tracker extrahiert die nötigen Information aus den verschiedenen Quellen, vereinheitlicht Darstellung und Skalierung der Felder und schreibt die Daten in DB2-Tabellen. Mit wenigen SQL-Anweisungen können die so bereitgestellten Daten in Verrechnungssysteme übernommen oder direkt ausgewertet werden. Informationen und Datenquellen
Für Accounting ermittelt Tracker u. a. folgende Daten: CPU-Zeit pro Batch-Job, CPU-Zeit pro CICS-Transaktion einschließlich des zugehörigen Verbrauchs unter DB2, und die CPU-Zeit pro IMS-Transaktion; sowie die Anzahl der gedruckten Seiten bzw. Zeilen pro Job, pro OUTPUTCLASS und pro OUTPUT Subsystem. Aus dem Bereich TCP/IP können Daten zu, FTP, HTTP und Telnet bereitgestellt werden.
Für die Kapazitätplanung ermittelt Tracker die Gesamtauslastung, die Auslastung pro Service Class und die Güte der Zielerfüllung gemäß "Goals". Die dafür nötigen Daten stammen aus SMF, RMF und MVIMS-Log.
Bestandteile des Trackers
Die Aufgabe besteht aus drei Teilen, der Sammlung der Daten, bzw. ihrer Extraktion aus den Dumps (SMF, RMF) und Logs (IMS), der Zuordung des erfaßten Verbrauchs zu Benutzern, Kunden, Mandanten, Kostenstellen, etc, und drittens der Aufbereitung und grafischen Darstellung.
Extractor extrahiert die Daten aus Dumps und Logs, homogenisiert die Felder - zum Beispiel werden alle Zeiten auf Sekunden skaliert - und schreibt DB2-Tabellen.
Correlator bildet den erfassten Verbrauch auf die Org-Struktur (Abteilungen, Kostenstellen, Mandanten,etc) ab. Naturgemäß ist der Correlator stark vom Umfeld des Anwenders abhängig und erfordert einige Anpassungsarbeit bei der Implementation. Der Correlator stellt einen Werkzeugkasten (Toolbox) dar, mit dem eine reguläre Verarbeitung, in der Regel eine monatliche, so aufgebaut wird, dass ein wartungsfreier Betrieb möglich ist.
COM-Server ermöglicht die Kommunikation zwischen DB2 und Workstations(PCs) über TCP/IP.
Viewer ist das Java-Programm zur Auswahl und Darstellung von Tabellen und Grafiken auf einer Workstation (PC), es kommuniziert über COM-Server mit DB2.
Extractor Das C-Programm 'Extractor' liest SMF/RMF- und andere Roh-Daten und schreibt DB2-Tabellen. Pro Verursacher wie Job oder Transaktion werden Verbrauchswerte zu CPU-Zeit und Druckseiten/zeilen ermittelt und mit ihren Identifikationsmerkmalen in DB2 Tabellen eingefügt. Diese Tabellen werden im Folgenden Basistabellen genannt, zur Unterscheidung von den Verwaltungstabellen, die der Anweder zur Verfügung stellt. Die Verwaltungstabellen enthalten Informationen zu Kostenstellen, Benutzergruppen, Mandanten usw. Aus RMF werden Felder zum Workload und zur CPU-Auslastung pro Performancegruppe und zur 'Goal' -Erfüllung ermittelt. Der Extractor ist ein Batchjob, der in die reguläre Verarbeitung der entsprechenden Rohdaten einzubetten ist. Damit eine lückenlose Datenversorgung gewährleistet wird, sollte er regelmäßig, möglichst durch einen Scheduler gesteuert, ausgeführt werden.
Der Extractor verarbeitet u.a. folgende Satztypen: - Typ 6 alle Subtypen - Druck (Print)
- Typ 70 - Resource Monitoring Facility (RMF)
- Typ 72 - RMF Service Klassen bzw. Program Gruppen
- Typ 110 - CICS Performance Record
Da der Ressourcenverbrauch der CICS Systeme in der Regel über den Satztyp 110 ermittelt wird, können die entsprechenden Sätze bei der Ermittlung der Batchlast, Satztyp 30, ausgefiltert werden. Ähnliches gilt für IMS. Wird der Verbrauch von IMS über IMF Sätze ermittelt, können die entsprechenden 30-er Sätze übersprungen werden. Der Benutzer kann das diesbezügliche Verhalten des Extractors durch eine Optionliste steuern.
Bei vielen Systemen hoher Aktivität können große Datenmengen anfallen, die dann zu einer erheblichen Anzahl von DB2 INSERTs führen. Um das Ladeverhalten zu optimieren, kann der Extractor statt INSERT das DB2 Load Utility aufrufen. Der Extractor erzeugt dann die Ladekarten und ruft das Utility, wenn gewünscht, mit 'LOG NO'.
Correlator Der 'Correlator' erfüllt u. a. folgende Funktionen:
- Er ordnet den Ressourcenverbrauch von Jobs und Transaktionen anhand der jeweiligen Kennungen wie Jobname, Accountingfelder, UserID, Transaktionsname und Programmname den betrieblichen Organisationseinheiten, Mandanten oder Arbeitsgebieten zu. Er stellt damit gewissermaßen den internen oder externen Auftraggeber fest und ordnet den beobachteten Verbrauch diesem zur späteren Rechnungsstellung oder Verrechnung zu.
- Er führt Datenverwaltungfunktionen aus. Meist sind die Daten der Basistabellen nur für einen bestimmten Zeitraum relevant. Der Correlator löscht deshalb "alte" Daten, lagert sie aus, lagert sie bei Bedarf wieder ein, oder komprimiert sie.
Die Funktionen des Correlators sind eng mit der Betriebsstruktur des Anwenders verknüpft. Kostenstellen-, Kunden- oder Mandanten-Listen werden benötigt. Mit Hilfe des Correlators können kundenspezifische Verwaltungstabellen für Mandanten, Kostenstellen, Nutzergruppen, usw. unter DB2 editiert oder regelmäßig von externen Quellen, zum Beispiel von SAP, eingelesen und fortgeschrieben werden. Der Correlator ist keine geschlossene Lösung, sondern ein Code-Beispiel nach dem der Anwender seine eigenen Abläufe mittes SQL und Rexx erstellt.
Wir bieten Schulung und einführende Unterstützung an, was immer dann zu empfehlen ist, wenn die Betreuerin oder der Betreuer des Verrechnungssystems noch keine Erfahrung mit SQL oder DB2 hat. UBS kann bei der Erstellung des Correlators zum Festpreis tätig werden.
|
