Permanente Überlastung ist ein typisches Merkmal fast jeder EDV-Abteilung. Es fehlt an Programmierkapazität, aber Personalanzeigen bringen nicht den gewünschten Erfolg. Um so mehr verwundert es, daß nicht schon heute in größerem Umfang Formuliersprachen eingesetzt werden, mit denen der Aufwand für die Neuerstellung von Programmen, Test, Korrektur, Wartung und Pflege erheblich reduziert werden könnte.

Programme veralten mindestens ebenso rasch wie die Computer, auf denen sie ablaufen. Aber während der Austausch einer kompletten RZ-Ausstattung gegen eine neue nur eine Angelegenheit von wenigen Tagen ist, erfordert die Modernisierung der Programme den ständigen Einsatz von 30 Prozent der Personalkapazität. Da mit zunehmender Zahl der Programme auch der Aufwand für deren Pflege ansteigt, kann diesem Problem nur durch eine grundsätzliche Umorientierung begegnet werden. Die weitgehende Verwendung einer Formuliersprache für alle Auswertungen befreit die DV-Abteilung von einem Großteil des Wartungsaufwandes, und das ohnehin knappe Personal wird für Neuanwendungen frei.

Die ersten Jahre nach Einführung der Datenverarbeitung in unserem Unternehmen waren mit Organisieren und Programmieren so ausgefüllt, daß alle Änderungswünsche aus den Fachabteilungen ignoriert und abgewiesen wurden. Zudem war unsere Anlage von der Kapazität her voll ausgelastet. Nach der Installation einer neuen, leistungsfähigeren Zentraleinheit wurden die Erwartungen der Anwender nur noch größer und der Hinweis auf die neue Anlage war ein sanfter, aber spürbarer Druck der Geschäftsleitung, doch endlich in dieser Richtung - der Modernisierung der Programme - etwas zu tun.

Neuralgische Punkte anaIysieren

Bevor wir, ein EDV-Team mit drei Programmierern, zwei Planern und Organisatoren, sowie die Zwei-Schicht-Mannschaft des Rechenzentrums und der Arbeitsvorbereitung, in die Hektik der unkontrollierten, weil individuell von der Fachabteilung gesteuerten, Änderung der Programme einstiegen, haben wir die neuralgischen Punkte analysiert. Dabei sind wir auf folgende Sachverhalte qestoßen:

- Die Listen entsprachen in der Form und dem Inhalt nicht mehr dem veränderten und vergrößerten Geschäftsablauf unseres Unternehmens.

- Viele gespeicherte und verfügbare Daten, die durch Neuanwendungen hinzugekommen sind, wurden nicht genutzt, weil sie zum Zeitpunkt der Programmerstellung noch unbekannt waren.

- Durch die mit den Jahren gewachsene Erfahrung der Programmierer konnten an die Logik der Verarbeitung, das heißt Anzahl der Abfragen, Gruppenwechsel und Querverbindungen zu mehreren Dateien höhere Anforderungen gestellt werden als früher.

- Vieles, was bei der Erstprogrammierung als konstant betrachtet wurde, zum Beispiel Warengruppen, Auslieferungslager etc., hat sich so häufig verändert, daß es nur noch als variable Steuerparameter verwendet werden kann.

- Die Laufzeit vieler Programme war, wegen einer umständlichen Ablauforganisation, zum Beispiel zu viele SORT-Aufrufe, zu hoch.

Mit einer "Programmkosmetik", also lediglich der Neugestaltung der Listbilder wären die Anwenderabteilungen zwar zufrieden gewesen. Aber wie lange? Nach spätestens zwei Jahren wären wir wieder vor dem gleichen Problem gestanden.

Wir suchten nach einer grundsätzlichen Lösung. Zunächst kauften wir ein Programmierwerkzeug zur maschinellen Unterstützung des Codierens und der Dokumentation. Aber das war nur eine Teillösung. Die Ursache für den hohen Aufwand zur Programmänderung steckte unserer Meinung nach in dem höheren Änderungsaufwand für die Programme (wir verwendeten fast ausschließlich Cobol). Konsequent verfolgten wir diese Spur. Unsere Fragestellung lautete: Worin steckt die Schwierigkeit, ein Cobol-Programm zu ändern?

Die Antwort darauf erhielten wir aus der eigenen Praxis, als einer meiner Mitarbeiter einen zusätzlichen Gruppenwechsel in ein Cobol-Programm "einbauen" wollte. Das "neue" Programm sah plötzlich ganz anders aus als das "alte". Der Unterschied war so grobe daß eigentlich nicht mehr von einer Änderung gesprochen werden konnte, sondern von einer Neuprogrammierung.

Programme up to date halten

Nachdem wir diese bittere Erkenntnis verdaut hatten, ergab eine kurze Überschlagsrechnung, daß wir mit dem vorhandenen Personal die vielen Programme niemals "up to date" halten können. Was wir benötigten, war ein allgemein verwendbares Datei-Auswertesystem, dessen Wartung nicht wir, sondern der Hersteller dieses Systems übernimmt. Die Anforderungen an ein solches Programm leiten sich unmittelbar aus der Erkenntnis ab, die wir bei der kritischen Betrachtung des Änderungsaufwandes von Cobol-Druckprogrammen gewonnen hatten, die über 60 Prozent aller aktiven Programme repräsentieren.

Das einzige, was sich in einem Auswerteprogramm nicht ändert sind "open", und "close" der Dateien. Alles andere ist variabel:

- Anzahl der Abfragen

- Anzahl der Organisationsform der angesprochenen Dateien

- Anzahl der Gruppenwechsel

- die Logik der Verarbeitung usw. eben alles, was in einem Programm vorkommen kann

Für die Anwendungen in unserem Unternehmen kamen einige spezielle Anforderungskriterien dazu: - DBOMP-Schnittstelle (beziehungsweise DL/I)

- ISAM- und VSAM-Unterstützung

- maximaler Hauptspeicherbedarf

- Schnittstellen zu speziellen Anwenderroutinen in Cobol und Assembler, um nur einige zu nennen.

Jedenfalls hatte, sich jetzt eine sehr konkrete Vorstellung von dem gebildet, was wir haben wollten. Die Auswahl geeigneter Programme beschränkte sich nach einer ersten Vorsortierung auf weniger als zehn Produkte. Drei davon wurden über sechs Monate lang in Testinstallationen untersucht. Nach Auswertung der Testergebnisse entschieden wir uns gemeinsam mit der Otto Wolff AG für den Einphasencompiler SIROS, der von der Ton Beller GmbH in Bensheim entwickelt wurde.

Die Struktur und Logik dieses Systems lag genau auf der Linie, die wir verfolgten: ein Programm besteht aus einem und einem Steuerteil. Beide können sich unabhängig voneinander ändern. SIROS besteht aus Tabellen, sogenannten Adresstafeln, in denen die Definitionen für Dateien und Datenbanken einmalig vorab angelegt sind und aus einem Anweisungsteil mit deutscher Syntax. Der Effekt hegt darin, daß ein SIROS-"Programm" nur etwa ein Zehntel so groß ist wie ein Cobol-Programm gleichen Funktionsumfanges. Zudem können wir die Tabellen und Anweisungsteile mit unserem Online-Programmierwerkzeug leicht handhaben. Der Wartungsaufwand für eine auf SIROS umgestellte Anwendung sank praktisch auf Null, weil eine Vielzahl von Änderungen beziehungsweise Modifikationen temporär von der Arbeitsvorbereitung durchgeführt werden.

Diese Entlastung haben wir seit der Installation des SIROS-Systems Anfang 1979 alle deutlich gespürt. Nach, den ersten Erfolgserlebnissen hatte sich auch das Vertrauen einiger konservativer und skeptischer Programmierer in SIROS gefestigt und wir gingen daran, nicht nur die Programme in ihren Anwendungsfunktionen umzustellen, sondern sie auch technisch zu erneuern.

Es war deshalb naheliegend, die Ablauforganisation mit den vielen aufeinanderfolgenden SORT'S zu straffen. Das Bensheimer Produkt setzt unmittelbar auf die SORT-IN-Phase auf und erlaubt bereits beim Einlesen den Aufbau von Summenfeldern.

Kombiniert mit der Unterprogrammtechnik (Der Einphasencompiler läßt bis zu 48 Schnittstellen zu Anwenderroutinen pro Abfrage zu) wurde die Verarbeitung insgesamt intensiviert und damit Durchlaufzeiten eingespart.

Bereits sechs Monate nach der Erstinstallation hatten wir 52 Einzelprogramme umgestellt, wobei 14 davon wegfielen, da SIROS durch einfache Modifikationen oft mehrere Programme ersetzt beziehungsweise mehrere Steps in einem Durchlauf erledigt. Heute laufen bei uns an die 200 SIROS-Programme.

*Maximilian Gruschka ist EDV-Leiter bei der Hommel Handel GmbH, Viernheim.