OSLO/DELMENHORST (je) - Viele RZ-Leiter und AV-Mitarbeiter glauben, daß man hinsichtlich der Jobabwicklung im RZ oder gar der Sequenz der Jobs wenig machen kann. Peter Solberg, Geschäftführer der Namic A/S in Oslo, hat diese Beobachtung gemacht und hält ihr entgegen, diese "Legende" sei von einigen Hardwareherstellern unterstützt worden.
Beigetragen zur Legendenbildung hat nach Solbergs Darstellung das Vorgehen dieser Hersteller, Systemkomponenten, die keine Möglichkeit zur Ressourcenplanung böten, unter irreführenden Bezeichnungen auf den Markt zu bringen. Wenn daher beim Anwender die RZ-Ablaufsteuerung nicht funktioniere, sei es nicht verwunderlich, daß die Ansicht Platz greife: Weil der Hersteller das Problem nicht lösen könne, müsse es wohl unlösbar sein.
Dem aber widerspricht Solberg: Zwar scheiterten effizente manuelle Lösungen an der Komplexität des Problems, auf eine Kontrolle des RZ-Ablaufs könne deshalb jedoch nicht verzichtet werden. Solberg läßt sich auch nicht beirren, daß ein derartiges Gesamtsystem kostspielig und darum unwirtschaftlich sei.
Er kommentiert:Für viele RZ- und AV-Mitarbeiter ist diese Behauptung natürlich sehr angenehm. Man kann andere, mehr übersichtliche Probleme aufgreifen, wo das Ergebnis durch einfache Kosten/Nutzen-Vergleiche meßbar ist."
Die derzeit noch weit verbreitete Auffassung - und nach Solbergs Worten auch die "Grundidee" der von ihm bezichtigten Hersteller - umreißt der Namic-Manager so: Die beste Job-Abwicklung im RZ ist weder LIFO (last in - first out), noch FIFO (first in - first out) sondern JIRO (jammed in - random out).
Nach dieser Philosophie werde ein Job gestartet, sobald seine Vorläufer fertig und die Eingabedateien vorbereitet seien. Anders: Sobald die Benutzerdaten zugänglich seien, werde der Job ohne Rücksicht auf Ressourcenverbrauch, Priorität oder Endtermin verarbeitet. Fragt Solberg spöttisch: "Wer würde Schach spielen, ohne die nächsten Züge des Gegners wie auch seine eigenen zu berücksichtigen?" Solberg schildert eine typische JIRO-Situation:
Ein sehr wichtiger Job A mit höchster Priorität wartet auf den Abschluß seines Vorläufers, der eine Eingabedatei erzeugt. Ein Job B mit niedriger Priorität wartet auch auf die Bereitstellung der Eingabedatei. Dieser unwichtigere Job B benötigt eine gewisse Ressource (beispielsweise drei Bandeinheiten) für eine ungewöhnlich lange Zeit - vielleicht zwei bis drei Stunden.
Scheinbare Benutzerbestimmung
Betrachtet man die Warteschlangen des Betriebssystems, so gibt es zwei Jobs, die beide auf gewisse Ergebnisse warten. Plötzlich wird der Vorläufer von Job B fertig, und B wird gestartet, weil Ressourcen vorhanden sind. Sekunden später wird auch der Vorläufer von Job A fertig. A will losfahren - es sind aber keine Bandeinheiten frei, weil Job B diese für zwei bis drei Stunden in Anspruch nimmt.
Dieser Mißstand - so Solberg - wird dann dadurch bemäntelt, daß "die Benutzer es seien, die die Abwicklung im RZ bestimmen". Von einer wahren Ablaufplanung könne aber hier keine Rede sein. Ein derartiges Planungssystem, meint Solberg, würde nämlich nicht gestatten, daß Job B kurz vor dem wichtigeren Job A starte.
Die gleichen Benutzer, meint Solberg trocken, die durch JIRO die Job-Abwicklung bestimmen, schimpfen über den Service und behaupten, daß das RZ durch ein besseres Management effizienter sein könnte. Wenn alle Jobs die gleiche Priorität hätten, dann möglicherweise wäre eine JIRO-Planung ideal. Solberg herausfordernd: "Wollen Sie so arbeiten?"
Informationen: Namic GmbH, Oldenburger Straße 52,
2870 Delmenhorst, Teldon: 0 42 21/80 84.