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.

18.06.1976

Mehr Hardware, um bei der Software zu sparen?

Mit Dr. Reinhold Fischer, Jagenberg-Werke, Düsseldorf, sprach CW-Chefredakteur Dr. G. Maurer

-Von IBM hört man schon seit langem, aber in jüngster Zeit verstärkt den Slogan: "Give us some dollar for hardware, and we will save you lots of dollar in programming." Was halten Sie von dieser These?

Diese These gilt sicherlich nicht dort, wo vorwiegend Batch-Verarbeitung betrieben wird. Hier lassen sich Einsparungen bei, der Programmierung eher durch neue Methoden und durch Orgware-Hilfe erzielen, die keine zusätzliche Hardware erfordern. Durch den Einsatz von Software, die eine effizientere Anwendungsprogrammierung und eine bessere Nutzung der Hardwareressourcen ermöglicht, können Hardwarekosten durch Softwarekosten substituiert werden.

-Wo hauptsächlich Batch läuft, lassen sich Einsparungen bei den Programmierungskosten also eher durch zusätzliche Software-Ausgaben realisieren?

Das ist richtig. Aber wir haben ja zunehmend eine Verschiebung hin zu interaktiven Anwendungen.

-Gilt also die These von mehr Dollars für die Hardware und dafür relativ weniger für die Programmierung - wenn nicht für die Vergangenheit, dann für die Zukunft - bei der Programmierung von Realtime-Anwendungen?

Der Hauptspeicher-Bedarf für komfortable TP-Monitore ist früher so hoch gewesen, daß man gezwungen war, mit kleinen TP-Monitoren zu fahren, die im wesentlichen nur die Grundfunktionen der Nachrichtensteuerung abdeckten. Dies hatte zur Folge, daß die Anwender Sicherheitsfunktionen, wie Zugriffsbeschränkungen oder das Restart-Verfahren jeweils anwenderspezifisch mit geringstmöglichem Hauptspeicheraufwand selbst zu schreiben hatten. Die Programmierungskosten für interaktive Programme waren dann wesentlich höher als für Batch-Programme. Andererseits war die Zuverlässigkeit bei komplexen Systemen geringer.

Heute ist in der Tat Hauptspeicher so preiswert geworden, daß es wirtschaftlich gerechtfertigt ist, die systemspezifischen Funktionen in komfortable TP-Monitore einzubauen, was die Programmierung erheblich vereinfacht. Insofern bringen die zusätzlichen Hardware-Dollar, nämlich die, die gebraucht werden, um diese TP-Monitore auf dem System zu fahren, tatsächlich eine Reduzierung der Programmierungskosten bei einer gleichzeitigen Erhöhung der Qualität der Anwendungsprogramme. Dasselbe gilt auch für Datenbanksysteme.

- Für die Nachrichtensteuerung mit GENA genügten einige Dutzend K. CICS erfordert auch auf virtuellen Maschinen etwa 150 K real. Ist dieser zusätzliche Aufwand gerechtfertigt?

Heute gibt es statt GENA den kleinen Monitor TCSS. Bei einem kleinen TP-Monitor, wie TCSS, müßte man sehr viele Standard-Funktionen, die im CICS realisiert sind, selber entwickeln, was a) zu teuer ist und b) Probleme der Kompatibilität aufwerfen wird, wenn man weitere TP-Anwendungen implementiert. Wir haben noch viele weitere TP-Anwendungen geplant und glauben, daß sich dann eine Kostendegression pro Anwendung einstellen wird.

- Genügt Ihnen dieser CICS-Komfort?

Unsere Realtime-Anwendungen erlauben bereits einigen Fachabteilungen, interaktiv mit dem Computer zu arbeiten. Und das bringt Rationalisierungsgewinne. Ich meine, es wäre wünschenswert, wenn auch die EVD-Abteilung selbst ihre Produktivität durch interaktive Computernutzung steigern könnte. Den Fachabteilungen ersparen wir das Wälzen von Listen und das Suchen in Ablagen. Dergleichen müßte auch in der Systemplanung und Programmierung und bei der Abwicklung des Testbetriebes möglich sein - hier wünschen wir uns Standardsoftware für interaktive Programmentwicklung, Da wir ja nun CICS implementiert haben, wäre es ein leichtes, den nächsten Schritt zu tun, nämlich durch mehr Hardware-Dollar - der obigen These folgend - Programmierkosten zu sparen und die Programmentwicklungszeit zu verkürzen.

- Ist interaktive Programmierung nicht ein Privileg der Großen, die auf OS-Maschinen TSO fahren?

Das stimmt heute wohl nicht mehr. Seit dem Frühjahr gibt es bei IBM das ETSS, das Entry Time Sharing System, das für Systeme 370/115 und /125 rechnerunterstützte Codierung, Kompilierung, Änderung, Dokumentation und insbesondere die Verwaltung der damit zusammenhängenden Texte ermöglicht. Des weiteren gibt es von Softlab und Philips das PET X1150-Programmentwicklungs-Terminalsystem, das als Stand-Alone-System für die Programmierabteilung ebenfalls eine Rationalisierung und Verbesserung der Produktqualität in der Softwareerstellung bringt.

- Das alles reduziert administrativen Aufwand und die lästigen Wartezeiten ebenso wie triviale Fehler - ist also Komfort. Genügt das - brauchen wir nicht vielmehr für das Senken der Programmentwicktungskosten neue Methoden?

Das eine ist wichtig, das andere kommt hinzu. IBM's ETSS verpflichtet noch nicht zur Nutzung neuer Systementwicklungs- und Programmiermethoden. Beim PET X1150 werden zusätzlich Verfahren der hierarchischen Verfeinerung und der strukturierten Programmierung durch eine entsprechende Struktursprache und die Möglichkeit des Ausdrucks von Struktogrammen unterstützt. Des weiteren gibt es auf dem Software-Markt interessante neue Pakete, zwar nicht für die interaktive Programmierung, die aber den Weg von einer Normierung der Batch-Verarbeitung hin zu einer Normierung für interaktive Anwendung aufzeigen. Auch hiermit muß man sich als Anwender intensiv auseinandersetzen.

- Welche Produkte dieser Art sind Ihnen bisher aufgefallen?

Wir verfolgen die Entwicklung des Programmiertools Delta von der GMO in Hamburg, möglicherweise ist auch LSS der Large Scale Standard von ADVIS Hannover interessant. Ansonsten erarbeiten wir intern zur Zeit einheitliche Schnittstellen für den Datenbank-Zugang sowie Programmrichtlinien für die Maskenaufbereitung und die Protokollierung aus Sicherheitserfordernissen. Ferner gibt es bereits ein genormtes Verfahren für die Verwendung von Unterprogrammen und Tabellen, sowohl für Batch-Anwendungen wie für Realtime-Anwendungen. Die dafür zu berücksichtigenden Programmier-Richtlinien schreiben bereits Modularisierung, wenn nicht gar schon hierarhische Verfeinerung vor.

- Das hieße eventuell, Kosten für neue Software- Pakete, in jedem Fall Kosten für interne Verfahren, also mehr Software-Dollar für weniger Programmierkosten. Und eben nicht mehr Investitionen in die Hardware, um die Programmierkosten zu senken.

Man muß auch in die Hardware investieren, um die Software fahren zu können. Die Investitionen für Software werden aber im Verhältnis stärker steigen. Mehr Hardwareleistung muß bei der gegebenen technischen Entwicklung nicht wesentlich höhere Hardware-Kosten bedeuten. Dagegen kann man die Kosten für die Anwendungs-Programmierung und insgesamt die Entwicklungskosten für ein System senken. Mit mehr Standard-Software erhöht man auch die Betriebssicherheit und Watrtungsfreundlichkeit der Programme. Für interaktive Anwendungen müssen hier höhere Anforderungen gestellt werden als im Batch-Betrieb. Wenn man dem rechtzeitig Rechnung trägt, spart man sich künftig sehr viel Ärger.

Dr. Reinhold Fischer (36)

ist Leiter Organisation und EDV bei den Jagenberg-Werken in Düsseldorf. Bei dem führenden Lieferanten von Spezialmaschinen für Verpackung und Papierverarbeitung ist eine 370/135 mit 384 K, 8mal 3330 und 4mal 3240 installiert. Angeschlossen sind derzeit 13 Bildschirme IBM 33270, vornehmlich für die On-line-Auftrags-Abwicklung einschließlich Fertigungssteuerung.

Dr. Fischer studierte Betriebswirtschaftslehre in Frankfurt und Wien, war Systeminginieur bei der IBM, danach bei den Jagenberg-Werken Direktionsassistent, seit 1970 Leiter der EDV-Abteilung, zudem seit 1973 auch für allgemeine Unternehmens-Organisation zuständig.