Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

14.11.1975

Mehr Mut zu Selbstkritik

Viele Rechenzentren könnten effizienter sein, wenn der EDV das Geld für die notwendigen Hilfsmittel genehmigt würde. Diese Aussage gilt allerdings nur für diejenigen EDV-Leiter, die sich mit dem Problem der Effizienz ihres Rechenzentrums befaßt haben - die aber wissen, daß und welche Hilfsmittel sie benötigen und trotz Erklärung auf Unverständnis ihres Managements stoßen.

Dabei sollte nicht übersehen werden, daß die Effizenz eines Rechenzentrums nicht unerheblich mit den dort laufenden Anwendungen im Zusammenhang steht. Aus schlechten, unausgewogenen oder nur teilintegrierten Lösungen ist vom Rechenzentrum, schwer etwas herauszuholen. Ebenso hindernd ist, wenn das Rechenzentrum und die Systemprogrammierung überraschend mit neuen Anwendungen und laufend mit Release-Wechseln konfrontiert werden.

Fazit: Man sollte sich eine Konsolidierungsphase gönnen. Dabei unterstelle ich, daß die grundlegende Entscheidung über die Basis-Software richtig getroffen wurde, d. h.

- das Betriebssystem und evtl. der TP-Monitor entsprechen der Hauptspeichergröße und -geschwindigkeit der für die Bedürfnisse der Firma ausgewählten CPU.

Aus Performance- und Wirtschaftlichkeitsgründen fahren wir daher (auf einer 370/135 512 K) DOS-VS und GENA. Dadurch unterliegen wir natürlich einigen Restriktionen, die jedoch nicht so schwerwiegend sind, daß sie auf der relativ langsamen CPU und bei

unserem Job-Profil den Einsatz von OS rechtfertigen. Dies hätte vielmehr per Definition zu einer Ineffizienz geführt. Auf dieser Basis haben wir nun folgende Maßnahmen zur Verbesserung der Effizienz getroffen:

Einsatz von Westinghouse-Dump-Restore

Bevor wir uns hierfür entschieden, haben wir mit dem (stand alone) OS-Dump-Restore gearbeitet, da das DOS Utility völlig unzureichend ist. Der OS-Dump gestattet jedoch nur die Verarbeitung von ganzen Platten und da auch immer nur jeweils eine einzige in einem Step (das gilt auch für Fast Copy Disk Volume).

Das war für unsere umfangreiche Datenbank (6 X 3330) nicht vertretbar. Wir haben uns für den Westinghouse-Dump entschieden, weil hier mehrere Platten und/oder auch einzelne Dateien innerhalb eines Steps verarbeitet werden können. Bei Platte zu Platte ist es sogar möglich, einzelne Zylinder oder Spuren von einem bestimmten Bereich auf einen anderen zu kopieren.

Aufbohren von Job Accounting

Es ist ein Jammer, daß unzählige Systemprogrammierer landauf, landab Zeit und Geld durch das Aufbohren von Job Accounting vergeuden müssen, um an brauchbare Information zu kommen.

Wir mußten das ebenfalls tun. Eine dieser Informationen veranlaßte uns dazu, bestimmte Programme wieder real laufen zu lassen. Resultat: 40 Maschinenstunden im Monat weniger.

Einsatz von EPAT

Ein Riesenschritt vorwärts, wenn man die Vorteile betrachtet, die allein durch Arbeitserleichterung in der AV und Arbeitsvereinfachung im Operating eingetreten sind.

Weiterhin: Wiederholläufe gibt es nicht mehr, die Bänder sind praktisch anonym und - last not least - wir haben eine Bandeinheit abmieten können.

EPAT allein ist schon sehr gut, zusammen mit einem ähnlich guten Plattenverwaltungssystem wäre es absolute Spitze.

Eine weitere Entlastung der Arbeitsvorbereitung versprechen wir uns durch den Einsatz eines Systems zur Jobablaufsteuerung. Da die auf dem Markt befindlichen Programmpakete nicht alle unsere Forderungen (z. B. katalogisierte Job Decks, kurzfristige Änderung über Bildschirm) abdecken, werden wir es selbst entwickeln. Bis dahin behelfen wir uns damit, daß wir dem Operating die Möglichkeit gegeben haben, den momentanen Systemzustand abzufragen, um die Prioritäten sinnvoll zu verändern (Erweiterung der Operator Communication Routine). Wir sind außerdem stark an einem Bibliothekspflege- und -sicherungssystem interessiert. Wir halten die angebotenen mit Einschränkungen gut für eigene Programme (eigene Wartungsverantwortung) und nicht gut für Fremdsoftware (Namensgebung, Numerierungsprobleme).

Die Entscheidung für einen Betriebssystem-Wechsel darf nur unter langfristigen Gesichtspunkten gefällt werden. (Die Aufstockung oder Abrüstung von Hardware darf viel kurzfristiger geplant werden.)

Ein Wechsel des Betriebssystems kann nur wirtschaftlich durchgezogen werden, wenn man die Anwendungen für die Dauer der Umstellung praktisch einfriert. Dies setzt voraus, daß die gegenwärtigen

Anwendungen stabil laufen (was selbstverständlich sein sollte!) und daß die Unternehmensleitung den zeitweiligen Verzicht auf neue Anwendungen mit trägt. Sie wird dies, nur tun, wenn die langfristige Planung der Anwendungen nach Art, Anzahl und Umfang mit ihr abgestimmt wurde.