Praxissemester bei IBM

Transkript

1 Praxissemester bei IBM Bericht zur Integrierten Praxisphase und dem begleitenden Literaturstudium Thomas Uhrig Matrikelnummer: Schwabstraÿe Stuttgart 25. März 2011 HdM Stuttgart Fakultät Druck und Medien Studiengang Medieninformatik Bachelor

2 Inhaltsverzeichnis 1 Das begleitende Literaturstudium SQL und prozedurale Erweiterungen SQL als Abfragesprache für relationale Datenbanken Prozedurale Erweiterungen Vorteile Nachteile DB2 und SQL/PL User Dened Functions in der DB2 Datenbank Beispiel einer User Defined Functions in SQL/PL Trigger in der DB2 Datenbank Beispiel eines Triggers in SQL/PL Stored Procedures in der DB2 Datenbank Beispiel einer Stored Procedure in SQL/PL Stored Procedures in DB2 (detailliert) Programmablauf einer Stored Procedure SQL/PL zur Entwicklung von Stored Procedures Methodenkopf und Rückgabeparameter Optionen Body Versionierung von Stored Procedures Entwicklungstools für Stored Procedures in DB Stored Procedures aus Java-Programmen heraus aufrufen Prozeduren anderer User nutzen Persönliche Bewertung von SQL/PL als Entwicklungssprache Nachteile Vorteile

3 Inhaltsverzeichnis 2 Das Praxissemester bei IBM Das Unternehmen IBM Die International Business Machines Corporation IBM Research & Development in Böblingen Meine Praktikumsstelle Bewerbung Beschreibung der Stelle Die Abteilung Problemstellungen und Lösungsansätze Der DB2 Performance Expert on z/os Das Test-Environment STAF/STAX Der DB2WorkloadService Das Framework Die Workloads Dokumentation Tests Integration in das bestehende Test-Environment Sonstige Aufgaben Tools und Technologien Eclipse und Java DB2 und SQL/PL z/os Sonstiges Persönliche Eindrücke Die IBM als Praktikumsstelle Persönliche Einschätzung des Lernerfolges

4 1 Das begleitende Literaturstudium Das Ziel meines Literaturstudiums, welches mein Praktikum in der IBM Böblingen begleitete, war die Aufbereitung des Themas prozedurale Erweiterungen in der DB2 Datenbank. Im Folgenden soll zunächst ein kurzer Überblick über die verfügbaren prozeduralen Erweiterungen in DB2 gegeben werden. Es soll geklärt werden was prozedurale Erweiterungen sind, wofür sie genutzt werden können und wie sie in DB2 anhand von User Defined Functions, Stored Procedures und Triggern zu nden sind. Danach soll am Beispiel der Stored Procedure eine prozedurale Erweiterungen genauer beleuchtet werden. Abschlieÿen möchte ich eine persönliche Bewertung von SQL/PL als Entwicklungssprache geben. 1.1 SQL und prozedurale Erweiterungen Datenbanken stellen in vielen Systemen und Softwarelösungen einen zentralen Bestandteil dar. Sie halten Lagerbestände, verwalten Konten oder katalogisieren Personen und Materialien. Für Firmen sind sie somit bares Geld, denn oftmals persistieren sie unternehmenskritische Daten. Daher gilt ihnen auch häug der Fokus in der Entwicklung von Applikationen für das Geschäftsumfeld. Aus der Sicht eines Softwareentwicklers sind Datenbank jedoch heutzutage weit mehr als reine Speicher. Denn längst bieten die meisten Hersteller von Datenbanksystemen, die Möglichkeit so genannte prozedurale Erweiterungen in ihren Produkten zu nutzen. So ist es möglich Geschäftslogik in diesen zu kapseln, Applikation in die Datenbank zu transferieren und damit Programmcode plattformübergreifend zu zentralisieren SQL als Abfragesprache für relationale Datenbanken Die bekannteste Abfragesprache für Datenbanken ist die Structured Query Language (kurz SQL). Sie ermöglicht es Daten mengenorientiert abzufragen bzw. zu manipulieren und hat sich als eine Art Quasi-Standard etabliert. SQL besteht dabei aus drei Teilgebieten: 4

5 1 Das begleitende Literaturstudium 1. Die Data Denition Language (DDL) ermöglicht es Datenbankobjekte zu denieren und zu erstellen. Sie bietet Befehle für das Anlegen von Tabellen, Views oder Schemata. Sie schlieÿt Befehle wie CREATE, ALTER oder DROP ein. >> CREATE TABLE MyTable ( value1 VARCHAR( 2 0 ) ) ; 2. Die Data Manipulation Language (DML) ermöglicht die Arbeit mit den eigentlichen Daten. Mit ihr können Daten in der Datenbank abgelegt werden oder nach Datensätzen gesucht werden. Zu ihr gehören beispielsweise die Befehle INSERT, SELECT oder DELETE. >> INSERT INTO MyTable ( value1 ) VALUES( ' t e s t ' ) ; 3. Die Data Control Language (DCL) fasst die Rechteverwaltung der Datenbank zusammen. Mit ihr lassen sich Nutzer und Rollen, erstellen und verwalten. Typische Befehle für sie sind GRANT und REVOKE. >> GRANT SELECT ON MyTable TO PUBLIC; Die Entwicklung von SQL begann Mitte der siebziger Jahre unter dem Namen SEQUEL (Structured English Query Language) im IBM San Jose Research Laboratory in Kalifornien 1. Ende der achtziger Jahre entstand mit SQL-86 der erste durch die ANSI und ISO genormte Standard folgte der Standard SQL-92. Bis zu diesem Zeitpunkt war die Structured Query Language eine reine Abfragesprache. Sie war eng an die mathematische Mengentheorie angelehnt und kannte keine Kontrollstrukturen wie sie in höheren Programmiersprachen zu nden sind. Mit ihr war es nur möglich Daten zu persistieren, abzufragen und zu ändern. Erste im Jahre 1999 wurden mit SQL:1999 (auch SQL3 genannt) prozedurale Konzepte eingeführt 2. Sie sind im so genannten SQL/PSM 3 ISO-Standard zusammengefasst. Dies ist einer von mehreren Teilen des heutigen SQL-Standards, wie etwa auch SQL/OLB 4 welcher die Einbindung von embedded SQL in Java beschreibt oder SQL/XML 5 welcher Erweiterungen für XML in SQL deniert Persistent Stored Modules 4 Object Language Bindings 5 XML-Related Specications 5

6 1 Das begleitende Literaturstudium Prozedurale Erweiterungen Die so genannten prozeduralen Erweiterungen sollen das relationale Konzept der Datenbanken um prozedurale Programmkonstrukte erweitern. Mit ihnen soll es ermöglicht werden, nicht nur Daten aus einer Datenbank abzufragen bzw. in einer Datenbank zu speichern, sondern auch Programmierlogik in die Datenbank zu legen. Sie erweitern das Konzept von SQL um Kontrollstrukturen, wie z.b. if -Konstrukte, while-schleifen oder Error-Handling. Die meisten Anbieter von Datenbank haben ihr eigenes Konzept bzw. ihren eigenen SQL-Dialekt zum Schreiben solcher Prozeduren entwickelt. So bezeichnet die IBM ihre SQL-Erweiterung als SQL/PL, Oracle als PL/SQL und Microsoft als T-SQL. Zwar unterscheiden sich diese Dialekte in ihrer Syntax und ihren Spracheigenschaften, jedoch ermöglichen sie die grundsätzlich selben Konzepte und Ausdrucksformen Vorteile Prozedurale Erweiterungen sollen den herkömmlichen SQL-Standard erweitern und so neue Möglichkeiten der Programmierung schaen. Mit ihnen soll komplexe Anwendungslogik (Geschäftslogik) in die Datenbank ausgelagert und dort zentral gebündelt werden. Dies soll verschiedene Vorteile mit sich bringen. Zentralisierter Code: Die Auslagerung von Anwendungslogik in die Datenbank, soll die Dublikation von Code in den Anwendungsprogrammen verhindern. Der Code liegt zentral an einer Stelle des Systems und kann so gemeinsam von verschiedenen Anwendungen genutzt werden. Einmal implementiert und eingerichtet, steht er somit allen Programmen oen, auch über Sprachgrenzen hinweg. Eine Java-Anwendung kann beispielsweise eine Cobol-Prozedur auf der Datenbank nutzen oder umgekehrt. Dies bleibt für das Programm und den Entwickler weitestgehend transparent. Des weiteren entsteht durch die Zentralisierung von Code ein so genannter Singel- Point-Of-Failure. Auf diesen kann im Problemfall schnell zugegrien werden, was die Fehlersuche und die Behebung des Problems erleichtert. Es muss kein Code mehr in unzähligen Client-Anwendungen gepatched werden - es reicht die Korrektur einer fehlerhaften Stelle in der Datenbank. Reduzierung des Netzwerkverkehrs: Die Auslagerung von Funktionalität in die Datenbank kann helfen den Netzwerktrac zwischen Client und Server drastisch zu reduziert. So müssen z.b. nicht mehr unzählige Datensätze für eine Berechnung zum Client durch 6

7 1 Das begleitende Literaturstudium eine Netzwerkverbindung übertragen werden. Die Berechnung kann direkt in der Datenbank stattndet, da durch Prozeduren auch komplexe Algorithmen abgebildet werden können. So muss lediglich ein Ergebnis übertragen werden. Performance: Datenbankprozeduren werden bei ihrer Erstellung compiliert und mit so genannten Ausführungsplänen in der Datenbank eingerichtet. Daher sind sie zum Zeitpunkt der Ausführung bekannt, die Datenbank ist sozusagen auf sie vorbereitet. Man spricht hierbei von statischem SQL im Gegensatz zum dynamischen SQL ( dieses wird erst beim Eingabezeitpunkt ausgewertet und ist zuvor nicht bekannt). Daher sind solche Prozeduren sehr performant und schnell. Sie eigenen sich daher insbesondere für aufwändige Berechnungen, wie sie sich beispielsweise im Datawarehouse-Bereich nden lassen. Sicherheit: Datenbankprozeduren können dazu dienen die Sicherheit in einem System zu erhöhen. Mit ihnen ist es möglich den Zugri auf bestimmte Objekte zu reglementieren und so das Rollen- und Rechtesystem einer Datenbank zu erweitern. Auÿerdem können sie dazu dienen auch komplexe Integritätsregeln für Datensätze zu prüfen und somit auch Sicherheit im Sinne von konsistenten Daten gewährleisten. Beispielsweise könnte das Einfügen eines neuen Datensätzen für jeden Datenbanknutzer grundsätzlich möglich sein. Je nach Rechtevergabe, könnte dann ein Trigger verschiedene Werte auch durch komplexe Algorithmen prüfen und entsprechend reagieren. So könnte das einfache Konzept von GRANT und REVOKE deutlich erweitert werden Nachteile Prozedurale Erweiterungen bringen jedoch auch Nachteile mit sich. Diese können je nach Anwendungsfall deutlicher ins Gewicht fallen als die Vorteile. Daher ist eine individuelle Abwägung nötig. Enge Kopplung: Die Auslagerung von Funktionalität in die Datenbank führt zu einer engen Kopplung des Softwaresystems an die konkrete Datenbank. Hieraus entstehen beiderseitige Verstrickungen. Sind Teile der Geschäftslogik in Form von Prozeduren in die Datenbank ausgelagert, kann diese nicht ohne weiteres ausgetauscht werden, da die Software auf sie angewiesen ist. Auÿerdem werden meist proprietäre Features verwendet, die sich stark von Hersteller zu Hersteller unterscheiden können. So kann die Datenbank nur schwer gewechselt werden. Mit zunehmender Nutzung der angebotenen prozeduralen Funktionen, entsteht eine zunehmende Abhängigkeit der Applikation zur Datenbank. 7

8 1 Das begleitende Literaturstudium Aufweichung von Zuständigkeiten: Eine Aufteilung der Geschäftslogik in Clientcode und Datenbankprozeduren führt zu einer Aufweichung von Zuständigkeiten. Eigentlich zusammengehörige logische Aufgaben werden voneinander getrennt und nden sich teils im Client und teils in der Datenbank wieder. Know-How: Für die Entwicklung solcher Systeme, sind nicht nur fundierte Kenntnisse der eigentlichen Programmiersprache der Clientanwendung nötig, sondern auch Kenntnisse der Datenbank über das herkömmliche SQL hinaus. Für den Entwickler bedeutet dies, dass eine weitere Sprache in einem Projekt verwendet wird. Auÿerdem kommen meist weitere, oft herstellerabhängige Entwicklungstools zum Einsatz. Damit wächst die Komplexität des Projekt. Es muss mehr Code gemanagt werden, das Deployment ist nicht mehr homogen und es kommen unweigerlich neue Tools und Konzept zu den bestehenden hinzu. 1.2 DB2 und SQL/PL Wie die meisten groÿen Datenbanken, so bietet auch die IBM Datenbank DB2 6 eine prozedurale Erweiterung an, die Structured Query Language/ Procedural Language (kurz SQL/PL). Diese erweitert das herkömmliche SQL um Kontroll- und Programmierstrukturen, so dass Funktionen und Methoden damit geschrieben werden können. Dies ermöglicht es prozedural und strukturiert in der Datenbank zu programmieren. DB2 bietet dabei drei grundlegende Arten von Funktionen. Zum Einen lassen sich so genannte User Defined Functions (kurz UDFs) erstellen. Diese werden als normale Datenbankobjekte angelegt und können dann in DML-Statements genutzt werden. Zum Anderen können Stored Procedures als gespeicherte Methoden in der Datenbank abgelegt werden. Sie können als eine Art eigenständige Programme aufgerufen und genutzt werden. Auÿerdem lassen sich Trigger anlegen, also Routinen die bei bestimmten denierten Ereignissen reagieren und ablaufen User Dened Functions in der DB2 Datenbank Als User Defined Function (kurz UDF) werden in DB2 Funktionen bezeichnet, welche in DML-Statements in SQL-Kommandos verwendet werden können. Diese müssen dabei nicht zwangsläug vom User angelegt werden. Die Datenbank bringt schon bei 6 8

9 1 Das begleitende Literaturstudium der Installation eine Reihe von voreingestellten UDFs mit sich, wie z.b. die sum(...)- Funktion um numerische Spaltenwerte zu addieren: >> SELECT sum ( ) AS SumOfRows FROM MyTable ; In der DB2 Datenbank gibt er drei grundsätzliche Typen von UDFs: 1. Sourced UDFs verweisen lediglich auf eine andere schon existierende Funktion. Sie lassen sich so als eine Art Wrapper Funktion verwenden, die beispielsweise einem User Defined Type für eine bereits bekannte UDF umwandelt. Auch können so verschiedene, je nach Anwendungsfall treendere Namen für UDFs vergeben werden. 2. SQL UDFs sind in SQL/PL geschriebene neue Funktionen. 3. External UDFs sind in einer anderen (höheren) Programmiersprache erstelle Funktionen. Sie können beispielsweise in C oder Java erstellt werden. Neben der Möglichkeit UDFs als Funktionen mit nur einem Rückgabeparameter zu erstellen, können auch Funktionen die ein gesamtes Result-Set 7 zurück liefern deniert werden. Man unterscheidet hierbei Scalar-Functions bzw. Table-Functions. Solche Funktionen können dann beispielsweise in der FROM-Klausel einer SELECT-Abfrage genutzt werden: >> SELECT FROM MyTable ( sqltablefunction ( ) ) nickname ; Beispiel einer User Dened Functions in SQL/PL Eine UDF in SQL/PL wird in der DB2 Datenbank durch den Befehl CREATE FUNC- TION angelegt. Sie erhält wie in anderen Programmiersprachen einen Methodenkopf mit Namen (hier MyFunction) und eine Liste von Eingabeparametern (hier zwei Integer- Variablen). Als Datentypen stehen dazu alle SQL-Datentypen zur Verfügung (z.b. IN- TEGER, VARCHAR oder CHAR). Anders als in Java oder C folgt dem Methodenkopf zunächst eine Liste von Optionen. Hier wird beispielsweise die Programmiersprache (z.b. SQL) und der Rückgabewert festgelegt. Den Optionen folgt nun der eigentliche Programmblock der mit BEGIN eingeleitet wird. Hier müssen zunächst die benötigten Variablen deklariert werden. Danach können Cursor und schlieÿlich die Programmlogik (im folgenden Beispiel eine simple Addition) implementiert werden. 7 ein Abfrageergebnis mit Spalten und Zeilen 9

10 1 Das begleitende Literaturstudium Algorithm 1.1 Beispiel einer SQL/PL UDF in der DB2 Datenbank CREATE FUNCTION MyFunction ( param1 INTEGER, RETURNS INTEGER LANGUAGE SQL BEGIN DECLARE r e s DATE; DECLARE i n c INTEGER DEFAULT 1 ; SET r e s = param1 + param2 + i n c ; RETURN r e s ; END; param2 INTEGER) Trigger in der DB2 Datenbank Trigger können ähnlich wie UDFs in SQL/PL durch einen SQL-Befehl in der DB2 Datenbank erstellt werden. Sie hören auf vorab denierte Ereignisse, wie etwa ein INSERT- Statement auf eine spezielle Tabelle und laufen daraufhin hab. Durch sie können etwa komplexe Integritätsregeln überprüft werden oder weitere Aktionen, die auf das Statement folgen müssen gestartet werden. Sie laufen dabei unbemerkt vom User ab und können nicht explizit aufgerufen werden. Bei Triggern unterscheidet die DB2 Datenbank ebenfalls zwischen externen Triggern in einer höheren Programmiersprache und solchen in SQL/PL. Bei beiden ist es möglich dezidiert Einuss darauf zunehmen, wann der Trigger gerufen wird. Algorithm 1.2 Ausschnitt des Syntaxdiagramms für einen Trigger >> CREATE TRIGGER t r i g g e r name + BEFORE + > + AFTER + ' INSTEAD OF ' > + INSERT + ON + t a b l e name + > + DELETE + ' view name ' ' UPDATE + + ' So kann ein Trigger vor (BEFORE) oder nach (AFTER) einem bestimmten DML- Statement aufgerufen werden. Dies ermöglicht es, beispielsweise eine Wertebereich für ein INSERT-Statement deutlich exibler zu prüfen, als es z.b. mit einem CHECK-Constrain 8 möglich wäre. Auÿerdem lässt sich so die Denition der Tabelle, mit der der Integritätsregeln (in Form eines Triggers) trennen. So kann ein Datenschema unabhängig von der Logik der Integritätsregeln entwickelt werden. Auf der anderen Seite können auch die Integritätsregeln leichter angepasst oder getauscht werden, schlieÿlich sind sie in Triggern gekapselt. Durch einen Trigger lassen sich ebenfalls Sicherheitsaspekte kontrollieren. So ermög- 8 Introduction to DB2 for z/os (Second edition, December 2010), Seite 59 10

11 1 Das begleitende Literaturstudium licht das Schlüsselwort INSTEAD OF, dass ein Trigger auf einen View angelegt werden kann. Statt dem Einfügen eines Datensatzes in den View (was eventuell nicht ohne weiteres möglich ist), reagiert der Trigger und kann eine komplexe Logik für das Einfügen kapseln. Er kann beispielsweise Rechte prüfen und die eigentlichen Tabellen vor dem Nutzer verbergen Beispiel eines Triggers in SQL/PL Ein Trigger wird in der Datenbank ebenfalls mit einem CREATE TRIGGER Statement in SQL/PL angelegt. Anders als eine Funktion erhält er jedoch keinen Methodenkopf, da seine Inputparameter nicht frei wählbar sind. Vielmehr ist die Aktion die ihn auslöst seine Eingabe. Wird beispielsweise in eine Tabelle namens MyTable ein neuer Datensatz eingefügt, so würde der folgende Trigger reagieren. Er könnte in seinem Ausführungsteil (Body) auf den eingefügten Datensatz zugreifen (z.b. auf einen Wert namens id). Algorithm 1.3 Beispiel eines SQL/PL Triggers in der DB2 Datenbank CREATE TRIGGER MyTrigger BEFORE INSERT ON MyTable REFERENCING NEW AS new FOR EACH ROW BEGIN DELETE FROM MyTable WHERE MyTable. id = new. id ; END; Der Aufbau eines Triggers ist dabei ähnlich dem einer UDF. Zwar fehlt der Methodenkopf, aber Optionen und Ausführungsteil (Body) sind von der Struktur identisch. Lediglich einige für den Trigger bzw. die UDF spezische Optionen sind nur in den jeweiligen Typen verwendbar. Hierzu gehört z.b. das BEFORE-Statement, welches nur im Trigger nicht aber in der UDF verwendet werden kann Stored Procedures in der DB2 Datenbank Die so genannten Stored Procedures stellen eigenständige Methoden dar, die in die Datenbank ausgelagert sind. Sie können ebenfalls über einen CREATE PROCEDURE Befehl in SQL/PL in der Datenbank angelegt und dann beispielsweise aus einem Java-Programm heraus gerufen werden. Sie stellen die umfangreichste und mächtigste prozedurale Erweiterung für die DB2 Datenbank dar und können für verschiedenste Problemstellungen genutzt werden. 11

12 1 Das begleitende Literaturstudium Beispiel einer Stored Procedure in SQL/PL Eine Stored Procedure wird über den CREATE PROCEDURE in SQL/PL in der Datenbank angelegt. Sie besitzt einen Methodenkopf, in welchem sowohl Input- als auch Output-Parameter deniert werden können. Zudem können ein oder mehrere Result-Sets an den Aufrufer zurückgeliefert werden. Diese müssen jedoch nicht als Parameter, sondern als Option (RESULT SETS 1) die dem Methodenkopf folgt, deklariert werden. Nach dem Methodenkopf und den Optionen (hier LANGUAGE SQL), folgt der eigentliche Ausführungsteil (Body). Algorithm 1.4 Beispiel einer SQL/PL Stored Procedure in der DB2 Datenbank CREATE PROCEDURE MyProc ( IN para1 INTEGER, OUT para2 INTEGER) LANGUAGE SQL BEGIN IF para1 >= 0 THEN SET para2 = 1 ; ELSE SET para2 = 0 ; END IF ; END; 1.3 Stored Procedures in DB2 (detailliert) Wie schon zuvor erläutert, handelt es sich bei einer Stored Procedure um eine in der Datenbank abgespeicherte Funktion. Sie kann von auÿen aufgerufen werden und Operationen in der Datenbank ausführen. In DB2 können für die Entwicklung von Stored Procedures verschiedene Programmiersprachen herangezogen werden, darunter REXX, C und Java. Im folgenden möchte ich eine native Stored Procedures in SQL/PL genauer beleuchten Programmablauf einer Stored Procedure Ein Anwendungsprogramm welches SQL-Statements ohne eine Stored Procedure ausführt, wendet sich für jedes SQL-Statement einzeln an den Datenbankserver. Es übermittelt das Statement über ein Netzwerk, wartet auf die Abarbeitung im Server und empfängt von diesem wiederum ein Ergebnis über das Netzwerk. Der Server muss dabei zunächst das Statement parsen, Abarbeitungspläne erstellen und diese dann ausführen. Verwendet ein Anwendungsprogramm hingegen eine Stored Procedure, so gestaltet sich der Ablauf anders. Der Client wendet sich hierbei nur einmal, mit einem CALL- Statement an den Server. Dieser startet eine Stored Procedure als Thread, welches die 12

13 1 Das begleitende Literaturstudium Abbildung 1.1: Programmablauf ohne Stored Procedure (links) und mit (rechts) [Introduction to DB2 for z/os (Second edition, December 2010), Seite 175f] Statements (z.b. ein UPDATE oder INSERT) ausführt. Dabei sind die Statements in der Stored Procedure dem DB2 zum Ausführungszeitpunkt schon bekannt. Schlieÿlich wurde die Prozedur zuvor mit einem CREATE-Befehl erzeugt, und Abarbeitungspläne für sie erstellt. Während der Abarbeitung der Stored Procedure kommuniziert lediglich diese mit dem DB2-System. Erst nach der kompletten Abarbeitung wird ein Ergebnis an den wartenden Client zurück geliefert. Während der Ausführung der Stored Procedure kann von dieser ein explizites COM- MIT erfolgen. Auch eine Option COMMIT ON RETURN ist möglich. Solch ein COM- MIT würde alle vorangegangenen SQL-Statements fest in die Datenbank schreiben. Wird keine dieser beiden Möglichkeiten gewählt, so steht es der aufrufenden Applikation frei ein COMMIT oder ein ROLLBACK zu machen. Somit können von der rufenden Applikation alle Statements der Stored Procedure revidiert oder explizit fest geschrieben werden. Der Aufruf einer Stored Procedure bendet sich somit komplett in einem Connection-Kontext der vom Client abhängt. Somit unterscheidet sich der CALL einer Prozedur in diesem Punkt nicht, von der Möglichkeit alle Statements einzeln im Client zu rufen. Wird in einer Stored Procedure explizit (oder mit COMMIT ON RETURN) ein COMMIT ausgelöst, so kann dies Folgen auf andere Stored Procedures haben. Da eine Stored Procedure wiederum andere Prozeduren aufrufen kann 9 wirkt sich ein COMMIT auf alle Statements, in allen aufgerufenen Prozeduren aus. Es betrit also den gesamten Aufrufbaum in diesem Connection-Kontext. Ruft eine Stored Procedure beispielsweise 9 so genannte Nested Stored Procedures 13

14 1 Das begleitende Literaturstudium in einer Schleife über einem geöneten Cursor 10, eine andere Prozedur auf und macht diese ein COMMIT-Statement, so schlieÿt dies wiederum unmittelbar den Cursor in der aufrufenden Prozedur. Dies kann zu unerwartetem Verhalten in den Prozeduren führen, da diese z.b. alleine ausgeführt problemlos arbeiten, in einer Call-Hierarchie jedoch zu Fehlern führen SQL/PL zur Entwicklung von Stored Procedures Neben herkömmlichen Programmiersprachen wie Java oder C, ist es auch möglich Stored Procedures mit SQL/PL zu entwickeln. SQL/PL eignet sich dabei in erster Linie für Stored Procedures, welche hauptsächlich SQL Statements ausführen und nur wenige Kontrollstrukturen benötigen. Diese sind leicht in SQL/PL abzubilden und laufen sehr performant. Eine Stored Procedure in SQL/PL kann Variablen, Cursor und Handler 11 enthalten. Auÿerdem können einfache Kontrollstukturen, Zuweisungen und alle herkömmlichen SQL-Befehle 12 verwendet werden. Somit ist es auch möglich andere Prozeduren zu rufen oder UDFs zu nutzen. Diese Möglichkeiten stimmen mit dem Persistent Stored Modules Standard (kurz PSM) der SQL-Spezikation überein 13. SQL/PL eignet sich als Entwicklungssprache für Stored Procedures hingegen weniger, wenn eine komplexe Logik im Programmcode gefordert ist. Ist es nötig mit Objekten zu hantieren oder hauptsächlich Bedingungen und Schleifen zu prüfen, so könnte dies ein Hinweis sein eine konventionelle Sprache als Alternative in Betracht zu ziehen. Auÿerdem stöÿt SQL/PL an Grenzen, wenn z.b. Dateien oder Netzwerkverbindungen (z.b. zu einer externen Webseite) mit einbezogen werden sollen. In solchen Fällen sollte z.b. Java als Programmiersprache für die Prozedur verwendet werden Methodenkopf und Rückgabeparameter Eine Stored Procedure beginnt in SQL/PL mit einem so genannten Methodenkopf. In ihm wird neben dem Namen der Stored Procedure auch deren Parameterliste deniert. Diese Parameterliste kann sowohl Eingabe- als auch Rückgabeparameter enthalten. Das Konzept unterscheidet sich somit grundlegend von Sprachen wie Java oder C. Während dort eine Methode entweder keinen (void) oder genau einen denierten Rückgabewert 10 ein verrückbarer Zeiger auf eine Datenset/ Result-Set 11 ein mit einer Condition assoziierter Block, vgl catch-blöcke in Java 12 Introduction to DB2 for z/os (Second edition, December 2010), Seite

15 1 Das begleitende Literaturstudium besitzt, ist dies bei Stored Procedures nicht der Fall. Diese können sowohl keinen, einen als auch mehrere Rückgabewerte besitzen. Algorithm 1.5 Prozedur mit drei Rückgabewerten (zwei Parametern p1, p2 und ein Result-Set cursor1) CREATE PROCEDURE MyProc2 (OUT p1 INTEGER, OUT p2 VARCHAR( 2 0 ) ) RESULT SET 1 LANGUAGE SQL BEGIN: Body END; Ebenfalls ist es möglich ein so genanntes Result-Set zurückzugeben, also eine Art Abfragemenge unbestimmter Gröÿe. Dieses Result-Set muss nicht im Methodenkopf deklariert werden, sondern in der anschlieÿenden Optionenliste. Es ist es ebenfalls möglich mehrere Result-Sets an den Aufrufer zurückzugeben. Neben den Möglichkeiten ein oder mehrere Result-Sets bzw. Output-Parameter zurückzugeben, gibt jede aufgerufene Stored Procedure auÿerdem einen Return-Code zurück. Dieser ist unabhängig von den anderen Parametern und signalisiert eine korrekte Ausführung (Return-Code 0) bzw. gibt einen Fehler-Code zurück. Der Wert dieses Rückgabeparameters kann selbst gesetzt werden. So sind auch eigene Fehlercodes möglich Optionen Dem Methodenkopf folgt eine Liste von Optionen. Diese legen verschiedene Eigenschaften der Prozedur fest und sind dabei stark von der jeweiligen Version des DB2 Systems abhängig. In den Optionen kann beispielsweise das Isolation Level 14 festgelegt werden (ISOLATI- ON LEVEL CS/RS/RR/UR) oder ob die Prozedur automatisch ein COMMIT vor ihrem Ende absetzen soll (COMMIT ON RETURN). So lassen sich die globalen Eigenschaften einer Prozedur sehr feingranular festlegen. Problematisch an dieser Art von Settings, ist jedoch ihre starke Abhängigkeit von der jeweiligen Version des Datenbanksystems. Kennt beispielsweise die Version 8 der DB2 Datenbank für z/os noch 18 verschiedene Optionen, so kennt Version 9 hingegen schon 31 und Version 10 schon 33 unterschiedliche Optionen ein Locking-Mechanismus um parallele Zugrie auf die selben Daten zu kontrollieren

16 1 Das begleitende Literaturstudium Body Der eigentliche Programmteil einer Stored Procedure bendet sich im so genannten SQL- Routine Body. Hier können Variablen deklariert werden, Schleifen und Bedingungen geprüft und SQL-Statements abgesetzt werden. Die Abfolge der Deklarationen im Programmteil ist dabei sehr strikt. Zuerst müssen Variablen, dann Cursor und zuletzt Handler deniert werden. Zwischen diesen Denitionen dürfen keine anderen Befehle (wie z.b. SQL-Statements) verwendet werden. Abbildung 1.2: Abfolge der Deklarationen im Programmteil einer Prozedur Die vorgeschriebene Reihenfolge der Deklarationen kann mittels Schachtelung von Body-Teilen teilweise umgangen werden. Man spricht von so genannten Compound Statements 16. Diese können wiederum andere Statements und Deklarationen beinhalten. So lassen sich Stored Procedures beliebig schachteln und in Namensräume unterteilen 17. Algorithm 1.6 Geschachtelte Prozedur CREATE PROCEDURE MyProc3 ( ) LANGUAGE SQL OUTTER: BEGIN DECLARE a S t r i n g VARCHAR( ) ; DECLARE acursor CURSOR FOR SELECT FROM dummy; INNER: BEGIN DECLARE anumber INTEGER; SET OUTTER. a S t r i n g = ' using antoher namespace ' ; END; END; Compound Statements lassen sich jedoch auch in anderen Kontexten nutzen. So können beispielsweise Handler deklariert werden, die mehr als nur eine Aktion ausführend. Ihr Programmteil wird in einem Compound Statement untergebracht und kann so wiederum relativ komplexe Logik kapseln. 16 vom Englischen compound, eine Assoziation, Bindung

17 1 Das begleitende Literaturstudium Algorithm 1.7 Handler mit einem Compound Statement in einer Stored Procedure CREATE PROCEDURE MyProc4 ( input1 INTEGER) BEGIN DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN SET input1 = 0 ; END;... Im Body-Teil können auÿerdem mittels IF-ELSE-Konstrukten Bedingungen (z.b. von Variablen) geprüft werden und durch WHILE- und LOOP-Konstrukte Schleifen erzeugt werden. Zudem lassen sich alle SQL-Befehle hier uneingeschränkt nutzen. So lässt sich schnell Programmlogik entwickeln, die eng mit SQL bzw. der Datenbank zusammenarbeitet Versionierung von Stored Procedures Ist eine Stored Procedure erst einmal in der Datenbank eingerichtet, so liegt diese dort in der ersten Version vor. Diese Version kann nun nicht mehr ohne weiteres geändert werden. Während man bei Tabellen beispielsweise einzelne Spalten modizieren kann, kann eine Stored Procedure nur als ganzes erneut deployed werden. Hierzu steht neben der Möglichkeit sie zu löschen und neu anzulegen, auch ein ALTER-Befehl in DB2 zu Verfügung. Algorithm 1.8 Anlegen und aktivieren einer zweiten Version einer Prozedur ALTER PROCEDURE MyProc3 ADD VERSION V2 ( ) DYNAMIC RESULT SETS 1 BEGIN... END; ALTER PROCEDURE MyProc3 ACTIVATE VERSION V2 ; Der ALTER-Befehl ermöglicht es die Parameternamen (nicht jedoch die Datentypen und die Anzahl der Parameter), die Optionen und den Programmteil einer Prozedur zu ändern. Es besteht die Möglichkeit eine bestehende Prozedur zu ersetzen bzw. eine neue Version von ihr hinzuzufügen. Diese Versionen können beliebig aktiviert bzw. deaktiviert werden. Dieser Mechanismus ermöglicht es auch in einem laufenden System Prozeduren sukzessive umzustellen. Erst wenn alle aktualisierten Versionen korrekt deployed wurden, kann die aktive Version gewechselt werden. 17

18 1 Das begleitende Literaturstudium Entwicklungstools für Stored Procedures in DB2 Grundsätzlich lassen sich Stored Procedures in SQL/PL ohne spezielle Editoren oder Entwicklungsumgebungen programmieren. Der Code einer Stored Procedure ist in SQL/PL letztendlich ein langes und recht komplexes SQL-Statement. Dieses kann beispielsweise in der DB2CMD 18 oder über eine JDBC-Verbindung an die Datenbank geschickt werden. Jedoch ist es so nicht möglich, eine detaillierte Auskunft über Fehler zu erhalten (es wird lediglich ein SQL-Error-Code zurückgeliefert) oder die Prozedur gar zu debuggen. Um die Programmierung von Stored Procedures zu erleichtern, bietet die IBM daher das frei verfügbare Data Studio 19 als Entwicklungsumgebung an. Dieses ist eine erweiterte Version der IDE Eclipse. Das IBM Data Studio bietet neben Syntax-High-Lighting, Fehlererkennung und verschiedenen Wizzards, auch die Möglichkeit Stored Procedures zu debuggen. Hierfür muss jedoch ein spezielles Runtime-Environment in der Datenbank eingerichtet werden. Zudem ist das Debuggen solcher Anwendungen relativ langsam, da alle Debugg-Information über ein Netzwerk zwischen der Datenbank und dem Client ausgetauscht werden müssen Stored Procedures aus Java-Programmen heraus aufrufen In der Datenbank gespeicherte Prozeduren, haben den Vorteil von verschiedensten Client- Applikation heraus aufgerufen werden zu können. Sie stellen so ein zentralisiertes Stück Code dar, welches wenn es erst einmal auf der Datenbank eingerichtet ist, unterschiedlichsten Anwendungen zur Verfügung steht. Der Aufruf einer Stored Procedure kann in Java über ein so genanntes Callable- Statement Objekt geschehen. Diesem wird zum Einen der SQL-CALL Befehl für die Prozedur und zum Anderen verschiedene Input-Parameter übergeben. Auÿerdem können auch Output-Parameter bei diesem Objekt registriert werden. Dies entspricht den Deklarationen im Methodenkopf der Prozedur. Nach der Ausführung kann von dem Statement auÿerdem ein ResultSet bezogen werden, insofern die Prozedur ein solches geliefert hat. Ansonsten wird null zurückgegeben. Algorithm 1.9 Aufruf einer Stored Procedure aus einem Java-Programm heraus CallableStatement cstmt = connection. preparecall ("CALL MyProc5 (? ) " ) ; cstmt. s e t I n t (1, 1 ) ; cstmt. execute ( ) ; ResultSet r s = cstmt. g e t R e s u l t S e t ( ) ; i n t para1 = cstmt.. g e t I n t ( 1 ) 18 DB2 Command Line, sie bietet einen zeilenbasierten Zugri auf die Datenbank

19 1 Das begleitende Literaturstudium Prozeduren anderer User nutzen Eine Prozedur wird in DB2 in einem bestimmten Schema 20 angelegt. Dieses Schema kann beliebig gewählt werden, ist jedoch in der Regel das, des ausführenden Nutzers. Bei einer entsprechenden Rechtevergabe können jedoch auch andere Nutzer diese Prozeduren aufrufen. Entsprechende Rechte lassen sich über den GRANT-Befehl verteilen. Somit kann eine einmal eingerichtete Prozedur global allen Benutzern zur Verfügung stehen. Jedoch können hieraus auch Namenskonikte entstehen, da gleichnamige Prozeduren sich nur noch anhand ihres Schemas unterschieden. Dies ist besonders bei Nested Calls, über Schemas hinweg problematisch. Daher kennt DB2 die Optionen SQLPATH und QUALIFIER für Stored Procedures. Diese stehen seit der Version 9 der DB2-Datenbank zur Verfügung. Abbildung 1.3: SQLPATH und QUALIFIER in Stored Procedures Die Optionen SQLPATH und QUALIFIER geben dabei an, wo bei unqualizierten Objektnamen 21 nach den entsprechenden Tabellen oder Funktionen gesucht werden soll. Dabei bezeichnet der SQLPATH den Schemanamen, indem andere Prozeduren gesucht werden sollen. Der QUALIFIER bezeichnet hingegen das Schema, in welchen nach Tabellen, Views und ähnliches gesucht wird. Sind beispielsweise jeweils zwei gleichnamige Prozeduren in zwei Schemata (A und B) eingerichtet, so würden sie ohne Angaben von SQLPATH und QUALIFIER sich nicht gegenseitig aufrufen. Zudem würden sie lediglich auf den Tabellen in ihrem eigenen Sche- 20 Zusammenfassung von Datenbankobjekten, beispielsweise eines Users 21 also solche ohne ein explizit angegebenes Schema 19

20 1 Das begleitende Literaturstudium ma arbeiten. Sind hingegen in den Prozeduren in Schema A sowohl SQLPATH als auch QUALIFIER auf das Schema B gesetzt, so rufen die Prozeduren in Schema A sowohl Tabellen als auch Prozeduren in B auf (links im Bild). Ist hingegen nur eine der beiden Optionen gesetzt, so wird entsprechend nur eine der beiden Suchen im anderen Schema ausgeführt. Ist beispielsweise in den Prozeduren in Schema A lediglich der SQLPATH auf B gesetzt (rechts im Bild), so werden weiterhin die eigenen Tabellen abgefragt. Durch diesen Mechanismus lassen sich exible Abhängigkeiten erzeugen. So können Prozeduren z.b. auf ihren eigenen Tabellen arbeiten (der QUALIFIER ist nicht gesetzt), nutzen aber für die Berechnung von Werten (z.b. mit Parametern aus diesen Tabellen) die Prozeduren in anderen Schemata (der SQLPATH ist gesetzt). Auÿerdem ist es so möglich Prozeduren global in einem einzigen Schema zu organisieren, sie aber auf unterschiedlichen Schemata arbeiten zu lassen. Dies kann die Rechtevergabe vereinfachen, da nur noch ein Schema zu kontrollieren ist. 1.4 Persönliche Bewertung von SQL/PL als Entwicklungssprache Nachteile Die teils gewöhnungsbedürftigen Unterschiede von SQL/PL zu Programmiersprachen wie Java oder C, machen den Einstieg in die Entwicklung von prozeduralen Erweiterungen für DB2 schwer. Nicht nur die Syntax ist dabei verschieden, sondern auch viele grundlegenden Konzepte (wie z.b. die Handhabung von Rückgabeparametern). Zwar lassen sich prozedurale Erweiterungen auch in Java oder C implementieren, da hierfür jedoch spezielle Vorkongurationen der Datenbank notwendig sind (z.b. eine spezielle JVM für Java), sind diese Möglichkeiten für Einsteiger, eine noch eher gröÿere Hürde. Spezielle Kritikpunkte sind aus meiner persönlichen Sicht: 1. Mehrere Rückgabeparameter: Eine Funktion oder Methode sollte genau einen Ausgabeparameter besitzen. Diese Einschränkung nur einen Wert zurückzugeben, die in viele höheren Programmiersprachen heute erzwungen wird, soll gewährleisten, dass eine Funktion nur eine Aufgabe und somit eine Zuständigkeit hat. Dieses so genannte Single Responsibility Principle 22 soll die Modularität von Code erzwingen. Gibt eine Funktion mehrere Parameter zurück, so verletzt sie dieses Prinzip schon vorweg, schlieÿlich berechnet sie zwei Werte. 22 Robert C. Martin - Clean Code, Seite

21 1 Das begleitende Literaturstudium 2. Reihenfolge der Deklarationen: Die Einschränkung Variablen in einer bestimmten Reihenfolge am Beginn der Procedure zu deklarieren, ist zwar in Programmiersprachen wie C ebenfalls wiederzunden, ist jedoch kaum zeitgemäÿ. Es macht die Programmierung nicht nur unkomfortabel, sondern trennt die Deklaration der Variablen auch räumlich von deren Benutzung 23. Dies macht den Code schwerer nachvollziehbar. 3. GOTO-Befehl: Der verfügbare GOTO-Befehl macht lange Ketten von Programmsprüngen möglich. 4. Mangelhafte Unterstützung durch IDEs: Zwar gibt es Entwicklungsumgebungen für SQL/PL, wie etwa das IBM Data Studio, jedoch sind diese weit unkomfortabler als zeitgemäÿe IDEs für z.b. Java oder C#. Es fehlt eine Code- Completion, die Fehlererkennung ist mangelhaft und das Debugging (bedingt durch die Client-Server-Architektur) schwerfällig. 5. Beschränkter Umfang: Es ist in SQL/PL nicht möglich zusätzliche Bibliotheken einzubinden oder den Sprachumfang in anderer Form zu erweitern. So hat SQL/PL eine begrenzte Domäne in der es Funktionen bietet. Daher ist SQL/PL zwar überblickbar und so schnell zu erlernen, aber eben auch auf spezielle Problemstellungen beschränkt Vorteile SQL (bzw. der SQL-Dialekt der DB2 Datenbank) ist eine direkte Untermenge von SQL/PL. Somit kann bei guten SQL-Kenntnissen relativ schnell in die Entwicklung von Stored Procedures in SQL/PL eingestiegen werden. Auch ist das Deployment dieser Art von Prozeduren (etwa im Gegensatz von Java-Prozeduren) sehr einfach. Besondere Vorteile sind aus meiner Sicht: 1. Integration von SQL: Da SQL eine Untermenge von SQL/PL ist und im Body einer Stored Procedure uneingeschränkt genutzt werden kann, ist dies eine bestmögliche Integration. So lässt sich beispielsweise mit nur einer Codezeile ein Wert aus einer Tabelle in eine Variable speichern. Möchte man diesen trivialen Schritt hingegen in Java implementieren, so muss ein Statement-Objekt erzeugt werden, ein String übergeben und Result-Set erhalten werden. Aus diesem muss dann der Wert entnommen und zugewiesen werden. Solche einfachen Anforderungen lassen 23 Robert C. Martin - Clean Code, Seite 80 21

22 1 Das begleitende Literaturstudium sich durch die enge Verzahnung von SQL und prozeduralen Konstrukten in SQL/PL sehr einfach implementieren. 2. Deployment: Eine SQL/PL Prozedur zu deployen heiÿt ein erfolgreiches SQL- Statement abzusetzen. Danach ist die Prozedur sofort verfügbar. Es müssen keine zusätzlichen Einstellungen an der Datenbank vorgenommen werden, es ist keine Vorcompilierung (wie etwa bei SQLJ) nötig und es muss durch den Entwickler kein weiterer Schritt (wie etwa ein Binden von Paketen) durchgeführt werden. 22

23 2 Das Praxissemester bei IBM Im Folgenden möchte ich einen Überblick über mein sieben-monatiges Praktikum bei er IBM im Entwicklungslabor in Böblingen geben. Zunächst stelle ich das Unternehmen IBM vor, das Labor in Böblingen und die Abteilung in der ich mein Praktikum absolvierte. Anschlieÿend beschreibe ich Inhalt und Aufgabe meiner Tätigkeit, sowie die von mir entwickelten Lösungen. Ich schlieÿe mit einem persönlichen Rückblick auf meine Praktikumszeit. 2.1 Das Unternehmen IBM Die International Business Machines Corporation Die International Business Machines Corporation 1 (IBM) ist eine der gröÿten und führenden Firmen im Bereich der Informations -Technologie und im Consulting. Sie stellt sowohl Hardware als auch Software her, bietet Finanz- und IT-Dienstleistungen und ist einer der weltweit gröÿten Anbieter für Unternehmensberatung. Die IBM blickt dabei auf eine langjährige Geschichte zurück. Bereits im Jahre 1896 gründete Herman Hollerith die Tabulating Machine Company, aus der im Jahre 1911 die Computing Tabulating Recording Corporation hervorging. Diese stellte in den USA, in erster Linie Maschinen zur Erfassung von Daten aus Lochkarten her, welche beispielsweise bei Wahlen zur Stimmauszählung eingesetzt wurden. Im Jahre 1924 wurde die Computing Tabulating Recording Corporation in International Business Machines (kurz IBM) umbenannt. Die Namensänderung sollte das Geschäftsfeld indem sich das Unternehmen bewegte deutlich machen: die Herstellung von Maschinen zur automatisierten Verarbeitung von Daten für Unternehmen. Während die IBM in ihren Anfangsjahren noch vor allem mechanische Geräte zur Auswertung von Daten entwickelte, entstanden in den späten 40er Jahren die ersten Computer. Schon früh produzierte die IBM dabei ihre eigene Hardware und Rechnerarchitekturen. Dies machte sie im Bereich der Groÿrechnertechnik schnell zum Marktführer

24 2 Das Praxissemester bei IBM Neben der für diese Rechner entwickelte Software (wie etwa das Betriebssystem z/os 2 ), entstanden in den 90er Jahren zunehmend Softwareprodukte in der IBM. Darunter zahlreiche Lösungen für Kunden (wie z.b. Lotus Notes 3 oder DB2 4 ), sowie für Entwickler (wie z.b. Rational Team Concert 5 ). Die IBM gliedert sich heute in vier Bereiche: Die IBM Global Services umfasst die Unternehmensberatung sowie verschiedene Dienstleistungen im Bereich der IT-Infrastruktur, wie z.b. Out-Sourcing oder Support. Die IBM Global Finance ist im Umfeld der Finazdienstleistung tätig. Sie bietet etwa Leih- und Finanzierungskonzepte für die verschiedenen Produkte des Unternehmens. Sie ist der weltweit gröÿte IT-Finanzdienstleister 6. Die IBM Systems and Technology Group deckt die Hardware-Palette der IBM ab. Hierzu gehören z.b. Server und Groÿrechner, wie das Bekannte IBM Betriebssystem z/os oder die IBM Power 7 Systeme. Die IBM Software Group umfasst das Gebiet der Softwareentwicklung. Die IBM beschäftigt derzeit knapp Mitarbeiter, davon rund in Deutschland. Eines der gröÿten Labore liegt dabei in Böblingen, mit knapp 2000 Mitarbeitern IBM Research & Development in Böblingen Die IBM ist seit 1910 durch ihre Tochtergesellschaft DEHOMAG 8, die später oziell zur IBM Deutschland GmbH umbenannt werden sollte, hierzulande vertreten. Der Hauptsitz der IBM Deutschland liegt seit 2009 in Ehningen, im Groÿraum Stuttgart. Eines der gröÿten Entwicklungslabore der IBM bendet sich seit 1953 in Böblingen. Es ist neben bekannten Lokationen im deutschsprachigen Raum, wie Mainz und Zürich, eines von mehr als 60 sogenannten Labs. Im Böblinger Forschungs- und Entwicklungszentrum, werden sowohl Hardware- als auch Softwarekomponenten entwickelt. Diese werden im Böblinger Labor sowohl exklusiv betreut, als auch in Kooperation mit anderen Standorten, z.b. in den USA oder Asien Deutsche Hollerith-Maschinen Gesellschaft mbh 24

25 2 Das Praxissemester bei IBM Abbildung 2.1: Labor der IBM in Böblingen [ 05.ibm.com/de/entwicklung] Unter anderem nden sich dort Projekte zum Informations Management, zu den IBM Hardwaresystemen und IBM WebSphere Server wieder. 2.2 Meine Praktikumsstelle Bewerbung Ich habe mich im Frühjahr 2010 bei der IBM, sowie bei einigen anderen kleineren Unternehmen (Libelle AG 9, GeBit Solutions 10 ) im Raum Stuttgart für ein Praxissemester beworben. Meine Informationen bezog ich aus verschiedene Quellen wie z.b. dem Internet oder dem schwarzen Brett meiner Hochschule. Auf die IBM wurde ich vor allem durch Professoren und Kooperation mit der HdM aufmerksam. Da ich die Chance des Praxissemesters nutzen wollte, um einmal die Softwareentwicklung in einem gröÿeren Team kennen zu lernen, entschied ich mich für eine Bewerbung bei der IBM. Die Firmenwebseite diente mir als Ausgangspunkt für meine Suche nach einer Praktikumsstelle. Über diese gelangte ich zu den verschiedenen Praktikumsausschreibungen, welche die IBM damals anbot. Ich interessierte mich in erster Linie für Stellen in der Softwareentwicklung, vorzugsweise mit Java und im Umfeld von Datenbanken. Per Online- Formular bewarb ich mich letztendlich auf drei Stellen in diesem Bereich, wobei ich eine Stelle im Test-Team des DB2 z Performance Management als Präferenz angab. Einige Wochen später hatte ich ein erstes Telefoninterview mit Karin Steckler aus dem Team des DB2 z Performance Management. Hierdurch ergab sich für mich die Chance für ein persönliches Vorstellungsgespräch. Dieses fand in der darauf folgenden Woche in Böblingen statt. Mit dabei war auch Stephan Arenswald, ein Kollege von Karin Steckler aus dem Test-Team. Dieser hatte ebenfalls eine oene

26 2 Das Praxissemester bei IBM Praktikumsstelle anzubieten, welche mir thematisch auch sehr zusagte. Mir wurde erklärt worum es sich in beiden Praktikumsstellen handeln sollte und ich konnte einen ersten Blick auf meinen zukünftigen Arbeitsplatz werfen. Auÿerdem konnte ich meine eigenen Wünsche und Vorstellungen für das Praktikum zur Sprache bringen. Ich bekam wenige Tage später eine Zusage von Stephan Arenswald für eine Praktikumsstelle, die ich annahm. Mein Praktikum begann daraufhin am 01. September 2010 und sollte am 31. März 2011 enden. Parallel zu meiner Bewerbung bei der IBM, hatte ich auch bei den anderen beiden Unternehmen ein Vorstellungsgespräch. Auch diese Firmen sagten mir eine Praktikumsstelle für das WS 10/11 zu. Ich entschied mich letztendlich für die IBM, da mir die Stelle und das Unternehmen am interessantesten erschienen. Ich hote dort am meisten lernen zu können Beschreibung der Stelle Die ursprüngliche Stelle, auf die ich mich bei Karin Steckler bewarb, sollte sich um die Entwicklung von automatisierten Testfällen für ein Command Line Interface drehen. Mit Hilfe eines von der IBM entwickelten Test-Frameworks namens STAF 11 (Software Testing Automation Framework) sollten in XML gefasste Testfälle entwickelt werden. Diese sollten zum Teil automatisch durch eigens entwickelte Tools erstellt werden und in das bestehende Test-Environment eingebunden werden. Die Praktikumsstelle von Stephan Arenswald, für die ich letztlich eine Zusage erhielt, war zum Teil ähnlich. Die Aufgabe bestand in groben Zügen darin, einen externen Service (eine Art Plugin) für das STAF Framework zu entwickeln um SQL- Workloads komfortabel auf Datenbanken ausführen zu können. Ein Student der Universität Stuttgart hatte bereits in Zusammenarbeit mit meinem Betreuer Stephan Arenswald eine erste Version des zu entwickelnden Workload-Tools implementiert. Dieses sollte nun deutlich erweitert und letztendlich einsatzbereit gemacht werden. Während das STAF Framework selbst in C++ implementiert ist, sollte für die Entwicklung des Services die Programmiersprache Java eingesetzt werden und auf die Java-API von STAF zurückgegrien werden. Auÿerdem sollten Workloads als atomare kleine Java- Programme implementiert und in den Service eingebunden sein. Diese sollten dann den eigentlichen Workload mittels SQL bzw. SQL/PL ausführen. Das Hauptaugenmerk sollte auf der Entwicklung weiterer Workloads liegen. Ein andere Aspekt meiner Praktikumsstelle war die Integration des entwickelten Ser

27 2 Das Praxissemester bei IBM vices in die bestehende Test-Umgebung. Hierzu arbeitete ich häug mit Georgie Straube, einem weiteren Praktikanten welcher die Praktikumsstelle von Karin Steckler übernahm, zusammen. Der überwiegende Teil meiner Arbeit war jedoch die Entwicklung des Service und der dazugehörigen Workloads Die Abteilung Mein Praktikum sollte ich in der Abteilung DB2 z Performance Management die zur Information Management Software Group gehört, absolvieren. Diese arbeitet an der Entwicklung eines Monitoring Tools für die IBM Datenbank DB2 auf z/os namens Tivoli OMEGAMON XE for DB2 Performance Expert on z/os 12. Mit diesem soll es ermöglicht werden die Datenbank zu überwachen, eventuelle Flaschenhälse zu nden und das System zu optimieren. Es ist vor allem für sehr groÿe Kunden gedacht, welche entsprechend umfassende Datenbanken betreiben. Das Team ist ca. 40 Personen stark und bendet sich zu gröÿten Teilen im IBM Labor in Böblingen. Einige Tester benden sich auÿerdem im weiÿ-russischen Minsk, sowie ein paar wenige Entwickler im US-amerikanischen Austin. Auÿerdem gehören regelmäÿig zwei bis vier Praktikanten zum Team. 2.3 Problemstellungen und Lösungsansätze Der DB2 Performance Expert on z/os Der DB2 Performance Expert on z/os, welcher in Böblingen entwickelt wird, ist ein Tool zur Messung und Überwachung der Datenbank. Er ermöglicht es, für die Performance ausschlaggebende Schlüsselwerte zu messen und so zu optimieren. Ähnliche Tools sind von allen groÿen Datenbankanbietern für ihr jeweiliges Produkt verfügbar 13. Durch die Überwachung der Datenbank, können Einstellungen und Kongurationen verbessert und auf die individuellen Ansprüche des Systems angepasst werden. Dadurch kann eine bessere Performance des Datenbanksystems, z.b. im Bezug auf CPU- Rechenzeit erzielt werden. Da je nach Lizenzvertrag mit der IBM jeder CPU-Takt auf dem darunter liegenden z/os-mainframe, ein Unternehmen bares Geld kostet, kann sich eine solche Performanceverbesserung direkt nanziell auszahlen. Der Performance Expert besteht aus zwei grundlegenden Teilen. Zum einen dem so genannten Collector, einem Server welcher Performance-Daten von der Datenbank sam z.b. der Automatic Database Diagnose Monitor (ADDM) für die Datenbanken des Softwareherstellers Oracle 27

28 2 Das Praxissemester bei IBM melt, speichert und auswertet. Auf der anderen Seite stehen verschiedene User-Interfaces um die Auswertung der Daten zu ermöglichen. Diese sind zum Teil sehr unterschiedlich. Es nden sich unter ihnen ältere, zeilenbasierte Interfaces, Clients auf Java-Basis, sowie Web-Interfaces mit modernen Internettechnologien. Gemeinsam haben sie jedoch die Notwendigkeit getestet zu werden Das Test-Environment Der DB2 Performance Expert on z/os wird von der IBM schon seit mehreren Jahren entwickelt und ist momentan in der aktuellen Version 5.10 (Stand Februar 2011) erhältlich. Er ist somit ein über lange Zeit gewachsenes Produkt und daher sehr komplex. Dementsprechend vielfältig gestalten sich die Tests. Neben Unit-Tests der Entwickler, Regression Tests und vielem mehr, stehen dabei natürlich die Oberächentests im Vordergrund. Durch die groÿe Anzahl an verschiedenen User-Interfaces sind diese weit gestreut. Ich konnte während meiner Praktikumszeit nur einen kleinen Einblick in die gesamte Testumgebung erhalten. Zusammen mit Georgie Straube befasste ich mich mit den Tests zum so genannten VTAM-Interface. Dieses ist ein auf Paneln basierendes Interface, welches über Testaturbefehle gesteuert werden kann. VTAM steht für Virtual Telecommunications Access Method, womit eine Programmierschnittstelle für die Netzwerkkommunikation bezeichnet wird. Diese wurde bereits in den 70er Jahren entwickelt, ist aber weiterhin von vielen Nutzern des Performance-Monitors gefragt. Georgie Straube entwickelte hierfür mit Hilfe des STAF Frameworks und dessen Workow-Kontroll Service STAX, XML-Skripte für automatisierte Oberächentests. Diese Tests kontrollierten durch den Rational Functional Tester 14 (kurz RFT) verschiedene Oberächeneigenschaften, wie z.b. Counter, Tabellen oder die Navigation zwischen den Panels im VTAM-Interface. Für die Ausführung der Oberächentests, war es dabei nötig bestimmten Workload auf einer Testdatenbank auszuführen. Sollte ein Testfall etwa die Ansicht der laufenden Threads in der Datenbank testen, so musste zuvor ein Workload gestartet werden der eben solche Threads erzeugte. Nur so war sicherzustellen, dass bestimmte Counter funktionierten oder Tabellen sinnvolle Werte ausgaben. Auch waren bestimmte Panels erst dann erreichbar, wenn Daten für sie zur Verfügung standen. Der Workow der Tests wurde dabei anhand der STAX-Skripte deniert, die wiederum das Testframework STAF aufriefen. An dieser Stelle kam meine Zusammenarbeit mit

29 2 Das Praxissemester bei IBM Georgie Straube ins Spiel. Die Skripte von Georgie Staube sollten auf das von mir zu entwickelnde Programm zurückgreifen und mit dessen Hilfe die benötigten Workloads starten. Hierzu mussten wir uns eng abstimmen: Die von Georgie Straube benötigten Workloads mussten von mir in dem neuen Tool umgesetzt werden und die Benutzung wiederum von ihm in den STAX-Skripten implementiert werden. Auÿerdem sollten wir sukzessive ein altes Tool ersetzen, welches diese Aufgabe bislang übernahm STAF/STAX Ein zentraler Bestandteil der Testumgebung stellte das Software Testing Automation Framework STAF dar. STAF ist ein Open Source Projekt der IBM und kann über bezogen werden. STAF dient zur Automatisierung von Tests. Hierzu wird die in C++ geschriebene Software auf allen Testmaschinen installiert und konguriert. Ist STAF erst einmal gestartet, so läuft es als eine Art Deamon Prozess im Hintergrund und wartet auf eingehende Kommandos. Diese Kommandos bieten Zugri auf viele Schnittstellen des Systems. So lassen sich z.b. Dateien kopieren, Logs schreiben oder beliebige Programme starten. Abbildung 2.2: Der gestartete STAF-Prozess STAF ermöglicht es auÿerdem so genannte Services als Plugins einzubinden und so beliebige Funktionalität in das Framework zu integrieren. Diese Services können beispielsweise in Java implementiert sein und funktionieren nahezu wie jedes herkömmliche Programm. Sind diese Services erst einmal im laufenden STAF-Prozess registriert, kann ebenfalls über Kommandos auf sie zugegrien werden. Auÿerdem kann wiederum jeder eingebundene Service, mit Hilfe der STAF-API auf wichtige Bestandteile von STAF zurückgreifen, wie etwa den zentralen Logging-Mechanismus. Der wohl wichtigste Bestandteil von STAF sind jedoch die Möglichkeiten zu verteilten Systemen. Ist STAF auf zwei verschiedenen Maschinen installiert, kann von einer Maschine mittels STAF nahezu uneingeschränkt auf die andere zugegrien werden. Es ist z.b. ohne weiteres möglich auf einer Reihe von Testmaschinen ein beliebiges Programm 29

30 2 Das Praxissemester bei IBM zu starten: >> STAF MyRemote PROCESS START COMMAND MyProg Dies ermöglicht es beispielsweise eine Applikation einfach auf einer groÿen Zahl von Testmaschinen zu verteilen, indem die Möglichkeiten Dateien durch STAF zu schreiben genutzt werden. Auÿerdem lässt sich so auch jeder eingebundene STAF Service auf einer entfernten Maschine starten und kontrollieren. Da dies alles nur mittels Kommandos geschieht, kann ein Testfall als Skript verfasst bzw. durch ein Skript gesteuert werden. Dies ermöglicht es beinahe jede Funktionalität in STAF einzubinden und sie auch remote ausführen und kontrollieren zu können. Des weiteren bietet STAF einen schon implementierten Service namens STAX. Mit diesem können komplexe Workows in XML-Dateien abgebildet und durch einen graschen Monitor gestartet und überwacht werden. So können auch aufwändige Testfälle in einer leicht lesbaren und editierbaren Form erstellt und abgelegt werden. Zur Erstellung solcher Testfälle bietet STAX verschiedene Kontrollstrukturen wie z.b. Schleifen oder Bedingungen, sowie eine volle Verfügbarkeit der STAF-Befehle Der DB2WorkloadService Der Hauptteil meines Praktikums bestand in der (Weiter-) Entwicklung des so genannten DB2WorkloadService. Dieser sollte vorwiegend als eine Art Plugin in das IBM Framework STAF integriert werden, welches vom Test-Team meiner Abteilung bereits genutzt wurde. Darüber hinaus musste es aber auch möglich sein den Service ohne STAF auszuführen und als Bibliothek in anderen Projekten zu nutzen. Der DB2WorkloadService sollte dabei mehrere andere, teils nicht mehr den Anforderungen entsprechende Tools ablösen. Zum einen sollte er ein grasches Tool für Workloads auf LUW ablösen. Dieses war ebenfalls von Studenten entwickelt worden, konnte aber nur teilweise mit den Anforderungen auf z/os umgehen. Auÿerdem brachte es viele nicht benötigte Funktionen für Workow-Einstellungen mit sich. Es wurde zudem nicht mehr weiterentwickelt und betreut. Zweitens sollte ein Java-Tool, welches der Vorgänger des DB2WorkloadService war, abgelöst werden, da eine bessere Integration in das STAF Framework benötigt wurde. Dadurch sollten die Vorteile von STAF (welches ohnehin schon verwendet wurde) wie z.b. das Logging und die Remote-Funktionen, genutzt werden. Das neue Tool sollte dabei aus zwei Teilen bestehen. Einerseits einem relativ exiblem Framework, welches die Entwicklung von neuen Workloads erleichtern und dem Programmierer verschiedene Hilfen zur Verfügung stellen sollte. Andererseits aus eigenständigen 30

31 2 Das Praxissemester bei IBM Abbildung 2.3: Screenshot des DB2WorkloadService Workloads, die die benötigten Arbeitslasten für die Testfälle abdeckten. Diese sollten wiederum als eine Art Plugin in das Framework integriert werden können. Das Framework und die konkreten Workloads mussten dabei denkbar lose gekoppelt sein. Die Workloads sollten lediglich eine abstrakte Klasse des Frameworks ableiten und deren abstrakte Methoden implementieren. Das Framework sollte dann zur Laufzeit diese konkreten Klassen aus einem denierten Ordner laden und bereitstellen. Dieser Mechanismus sollte es möglich machen, konkrete Workloads für das Framework zu schreiben, ohne dieses selbst an zufassen Das Framework Das Framework des DB2WorkloadSerive war neben den eigentlichen Workloads einer der beiden zentralen Bestandteile meiner Praktikumsstelle. Die Aufgabe war es, die aktuelle Version weiter zu entwickeln, um diese schlieÿlich in das Test-Environment einbinden zu können. Dabei sollten verschiedene Anforderungen berücksichtigt werden: Integration in STAF, sowie die Möglichkeit der Ausführung auch ohne STAF Verschiedene Logging-Mechanismen (File-, Datenbank-, STAF- oder Live-Log) Parallele Ausführung von mehreren Workloads Eine konsistente Fehlerbehandlung 31

32 2 Das Praxissemester bei IBM Abbildung 2.4: Architektur des DB2WorkloadService Kontrollmöglichkeit für die Ausführung (z.b. Dauer, statisch oder dynamisch) Prüfungen der Erreichbarkeit von Ressourcen (z.b. Datenbanken) Nutzung von Kongurationsdateien Entgegennahme und Prüfung von Kommandos Grasche Oberäche zur Kontrolle der Ausführung Bereits vor meinem Praktikum hatte ein Student der Universität Stuttgart zusammen mit meinem Betreuer Stephan Arenswald eine erste Version entwickelt. Jedoch fehlten in dieser noch wichtige Anforderungen. So konnte sie z.b. keine Workloads parallel ausführen, verfügte über keine grasche Oberäche oder konnte die Erreichbarkeit einer Datenbank schon im Vorfeld testen. Während meiner Praktikumszeit machte ich mich mit STAF und den Anforderungen an das Tool vertraut. Ich implementierte einen Groÿteil der geforderten Funktionen in dem Framework. Da mein Betreuer mir hierzu weitestgehend freie Hand lieÿ, konnte ich 32

33 2 Das Praxissemester bei IBM viel ausprobieren und experimentieren. Ich setzte mich intensiv mit Threading auseinander, entwickelte eine grasche Oberäche und konnte noch im vergangenen Jahr eine erste Version, auf einer IBM internen Webseite präsentieren. Auÿerdem befasste ich mich eingehend mit der Architektur und dem Aufbau einer solchen Applikation. Zwar stellte ich mehrmals zentrale Bestandteile um, jedoch konnte ich ein relativ klar strukturiertes Programm entwickeln, welches in mehreren Umgebungen lief (STAF, Stand-Alone und im DB2-Environment) und leicht als Bibliothek in anderen Anwendungen verwendet werden kann. Als Architektur für das System erwies sich der in Abbildung 2.4 beschriebene Aufbau als sinnvoll. Hierbei ist der eigentliche Service als eine Core.jar implementiert. Dieses JAR-Archiv enthält alle wesentlichen Bestandteile, kann aber nicht alleine ausgeführt werden. Hierfür stehen verschiedene Wrapper zur Verfügung, etwa für die Ausführung in STAF. Diese Wrapper laden den Kern, sowie alle von ihm und von ihnen benötigten Bibliotheken. Da sich diese je nach Wrapper unterschieden können, ist dieser Ladevorgang in die Wrapper ausgelagert. Der Kern wiederum lädt dynamisch alle momentan verfügbaren Workloads, schreibt Logging-Information und sucht nach Einstellungen. Der Wrapper selbst implementiert neben dem Ladevorgang für die Bibliotheken nur ein einfaches Interface für seine Umgebung. Der Kern weiÿ seinerseits nichts von dem Environment in dem er verwendet wird. So kann er auch ohne Vorbedingungen als Bibliothek eingesetzt werden. Durch das dynamische laden der benötigten Klassenbibliotheken in den Wrappern, muss zudem keine Bibliothek auf dem Klassenpfad liegen. Dies erleichtert die Einrichtung des Programms. Auÿerdem müssen die Wrapper dem Kern nicht bekannt sein, sie können somit leicht erweitert werden Die Workloads Der zweite maÿgebliche Bestandteil meiner Praktikumsstelle war neben der Entwicklung des Frameworks, die der eigentlichen Workloads. Diese sollten als unabhängige Java- Klassen (in JAR-Archive gekapselt) in das Framework eingebunden werden können. Ein Workload war dabei ein relativ weit gefasster Begri. Grundsätzlich sollte ein Arbeitsaufwand auf der Datenbank erzeugt werden, um die Anzeigen bestimmter Ober- ächenteile kontrollieren zu können. Dieser Arbeitsaufwand konnte verschiedenster Art sein. So feuerten manche Workloads nur viele und einfache SELECT-Statements ab, andere arbeiteten mit User-dened-Functions und wieder andere legten Stored Procedures in der Datenbank an um diese aufzurufen. Auch Benchmark-Tests wie etwa der TPC-C Workload wurden für den DB2WorkloadService adaptiert. 33

34 2 Das Praxissemester bei IBM Alle Workloads mussten dabei einige Aspekte berücksichtigen: Unterteilung in drei unabhängige Phasen (Initialisierung, Ausführung und abschlieÿende Bereinigung) Unterbrechbarkeit zu jedem beliebigen Zeitpunkt Bereinigung der Datenbank, auch im Fehlerfall oder bei einer Unterbrechung Beliebige Wiederholbarkeit und parallelen Ausführbarkeit Diese Anforderungen mussten dabei teilweise in den einzelnen Workloads individuell umgesetzt werden oder konnten als Funktionen in das Framework gezogen werden. So bot das Framework z.b. Möglichkeiten um jeden Workload für eine vorgegebene Zeit in einer Schleife auszuführen. Hierfür musste der Workload wiederum garantieren, dass eine mehrfache Ausführung für ihn möglich war Dokumentation Neben der eigentlichen Entwicklung musste das Projekt auch selbst getestet und dokumentiert werden. Dies war vor allem deshalb wichtig, da dies ein rein studentisches Projekt war und somit die Leute die es betreuen und weiterentwickeln häug wechseln. Zu Beginn meines Praktikums existierte neben dem groben Grundriss des Programms, lediglich eine Auistung der bereits existierenden Workloads. Während meiner Entwicklungszeit entstand hieraus eine umfassende Dokumentation, sowohl für den User als auch für den zukünftigen Entwickler, in Form eines PDFs und einer Java-Doc. Auÿerdem wurde ein Change-Log angelegt und durch das Versionierungssystem die Arbeit am Projekt getrackt und nachvollziehbar gemacht Tests Parallel zu den Arbeiten am Service und an der Dokumentation habe ich JUnit Tests für einen Groÿteil der Klassen erstellt. Diese haben zu Praktikumsbeginn gefehlt und wurden erst im Nachhinein implementiert. Sie sollten es in Zukunft ermöglichen, bei neuen Programmteilen oder Änderungen am bestehenden Quellcode sofort mögliche negative Folgen zu erkennen und zu beheben. Dies gibt besonders einem neuen Studenten der dieses Projekt nach mir betreut die Sicherheit nichts kaputt zu machen. 34

35 2 Das Praxissemester bei IBM Abbildung 2.5: Übersicht über die Codeabdeckung einer JUnit-Testsuit mit ECLEmma Integration in das bestehende Test-Environment Gegen Ende meiner Praktikumszeit war eine erste Version des DB2WorkloadService fertig gestellt. Neben einer Veröentlichung im IBM Intranet, sollte es nun auch in das bestehende Test-Environment eingebunden werden. Hierzu arbeitete ich mit Georgie Straube, dem Praktikanten von Karin Steckler zusammen. Der DB2WorkloadService musste mit allen Abhängigkeiten und Kongurationen auf ca. acht Testmaschinen deployed 15 werden. Darunter waren sowohl Linux als auch Windows Rechner. Auÿerdem mussten noch abschlieÿende Testläufe gegen insgesamt drei Datenbankversionen gefahren werden. Die bestehenden Tools mussten zudem manuell in den Testskripten durch Aufrufe unseres Programms ersetzt werden. Diese Arbeiten waren relativ ähnlich und mussten von Zeit zu Zeit erneut ausgeführt werden. So musste z.b. der Service bei einer neuen Version, wieder auf allen Testmaschinen deployed werden. Daher bot sich diese Arbeit für eine Automatisierung an. Ich implementierte einige Helfer-Klassen um automatisch STAX Skripte in XML zu erzeugen. Ein Batch-File übernahm die immer gleich bleibenden Schritte beim Deployen der Applikation. 15 eingerichtet 35

36 2 Das Praxissemester bei IBM Sonstige Aufgaben Mein Praktikum bestand hauptsächlich in der Entwicklung des DB2WorkloadService, mit seinen Tests, Dokumentation und ähnlichem. Gegen Ende meiner Praktikumszeit bekam ich jedoch die Gelegenheit einige kleinere Tools für ein anderes Test-Team meiner Abteilung zu schreiben. Auch diese waren in Java implementiert und sollten SQL-Workloads auf Datenbanken ausführen. Jedoch mussten sie sich in ein völlig anderes Testframework integrieren und waren daher nicht direkt in den DB2WorkloadService integriert. Jedoch wurde dieser hierfür als Bibliothek verwendet, da so kein Code dupliziert werden musste. 2.4 Tools und Technologien Eclipse und Java Für die Entwicklung des DB2WorkloadService wurde die Programmiersprache Java und die IDE Eclipse herangezogen. Java wurde aufgrund der Verbreitung, der bestehenden STAF-API, der Anbindung an die DB2 Datenbank und der Anforderung einen plattformunabhängigen Service zu implementieren gewählt. Auÿerdem wird in der Abteilung in der ich mein Praktikum absolvierte, selbst mit Java entwickelt. Daher konnte mein Betreuer auf viel Erfahrung in diesem Gebiet zurückblicken. Da die IBM auch konzernintern auf die Java-Plattform setzt und in diesem Umfeld sogar mit Konkurrenten wir Oracle zusammenarbeitet, war dies die erste Wahl. Eclipse wurde in Verbindung mit dem neuen IBM Versionierungssystem Rational Team Concert 16 (RTC) zur Entwicklung herangezogen. RTC bietet neben der herkömmlichen Sourcecodeverwaltung, auch Möglichkeiten zu Projektplanung, Arbeitseinteilung und Dokumentation. So kann man für Komponenten so genannte Defects oder neue Tasks erönen und diese einzelnen Mitarbeitern zugewiesen. Diese können dann bearbeitet, abgelehnt, diskutiert und vieles mehr werden. Dies soll es ermöglichen die Arbeit eines ganzen Teams zentral zu verwalten und zu gemanagen. Der Vorteil zu anderen Tools ist hierbei die Integration in Eclipse. Sowohl Sourcecodeverwaltung, als auch Projektplanung können an einer gemeinsamen Stelle bewerkstelligt werden. Jedoch ist Rational Team Concert auch sehr kompliziert und bedurfte daher zu Beginn einer längeren Einarbeitungsphase

37 2 Das Praxissemester bei IBM Abbildung 2.6: Persönliche Arbeitsansicht im RTC Auÿerdem wurde mit gängigen Java Frameworks, wie JUnit 17, ECLEmma 18 und Java Doc gearbeitet. Eine Einschränkung in der Entwicklung war die Vorgabe lediglich die Java Version 1.5 zu nutzen. Dies sollte gewährleisten, dass der neue Service ohne gröÿere Aktualisierungen oder Kongurationen auf allen bestehenden Testmaschinen laufen konnte. Jedoch mussten in einigen Bereichen, wie etwa der Swing-Oberäche oder der XML-Verarbeitungen Einschränkungen in Kauf genommen werden, bzw. Work-Arrounds gesucht werden DB2 und SQL/PL Die Workloads für den DB2WorkloadService wurden mittels JDBC aus Java heraus auf der Datenbank ausgeführt. Hierfür war es oftmals nötig sich nicht nur detailliert mit Java, sondern auch mit den Eigenheiten der DB2 Datenbank und ihrem SQL Dialekt zu befassen. Besonders für das Schreiben von Stored Procedures oder User Dened Functions, war eine genaue Einarbeitung in die Syntax nötig. Da meine Abteilung den Performance Expert ausschlieÿlich für das IBM Betriebssystem z/os entwickelt, mussten die Workloads in erster Linie mit der z/os Version der DB2 Datenbank kompatibel sein. Da sich diese in einigen Punkten von der LUW 19 Im Linux, Unix und Windows 37

38 2 Das Praxissemester bei IBM plementation unterscheidet, war hierbei erhöhte Aufmerksamkeit erforderlich. Besonders kritisch waren dabei folgende Punkte: Unterschiedliche SQL-Keywords Unterschiedliches Default-Verhalten beim Anlegen von Tabellen und Tabellenbereichen Unterschiedliche Features in den einzelnen Versionen Als Referenz für meine Arbeit stand mir in weiten Teilen die ozielle und frei verfügbare IBM Dokumentation zur Hand. Hierbei lernte ich auch, wie man sich in solchen umfangreichen Dokumentationen zurecht ndet und schnell verlässliche Quellen und benötigtes Wissen ndet z/os Die von mir entwickelten Workloads, sollten auf der z/os Version der DB2 Datenbank laufen. Daher musste ich mich von Zeit zu Zeit auch auf diesem Betriebssystem bewegen, um z.b. die Ausführung von Workloads zu überprüfen. Zur Kontrolle der Workloads zog ich vor allem das VTAM Interface heran. Dieses bietet einen zeilenbasierten Zugri auf den Performance Expert auf z/os. Da ich noch nie mit einer Terminalanwendung auf einem Groÿrechner gearbeitet habe, bedeutete dies für mich eine groÿe Umstellung. Jedoch konnte ich auch auf diesem, für mich neuem Gebiet, eine Mengen Wissen für mein Studium und meine spätere Arbeit mitnehmen. Ich habe gelernt wie ein Groÿrechner in groben Zügen funktioniert und aufgebaut ist. Auÿerdem konnte ich viel über den Einsatz und den Umgang mit solchen System lernen. Die IBM konnte mir dieses Wissen zudem aus erster Hand vermitteln. Abbildung 2.7: Das VTAM Interface 38