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.

22.09.1978 - 

Kritisches aus dem Alltag der Programm-Pflege:

Compiler: Beschränkter Wortschatz - aber Herstellerbindung

BERLIN (ee) - Narte Kritik, von praktischer Erfahrung gestützt, richtete Dipl.- lng. Dieter von Ammon von der Bundesanstalt für Straßenwesen in Köln an die Hardware-Hersteller: "Sie alle bieten Compiler an, die nicht vollständig den genormten Sprachumfang leisten, dafür aber eine Fülle von Spracherweiterungen zur Verfügung stellen, deren Verwendung sofort eine starke Bindung an den Hersteller bedeutet." Von Ammons Alltag: 170 Programme, die zum Teil im vergangenen Jahrzehnt für unterschiedlichste Maschinen - mit Rücksicht auf Maschineneinheiten - geschrieben worden waren, für zeitgemäße Betriebssysteme lauffähig zu machen.

Die Pflege von Programmen des Bundes auf dem Gebiet des Straßenwesens umfaßt derzeit zirka 200 000 Programmzeilen und ungefähr 170 Programme, die in den Programmiersprachen FORTRAN und COBOL erstellt worden sind.

Diese 170 Programme hat der Bund - teilweise schon Ende des letzten Jahrzehnts - für die Anwendung in den Straßenbauverwaltungen der Länder, die im Auftrage des Bundes die Bundesstraßen und Bundesautobahnen bauen und unterhalten, entwickeln lassen. Wie seinerzeit oftmals wurden die Programme nur für einen Typ DV-Anlage erstellt; teilweise wurden sogar Sprach- oder Grundsoftware-Besonderheiten derjenigen DV-Anlage, auf der die Entwicklung stattfand, ausgenutzt. In diesem Zustand erhielten wir dann die Programme mit dem Auftrag, die Programme für alle Straßenbauverwaltungen der Länder, einige dem BMV unmittelbar nachgeordnete Dienststellen wie zum Beispiel die Bundesanstalt für Wasserbau sowie für Dienststellen anderer Ressorts anwendbar zu machen. Das Problem wird deutlich, wenn man sieht, daß dafür mindestens die DV-Anlagen der Firmen IBM und SIEMENS und dabei die vier Betriebssysteme OS und DOS oder BS2000 und BS1000 zu berücksichtigen waren.

Die oft angewandte Vorgehensweise wäre gewesen, für jedes Betriebssystem eine Programmversion zu erstellen. Das hätte jedoch bedeutet, daß wir anschließend physisch statt 170 680 Programme und statt rund 200 000 zirka 800 000 Programmzeilen hätten pflegen müssen. Dies wäre jedoch ein Umfang gewesen, der weder personell noch organisatorisch tragbar war.

Von Anfang an waren wir der Auffassung, daß zweierlei möglich sein müßte:

- Eine möglichst vollständige, gemeinsame Sprachuntermenge für die beiden verwendeten Programmiersprachen (FORTRAN und COBOL) zu finden, die mit den vier zu verwendenden Betriebssystemen und den dazugehörigen Compilern verträglich ist.

- Unbedingt erforderliche Besonderheiten der verschiedenen Betriebssysteme physisch in einem Quellprogramm zu vereinen.

Nach einigen Anlaufschwierigkeiten konnten wir unter diesen beiden Maximen Problemlösungen erarbeiten, die jedoch für die beiden Programmiersprachen verschieden aussehen.

Für FORTRAN gilt nun: Programme, die anhand den von uns zusammengestellten "Regeln für die FORTRAN-Programmierung" erstellt oder geändert (angepaßt) worden sind, sind zu 100 Prozent zwischen den vier genannten Betriebssystemen kompatibel.

Bei COBOL war es schwieriger, eine Lösung zu finden, da gewisse Sprachelemente, wie CURRENT-DATE, SELECT-Klauseln und einige Dateizugriffe entweder von den Herstellern verschieden behandelt werden oder abhängig von der Hardware-Konfiguration oder sogar von der Grundsoftware-Generierung sind.

Hier muß man also hinnehmen, daß derzeit leider keine vollständige Kompatibilität zu erreichen ist. Dieser Mangel mußte also organisatorisch aufgefangen werden, um die zweite Forderung (ein physisches Quellprogramm für verschiedene Betriebssysteme) erfüllen zu können. Bei uns hat sich nun hierfür folgendes Verfahren als sehr erfolgreich und effektiv erwiesen.

Alle betriebssystemabhängigen Programmzeilen für die vier Betriebssysteme werden an der Stelle in das Programm gebracht, wo sie benötigt werden. Die Programmzeilen, die nicht zum "aktiven" Betriebssystem, also nicht zu dem Betriebssystem gehören, mit dem zu einem bestimmten Zeitpunkt gearbeitet wird, werden mit einem Kommentar-* in Spalte 7 versehen. Um nun die Programmzeilen, die zu einem bestimmten Betriebssystem oder zu einer Gruppe von Betriebssystemen gehören, erkennen zu können, werden in Spalte 80, die für diesen Zweck reserviert ist, Kennzeichen gesetzt, wie zum Beispiel O für IBM/OS, V für Siemens-BS2000, I für IBM-OS/ DOS.

Um dem jeweiligen Anwender die meist mühselige Deaktivierung der speziellen Programmzeilen für ein fremdes Betriebssystem und die Aktivierung der speziellen Programmzeilen seines eigenen Betriebssystems zu erleichtern, haben wir ein Programm entwickelt, das diese Umsetzung für den jeweiligen Anwender bereits vornimmt. Mit diesem Programm können auch spezielle anwender-orientierte Änderungen, etwa den SELECT-Klauseln, vorgenommen werden, so daß die Anwender in der Regel die von uns gelieferten Programme ohne irgendwelche Umstellungs- oder Anpassungsarbeiten sofort auf ihre DV-Anlage übernehmen können.

Bevor es jedoch soweit ist, müssen wir natürlich in jedem der 4 Betriebssysteme umfangreiche Tests fahren, damit eine Programmübernahme wirklich so reibungslos vonstatten gehen kann.

Parallel hierzu ergänzen wir die mehr oder weniger guten vorhandenen Dokumentationen zu den Programmen zumindest um ein Installationshandbuch, in dem für jedes der vier Betriebssysteme detaillierte Angaben für die Programminstallation enthalten sind.

Für viele Programme, zum Beispiel für das ganze Programmsystem "Straßendatenbank" haben wir darüber hinaus vollständige neue Teile der Dokumentation, insbesondere übergeordnete Teile wie zum Beispiel Daten- und Dateibeschreibungen sowie Jobfolgenbeschreibung erstellt, die es dem Anwender ermöglichen, im Regelfall ohne Programmeinzeldokumentationen mit den Programmen zu arbeiten.