Der RZ-Betrieb wird automatisiert

21.03.1975

Mit Peter Solberg, Geschäftsführer der Namic A. S., Oslo, sprach Dr. Gerhard Maurer

Peter Solberg, (35) ist Norweger. Seinen Dipl.-Ing. (Elektro-Maschinenbau) machte er vor 12 Jahren an der ETH in Zürich. Bei der BBC Norwegen arbeitete er in der Fertigungsindustrie, - daher auch sein Interesse an der Produktionssteuerung, das ihn für den Bereich der EDV die Frage stellen ließ, ob nicht auch das Rechenzentrum als Fabrik automatisiert werden könne.

Zur gleichen Frage führte ihn auch die Beschäftigung mit Operations-Research bei einer Pariser EDV-Beratungsfirma.

1971 gründete er, nach Norwegen wieder zurückgekehrt, mit Kollegen die Namic S. A., die 1972 einen Vertrag mit der amerikanischen Value Computing Inc., Cherry Hill, N.J., über den Vertrieb des in den USA sehr erfolgreichen Computer Scheduling and Control Systems in Skandinavien und Deutschland abschloß.

Teilsysteme des CSCS sind: System 1 Job Accounting (Systemmanagement), System 2 Job Costing (Kostenverrechnung), System 3 Single/Multi Machine Scheduler und das System 4 Automatic Tape Library.

In der BRD, die der vier Sprachen nahezu perfekt beherrschende Solberg seit Herbst '73 von Oslo aus betreut, konnten insgesamt acht dieser etwa 20 000 bis 40 000 Mark kostenden Teilsysteme verkauft werden, - so bei der Deutschen Bundesbank, Ciba-Geigy, Neckermann und Deutscher Ring. Das System 3 zur Automatisierung des Rechenzentrum-Betriebs wurde hierzulande allerdings erst einmal an den Mann gebracht. Solberg: "Das Interesse ist riesig, die Leute möchten wohl, aber trauen sich nicht."

- Ihr Computer Scheduling and Control System ist Standard-Software für die Automatisierung des Rechenzentrum-Betriebs. Was kann bei den heute üblichen Arbeitsabläufen verbessert werden?

Schauen wir die Praxis an. Wer trifft eigentlich die schwierigsten und wichtigsten Entscheidungen im Rechenzentrum? Wer ist maßgebend für dessen Produktionseffektivität? Das sind die Operateure, die in der Hierarchie am niedrigsten gestellten und mit am niedrigsten bezahlten Mitarbeiter. Sie sitzen an ihren Konsolen und müssen täglich 200, 300 vielleicht 600 Jobs am Computer starten. Die Freigabe selbst ist nicht schwierig. Der betroffene Operateur hat aber auch eine Wahl zu treffen: Soll Job A, B oder vielleicht Job G gestartet werden? Für diese Entscheidungen hat er natürlich Richtlinien bekommen, sie lauten etwa: Der Operator soll die Systemkomponenten möglichst gut auslasten. Soweit, so gut. Aber wie definiert man "möglichst gut"? Wie mißt man die Produktivität? Läßt sich die Arbeit des Operators eigentlich kontrollieren?

- Übersehen Sie nicht, daß in den meisten Rechenzentren Terminpläne ausgearbeitet werden, an die sich der Operator zu halten hat?

Ich stelle hier die Gegenfrage: Wie gut sind diese Pläne? Auch der Terminplaner ist wie der Operator ein Mensch, der die Vielfältigkeit der Kombinationen von zum Beispiel 300 Jobs nicht überblicken kann. Er wird am Tag vielleicht ein bis zwei Grobpläne aufstellen. Daß diese die Ressourcen optimal auslasten ist höchst unwahrscheinlich. Ich erlaube mir eine zweite Gegenfrage: Arbeitet der Operator denn gemäß den Grobplänen? Vielleicht am Anfang, wenn er seine Anlage vollpackt. Dann bekommt er bald eine Konsol-Meldung, die lauten könnte: Job XY kann nicht freigegeben werden, da von verlangten drei Bandeinheiten nur zwei verfügbar sind. Der Operator wird diesen Job zurückstellen, bis die notwendigen Units frei sind. Statt dessen wird er einen Job starten, der im Grobplan vielleicht zwei Stunden später vorgesehen ist, der mit keinem festen Start-Termin eingeplant wurde, aber nur zwei Bandeinheiten benötigt. Später ballen sich die Termine und der Mann kommt ins Schleudern. Dabei geht kostspielige Kapazität verloren. In den meisten Rechenzentren weiß man dies nicht einmal, weil auf die notwendige Analyse des Job Accounts verzichtet wird.

- Aber die Betriebssysteme der Hersteller haben doch auch Planungsfunktionen.

Was ich eben beschrieb, war die Operator-Planung, jetzt berühren sie die Betriebssystem-Planung. Nehmen wir als Beispiel IBM's OS, in dem es ja einen "Master Scheduler" gibt. Der aber macht keine Planung im richtigen Sinn des Wortes. Er führt eine "Momentan-Disposition" durch und kann nicht die nächsten zwei bis drei Stunden überblicken, um zu untersuchen, ob vielleicht ein Job vorhanden ist, der für die augenblickliche Situation der richtige wäre. Bekanntlich werden die Jobs in Klassen eingeteilt, die für jede Klasse Warteschlangen bilden. Der Master-Scheduler beginnt bei der Schlange mit der höchsten Priorität. Er untersucht, ob die im Moment zur Verfügung stehenden Resourcen für einen Job dieser Schlange ausreichend sind. Wenn nicht, geht er zur nächsten Schlange, - und so weiter. Dabei wird immer wieder passieren, daß der Master-Scheduler einen Job niedrigerer Priorität freigibt, aber Sekunden später wegen der Terminierung eines anderen Jobs die erforderlichen Resourcen freiwerden für Jobs mit höherer Priorität. Jetzt kann der Fall auftreten, daß der Master-Scheduler wegen besetzter Resourcen nicht nur einmal sondern mehrfach vielleicht gar zehnmal Jobs mit höherer Priorität nicht starten kann, so daß schließlich Endtermine gefährdet sind. Was tut der Operator? Er bricht andere Jobs ab, um den Job mit höherer Priorität zum Fixtermin freizugeben. Daß dann nachträglich Wiederholungsläufe durchgeführt werden müssen, merkt das RZ-Management nicht, denn es hat aufgrund fehler Job Accounting-Auswertungen meistens keine Möglichkeit, das Operating im RZ zu kontrollieren.

- Manche Anwender arbeiten aber mit HASP und was bringt VS? Beispielsweise gibt es für VS 2 doch das neue Job Entry System 3.

Zwar richtig, aber im Prinzip der Terminplanung ändert sich nichts. VS macht meiner Meinung sogar die Terminplanung schwieriger. Es kann passieren, daß auf der Maschine das Betriebssystem nur Paging statt produktiver Arbeit macht. Dadurch wird die Einhaltung von Terminen erneut erschwert.

- Wie sieht aus Ihrer Sicht ein vernünftiges Kontroll- und Planungsverfahren für den RZ-Betrieb aus?

Die Planung und die Kontrolle der DV-Produktion gehören sehr eng zusammen. Wie man in der Fertigungsindustrie die Produktion einer Fabrik steuert, so sollte man auch die DV-Produktion im RZ behandeln. Von der Theorie her gibt es sowieso keinen Unterschied. In der Praxis ist die Steuerung im RZ einerseits komplexer, denn es gibt viel mehr Variablen zu beachten, andererseits ist sie einfacher, denn man kann die Steuerung voll automatisieren. Vom Prinzip her ist es möglich, daß der Computer den Computer steuert.

- Werbung für Ihr Computer Scheduling und Control System wird in diesem Interview wohl nicht ganz zu umgehen sein. Also dann beschreiben Sie doch kurz, wie das von Ihnen vertriebene System arbeitet.

Ausgangspunkt ist der Job Account des Betriebssystems zum Beispiel SMF bei IBM's OS. Durch tägliche Akkumulation der Job Account-Daten bilden wir eine sogenannte Jobstammdatei. Gleichzeitig erstellen wir Kontrollisten mit Soll/Ist-Vergleichen bezüglich geplanter und wirklicher Produktion. Die Terminplanung wird dann mittels eines mathematischen Algorithmus anhand der historischen Daten der Jobstammdatei durchgeführt. Die Güte dieser Daten messen wir durch einen Soll/Ist-Vergleich. Wenn nötig, werden Einzelinformationen der Jobstammdatei korrigiert.

- Aber Ihre Jobstammdatei kann doch nur historische Daten speichern?

Die Angaben des Job Accounts sind für eine realistische Terminplanung nicht ausreichend. Sie müssen mit den Randbedingungen des Benutzers ergänzt werden: Jobabhängigkeiten, Termine, Kalenderangaben und so weiter müssen ebenfalls der Jobstammdatei zugeführt werden. Die Idealsituation ist erreicht, wenn der Terminplaner durch eine einzige Angabe des Datums und des Planintervalls den Produktionsplan erzeugen kann.

- Was aber, wenn Einheiten ausfallen?

Ab und zu gibt es natürlich Störungen und der Plan muß revidiert werden. Das läßt sich durch Angabe der neuen Lage einfach durchführen. Man kann soweit gehen, daß dies automatisch ohne Operatoreingriff geschieht. Das System merkt ja selber, welche Einheiten ausfallen und kann online, Real-Time neue Pläne erstellen.

- Es gibt aber auch immer wieder unvorhersehbare Dinge, - zum Beispiel Testläufe.

Auch dafür ist Vorkehrung getroffen. Der Terminplaner oder der Schichtleiter bekommt nicht nur einen Plan mit Angabe, wann und wo die verschiedenen planbaren Jobs gestartet werden müssen, er erhält auch eine Liste mit Angaben der jeweils noch zur Verfügung stehenden Resourcen. So weiß er morgens, daß etwa um 11.15 Uhr 2 Partitions gewisser Größe mit soundsoviel Peripherie noch frei sind. Er kann also hier Testläufe, die die entsprechenden Resourcen beanspruchen, starten, ohne die sonstige Routine-Produktion zu stören. Noch besser wäre es natürlich, wenn der Terminplaner von der Programmierabteilung etwa zweimal täglich eine Liste der kommenden Testläufe mit Angaben über Resourcen-Bedarf und CPU-Intensität erhielte, die dann im Plan automatisch dort eingepaßt werden, wo sie zu einer optimalen Systemauslastung beitragen. Viele unserer Benutzer arbeiten auf diese Weise. Das Ergebnis ist mehr Disziplin und besserer Service.

- Das System ist also schon implementiert?

Das Verfahren optimale Ablaufpläne auszudrucken ist schon gut vier Jahre alt, und es wird heute von weltweit etwa 100 Anwendern eingesetzt. Die automatische Jobfreigabe mit Autokorrektur ist neu und es gibt bis jetzt nur einige Benutzer in den USA.

- Welche meßbaren Ergebnisse bringt die Automatisierung des RZ-Betriebes? Was spart man an Manpower und an Hardware?

Bei unserer letzten Installation in Kopenhagen wird jetzt die Terminplanung von einem Mann in, täglich zwei Stunden besorgt. Vorher hatte man dafür drei Mann Fulltime benötigt. Die durchschnittliche Verbesserung der Hardware-Auslastung liegt bei etwa 25 Prozent.