Viele deutsche Rechenzentren verlassen sich bei ihrer Jobsteuerung immer noch auf die manuellen Fertigkeiten und jahrelangen Erfahrungen ihrer "alten Job-Control-Hasen" in Arbeitsvorbereitung und Operating. Anstatt sich, wie es in modernen RZs längst "state-of-the- art" sein sollte, in der DV-Produktion mit softwaregestützten Planungs/Steuerungsinstrumenten analog eines industriellen Fertigungssteuerungssystems abzusichern, hält man gerne am Altbewährten fest.

So stehen den zirka 7500 in Deutschland installierten Großrechnern mit IBM/Siemens/Nixdorf-Betriebssystemen nur etwa 200 verkaufte Softwarepakete für Jobplanung- und -steuerung gegenüber - dieser nicht mal dreiprozentige Deckungsgrad muß um so mehr verwundern, wenn man sich die über 30prozentige Rationalisierungsreserve vor Augen hält, von denen RZ-Spezialisten ausgehen. Welche Erfahrungen nun Anwender solcher Planungssysteme gemacht haben, schildern drei User des Jobplanungs- und -steuerungssystems HS5000.

"Wir haben Jobabläufe, da sträuben sich einem die Haare", bekennt Dr. Georg Greve, technischer Leiter beim Landschaftsverband Rheinland in Köln. "Die wahnsinnig komplexen Abhängigkeiten in Streams mit bis zu 50 verschiedenen Jobs" sowie "willkürliche Vorlaufkarten ohne erkennbares System" seien bei ihm wesentliche Problemursachen gewesen, die bisher "dadurch gelöst wurden, daß man die anstehenden Aufgaben einfach linear abgearbeitet hat" Hier kann sich Greve einen Seitenhieb auf seine Kollegen der Programmierabteilung nicht verkneifen: "Der RZ/AV-Bereich kann immer nur so gut sein, wie die Programme, die von der Organisationsprogrammierung kommen; denn bei schlechten Programmen nutzt auch kein Jobablaufsystem" Man solle doch lieber "öfter mal Standard-Software einkaufen, als immer die eigenen komplizierten, fehleranfälligen selbstgestrickten Systeme im RZ abzuliefern", redet sich der RZ-Mann den innerbetrieblichen DV-Frust von der Seele.

Aber auch im eigenen RZ-Bereich hat Greve "wesentliche Fehlerquellen" ausgemacht .Bei der manuellen Jobsteuerung und Ressourcenzuordnung nach Operator-Gutdünken kommt es ganz automatisch zu Fehlern". Beispiele dafür seien konkurrierende Updates, nicht genügender Arbeitsplatz auf Platten sowie Ausgabebänder auf Nicht-Scratch-Volumes.

"Fast jede Nacht krachte es auch beim Rheinischen Rechenzentrum für Kirche und Diakonie (RKD) in Düsseldorf. Die Jobsteuerung sei sehr problematisch zu fahren, berichtet Produktions-Ablauf-Leiter Klaus Seifert. Durch die räumliche Trennung von vier Arbeitsvorbereitungen in den RD-Fachabteilungen bedingt, sei mal ein Job zu früh gestartet, mal ein anderer abgebrochen worden. Auch habe es keine vernünftigen Anweisungen für Restart-Aufsetzpunkte gegeben, so daß die allein den Operatoren überlassenen Jobsteuerungen zwar zu 80 Prozent richtig war, aber eben doch genügend Fehler auftraten".

Da schon Beschwerde-Anrufe von RZ-Kunden beim RKD eintrafen, war schließlich selbst die Gesellschaftsführung der Meinung, "daß gegen dieses Problem endlich etwas gemacht werden müßte".

Auch bei Clark Equipment; Mülleim an der Ruhr "war allen klar daß etwas in der Richtung getan werden muß" wie RZ-Leiter Rolf Lichtenberger berichtet. Infolge der großen Abhängigkeiten (Lichtenberger: "Nur mit Gottes Hilfe zu durchschauen") sowie der alleinigen Operatorenentscheidungen in der Nacht, häuften sich dort die Wiederholungsläufe. Das Ende vom Lied - wieder einmal klingelte bei Lichtenberger nachts das Telefon.

So brannte dem RZ-Leiter "die Verzögerung des morgendlichen Online-Betriebes durch Batchprobleme in der Nacht am meisten unter den Nägeln". Weiter waren bei Clark automatische Reruns Ziele der HS5000-Einführung. Außerdem kam es darauf an, soweit wie möglich ohne manuelle Operatoreneingriffe auszukommen, sagt Lichtenberger. Klaus Seifert vom RKD lag besonders am Herzen, "die sichere RZ-Produktion und -Verarbeitung mit Abhängigkeiten verschiedenster Bereiche zu gestalten und zu gewährleisten".

Außerdem hatte sich das RKD-Rechenzentrum eine Umstellung von Drei-Schicht- auf Zwei-Schicht-Betrieb vorgenommen.

"Wesentlicher Anstoß" beim Landschaftsverband Rheinland war der sehr knappe Personalstand sowie das Ziel "vom Zwei-Schicht-Betrieb herunterzukommen". DV-Produktionsleiter Dr. Georg Greve, den "eine Durchsatzsteigerung bei diesem Projekt primär nicht so sehr interessiert, sieht vor allen Dingen die Notwendigkeit, "mehr Sicherheit und Revisionsfähigkeit zu gewährleisten sowie alle Batchläufe organisatorisch so zu automatisieren, daß zumindest die Hauptjobs operatorlos laufen". Besonders das Dokumentationsproblem sieht Greve "als A und O der Arbeitsvorbereitung" an.

Stärken und Schwächen Punkt für Punkt durchgehen

Gut eingearbeitete ADV-Mitarbeiter kennen zwar seiner Meinung nach ihr Sachgebiet so genau, daß "alles ganz gut klappt", doch seien bei Urlaub und Krankheit Vertretungen nicht in der Lage, undokumentierte Abläufe zu durchschauen. Ein weiterer Schwerpunkt wurde beim Landschaltsverband darauf gelegt, "die Produktion so zu dokumentieren und organisieren, daß Jobs zukünftig unabhängig voneinander laufen können". So bekomme zum Beispiel jetzt jeder Job seine Arbeitsplatte exklusiv per Vol-SER-Nummer zugeordnet. Dr. Greve: "Der Performance-Verlust durch diese Maßnahme bleibt gegenüber dem Verteilen von Workspace auf mehrere Vol-SER's denkbar gering".

Einen "exzessiven Softwarevergleich für Jobplanungssysteme" hat der Landschaftsverband Rheinland in Zusammenarbeit mit anderen Anwendern wie der Bundespost durchgeführt und ist dabei - so Dr. Greve - "Stärken und Schwächen Punkt für Punkt durchgegangen" Von ursprünglich vier getesteten Systemen kamen schließlich HS5000 sowie UCC7 in die engere Auswahl. Vergleichbare Leistungen fand Dr. Greve bei folgenden Punkten vor:

- auf der Ebene der Benutzerschnittstelle bieten beide Systeme ungefähr gleiche Leistung

- Systembelastungen

- Schnittstellen zu anderen Systemsoftwareprodukten wie Bandverwaltung oder RACF

- beide haben eigenen Editor, weil TSO-Editor gewaltigen Systemoverhead bringt

- in beiden Systemen "wahnsinnige Möglichkeiten mit Terminen/Abhängigkeiten zu tricksen"

Vorteile für HS5000 hat Greve bei dem Vergleich bei folgenden Punkten ausgemacht:

- Implementierungsaufwand nur wenige Tage, in der Startphase mit HS5000 leichter

- System-Release-Abhängigkeit nicht vorhanden (Greve: "Andere Produkte sterben in dem Augenblick, wenn IBM den SMF-Exit wegfallen läßt")

- Plattenplatz geringer

- Parameter/Vorlaufkartentabellen

- Preis mit 96 000 Mark wesentlich geringer

- Betreuung hervorragend

Nachteile für HS5000 schließlich registrierte der Landschaftsverband bei folgenden Punkten:

- Restartmanagement nicht so komfortabel. Greve: "ln 99 Prozent aller Restartfälle ist bei uns sowieso ein manueller Eingriff erforderlich. So werden wir auch in Zukunft unsere Jobs so aufbauen, daß kein Auto-Restart gemacht wird"

- Deadline-Scheduling etwas schwächer

- Jobs, die nur einmal geladen werden, muß ADV manuell in den Plan einarbeiten

Bei all den Vergleichskriterien empfiehlt Dr. Greve den entscheidenden Aspekt nicht aus den Augen zu verlieren: "Wichtig ist schließlich, wie optimal der Benutzer seine individuelle RZ-Produktion mit dem Softwareprodukt steuern kann".

Clark Equipment kam es bei der Softwareauswahl auf die folgenden wichtigsten Voraussetzungen an:

- Übernahme der Power-Account-Daten

- Weiterverwendung von "Include" in der Job Control

- Berücksichtigung von Sonderterminen

- flexibel anwendbares System

Als Service-Rechenzentrum legte man außerdem besonderen Wert auf

die Weiterbelastungsfähigkeiten des Softwareproduktes für die monatlichen Kostenabrechnungen auf die Fachabteilungen.

IBM hat im DOS-Bereich kein Schedulersystem anzubieten - auch das neue DOS-Release enthalte - so RZ-Leiter Rolf Lichtenberger - " nur Return-Code-Abfragen und die Möglichkeit, Power-Commands aufzusetzen". Hier komme wieder die alte IBM-Politik durch: "Bloß kein Tuning betreiben und zum besseren Jobdurchsatz beitragen"

"Andere Produkte außer HS5000 haben unsere Voraussetzungen einfach nicht erfüllt", beschließt Lichtenberger bündig das Softwauswahl-Problem.

" Ohne HS5000 wären wir heute total überfordert", faßt Klaus Seifert vom RKD seine eineinhalbjährigen Erfahrungen mit dem Jobplanungs- und -steuerungssystem zusammen. Beim Implementierungsaufwand hat er herausgefunden, daß "man zwar sofort mit dem Softwareprodukt arbeiten könne", doch das "richtige Kennenlernen mit allen Kniffen und Tricks dauert Monate und Jahre". So habe auch die Umstellung länger als geplant gedauert und er habe sich "das letzte halbe Jahr nur noch damit beschäftigt". Im Zuge der Umstelung beim RKD wurden allerdings nicht nur "alle Jobstreams neu überdacht und zum Beispiel Abläufe die in einer Partition mit 50 Steps qefahren wurden, ganz auseinander gezogen", sondern auch neue systematische Jobnamen aufgebaut sowie die Bandverarbeitung abgebaut. Der Aufwand beim RKD scheint sich jedenfalls gelohnt zu haben: "Batchverarbeitungen, die früher 18 bis 20 Stunden gedauert haben, schaffen wir heute in einer Nacht, wobei sogar noch zusätzliche Arbeitsbelastungen hinzugekommen sind," berichtet Seifert.

Auch das nächtliche Telefonieren habe allein wegen der neuen Restart-Anweisungen, die es früher überhaupt nicht vorhanden waren, merklich nachgelassen.

Als weiteren Lohn der Umstellungsmühen bucht Seifert für sich, daß "das manuelle Nachschieben von Jobs auf ganz wenige reduziert werden konnte" sowie, daß jetzt auch "selbst Online-Anwender ihre Batchjobs mit CMS-Prozeduren eigenverantwortlich planen können". Positiv sei schließlich auch der Spool-Service von HS5000 beim RKD angekommen. Seifert: "Wird bei uns unter MVS intensiv zum Listenanschauen benutzt".

Systemimplementation macht Schwierigkeiten

Negativ schließlich fiel beim RKD der TSO-ähnliche Editor von HS5000 auf, der "am Anfang etliche Macken hatte und kein Vergleich zum CMS darstellt" wie Klaus Seifert berichtet. Allerdings gebe es in der Job Control nicht so viel zu ändern und man benutze jetzt bei kleinen Änderungen den HS5000-Editor und bei größeren JCL-Umstellungen den CMS-Support.

"Nicht mehr missen" möchte auch RZ-Leiter Rolf Lichtenberger das HS5000-System. Schwierigkeiten gab es bei Clark Equipment allerdings erst einmal mit der Systemimplementation von HS5000, da durch starke Sicherheitsauflagen mit dem Systemsoftware-Produkt Access-Control alle Systemdateien geschützt sind. "Bei uns kann nicht jeder im System rumwühlen, sondern muß echt auf Karten-Ebene seine Systemprogramme einspielen", berichtet Lichtenberger von der Implementierung, die dann auch drei Tage ohne Jobdefinitionsaufwand dauerte.

Für die Hauptproduktion mit zirka 75 bis 80 Jobs wurde für die Definitionsarbeit dann allerdings nur eine Woche benötigt, da manuell geschriebene Jobablaufpläne zur Verfügung standen. "Die Mittagsjobs stehen jetzt", atmet Rolf Lichtenberger auf, der "Druck ausgeübt hat, daß HS5000 in Produktion geht, da sich die Geschichte rentiert". Bei Clark wurde aus längeren Prozeduren Einzeljobs gemacht, die nach Abhängigkeiten gesteuert werden. Dies sei wichtig wegen der Account-Daten und der damit verbundenen Weiterbelastungsmöglichkeit der Kosten: "Über die Kostenweiterbelastung erziehen wir uns unsere Fachabteilung zu Ordnung", berichtet Lichtenberger über den Stellenwert dieses Punktes bei Clark Equipment.

Seine Arbeitsvorbereitung sei jetzt mehr entlastet als früher, da sie "nicht mehr jeden Job einzeln submitten braucht und zum Beispiel jetzt alle Jobs für zwei Monate im voraus fertig hat. Während früher ganze Prozeduren bis abends liefen, könne die AV fertige Einzeljobs jetzt schon zwischendurch nachprüfen, gibt Lichtenberger noch als weiteren Vorteil an. Auch bei ihm ist die Telefon-Intensität ein wichtiges Indiz für den Erfolg einer Systemeinführung: "Teilweise war es früher schon fürchterlich mit den Anrufen zu Hause", stöhnt er rückblickend - "jetzt klingelt bei mir nur noch ganz selten das Telefon", registriert er zufrieden.

Als "Handicaps" bei HS5000 empfindet Lichtenberger einmal den Editor ("Wir sind eben CMS gewohnt") sowie das 10-Sekunden-Intervall zum Anstoß des Internal Readers nach jedem beendeten Job, daß bei einer kompletten Mittagsschicht "fast eine Stunde ausgemacht" . Die Ursache für das Problem sieht Rolf Lichtenberger allerdings bei seiner Systemsoftware: "Bei unseren 3-DOS-Systemen mit Shared Power liegt dafür zu 80 Prozent die Fehlerursache".

Bei der Benutzerakzeptanz im AV/ RZ-Bereich waren am Anfang, wie nicht anders zu erwarten, einige Wiederstände aus dem Weg zu räumen: "Am Anfang war das Thema den Leuten schon schwierig beizubringen", bekennt Klaus Seifert, Abschnittsleiter beim RKD für Produktionsplanung und Ablaufoptimierung. Erst "nachdem alles gut lief" seien die Operators "positiv eingestellt" gewesen.

Als "Minderqualifizierung" gar, empfanden die Maschinenbediener vom Landschaftsverband Rheinland die neue Arbeitsverteilung, bei der sie keine Jobs mehr zu submitten haben. DV-Produktions-Leiter Dr. Georg Greve konnte allerdings sofort ein neues interessantes Betätigungsfeld für seine Leute bieten: "Ich brauche meine Operatoren zur TP-Netz-Koordination, denn ein funktionierendes Online-System ist für unsere DV-Abteilung sehr wichtig".

"Größte Sorge im Maschinenraum Akzeptanz zu finden", hatte auch Rolf Lichtenberger von Clark Equipment. Erst als er jede Mittagsschicht eine Woche lang begleitet und jedem sein eigenes Handbuch ausgedruckt hätte, sei "der Streß vorbei gewesen".

Startphase bringt erhöhten Personalbedarf

Als Vorurteil sowohl bei den Betroffenen in AV/RZ als auch bei den DV-Managern stellte sich die Erwartung heraus, daß durch den Einsatz eines Jobplanungs- und -steuerungssystems Personal eingespart werde.

"Hier beim RKD ist dadurch niemand eingespart worden," bekräftigt Produktions-Ablauf-Spezialist Klaus Seifert, "während unsere Arbeitsvorbereiter früher ständig mit Jobvorbereitungen beschäftigt waren, haben sie jetzt aber viel mehr Zeit, sich mit den Abläufen im Detail zu beschäftigen, "

Als "dummes Gerede" pointierte gar Dr. Georg Greve vom Landschaftsverband Rheinland, daß man AV/RZ-Leute einspart. Er sieht zumindest in der Startphase sogar erhöhten Aufwand auf den Anwender zukommen: "Bei Ausnutzung des vollen Funktionsumfanges muß man Wochen und Monate zusätzlichen Arbeitseinsatz bringen". Für manche Jobsteuerungssysteme brauche man selbst langfristig eher mehr als weniger Personal, schätzt Greve den Personalaspekt eher skeptisch ein. So sei die Arbeit in der AV zwar komfortabler geworden, habe sich aber im Aufwand überhaupt nicht verringert. Im Bereich des RZ-Operatings dagegen seien zwar Tätigkeiten wie Job-Submitten herausgezogen worden, doch dafür seien andere Aufgaben wie Benutzerbetreuung oder TP-Koordination hinzugekommen.

U. Kellerbach ist freier EDV-Berater und EDV-Fachjournalist in Bergisch-Gladbach 1