SAP auf System z10

Auch der Schweizer Messgerätehersteller Endress+Hauser hat sich für zwei neue, voll ausgestattete System-z10-Maschinen für seine SAP-Umgebung entschieden. Dabei kommt IBMs neue Java Virtual Machine für zLinux, genannt J9, zum Einsatz. SAP selbst unterstützt J9 mit Java-Anwendungen, die auf Netweaver 6.4 und 7.0 basieren. Auch Java muss nicht auf den teuren Hauptprozessoren, sondern kann auf den Spezialprozessoren laufen. Damit senkt der schweizerische Hersteller seine Kosten erheblich. Da Endress+Hauser nur seine SAP-Anwendung auf dem Mainframe laufen lässt, wurde vor der Entscheidung für die neuen Mainframes ein Betriebskostenvergleich zu anderen Plattformen angestellt. "Es hat sich herausgestellt, dass der Mainframe unterm Strich die günstigere Lösung darstellt. Und hierbei wurden etwaige Migrationskosten kaum berücksichtigt", sagt Hansjörg Klaiber, IT-Manager beim Freiburger Rechenzentrum von Endress+Hauser.

Durch die Verarbeitung von Workloads auf den Spezialprozessoren sparen Anwender mit alten Anwendungen, die auf Cobol, PL/I oder Cics basieren, allerdings wenig. Sie sind buchstäblich die "Gekniffenen" der traditionellen Lizenzpolitik von IBM. Solcherlei Programme müssen über die Standardprozessoren abgearbeitet werden. IBM rechnet dabei gnadenlos nach verbrauchter Rechenleistung ab. Verhandeln ist zwecklos.

"Mit einem Monopolisten zu verhandeln ist praktisch unmöglich", bestätigt Alfred Isenbeck, Director Infrastructure bei den LVM Versicherungen in Aachen. IBM hat seine Preistabelle, Rabatte gibt es nur innerhalb einer vorgegebenen Staffel, die Kriterien sind Volumen und Workload-Wachstum - Ende der Durchsage. "Kauf dich reich", heißt laut Isenbeck das Motto von IBM bei solchen Verhandlungen. Wer mehr Rechenleistung kauft, bekommt bessere Preise. "Wenn dein Gegenüber weiß, dass du keine Alternative hast, braucht es nicht groß zu verhandeln."

Traditionelle IBM-Kunden, vor allem Unternehmen aus dem Bereich Finanzdienstleistungen, die ihre hausgemachten Kernanwendungen immer noch auf Basis älterer Programmiersprachen fahren, werden es noch eine Weile mit dieser Situation aushalten müssen. Wie lange, hängt auch von ihnen selbst ab. Für diejenigen, für die eine Migration auf eine andere Plattform nicht in Frage kommt, lautet die Lösung: Programme neu schreiben.

So wie die meisten Versicherer macht auch die LVM genau das. "Unsere Entwicklung konzentriert sich zunächst auf die verteilten Anwendungen", sagt Isenbeck. "Statt aber den alten Code zu migrieren, schreiben wir die Anwendungen komplett neu in Java. Damit können wir sie auch auf p- oder xSeries-Maschinen laufen lassen." Ein solcher Zyklus dauert allerdings zwei bis drei Jahre pro Anwendung. LVM hat immerhin schon die Hälfte seiner Anwendungen von PL/I auf Java übertragen. Die Versicherungs-Kernanwendung läuft derweil "gekapselt" weiter auf dem Mainframe.