-Herr Mergard, welchen Anlaß kann ein EDV-Anwender haben, mit fremder System-Software herumzuspielen, wenn ihm doch vom EDV-Hersteller eine Maschine hingestellt wird, bei der er den Schlüssel umdreht und losfährt.
Der kann wohl losfahren. Aber es ist wie beim Auto ein Unterschied, ob er dreißig oder nur zehn Liter Sprit braucht...
-... und Sie, als Systemsoftware-Werkstatt, würden den Vergaser einstellen?
Das kommt darauf an, wie groß das Softwarehaus, wie groß die Werkstatt ist. Sie müßten sich schon eine Werkstatt suchen, die zumindest den CO-Wert an ihrem Wagen messen kann. Ohne Meßgerät wird es wieder nur ein handeingestellter Vergaser. Das heißt: Ein Softwarehaus ohne Performance-Meßinstrumente kann keine gute System-Software bauen. Es müßte viel mehr Performance-Meßinstrumente auf dem Markt geben.
- Empfehlen Sie dem Anwender, konkret nach Meßmethoden zu fragen, wenn er sein Operating-System optimieren will und ein Softwarehaus kontaktiert?
Er soll fragen, womit die Systemlast gemessen wird. Denn es gibt genügend Tricks, daß einem ohne Performance-Meßinstrument angst und bange wird: Wie wollen Sie denn sonst feststellen, ob einer zum Beispiel alle Pages im VS fixed und damit alle anderen Partitions deaktiviert?
- Nun dürften aber Anwender, ehe sie sich für so einen Betriebssystem-Optimizer entscheiden, in der Regel eine vergleichende Produktauswahl treffen.
Die haben die Instrumente nicht. Wir sehen ja, was draußen am Markt ist. Und wenn ich beispielsweise einen Disc-Monitor nehme, mit dem ich auf einer 148er drei Stunden Verwaltungszeit pro Tag brauche, dann kann ich doch nicht sagen. Weil's das einzige Produkt ist, nehme ich's trotzdem. Da ist es doch effizienter, den Plattenplatz wieder von Hand zuzuordnen.
- Nun werden aber solche Dienstprogramme eingesetzt, weil sie gegenüber dem bisherigen Zustand immerhin eine Verbesserung bringen.
Drei Stunden Verwaltungszeit sind keine Verbesserung, die kann man nicht einholen. Nun sind in den jetzigen IBM-Betriebssystemen überall Probleme drin, weil sie vom Ursprung her für Single-Batch-Betrieb entwickelt wurden. Einfach einen Spooler mitzuliefern und zu sagen, jetzt könnt ihr Multi-Programming fahren, das beseitigt keine Engpässe im Betriebssystem.
- Aber der Hersteller beseitigt doch auch selbst solche Engpässe.
Ja. Ein solcher Weg für IBM dürfte sein, daß zum Beispiel Plattenlaufwerke mit mehreren Zugriffsarmen und mehreren Leseköpfen geliefert werden und daß derjenige Zugriffsarm lesen wird, der am dichtesten an der Datei steht. Aber: Solche Engpässe kann man eben erst beseitigen, wenn man sie erkannt hat.
- Können Sie angeben, nach welchen Kriterien Softwareprodukte, die diese Engpässe beseitigen, auszuwählen sind?
So können Sie mich nicht fragen. Natürlich gibt's für jedes Software-Produkt andere Maßzahlen. Also muß für jedes Produkt ein eigenes Meßinstrument, eine eigene Maßzahl entwickelt werden.
- Ist das nicht ein Widerspruch? Auf der einen Seite wollen Anwender solche Instrumente, auf der anderen Seite wenden sie diese nicht an?
Wenn ich jetzt vom Anwender spreche, dann meine ich, daß zwar die Leute in der Systemgruppe diese Probleme sehen. Aber wenn jetzt dessen Vorgesetzter anordnet: Erst machen wir dies und das und der Systemmann kommt gar nicht zu seinem Benchmark, weil er die Zeit dafür nicht bekommt, dann kann er daran nichts ändern. Praktisch ist das Problem zwar erkannt, aber dennoch werden selbst in Unternehmen, die monatlich vierhundert-, fünfhunderttausen Mark EDV-Budget verbraten, keine System-Tuner eingestellt, obwohl ich ganz sicher bin, daß man da ganz erheblich Maschinenkosten reduzieren kann.
- Um die Performance zu verbessern, müssen Sie einmal herstellerabhängige, dann firmenspezifische und zudem produktabhängige Probleme lösen. Da haben wir gleich die Kennfrage: Gibt es überhaupt eine allgemein gültige Bewertungsgrundlage, von der man ausgehen kann?
Ja doch, die gibt es, die kann man zur Verfügung stellen. Wenn wir jetzt zum Beispiel mal über ein Lohn- und Gehaltssystem diskutieren, das auf IBM läuft und mit allen Testhilfen implementiert wird, kann ich Ihnen erschreckende Zahlen nennen: Da haben wir bei einigen Kunden nachgemessen, daß die CPU über mehrere Stunden zu hundert Prozent ausgelastet ist, weil dieses Programm über weite Strecken 95 Prozent CPU-Auslastung verursacht. Da waren alle Testhilfen mit einem Handgriff aus dem Programm zu entfernen, und dann lief das nur noch zehn, zwanzig Minuten. So etwas ist doch ein Lorbeerkranzsystem, das man vom Anwender ,her direkt herauspicken müßte. Denn ein Programm, das mir meine CPU zu 95 Prozent zumacht, das ist für mich kein Lohn- und Gehaltssystem.
- Wenn die Systemoptimierung so einfach wäre, wie Sie es sagen...
Die ist so einfach, wenn man das entsprechende Instrument hat. Die Leute in unserem Geschäft haben alle Logik, das kann jeder.
- Wenn's jeder kann, warum lassen es die Anwender dann schleifen?
Die Anlage ist eine reine black box. Solange ich da nicht eine Anzeige habe, an der ich die CPU-Belastung ablesen kann, solange weiß ich nicht, was sich tut.
- Nun gibt's aber erfahrene Anwender, die das durchaus wissen.
Es gibt vielleicht vierzig, fünfzig Measurement-Profis in der Bundesrepublik, die sehr gut sind und ihre Probleme lösen können.
-Sie meinen die ECOMA-Leute?
Ja, obwohl die recht viel theoretisieren. Das ist zwar auch wichtig, aber beim Softwarehaus muß eben Geld rauskommen, während die beim Anwender viel mehr nachdenken und Ideen produzieren können, die sich im Prinzip nie vermarkten ließen. Aber was mir echt wehtut, wenn ich rauskomme zum Anwender, ist, zu sehen, wie teure Maschinenzeit einfach verschwendet wird. Da ist die Anlage täglich randvoll - dennoch wird einfach kein Tuner eingestellt, obwohl der in jede Firma gehörte.
-Warum ist für viele Anwender die Auslastung eine heilige Kuh? Liegt es an der Akzeptanz? Liegt es an den Zeitproblemen?
Es fehlt ein Instrument, das dem Anwender klarmacht, wieviel Geld er mit lahmen Systemläufen vertut. Aber dazu muß man erst wissen, woran es liegt - und solange das ein Abteilungsleiter oder Vorstand nicht weiß, übernimmt der die Kosten für ein Optimierungs-Werkzeug nicht.
-Nun geht es aber nicht nur um reine Software - ganz ausklammern kann man auch die Hardware nicht. Es ist ja nicht der Hauptspeicher, der heute Geld kostet, sondern es sind die Channels: Und wenn ich nun sage, ich will mehr Schnelligkeit, dafür muß aber noch ein Kanal dran, dann kostet mich das eben soundso viel. Für Ihre Beratung, das Werkzeug und die Einführung muß ich auch was hinlegen. Da weiß ich noch gar nicht, ob das etwas bringt. Also bin ich lieber etwas lahmer und spare Geld!
Daß das im Prinzip nicht stimmt, dafür kann ich Beispiele bringen: Wir haben drei Kunden, die hatten die 135 voll ausgelastet und gesagt, da kommt nichts mehr raus. Nur warum, das wußte sie nicht. Dann haben sie bei IBM im Rechenzentrum gesehen, daß sie 30 bis 40 Prozent Einsparung kriegen, wenn sie auf die 145 gehen. Tatsächlich aber haben sie bei den meisten Programmen die gleichen Laufzeiten erzielt, nur die CPU-intensiven waren ein bißchen schneller - aber generell kamen die gleichen Resultate heraus. Was den Leuten tatsächlich was gebracht hat, war, einen zweiten Kanal daranzuhängen. Das hätten sie aber auch bei der 135 haben können. So aber haben sie mehr Geld für die 145 hingelegt und dann erst noch einen zweiten Kanal anhängen müssen. Das hätten sie sich durch einen Gang zum Systemsoftwarehaus sparen können.
-Und wie hat IBM beraten?
Die haben sich mit ihm über die nächstgrößere CPU unterhalten.
-Ist das Ihre generelle Aussage, daß IBM immer nur zum größeren System rät?
Ich würde sagen, die einzelnen Mitarbeiter, die von IBM ins Haus kommen, haben ja oft auch nicht das Instrument, um einen Rat zu geben. Wer entscheidet denn über die größere Anlage? Da sitzt der EDV-Leiter oder Abteilungsdirektor mit dem IBM-VB zusammen, und wenn es heißt, unsere Anlage ist zu, dann rät der VB "Nehmen sie doch das nächstgrößere System" - und schon ist's passiert.
-Der Weg des geringsten Widerstandes?
Nein. Aber der VB, der doch selbst durch Upgrades viel Geld machen könnte, schafft es ja auch nicht, die Ursache des Engpasses nachzuweisen, wenn einer zum Beispiel soviel Deaktivation hat, daß er nur noch 15 Minuten echt arbeiten kann. Er müßte also mehr K's haben. Weil ihm aber am IBM-System nicht aufgezeigt wird, daß er deaktiviert ist, erkennt er's nicht und weiß nicht, wo sein Problem liegt.
-Aber man kann Tuning-Entscheidungen nicht nur an reinen Betriebssystem-Aktivitäten ausrichten. So eine Entscheidung muß doch auch Anwendungs-Aspekte berücksichtigen.
Sicher. Solange ich nicht erkenne, woran es liegt, daß ich so lahm bin, würde auch ich nicht gleich ins Betriebssystem zum Tunen schreiten, sondern mal meine Anwenderprogramme in Trab bringen. Erst dann würde ich etwas an Betriebssystem-Pflege tun.
-Das scheint uns aber tiefer zu gehen: Wir haben doch viele Anwender, die drei IBM-Generationen vernascht haben, ihre Anwendungs-Software aber im Prinzip eins zu eins übernommen haben. So wurden Fehler praktisch über Generationen mitgeschleppt - weshalb sich tatsächlich trotz neuer Hardware an der Laufzeit nichts geändert hat. Aber was soll der Anwender denn machen: Er kann die Programme doch nicht in den Papierkorb werfen. Er kann zwar das Programm einmal für 4000 Mark bei Ihnen optimieren lassen. Aber irgendwann wird's Leichenschändung. Und neu schreiben, das kostet 200 000 Mark.
Gut. Das Problem, das wir haben, ist: Die ganzen Software-Erstellungs-Methoden, mit denen wir im Moment arbeiten müssen, sind alle von der Konzeption total falsch. Es müßte ein System geben, das mir ein Programm erzeugt, das für jedes Design neu generiert werden kann. Warum muß ich jedesmal mein Programm neu schreiben? Warum habe ich keine standardisierte Formulierungssprache, die mir stets ein optimales Programm generiert?
-Wie viele Anwender, Herr Mergard, arbeiten nach Ihrer Ansicht zu teuer.
Vielleicht neunzig Prozent.
-Und um wieviel Prozent arbeiten diese neunzig Prozent zu teuer?
Das kann ich nicht sagen. Aber bestimmt arbeiten einige von denen um hundert Prozent zu teuer: Die bräuchten nämlich gar keine EDV.