Die IBM AS/400 kennt eine Menge Möglichkeiten und Technologien, um an Daten zu kommen und nicht immer ist es einfach herauszufinden wie man am schnellsten zu ergebnissen kommt. Eine Eigenart des Systems ist z.B. die unterscheidung von logischen Dateien und SQL Index Daten.
Inhaltlich bilden beide so ziemlich das selbe ab, haben aber eine komplett unterschiedliche Historie. Zwar können sowohl RPG/COBOL Programme als auch JDBC/SQL Anweisungen von beiden Index Daten profitieren, im Detail gibt es aber doch Unterschiede in der Handhabung. Heute bin ich auf ein (wenn auch etwas älteres) Paper von IBM gestoßen welches das ganze recht anschaulich illustriert.
In meinen letzten Projekten hab ich eine Menge neue Erfahrungen über eine ganz alte Maschine gemacht. Während ich bisher im wesentlichen mit PC basierten Systemen (Windows, Solaris, Unix) zu tun hatte, setzen meine derzeitigen Kunden die IBM AS/400 als zentralen Datenbankserver ein (das System hat in der Zwischenzeit einige Namensänderungen hinter sich, der Begriff AS/400 ist aber nach wie vor am weitesten verbreitet). Die Maschine stammt auf den 80er und wurde als integrierter Server mit für die Datenverwaltung in mittelständischen Betrieben konzipiert. Dabei wurde Software und Hardware als Bundle geschnürt und der Kunde hatte praktisch eine Komplettlösung für seine Unternehmssoftware. Der Zugriff erfolgte dann über Terminals. Software war textbasiert und wurde oft in COBOL oder RPG geschrieben.
Da dieser Systeme oft den Kern der betrieblichen Anwendungen bilden, haben sie bei vielen mittelständischen Kunden überlebt. Zwar kommen heute keine Terminals mehr zum Einsatz, sondern Windows basierte Emulationen, dere Text basierte Zugriff scheint aber in vielen Unternehmen nach wie vor gang und gebe zu sein.
Nun hatte ich die Aufgabe auf die Daten in einem solchen System mit Java zuzugreifen. Von großem Vorteil ist es das IBM das AS/400 Toolbox Projekt massiv unterstützt, es bietet mit dem Treiber com.ibm.as400.access.AS400JDBCDriver einen vollwertigen JDBC Treiber liefert mit dem man auf die Datenbank zugreifen kann.
Wie so oft liegt der Teufel aber hier im Detail, so dass einige Besonderheiten zu beachten sind:
- auf der AS/400 spricht man nicht von SQL Schema sondern von Bibliotheken, technisch ist das das selbe aber man redet gerne aneinander vorbei. Erschwerend kommt hinzu, dass auf der Plattform das Trennzeichen zwischen Schemaname und Tabellenname konfigurierbar ist, default ist der Slash (‘/’) nicht wie bei JDBC SQL der Punkt (‘.’):
- der AS/400 Treiber fragt bei einem falschen Kennwort/Benutzernamen in der Regel interaktiv (sprich mit einer Swing GUI) nach dem korrekten Benutzernamen, möchte man dieses Verhalten (z.B. bei einer Webanwendung) nicht haben muss man explizit prompt=false bei der Connection URL mitgeben
- die AS/400 unterstützt keine in Memory Transaktionen, spricht man kann i.d.R. nicht so einfach Daten via SQL schreiben. Um Daten in eine AS/400 Tabelle schreiben zu können muss diese journalisiert sein. Dazu muss mit einem Verwaltungstool für die entsprechende Tabelle ein Journalreceiver erstellt und die Journalisierung explizit gestartet werden. Mach man das nicht bekommt man nur kryptische Fehlermeldungen.
- auf der AS/400 können pro Tabellenspalte unterschiedliche Zeichensätze verwendet werden. Per default sind die Tabellen i.d.R. nicht UNICODE fähig so dass man oft Probleme mit Internationalen Zeichen bekommt. Wenn man die Möglichkeit hat ein eigenes Datenmodell zu erstellen, ist es empfehlenswert Texte in einer Spalte vom Typ VARGRAPHIC (eine Spezielle VARCHAR Variante) mit einer CCSID von 13488 zu erstellen. Ist die Tabellendefinition dagegen vorgegeben wird das ganze etwas komplizierter.
- stammen die Daten aus einer Legacy Anwendung werden häufig Tabellenspalten mit fixen Breiten verwendet, sprich man erhält eine Sting der jeweils mit Leerzeichen aufgefüllt ist. Für die Anwendung in Webanwendung muss man dann in der Regel jeweils explzit ein .trim() aufrufen.