Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

28.02.1992

Die Mär vom Mainframe als Datenserver

Manfred Gahr,

selbständiger Unternehmensberater und technischer Leiter für die Neugestaltung der kommerziellen DV bei einem deutschen Großunternehmen

Im Rückzugsgefecht der Großrechnerhersteller ist immer häufiger die Rede vom Mainframe als Daten-Server. Nur auf einem "Dinosaurier" seien die Daten wirklich sicher, und nur ein Mainframe sei aufgrund seiner seit 30 Jahren bewährten Architektur in der Lage, Daten mit vernünftigen Response-Zeiten zur Verfügung zu stellen. Lediglich für den Front-end-Bereich sei es möglicherweise sinnvoller, einen Applikations-Server einzusetzen, vielleicht ein Unix-System.

Wenn man einem Mainframe Spezialisten den Prospekt eines Unix-Systems unter die Nase hält und die Frage stellt, warum denn eigentlich im Mainframe-Bereich 1 MB Memory 20mal soviel kosten muß wie im Unix-Bereich und warum es sich mit den Magnetplatten genauso verhält, so wird dieser genervt antworten: "Diese Daten sind überhaupt nicht miteinander vergleichbar!". Anschließend wird er üblicherweise jedes weitere Gespräch mit einem so inkompetenten Mitmenschen verzeigern. Bytes sind schließlich nicht gleich Bytes und MIPS nicht gleich MIPS.

Auf drängende Kostenfragen antworten die Hersteller nur selten. Warum muß allein die Betriebssystem-Miete eine Viertelmillion pro Jahr betragen? Warum ist die Wartung so horrend teuer? Warum muß für die Lizenz der Datenbank, des Compilers oder der Plotter-Software ein sechs- oder siebenstelliger Betrag auf den Tisch gelegt werden, während im Unix-Bereich nur ein vier- oder fünfstelliger verlangt wird?

Die Frage, warum die Magnetplatten mit einer Kapazität von IGB noch immer die Größe eines Kleiderschrankes haben, wagt der Kunde gar nicht mehr zu stellen. Sieht er sich die neuen Platten an, so weiß er sofort, daß nur im Mainframe-Bereich noch "ordentliche" Hardware produziert wird: ein koffergroßes Netzteil wandelt den Kraftstrom um, die Platinen sind noch anständig mit Wire-Wrap verdrahtet, armdicke Stränge aus Klingeldraht ziehen sich an Schwungscheiben und Keilriemen vorbei - das ist noch richtige Technik. Weniger überzeugend sind allerdings die technischen Daten.

Entsprechend flexibel muß sich der Mainframe-Spezialist bei der Vorstandsdebatte zur Diskussion des Hardware-Etats verhalten. Pflichtgemäß spricht er von den ungeheuren Belastungen des Dialogbetriebs auf dem Rechner, den erweiterten Anforderungen und daß die neue Datenbank, obgleich nicht relational, enorme Ressourcen verbraucht. Die Stellflächen werden zu klein, und eine neue Klimaanlage muß her, denn die neuen Platten heizen dem Rechenzentrum ganz schön ein.

Leider schraubt die schnellere CPU auch die Lizenzgebühren für alle Softwarepakete die Höhe, denn man ist in der nächsthöheren Leistungsklasse gelandet, aber der sechsstellige Zusatzbetrag wird im Betriebshaushalt schon irgendwie unterzubringen sei - Fortschritt verpflichte schließlich.

Ich behaupte: Teurer und ungünstiger als über einen Mainframe kann man keinen Daten-Server realisieren. Dazu möchte ich kurz die immer wiederkehrenden Argumente der Mainframer widerlegen.

Ein Mainframe ist aufgrund seines hohen Datendurchsatzes für eine Datenbank besonders geeignet.

Falsch! Für die Performance moderner relationaler Datenbanken sind drei Faktoren entscheidend: die Menge an Hauptspeicher (erste Priorität), der Kanaldurchsatz (zweite Priorität), die Rechenleistung (dritte Priorität). Moderne relationale Datenbanksysteme (RDBMS) wickeln alle Datenoperationen (Lesen, Schreiben, Joins, Sortieren) im Hauptspeicher ab, der über asynchrone Prozesse bedient wird.

Schreiboperationen werden zwar über einen synchronen After Image Log protokolliert, der aber ist selten Performance-kritisch. Stellt man einem RDBMS genügend Hauptspeicher zur Verfügung, so kann im kommerziellen Mischbetrieb die Rechenleistung sogar noch eher als der Datendurchsatz zum Bottleneck werden: Das "Parsen" der SQL-Anweisungen, Sortieren, Vergleiches, "Joinen" etc. erfordern viel Rechenleistung. Diese ist ebenso wie Hauptspeicher im Mainframe-Bereich extrem teuer, im Unix-Umfeld dagegen kostengünstig.

Für viele Anwender, die Transaktionsserarbeitung machen wollen, wird ein Transaktionsmonitor benötigt - vernünftige gibt es aber nur für Mainframes.

Falsch! Ein Transaktionsmonitor hat im wesentlichen drei Aufgaben: Sicherung der Back-end-Transaktion (Daten), Sicherung der Front-end-Transaktion (Bildschirmausgabe), Re-Entrant-code-Verarbeitung (Teilhaberbetrieb). Alle RDBMS verfügen jedoch über ausgefeilte Verfahren zur Sicherung der Back-end-Transaktionen, die sich in der Regel mit einem Transaktionsmonitor gar nicht vertragen beziehungsweise diesen nicht erfordern.

Verfahren zur Sicherung der Front-end-Transaktionen bei tastensensitiven Dialogen und Window-orientierten Systemen sind mir nicht bekannt, auf jeden Fall leisten dies gängige Mainframe-Transaktionsmonitore nicht. Schließlich kann auf Unix-Systemen jedes Programm re-entrant gefahren werden, ohne daß das Programm hierfür modifiziert werden muß - ein ohnehin wesentlich intelligenteres Konzept.

Ein Time-slice-orientiertes Betriebssystem ist für viele Transaktions-Anwender besser geeignet als ein Interrupt-orientiertes System.

Falsch! Bei tastensensitiven Dialogen werden eine Unzahl kleiner und sehr kleiner Datenbankabfragen abgesetzt, beim Aufruf einer einzigen Maske ohne weiteres bis zu 50. Im kommerziellen Mischbetrieb ist es sinnvoller, wenn diese Interrupt-orientiert zu größeren Queries quasi-parallel abgearbeitet werden, um gute Response-Zeiten zu erhalten.

Mainframes haben eine höhere Verfügbarkeit.

Falsch, vorausgesetzt ein Unix-System wird genauso professionell administriert wie ein Mainframe.

Hohe Transaktionsraten lassen sich nur über einen Mainframe erzielen.

Falsch! Die Transaktions-Olympiaden von RDBMS-Herstellern werden fast ausnahmslos auf Unix-Rechnern gefahren. Dabei sind Leistungen von mehreren hundert Transaktionen pro Sekunde erzielt worden - weit mehr als in mittleren und großen Unternehmen in der Regel benötigt wird.

Es bleibt wenig übrig, was für einen Mainframe spricht, aber einiges, was gegen ihn spricht:

Einsatzbreite: Ein Unix-System ist für Bitmap-, Grafik- und Window-orientierte Oberflächen ebenso geeignet wie für die Transaktionsverarbeitung eines RDBMS. RISC-Rechner unter Unix und relationale Datenbanken passen sehr gut zusammen. Damit können Applikations- und Daten-Server also aus derselben Systemfamilie stammen - das macht die Betreuung erheblich einfacher und kostengünstiger.

Performance: Unix ist ein Betriebssystem, das sich recht mühelos auf jede beliebige Prozessorarchitektur übertragen läßt, egal, ob es sich um RISC-, CISC- oder Parallel-Architekturen handelt. Es läuft dort im native mode, nicht als Emulation. Das ermöglicht Innovationszyklen bei der Hardware, von der Mainframe-Hersteller nicht einmal zu träumen wagen. Dem Endanwender stehen somit immer leistungsfähigere Systeme zur Verfügung.

Raum- und Energiebedarf: Unix-Systeme benötigen bei gleicher Leistung einen Bruchteil der Stellflächen und der elektrischen Energie von Mainframes.

Software-Angebot und Investitionsschutz: Unix entwickelt sich zum MS-DOS des Midrange- und Mainframe-Marktes. Ein Softwarehersteller muß sich heute genau überlegen, ob er auf ein Proprietary-System setzt, das möglicherweise bald aus der Produktion genommen wird (siehe 8870 von Nixdorf), für das keine vernünftigen Migrationspfade angeboten werden (siehe /36 von IBM) und mit dem er womöglich nur eine kleine Nachfrage befriedigen kann.

Ein Engagement im Unix-Bereich sichert ihm Investitionsschutz, denn wenn einer der Hardware- oder Systemanbieter aus dem Markt ausscheidet, wirft dieser Schritt keine gravierenden Probleme auf. Das gilt gleichermaßen auch für den Anwender. Dementsprechend vergrößerte sich das Software-Angebot in den letzten Jahren explosionsartig.

Kosteneinsparung: Wenn man über Kosteneinsparungen von Unix gegenüber Mainframes spricht, dann ist nicht die Rede von Prozentpunkten, dann geht es um Faktoren - zum Teil um zweistellige. Es fängt bei der Hardware an, bei den Raum- und Energiekosten, bei der entfallenden Miete für das Betriebssystem, den geringeren Wartungskosten und hört bei den Kosten für Compiler und Softwarepakete auf.

DV-Leiter werden sich künftig die Frage gefallen lassen müssen, warum für eine Mainframe-Platte 250 000 Mark hingeblättert werden, während eine vergleichbare Platte für einen Unix-Server für ein Zwanzigstel des Preises zu haben ist. Dabei entwickelt sich das Preis-Leistungs-Verhältnis derzeit sogar noch immer zugunsten von Unix. Aber Vorsicht: Wer sich einen Unix-Hardware-Zoo zulegt, muß mit einer aufwendigen Betreuung rechnen.

Der Mainframe als Dialogsystem ist mindestens ebensosehr in Frage zu stellen, wie der Mainframe als Daten-Server. Der Abloch-Arbeitsplatz, an dem von morgens bis abends Buchungen eingetippt werden, stirbt aus. Heute verlangt der Wettbewerbsdruck in vielen Bereichen ein dezentralisiertes Management mit hoher Kompetenz, umfassender Informationsmöglichkeit und kurzen Reaktionszeiten.

Dementsprechend wandeln sich die Anforderungen an einen Bildschirm Arbeitsplatz von einem Lochkarten-Ersatz zu einem multifunktionalen Terminal, das neben maskenorientierten Dialogen auch Grafiken, Spreadsheets und komplexe Dokumente verarbeiten und über Windows möglichst mehr als nur einen Dialog gleichzeitig führen können sollte. Von der Rechnungserfassung will der Anwender schnell in den Lieferantenstamm wechseln, nebenher noch einen Brief oder gleich ein Fax tippen, an den Sachbearbeiter in der Außenstelle eine elektronische Mitteilung schicken, um dann mit der Rechnungserfassung fortzufahren.

Bei diesen Anforderungen scheiden klassische Blockmode-Dialoge von Mainframe-Systemen aus: Nicht einmal ein Fließtext mit automatischem Zeilenumbruch läßt sich dort sinnvoll erfassen - von Spreadsheets oder der interaktiven Erstellung von Grafiken ganz zu schweigen. Den Mainframe-Herstellern ist dieses Dilemma seit langem bekannt, allerdings kommen sie von der veralteten Dialogtechnik so leicht nicht weg.

Als Ausweg wird das Ankoppeln peripherer Systeme, zum Beispiel PCs, empfohlen. Hier kann der Anwender wenigstens von der Dialoganwendung in eine vernünftige Textverarbeitung wechseln oder sich über viele Zwischenschritte die Betriebsdaten in ein Spreadsheet laden und diese lokal weiterverarbeiten. Mit der Datenintegration hapert es dann natürlich.

Ist schon das Herunterladen von Daten aufwendig, so bereitet die Re-lntegration von Daten, die am PC bearbeitet wurden, noch erheblich größere Probleme. Die Folge ist, daß darauf meistens verzichtet wird. Die Daten bleiben auf dem PC, womit sich der nächste Problemkreis öffnet: Datenschutz und Datensicherheit am PC.

Wenigstens der Maskendialog schien bisher die unangefochtene Domäne der Mainframes zu sein - doch auch das ändert sich. Heute möchte man auch in kommerziellen Anwendungen über Pop-up-Funktionen verfügen: zum Nachschlagen von Ordnungsbegriffen oder Stammdaten, um schnell etwas zu ändern, um den Bildschirm leerer zu bekommen, um den Kontext einer Bearbeitung sehen zu können oder um schnell einen anderen Vorgang zu erledigen, weil gerade der Kunde am Telefon ist. Eine Prüfung soll nicht erst möglich sein, wenn eine Maske komplett eingetippt ist, sondern wenn sich der Fehler erkennen läßt. Anwender möchten nicht nur blättern, sie wollen auch zeilenweise rollen. Man möchte über eine Pop-up-Funktion auf die Schnelle den Auftragstext erfassen, natürlich als Fließtext mit automatischem Zeilenumbruch und vielleicht sogar mit Silbentrennung - beim Mainframe alles Fehlanzeige, die alte Dialogtechnik gibt das nicht her.

Bedeutet Unix-Einsatz den Umstieg in eine heile Welt? Keinesfalls, Unix trägt heute noch teilweise studentische Handschriften aus den Entwicklungslabors, und man sollte sich vor einem Anbieter hüten, der Hardware aus allen möglichen Komponenten zusammenschraubt, sein Firmenlogo aufklebt und dann das Unix-Band ungesehen darauf installiert. Aber schließlich gab es auch IBM-Betriebssysteme mit über 30 000 berichteten Fehlern. Warum also mehr für die Fehler zahlen als nötig?

Bislang galt das Sprichwort: "nobody got fired for buying IBM." Diese Regel könnte bald ungültig werden. Wer heute unbesehen Mainframe-Hardware einkauft, teilweise überholte Technologien zu exorbitanten Preisen erwirbt und damit die Wettbewerbsfähigkeit seines Unternehmens gefährdet, der könnte sich rascher beim Arbeitsamt wiederfinden, als ihm lieb sein kann. Zumindest für mittelgroße Unternehmen stellt sich die Frage nach einem Mainframe heute nicht mehr. Es gibt Besseres und Billigeres.