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.

13.06.1980 - 

Intelligente Systemsoftware kann auch deutschen Ursprungs sein:

Allround-Utility verschönert DL/1-Alltag

Der Einsatz eines Datenbank-Systems stellt alle Beteiligten vor eine Fülle neuer Aufgaben. Diese Tatsache findet ihren Niederschlag auch in der Entstehung neuer veränderter Berufs-Bilder: Der Programmierer spezialisiert sich zum "DB/DC-Programmierer", und der "Datenbank-Administrator" nimmt Aufgaben wahr, die zuvor unbekannt waren. Wie die tägliche Arbeit dieses Personenkreises mit Hilfe eines Datenbank-Utilitys in vielen Punkten vereinfacht werden kann, schildert Hans-W. Ohliger, Projektleiter bei der Bavaria-St. Pauli-Brauerei AG, Hamburg, in dem folgenden Beitrag.

Die Bavaria-St. Pauli-Brauerei AG setzt seit 1977 Großrechner der IBM ein, derzeit eine /370-138 mit einem Megabyte. CICS und DL/1 wurden von Anfang an für die Entwicklung komplexer Anwendungs-Systeme eingesetzt. In kurzen Abständen wurden vier DB-orientierte Projekte ins Leben gerufen:

þNeugestaltung Artikelstamm-Verwaltung

þNeugestaltung Kundenstamm-Verwaltung

þSchaffung eines übergeordneten Tabellenwesens

þAblösung der Fibu durch ein Dialog-Software-Produkt

Diese gleichzeitige Häufung von Datenbank-Aktivitäten hatte sehr bald zur Folge, daß im Bereich Systementwicklung die tägliche Arbeit zu einem großen Teil aus Tätigkeiten

bestand, die in der einen oder anderen Weise gegen eine Datenbank gerichtet waren.

Jeder DB-Anwender kennt das: Datenbanken müssen

- geladen,

- ausgedruckt,

- verändert,

- mit Testdaten beschickt,

- oder für die Weiterverarbeitung auf sequentielle Dateien ausgegeben werden;

und diese Aktivitäten sind ständig und immer wieder auszuführen, zumindest während des Testbetriebes. Sicherlich konnten diese Aufgaben alle relativ problemlos bewältigt werden - man schrieb halt jedesmal ein Programm. Auf die Dauer jedoch empfanden wir es als unbefriedigend (weil unwirtschaftlich), immer wieder ein Hilfsprogramm zu schreiben oder ein bereits bestehendes zu ändern, weil ein anderes Segment oder eine andere Teilmenge von Segmenten benötigt wurde oder ein anderer Zugriffs-Pfad getestet werden sollte.

Interpreter sui generis

Wir suchten Abhilfe und fanden sie in dem Programm-Paket "Dlimastr", einem speziellen DL/1-Utility, das von der Hamburger S.P.O. consult GmbH entwickelt wurde. Es handelt sich dabei um einen Interpreter, der normalerweise als Batch-System arbeitet. Ein Subset seiner Funktionen ist auch online (unter CICS) einsetzbar. Dieses Produkt ist von so verblüffender Einfachheit in der Anwendung und dabei doch umfassend einsetzbar, daß man sich fragt, warum es nicht zur Grundausrüstung jedes Datenbank-Systems gehört (etwa wie "Ditto" zu jedem IBM-Rechner). Wir sagen dies, weil nach unserer bisherigen Erfahrung allen Utilities ein prinzipieller Widerspruch anhaftet: Je vielseitiger sie einsetzbar sind, desto komplizierter werden sie in der Anwendung - eine logische Folge des größeren Sprachumfanges. Das leidige Problem mangelnder Benutzer-Akzeptanz, welches vielen an sich guten Systemen das Leben schwer macht, ist unseres Erachtens eine direkte Folge dieses nicht gelösten Widerspruches.

Das System Dlimastr löst dieses Dilemma, indem es auf Formal-Regeln zurückgreift, die jedem DL/1-Programmierer ohnehin geläufig sein dürften. So wird etwa der Zugriff zu einem Segment (oder einer Menge von Segmenten) nach genau denselben Regeln spezifiziert, wie sie der DL/1-Call in einem Programm zu beachten hat, nämlich durch Angabe eines Funktions-Codes und einer variablen Liste von SSAs, qualifiziert oder unqualifiziert (Beispiel s. Kasten). Auf diese Weise ist jeder DL/1-Zugriff zu jedem beliebigen Segment in jeder beliebigen Datenbank ausführbar.

Schnelle Quasi-Programme

Um die Ergebnisse solcher DB-Calls zu verarbeiten, stellt Dlimastr einen Satz von Commands ("Aktionen") zur Verfügung, die es dem Anwender erlauben, zum Beispiel Segmente auszudrucken (PRINT), auszugeben (EXTRACT) oder zu verändern (MODIF), auf Wunsch auch mit Zufalls-Daten (RANDOM) zu beschicken. In Verbindung mit einem Cobol-ähnlichen IF-Statement, welches beliebige AND/ OR-Verknüpfungen zuläßt, und einem GOTO-Statement lassen sich regelrechte kleine "Programme" schreiben, ohne mehr als vielleicht ein Dutzend Anweisungen zu geben und vor allem ohne Compile-Lauf.

Die oben beschriebene völlige Unbeschränktheit des Datenbank-Zugriffs hat bei uns anfänglich nicht nur Begeisterung hervorgerufen, birgt sie doch die Gefahr von unkontrollierter Daten-Zerstörung (DELETE/REPLACE). Wir meinen jedoch, daß wir hinreichend abgesichert sind, indem wir von den beiden Zugriffsschutz-Verfahren des Dlimastr Gebrauch machen: Zum einen handelt es sich um eine DB-Tabelle, die die Namen jener Datenbanken aufnimmt, auf die zugegriffen werden darf (bei uns nur Test-Datenbanken); zum anderen existiert ein benutzerbezogener Password-Schutz, der über eine wahlweise "automatische Dynamisierung" des Passwords zu ungeahnter Effektivität

getrieben werden kann (wirksam selbst gegen den Password-Inhaber, wenn er nicht aufpaßt).

Hilfreiches Cobol-Feature

Neben den variablen DB-Zugriffen welche den eigentlichen Hauptzweck von Dlimastr darstellen, bietet das System noch eine Reihe von "Bonbons" die unsere Arbeit zum Teil ganz erheblich unterstützen. Als Beispiel sei das sogenannte Cobol-Format von Segment-Ausdrucken gewählt: Auf Wunsch gibt das System ein gelesenes Segment nicht nur im bekannten Ditto-Format aus (Char/hex), sondern in einem Format, das 1:1 der Cobol-Definition des Segmente; entspricht, also mit Feldnamen, Format und Wert (tatsächlicher Feldinhalt). Hierzu ist lediglich erforderlich, dle Original-Cobol-Satzstruktur einmalig zuvor von einem mitgelieferten Übersetzer lesen zu lassen. Die Informationen werden intern gespeicherl und bei der späteren Verarbeitung automatisch abgerufen. Es entfällt also jede manuelle Feld-Definition in irgendeinem Satzbeschreibungs-Medium. Dieses "Cobol-Feature" hat sich als spürbare Arbeitserleichterung beispielsweise beim Abgleich großer Mengen von Testergebnissen erwiesen.

Die besondere Benutzerfreundlichkeit des Systems zeigt sich auch in einem Merkmal, das nach unserer Kenntnis bei Systemen dieser Art einmalig ist: Der gesamte Sprachschatz (etwa 50 Aktionen) ist an einer zentralen Stelle definiert, die dem Benutzer zugänglich ist; die formalen Eigenschaften der Dlimastr-Sprache können also nach Belieben an Benutzerwünsche angepaßt werden. Dies gilt nicht nur für den reinen Wortlaut von Befehlen, sondern auch für eine Reihe von Verarbeitungsmerkmalen, wie Zeitpunkt der Ausführung, zulässige Formate von Variablen etc. Auch die Erweiterung des Sprach-Vorrates durch den Benutzer ist vorgesehen. Alles in allem eine Rücksichtsmaßnahme auf Anwenderbedürfnisse, von der wir angenehm überrascht waren.

Dlimastr ist ein weiteres Beispiel dafür, daß intelligente System-Software auch deutschen Ursprungs sein kann. Diese Feststellung gewinnt an Bedeutung durch die Tatsache, daß sämtliche Texte (Benutzerhandbuch Fehlermeldungen) in deutsch abgefußt sind. Nur das Vokabular der Befehls-Sprache enthält aus dem Englischen entlehnte Wörter. Aber dies - s. oben - kann der Anwender ja ändern.