Mit Dipl.-Ing. Wilhelm Breuß, Leiter der EDV-Abteilung bei der Österreichischen Donaukraftwerke AG, Wien, sprach Dr. Gerhard Maurer:

Dipl.-Ing. Wilhelm Breuß (49)

ist Leiter der EDV-Abteilung bei der Österreichische Donaukraftwerke AG, die mit vier fertiggestellten Donaukraftwerken der größte Stromerzeuger Österreichs ist. Jährlich werden etwa zwei Milliarden Schilling für den Ausbau weiterer Kraftwerke investiert. Der Rationalisierung in der Projektierung, beim Bau und beim Betrieb von Kraftwerken, kommt also große Bedeutung zu, so daß neben den üblicher kaufmännischen-administrativen Arbeiten vielfältige technisch-wissenschaftliche Aufgaben hinzukommen (lineare Programmierung, Netzplantechnik, Einsatz von Plotter und Digitalisierungsgeräten). Eine Prozeßrechner-Steuerung der Kraftwerkskette wird geplant. Breuß: "Wenn es uns gelingt, diese für unser Unternehmen bedeutenden Aufgaben mit relativ bescheidenen aber gut eingesetzten Mitteln zu lösen, dann bin ich mit meiner Rolle als Leiter einer >Klein-EDV< durchaus zufrieden.

Breuß, der bereits 20 Jahre in seiner Firma arbeitet, erhielt 1959 für die Vermessungsabteilung einen Zuse-Rechner danach wurde er mit dem Aufbau der EDV-Abteilung beauftragt, in er heute eine 370/125 steht.

- Auf Ihrem System, einer IBM 370/125 mit 192 K. laufen etwa 60 Prozent technische Anwendungen und 40 Prozent kommerzielle Arbeiten. Welche Besonderheiten ergeben sich daraus gegenüber den Rechenzentren, die nur kommerzielle Arbeiten erledigen?

Bei einer Mischung von kommerziellen und technischen Arbeiten besteht eine bessere Möglichkeit, die Gesamtkonfiguration optimal auszunützen. Die technischen Arbeiten sind im allgemeinen mehr CPU-intensiv als kaufmännische Arbeiten, so daß eine Mischung zu einer guten Nutzung des gesamten Systems führt.

- Wie ermitteln Sie welche Jobs Sie am besten mit welchen der anderen Kategorie zusammenlaufen lassen?

Wir nutzen die DOS-Job-Accounting Daten, retten die auf eine Platte und machen aus diesen Daten eine monatliche Auswertung, in der für jeden Job Verweilzeiten und CPU-Zeiten - aufgeschlüsselt nach Test und Produktion - ersichtlich sind. Zusätzlich ist auf diesen Listen pro Job seitlich ein Balken mit angedruckt, der die Jobs mit Extremwerten optisch signalisiert.

- Wie sieht das in der Praxis aus?

Ich habe ja nicht immer alle Jobs zur Verfügung. Daher geschieht in der Praxis folgendes: Es werden in einer Partition mit höherer Priorität die anfallenden kaufmännischen Arbeiten gefahren, die - mit ganz wenigen bekannten Ausnahmen - ein/ausgabeintensiv sind. Des weiteren habe ich meistens eine Anzahl von etwa fünf sehr CPU-intensiven technischen Arbeiten sozusagen "auf Lager". Das sind Forschungsarbeiten, die sich auf Jahre hinziehen und monatlich etwa 70 CPU-Stunden verbrauchen. Diese Arbeiten werden in einer Partition mit niedrigster Priorität gefahren und sollen die in den Partitions mit höherer Priorität anfallenden Wait-Zeiten sinnvoll nutzen.

- Natürlich interessiert jetzt die CPU-Auslastung Ihrer Anlage. Wenn CPU-Intensität definiert ist als reine CPU-Zeit im Verhältnis zur Summe aus CPU-Zeit, Overhead und Wait-Zeit, welchen Wert erzielen Sie?

Der Wert schwankt zwischen 55 und 70 Prozent, je nach anfallenden technischen Arbeiten.

- Wie ist Ihr Hauptspeicher von 192 K aufgeteilt?

Wir fahren DOS/VS mit Power/Real und haben derzeit einen Systemanteil von 72 K. Im DOS verwenden wir fünf Partitions, wobei der F1 für Power verwendet wird. Im F2 lauft ständig ein Plotter/Spool-Programm, das nur 4 K braucht. Im F3 sind die normalen kaufmännischen Arbeiten und sonstigen Arbeiten, die Bänder benötigen. Im BG lauten alle Umwandlungen und alle technischen Arbeiten, die kein Band benötigen. Im F4 lassen wir spezielle technische Arbeiten, die im wesentlichen nur CPU-Zeit brauchen (im Monat etwa 50 Stunden), still vor sich hinarbeiten und die in den übrigen Partitions anfallenden Waits schlucken.

- Sie fahren das DOS/VS Release 28. Um wieviel überziehen Sie Ihr Bankkonto? Wie ist das Verhältnis virtuell beanspruchter Speicherraum zu realem Hauptspeicher?

Seit wir mit 4 Arbeitspartitions und Power fahren und 192 K Zur Verfügung haben, ist das Verhältnis etwa 1 : 1,4. Als wir unsere 125 bekamen, hatten wir nur 128 K zur Verfügung. Das war für einen Drei-Partitions-Betrieb, selbst wenn man berücksichtigt, daß die Plott-Partition nur 4 K verbraucht, nur mit Einschränkungen sinnvoll. Wir hatten zwar die meisten Programme von früher her relativ klein ausgelegt, so daß durchaus zwei kommerzielle Arbeiten nebeneinander laufen konnten, ohne Paging-Aktivitäten auszulösen. Sobald aber ein großes technisches Programm zusammen mit einer Umwandlung laufen mußte - wir verwenden den PL 1 Optimizing Compiler - stiegen die Umwandlungszeiten sehr stark an, so daß wir dem Operating die Anweisung geben mußten, Umwandlungen nicht mit gewissen technischen Arbeiten gemeinsam laufen zu lassen.

- Sie spoolen Ihre Druckausgabe, arbeiten aber noch mit dem Power/Real. Wann kommt Power/VS?

Wir möchten bald auf Power/VS übergehen, da wir davon doch einiges erwarten dürfen. Derzeit ist unser Drucker nur ungefähr 15 Prozent der gesamten Einschaltzeit aktiv, noch krasser ist das Verhältnis beim Kartenleser und -stanzer Ein virtuelles Power müßte uns also einen beträchtlichen Gewinn an nutzbarem Hauptspeicher bringen. Jetzt, kostet uns Power/Real 30 K, die die ganze Einsatzzeit über für die übrigen Partitions verloren sind. Später würden wir zwar auch 30 K, wahrscheinlich sogar etwas mehr zuordnen, aber dieser Hauptspeicher ist ja nur etwa 15 Prozent der Gesamtzeit für die übrigen Partitions verloren.

- Wann wollen sie Power/VS einsetzen?

Ein erster Versuch, Power/VS mit Release 28 zu kombinieren, ist vor einigen Monaten fehlgeschlagen. Dergleichen war von IBM ja auch nicht vorgesehen, es war uns aber bekannt, daß es IBM-Kunden gibt, die mit Release 29, wo ebenfalls ein Einsatz von Power/VS nicht vorgesehen ist, diese Möglichkeiten erfolgreich realisiert haben. Derzeit laufen bei uns die Arbeiten für die Umstellung auf Release 30, anschließend soll die Umstellung auf Power/VS erfolgen.

- Man hört allerorten von Schwierigkeiten bei der Einführung des Release 30. Angeblich sollen IBM-SEs selber vor dieser Betriebssystem-Version warnen. Release 31 soll Mitte des Jahres kommen. Haben Sie Ähnliches gehört?

Ich habe diese Gerüchte erst vor kurzem gehört. Unsere ersten Versuche mit Release 30 haben zu Schwierigkeiten geführt, so daß wir die Einführung der fünften Partition, die wir zunächst erst mit Release 30 vornehmen wollten, inzwischen in Release 28 durchgeführt haben. Ich werde versuchen, weitere Informationen über Release 30 zu erhalten. Falls sich diese Gerüchte bestätigen sollten, würden wir wahrscheinlich Release 31 abwarten.

- Sind Sie eigentlich grundsätzlich ein Pionier, der jedes Release in der ersten Stunde gleich übernimmt?

Wir versuchen zunächst einmal, möglichst lang mit einem bestehenden Release zu fahren und übernahmen ein neues Release nur dann, wenn wir uns wesentliche Vorteile davon versprechen. Beim Release 30 ist aus der Sicht unserer Anwendungen besonders interessant erstens die Möglichkeit, Power/VS zu fahren, zweitens die neue Art der Speicherung der Core Image Library, von der wir uns die Möglichkeit versprechen, in einer Shared-Virtual-Area verschiedene Komponenten unterzubringen, die die Ladezeiten verkürzen. Ich muß dazu erwähnen, daß wir sehr viele Kurz-Jobs haben, bei denen die Ladezeit ins Gewicht fällt. Aus diesem Grund wollten wir das Release 30 übernehmen, obwohl uns bewußt ist, daß dies ein gewisses Risiko darstellt, - weil ja in diesem Release bedeutende Veränderungen gegenüber früheren Versionen vorgenommen wurden.

- Was kann man als Anwender von Mittel- und Kleinsystemen von den Großen lernen?

Bei großen EDV-Installationen ist der gesamte EDV-Betrieb zur Routine geworden. Die kleinen Installationen werden vielfach noch im Pionierstil betrieben. Hier müßte im Laufe der Zeit eine gewisse Angleichung an die Großen erfolgen.

- Sie plädieren also für mehr Systematik, für mehr Effizienz, eigentlich für besseres Management bei Kleinanlagen?

Ja, das ist richtig. Ich möchte das noch etwas spezifizieren: Wirksamere Methoden in der Programmierung, besseres Management von EDV-Projekten, Effizienz in den Arbeitsabläufen und Transparenz in den Kosten.

- Schneiden wir die vier Punkte doch kurz an: Wie konnten Sie wirksamere Methoden der Programmierung bei Ihnen einführen?

Ich möchte hier drei Hauptpunkte nennen. Erstens: Grundsätzliche Verwendung von höheren Programmiersprachen. Wir verwenden mit ganz geringen Ausnahmen PL 1 als Programmiersprache. Zweitens: Verwendung eines selbstgebauten Pre-Prozessors, der sämtliche Strukturen, sämtliche Dateien und gewisse Standard-Routinen mit wenigen Karten aufrufbar macht. Drittens: Strukturierter Aufbau der Programme in Anlehnung an den Aufbau der normierten Programmierung. Meine sechs Mitarbeiter in der Programmierung und ich haben diese Standards gemeinsam erarbeitet und sie werden auch eingehalten.

- Was tut sich bei den Donaukraftwerken in Dingen "Projekt-Management" ?

Ich habe vorhin gesagt: Da können wir von den Großen lernen. Das ist ein Punkt, wo wir noch aufzuholen haben.

- Wie sieht es aus mit mehr Effizienz in den Arbeitsabläufen im Rechenzentrumsbetrieb?

Was sicher nicht überall bei einer Maschine von der Größenordnung 370/125 der Fall ist - wir arbeiten in einem strikten Closed Shop-Betrieb. Dazu kommt, da wir mit wenig Arbeitsvorbereitung einen Fünf-Partition-Betrieb mit einer kleinen Operating-Mannschaft fahren können. Wir konnten durch fixe Zuordnungen der peripheren Einheiten zu den Partitions das Handling sehr vereinfachen. Dadurch ist es möglich, daß in einer Schicht jeweils nur ein Operator anwesend ist, der die laufenden Arbeiten einschließlich des Plotters zu betreuen hat. Da in der untersten Priorität im allgemeinen ein CPU-intensiver Job läuft, ist es nicht schwerwiegend, wenn durch Verzögerungen im Handling Wait-Zeiten auftreten.

- Zuletzt forderten Sie auch für Kleinsysteme mehr Transparenz in der Kostenstruktur. Stichwort "Job-Accounting".

Kostenverrechnung mit den Fachabteilungen ist bei uns auch in weiterer Zukunft nicht vorgesehen. Daraus folgt allerdings nicht, daß Job-Accounting für uns uninteressant wäre. Wir verwenden die Informationen des DOS-Job-Accounting für das System-Management, - etwa um zu erkennen, bei welchen Programmen ein Tuning lohnend ist oder um zu erkennen, welche Programme sinnvoll miteinander im Job-Mix gefahren werden sollen. Eine Analyse unserer Auslastungsstatistik erbrachte die entscheidenden Unterlagen für den Ausbau unserer Konfiguration von 128 K auf 192 K Hauptspeicher.

- Diese Entscheidung fiel ja nur zwei Monate, nachdem die 128 K-Maschine installiert worden war. Hätte man die Notwendigkeit einer Erweiterung nicht früher erkennen können ?

Zum Zeitpunkt der Bestellung war die 125 mit maximal 128 K lieferbar. Aufgrund der uns damals zur Verfügung stehenden Unterlagen mußten wir erwarten, daß das Betriebssystem plus Power nur etwa 50 K bis 56 K beanspruchen würde. Der tatsächliche Bedarf bei der Übernahme war 72 K.

- Alle Planung versagt also, wenn man vom Hersteller nicht die richtigen Angaben bekommt.

Das haben Sie gesagt.