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.

25.01.1985 - 

Selbsthilfe oft einziger Weg aus dem Anwendungsdilemma:

Praktiker fordern mehr als schöne Argumente

Noch immer klaffen Theorie und Praxis bei der Lösung tagtäglicher Probleme im DV-Bereich weit auseinander. Frontkämpfer können sich oft des Eindruckes nicht erwehren, daß ihnen statt praktikabler Lösungen nur neue Werkzeuge angeboten werden.

Darüber hinaus erzeugen Verkaufsargumente wie zehnfache Produktivität oder leichte Bedienbarkeit eine Erwartungshaltung, die in keiner Weise zu befriedigen ist. Unter Berücksichtigung der Lebensdauer von Software sind neben der Betonung der Softwareentwicklung auch "Abwicklung" und "Anwendung" stärker ins Kalkül zu ziehen.

Unternehmensberater Franz Mugrauer aus Tönisvorst schildert in seinem Beitrag den Selbsthilfeweg der RZ-Mitarbeiter eines Unternehmens (Name der Red. bek.) durch eine Gegenüberstellung der Situation in den Jahren 1981 und 1984. Permanente Störungen des Dialogbetriebes und unbefriedigende extern vorgeschlagene Lösungsmöglichkeiten veranlaßten die RZler vorerst zu einer umfassenden Analyse - Schwachstellen gab es genug.

Die Dialogentwicklung, -anwendung und -abwicklung hatte zu jener Zeit wesentliche Merkmale, die bereits Hinweise auf die zu lösenden Schwierigkeiten beinhalten. Beim morgendlichen Start der Dialogabwicklung (Abb.1) durch das Operating wurde automatisch ein Programm gestartet, daß die - in einer programminternen Tabelle gespeicherten - Dialogdateien eröffnete. Dieses Programm wiederum startete eine Hintergrundtask, die dort abends im Batch abgestellte Protokollsätze in die entsprechenden Datenbankdateien verbuchte.

Zum Systemumfeld 1981 siehe untenstehenden Kasten I.

Der Teilnehmer hatte vier Möglichkeiten des Dialogeinstieges. Während bei Code 1 bis 3 nur das entsprechende System angewandt werden konnte, (zum Beispiel mit Code 1 nur Transaktionen des Vertriebssystems) bestand bei Code 4 die Möglichkeit, jedes System anzuwählen. Dieses zusätzliche Einstiegsverfahren war aufgrund von Anwenderwünschen geschaffen worden, die sich nicht bei jedem Einzelsystem neu anmelden wollten. In einer externen Tabelle waren die Benutzer mit Anmeldecode und ihren Transaktionsberechtigungen gespeichert (zum Beispiel MUSTERFRAU CODE DLO1 DL02 FDO1). Nach Prüfung der generellen Berechtigung (Name Benutzer und Anmeldecode) konnte der Anwender durch Eingabe der gewünschten Transaktion (zum Beispiel TRCD: DL02) seine Arbeit starten. Das erste Programm der Transaktion wurde über eine programminterne Tabelle ermittelt.

Die Transaktionen des Vertriebes stellten die Daten in eine Protokolldatei ab und wurden von dort durch die Hintergrundtask (Verbuchungsprogramm) in die DB-Dateien verbucht. Alle anderen Systeme führten die Veränderung der Daten direkt in der Datenbank durch.

Eine Transaktion (Abb.2) bestand aus maximal drei, teilweise mehrseitigen Masken, die in vier Programmen behandelt wurden. Das erste Programm stellte dem Benutzer die erste Maske zur Verfügung, die im zweiten Programm gelesen, geprüft und verarbeitet wurde, Trat bei Prüfung der Maske ein Fehler auf, so wurde eine Fehlermeldung gesendet und der Benutzer der Korrektur aufgefordert. Die Folgeprogramme arbeiteten nach dem gleichen Ablaufschema. Die Bedienung der Maske erfolgte über Behandlungscodes ("J" = bearbeiten, "N" = nicht bearbeiten). Bei Eingabe "N" in der ersten Maske sollte dem Anwender die Auswahl einer neuen Transaktion ermöglicht, ansonsten die erste Maske gesendet werden. Mehrseitige Masken konnten über ein Seitenfeld gesteuert werden. Bei Betätigen der Datenfreigabetaste wurde dem Anwender die nächste Seite, bei Vorgabe einer Seitennummer, die angeforderte Seite zur Verfügung gestellt.

Die Transaktionen des Vertriebssystems stellten die Daten in eine Protokolldatei ab, die von dort durch die Hintergrundtask in die entsprechenden DB-Dateien verbucht wurden (Abb.1). Alle anderen Systeme führten die Veränderung der Daten direkt in den DB-Dateien durch.

Abends beendete das Operating den Dialog über eine Vertriebstransaktion. Der Operator gab die noch verbleibende Zeit (zum Beispiel DIALOG NOCH AKTIV: 15 MINUTEN) ein. Bei Erreichen der Zeitgrenze und vollständig verbuchter Protokolldatei, wurden alle DB-Dateien geschlossen und die Dialogabwicklung konnte mit dem entsprechenden TP-Monitor-Befehl beendet werden.

Im TP-Monitor CICS besteht die Möglichkeit, Daten von Programm zu Programm (Abb.2) entweder über eine sogenannte TWA (Transaktion-Work-Area) oder über eine DFHCOMMAREA weiterzugeben. Der Unterschied besteht darin, daß bei Bedienung einer Task (im Sinne von CICS) die Daten der TWA verloren sind, während bei DFHCOMMAREA die Daten erhalten bleiben. Reichte der Platz in der TWA beziehungsweise DFHCOMMAREA zur Übergabe nicht aus, so wurde der Temporary Storage benutzt. Die Behandlung von Daten im Temporary Storage obliegt den Anwendungsprogrammen (reservieren, löschen). Zur Adressierung dieser Daten diente die Terminalkennung. Dadurch sollten Belegungsprobleme innerhalb der parallel laufenden Transaktionen vermieden werden.

Dem Programmierer stand ein Rahmenprogramm mit Steuerleiste und Verarbeitungsanschlüssen (Abb.3) zur Verfügung. Über die Steuerleiste wurde in die einzelnen Programmabschnitte mit GO TO FXX DEPENDING ON IND verzweigt. Zur Lösung der individuellen Programmaufgabe konnten die Anschlüsse F01- F10 benutzt werden. Die Anschlüsse F11 - F13 waren für programmabschließende Tätigkeiten vorgesehen. Im Block F 11 wurde veranlaßt, daß dieses Programm nach Korrektur der Maskendaten durch den Anwender, vom TP-Monitor erneut aktiviert wurde (zum Beispiel nach Senden einer Fehlermeldung). Im Block F 12 startete der TP-Monitor das mitgegebene Programm sofort. Über den Ausgang F 13 wurde erreicht, daß der TP-Monitor das mitgegebene Programm, nach Füllen der Maske durch den Anwender, ausführen sollte. Dieser Ausgang war erforderlich, da eine Maske in einem Programm aufbereitet und gesendet, aber erst im Folgeprogramm bearbeitet wurde (Abb.2). In der Zwischenzeit (Eingabe der Daten durch den Anwender) sollte der TP-Monitor nicht bereits mit einem aktivierten Programm belastet werden. Im System Vertriebsabwicklung waren die Ausgänge F 11 und F 13 in dieser Form nicht möglich, da durch Benutzung der TWA der TP-Monitor dies nicht zuläßt (die Daten der TWA werden in solchen Fällen gelöscht).

Die tägliche Arbeit mit diesem System legte einige Schwachstellen offen.

Bei Betrachtung der Wünsche der beteiligten Gruppen, ergeben sich verschiedene Anforderungen. So sollte der Dialog für den Anwender verfügbar, schnell und bedienungsfreundlich, für die Abwicklung pflegefreundlich und steuer-/kontrollierbar sein. Die Entwicklung forderte konzeptions- und wartungsfreundlichen, das Management sicheren und wirtschaftlichen Dialogverkehr.

Den Wünschen dieser Gruppen stand die tägliche Realität entgegen. Verschiedene Systembedingungen erschwerten die Verwirklichung der Vorstellungen. So waren für einige Dialogsysteme abends noch Batch-Arbeiten erforderlich. Ein Abbruch in diesen Verfahren verzögerte den Start der Dialogabwicklung am nächsten Morgen. Der Fehler mußte erst beseitigt beziehungsweise umgangen werden.

Schwierigkeiten im Verbuchungsprogramm (Hintergrundtask) behinderten den gesamten Dialog, da dieses Programm bei Start und Ende automatisch initialisiert wurde.

Schwerwiegende Fehler in Systemen, Transaktionen oder Dateien während der Verarbeitung mußten vor Restart zuerst behoben werden, da einzelne Komponenten nicht ausgeschlossen werden konnten.

Bei Änderungen in den Standardprogrammen (Berechtigungsprüfung, Transaktionsverteilung Open/Close-Programme) war bei fehlerhafter Änderung der gesamte Dialog gefährdet.

Bei abnormalem Ende eines Programmes (programmierter Abbruch, kein Dump) wurde die Beendigungsursache dem Teilnehmer auf seinem Bildschirm mitgeteilt. Der Teilnehmer ignorierte häufig die Meldung, so daß eskalierende Fehlersituationen zu spät erkannt wurden.

Wurde in einer Transaktion der Temporary Storage nicht gelöscht (zum Beispiel nach Dump) konnte der Anwender dieses Terminal nicht mehr benutzen. Bei Doppelbelegung einer Adresse bekamen nachfolgende Transaktionen falsche Daten geliefert.

Der Anwender hatte darüberhinaus keine interaktive Möglichkeit festzustellen, für welche Transaktionen er berechtigt war. Dies hat zwangsläufig Rückfragen zur Folge, da er bei abgewiesener Transaktionsforderung nicht wußte, ob er eine ungültige oder nicht berechtigte Transaktion aufgerufen hatte.

Die Bedienungslogik war zudem nicht einheitlich programmiert. Zur Behandlung der Bedienungscodes (J/N) wurden systemindividuelle Copy-Anweisungen eingesetzt. So konnte dem Anwender passieren, daß bei der Eingabe von Code "N" grundsätzlich in die Transaktionsverteilung verzweigt wurde.

Die Seitenbehandlung war nicht standardisiert. Während der User in einer Transaktion bei Erreichen der letzten Seite wieder die erste Seite erhielt, mußte in einem anderen Fall die Seite vorgegeben werden, ansonsten wurde das Programm beendet.

Die Versorgung der Anwender mit den notwendigen Handbüchern war aufgrund der komplexen Verteilungsproblematik nicht möglich. Wie soll, einigermaßen wirtschaftlich, die Verteilung/Wartung organisiert sein, wenn Benutzer und deren Berechtigungen sich laufend ändern?

Bei Schwierigkeiten oder auch bei geplanten Unterbrechungen des Dialoges müssen die Anwender informiert werden. Bei geplanten Unterbrechungen (zum Beispiel Austausch Steuereinheit) ist eine Benachrichtigung, wenn auch aufwendig, noch möglich. Bei Störungen ist eine systematische Benachrichtigung unmöglich, da durch diverse Rückfragen sämtliche Telefonleitungen im RZ blockiert werden.

Befand sich ein Anwender in einer umfangreichen Transaktion (zum Beispiel bei Position i5 von 30 eines Auftrages) und mußte dringend eine andere Transkation durchgeführt werden, so mußte diese Arbeit an einem anderen Terminal abgewickelt werden, ansonsten wäre eine erneute Eingabe der Datei erforderlich gewesen.

Auch im Steuer- und Kontrollsektor haperte es. Eine Einsatzsteuerung der Systeme, Transaktionen und Dateien war nicht möglich. Die Realität ist: Je mehr Komponenten im Einsatz sind, um so wahrscheinlicher ist eine Störung. Es mußte nach dem Motto verfahren werden: "Alles oder nichts!"

Eine Kontrolle war nur über die Dump-Datei des CICS möglich. Programmierte Abbrüche wurden häufig nicht behandelt, da der Anwender sich nicht meldete, sondern die Arbeit sofort oder später wiederholte und es bei positivem Ergebnis dabei bewenden ließ.

Die Benutzer und deren Transaktionsberechtigungen konnten nur mit einem Batch-Verfahren gepflegt werden. Zeitkritische Änderungen konnten nur mit erheblichem Aufwand durchgeführt werden.

Ebenso ließen Konzeptions- und Wartungsfreundlichkeit Wünsche offen. So wurde die dargestellte Struktur/Logik der Transaktionen nicht konsequent eingehalten. Es konnte vorkommen, daß im zweiten Programm die erste Seite der Maske aufbereitet und gesendet wurden die Folgeseiten aber im dritten Programm. Es waren auch noch andere Transaktionsstrukturen vorhanden. Eine Fremdfirma behandelte alle drei Masken einer Transaktion in einem Programm.

Die vor der Durchführung von CICS-Anweisungen notwendigen Fehlerausgänge waren nicht immer gesetzt. Die Programme wurden in der Regel kopiert. Dies hatte zur Folge, daß Fehler dupliziert und damit häufig auftreten konnten. Die Zuordnung, welche Anweisungen unter einem Abschnitt (FO1 - F10) zu programmieren sind, blieb den individuellen Fähigkeiten der Programmierer überlassen (Strukturierung).

Bei Änderung von Transaktionen und Programmen war für Nichtautoren eine komplette Einarbeitung in die Logik erforderlich. Bei Änderungen der Standardprogramme waren innerhalb der Systementwicklung Absprachen erforderlich, um zu vermeiden, daß noch nicht freigegebene Systeme in das Echtsystem gelangten. Der Testaufwand war bei Änderungen der Standardprogramme erheblich, da auch nicht betroffene Systeme und Transaktionen beeinflußt werden konnten.

Die aufwendige Änderungsprozedur der Benutzertabelle führte dazu, daß die Anmeldercodes selten gewechselt wurden. Durch fehlende, zwangsläufige Konzeptions- und Programmierrichtlinien war eine Personenabhängigkeit gegeben.

Diese Probleme schlugen auch auf die Wirtschaftlichkeit durch. Durch die permanenten Ausfälle mußten zeitkritische Anwendungen über Notorganisation abgewickelt werden. Diese Arbeiten waren nicht nur aufwendiger, sondern mußten anschließend im Dialog nachvollzogen werden. Die zwangsläufige aufwendige Entwicklung und Wartung der Systeme war personalintensiv.

Gespräche mit befreundeteten Kollegen ergaben, daß die vorhandene Problemstellung nicht einmalig sei.

Die erarbeiteten Analyseergebnisse waren indes wenig ermutigend:

- Für die real existierenden Probleme konnten kaum Hilfen gefunden werden. Angeboten wurden: andere Maskengeneratoren, Sprachen der vierten Generation, andere TP-Monitore, andere Datenbanken mit Auskunftsgeneratoren etc. Die Probleme waren jedoch hauptsächlich nicht in den vorhandenen Werkzeugen begründet, sondern in deren methodischen Einsatz.

- Bei Entscheidung für andere Werkzeuge wären die Mitarbeiter gezwungen gewesen, zusätzliche neue Instrumente zu beherrschen. Die RZler hielten dies nicht für machbar.

- Die als einfach dargestellten Sprachen der vierten Generation waren auch nur bei einfachen Aufgabenstellungen, einfach. Bei langlebiger Software existieren jedoch mittel bis schwere Problemstellungen. Bei kurzlebiger Software, sogenannten Ad-hoc-Anfragen, ist dieser Einsatz sinnvoll.

- Die alten Systeme wären weiterhin instabil geblieben und hätten intensiver Wartung bedurft.

- Die Personenunabhängigkeit hätte sich durch neue Wissensanforderungen erhöht. Wie soll kurzfristig ein Entwickler gefunden werden, der alle diese Instrumente beherrscht?

Bei Teilnahme an Seminaren und Vorführungen der Vertreiber dieser Werkzeuge stellten die Beteiligten erneut fest, daß die Probleme nicht einmalig sind. Die Referenten waren darüber hinaus auf gezielte Fragen (siehe Schwachstellenanalyse) dieser Art wenig vorbereitet und antworteten entweder ausweichend beziehungsweise versuchten die Frage zu verharmlosen.

Durch die Erkenntnisse der Marktanalyse bedingt, entschlossen sich die Mitarbeiter des Unternehmens, die Probleme selbst zu lösen.

Heute hat die Dialogabwicklung, -anwendung und -entwicklung wesentlich andere Merkmale.

Nach dem morgendlichen Hochfahren der Dialogabwicklung startet das Operating eine - nur vom Masterterminal anzuwendende -

Transaktion (Abb.4). Dem Operator werden alle einzelnen Systeme angezeigt. Er hat die Möglichkeit, Systeme vom Dialogbetrieb auszuschließen. Wird beim Eröffnen der Systeme ein schwerwiegender Fehler festgestellt, so werden alle davon betroffenen Transaktionen gesperrt. Die hier erforderlichen Informationen sind in einer Datenbank ausgelagert.

Der Teilnehmer hat zwei Möglichkeiten der Dialoganwendung. Durch Eingabe eines festgelegten Codes kann er sich vom Rechenzentrum eventuell hinterlegte Nachrichten (Broadcasting-Funktion) anzeigen lassen. Über einen weiteren Code startet der die Anmeldeprozedur. Vom Anwender wird zuerst die Eingabe seines Namens und seines Anmeldecodes (Code Alt) verlangt. Bei dieser Gelegenheit kann er seinen Anmeldecode (Code Neu) ändern.

Nach positiver Berechtigung wird durch Eingabe der gewünschten Transaktion in das erste Programm verzweigt. Das Benutzer-Menü (Anzeige der Transaktion eines Anwenders) wird ihm auf Wunsch, bei ungültiger Auswahl oder bei gesperrter Transaktion zur Verfügung gestellt. In der Regel weiß der Anwender, welche Arbeit er durchführen will. Durch Eingabe der gewünschten Transaktion und seines Namens direkt hinter CICS-Aufruf kann ein verkürzter Dialogeinstieg gewählt werden (er wird nur zur Eingabe des Berechtigungscodes aufgefordert).

Eine Transaktion besteht theoretisch aus einer beliebigen Anzahl von Masken (Abb.5). In der bisherigen Praxis waren fünf Masken das Maximum. In Abhängigkeit des Anwenderwunsches können auch nur Teile einer Transaktion durchgeführt werden (so hat der Anwender die Möglichkeit, den gesuchten Kunden entweder durch Eingabe der Kundennummer oder über ein vorheriges Suchen über Matchcode anzufordern). Transaktionen können auch gemeinsame Schlüsselmasken (erste Maske) aber unterschiedliche Datenmasken aufweisen (in der Schlüsselmaske zum Beispiel kann die Artikelnummer und ein Auswahlkennzeichen eingegeben werden. In Abhängigkeit der Auswahl wird dem Anwender entweder die Bestandsplanung oder die Absatzplanung angezeigt).

Jede Maske wird als Informationseinheit betrachtet und in einem Programm behandelt. Die Bedienung der Masken erfolgt über Behandlungscodes. Die bereits vorhandenen Codes (J/N) und deren Bedeutung haben wir beibehalten. Zusätzlich haben wir die Vorgabe der nächsten Transaktion (TRCD: DLO2) aufgenommen. Bei Eingabe "N" und dieser Aufforderung wird direkt über die Transaktionsverteilung in die gewünschte Transaktion verzweige (Prinzip: kürzestmöglicher Weg). Erweitert sind die Behandlungscodes um die Funktionen "O", "H" und "R". Bei Anwendung Code "H" und Eingabe einer zusätzlichen Spezifikation kann der Benutzer direkt Beschreibungen über System, Transaktion und Maske anfordern. Über den Behandlungscode "O" kann er an jeder x-beliebigen Stelle eine andere Transaktion aufrufen, mit dem Wunsch hierher zurückzukehren. Durch Eingabe Code "R" wird wieder in die mit "H" oder "O" verlassene Maske zurückgekehrt. Er kann seine Arbeit fortsetzen, so als hätte er sie nie unterbrochen.

Die prinzipielle Methodik der Seitenbehandlung wurde beibehalten. Bei Erreichen der maximalen Seitenzahl wird dem Anwender wieder die erste Seite zur Verfügung gestellt. Durch Eingabe "END" in das, Seitenfeld beendet er die Seitenbehandlung und es wird ihm die logisch folgende Maske angezeigt.

Die Veränderung der Daten werden direkt in den DB-Dateien durchgeführt. Die Buchungsmethodik im Vertriebssystem ist jedoch weiterhin vorhanden. Die Mitarbeiter entwickelten ein Dialogsteuerungssystem (Abb.4), mit dessen Hilfe besondere Vorkommnisse und die variablen Daten behandelt werden können. Dieses System besteht aus einer Reihe von Transaktionen, die verschiedene Belange abdecken:

- Starten und Beenden einzelner Systeme (zum Beispiel ein System konnte morgens nicht eröffnet werden).

- Aufgabe von Nachrichten an die Dialogteilnehmer mit Kurznachricht auf jedem aktiven Bildschirm

- Sperren/Freigeben von Systemen, Transaktionen, Dateigruppen und einzelnen Daten

- verschiedene Transaktionen zur Pflege der variablen Daten (Systeme, Transaktionen, Dateien, Dateizugriffe, Benutzer mit ihren Berechtigungen).

- Anzeige der gespeicherten Beschreibungen über allgemeines Dialoghandling (zum Beispiel Behandlungscodes, Seitenbehandlung, Aufbau Standardbild), Systeme, Transaktionen und Masken.

Abends beendet (Abb.4) der Operator vom Maskenterminal aus den Dialog. Es werden ihm alle Systeme angezeigt und einzeln geschlossen falls ein System nicht schon vorab beendet wurde. Die früher notwendige Zeitvorgabe und die Prüfung der Protokolldatei ist weiterhin vorhanden, aber jetzt nur noch eine Komponente des Vertriebssystems.

Daten werden von Programm zu Programm (Abb. 5) über DFHCOMMAREA weitergegeben. Dieser Bereich besteht aus einem standardisierten und einem individuellen Teil. Umfangreiche Daten werden weiterhin über Temporary Storage behandelt. Es wurde jedoch eine Methode entwickelt, die Adressierungsprobleme ausschließt.

Der gesetzmäßige Ablauf einer Maskenbehandlung (Abb.6) bietet sich als natürliche, daher leicht verständliche Logik an. Es steht ein Rahmenprogramm mit Copy-Bausteinen zur Verfügung. In diesen Copy-Bausteinen sind alle notwendigen Steueranweisungen für den TP-Monitor und für die standardisierte Bedienungslogik enthalten. Der individuelle Anwendungscode kann bausteinmäßig (Baustein A - Z) eingefügt werden. In der Regel sind nur ANS-Cobol-Kenntnisse erforderlich. Durch die festgelegten Methoden und Standards ist es möglich, dem Anwender die Transaktion nach Definition von sechs Programmvariablen, Maskengenerierung, Compilierung des Programms, Pflege der ClCS-Tabellen und Pflege der variablen Daten der Dialogsteuerung mit allem Bedienungskomfort zu demonstrieren.

Beim Vergleich der Schwachstellen 1981/1984 ergibt sich ein positiveres Bild. Es können auch heute noch keine Störungen durch Batch-Arbeiten vermieden werden. Der Fehler wirkt sich jedoch nur noch auf das verursachende System aus. Schwierigkeiten in der Hintergrundtask des Vertriebssystems tangieren auch nur dieses System.

Schwerwiegende Fehler in Systemen, Transaktionen, Dateien sind auch heute nicht gänzlich zu vermeiden. Die RZler sind jedoch in der Lage, die entsprechende Komponente zu sperren und den Dialog unverzüglich wieder zur Verfügung zu stellen. Änderungen in den Standardprogrammen sind nicht erforderlich, da die variablen Daten in einer Datenbank ausgelagert sind.

Das abnormale Ende eines Programmes wird protokolliert und kann jederzeit interaktiv überprüft werden. So werden rechtzeitig eskalierende Fehlersituationen erkannt und es können notwendige Gegenmaßnahmen eingeleitet werden. Durch die neue Adressierungsmethode treten Probleme mit Temporary Storage nicht mehr auf.

Durch systemtechnische Maßnahmen wurde auch die Schnelligkeit verbessert (siehe Kasten II).

Die Anmelderroutine führt den Anwender, unter Beachtung der Sicherheitsanforderungen, auf den kürzestmöglichen Weg, zu seiner Transaktion. Über das Benutzer-Menü erfährt er aktuell, welche Transaktionen er anwenden darf und welche zur Zeit gesperrt sind.

Die Bedienungslogik ist durch den Standardrahmen der Programme einheitlich geregelt. Über das Helpsystem ist die Versorgung der Anwender mit Benutzerhandbüchern und die Wartung dieser Beschreibungen einfach gelöst. Die Broadcasting-Funktion sichert, daß die Anwender jederzeit über geplante Unterbrechungen beziehungsweise aktuelle Störungen informiert werden können (außer bei Hardware- oder Betriebssystemschwierigkeiten).

Die Standardlogik gibt dem Anwender die Möglichkeit, jederzeit eine Transaktion zu unterbrechen und sie nach Abwicklung einer anderen Tätigkeit fortzusetzen. Das Startverfahren des Dialoges und die Transaktionen der Dialogsteuerung erlauben einen flexiblen Einsatz der Systeme, Transaktionen und Dateien. Das Motto heißt heute: "Soviel wie möglich!" Programmierte Abbrüche werden von allen Programmen gemeldet. Die regelmäßige Bereinigung dieser Schwachstellen hat zu einer erheblichen Reduzierung geführt.

Verbesserungen auch bei der Pflegefreundlichkeit. So kann die Pflege der variablen Daten (Systeme, Transaktionen, Benutzer, Berechtigungen etc.) interaktiv durchgeführt werden. Bei Löschung einer Transaktion werden den Benutzern automatisch die Berechtigungen entzogen.

Die konzipierte Struktur/Logik einer Transaktion kann nach wenigen Arbeitsschritten dem Anwender demonstriert werden. Die Transaktions- und Programmvorgabe kann strukturiert gestaltet werden, bausteinmäßig programmiert und getestet werden. Die Bildbehandlungscodes ("J/N/O/R/H") sind im Standardrahmen einmalig gelöst. Die Seitenbehandlung ist standardisiert und braucht nicht erneut erdacht und realisiert werden. Die vor Durchführung von CICS-Anweisungen notwendigen Fehlerausgänge sind im Standardrahmen abgedeckt.

Es werden auch heute noch Programme kopiert (warum nicht?), aber die Auslagerung der Standardanweisungen in Copy-Bausteinen verhindert die Duplizierung von Fehlern (außer im Anwendungsteil). Durch die Standardstruktur wird der Programmierer angehalten, die Anweisungen an den richtigen Stellen zu montieren.

Durch die zwangsläufige Struktur/Logik der Transaktion und des Programmes ist eine Einarbeitung für

Nichtautoren vereinfacht. So kann zum Beispiel die Prüfung der Daten einer Maske nur in einer klar definierten Sektion erfolgen (direkter Zugriff). Durch die Auslagerung der variablen Daten in eine Datenbank sind Absprachen nicht mehr erforderlich. Jeder kann, ohne jemand zu behindern, seinen Teil pflegen.

Die Standardprogramme haben eine hohe Verfügbarkeit ( 100 Prozent nach einem Jahr Echteinsatz). Rücksicht wurde bei der Ausarbeitung des Konzeptes auch auf Sicherheit und Wirtschaftlichkeit genommen. Bei jeder Dialogsitzung kann der Anwender seinen Anmeldecode ändern. Die Konzeptions- und Realisierungsrichtlinien haben die Personenabhängigkeit verringert, und die Wartung der eingesetzten Werkzeuge ist durch den Hardwarelieferanten langfristig gesichert (außer Datenbank).

Die Ausfälle der Dialogabwicklung konnten drastisch reduziert werden. Die Notorganisation muß daher seltener angewandt werden und dann auch nur für das betroffene System. Der Personalaufwand für Entwicklung und Wartung konnte trotz verbessertem Service erheblich verringert werden.

Die Mitarbeiter des Unternehmens haben die gravierendsten Schwachstellen entweder beseitigt oder deren Auswirkungen eingeschränkt. Selbstverständlich ist dies nur ein Schritt auf dem richtigen Weg. Auch die heutige Konzeption hat nach eigener Meinung Schwachstellen und sollte weiter verbessert werden.

Anhand dieser Problemstellung kann abgeleitet werden, daß die Softwarequalität nicht so sehr von den vorhandenen Werkzeugen abhängt, sondern in der noch nicht ausreichenden Methodik und Standardisierung der Softwareherstellung zu suchen ist.

Die in dem Unternehmen vorgefundene Situation mit durchaus guten Methoden und Standards (zum Beispiel Bedienungslogik oder Anmeldeverfahren) mußte den gestiegenen Anforderungen und veränderten Umständen angepaßt werden. Die Schwierigkeiten lagen hauptsächlich in der Anwendung diverser Systeme unter einer Dialogabwicklung begründet. Es ist leider häufig so, daß sachlich gute Software wegen durchaus zu behebender Abwicklungsschwierigkeiten abgelehnt und abgelöst wird.

Der eingeschlagene Weg ist nach Meinung der Beteiligten sicher nicht einfach und löst alle Probleme auf einen Schlag. Er zeigt auch, daß nicht nur an die Softwareentwicklung, sondern auch an deren Abwicklung und Anwendung gedacht werden muß. Die beiden letzteren Aspekte wurden in der Vergangenheit zu wenig berücksichtigt. Durch die Mikro-Konkurrenz werden die Anforderungen der Anwender (zum Beispiel Bedienungs- und Auswertungskomfort) stärker beachtet. Leider läßt sich dies für den Bereich der Abwicklung nicht sagen. Es nützt dem Anwender wenig, wenn er gut aufbereitete Grafiken, Computeranalysen etc. erhält, nur zum falschen Zeitpunkt oder mit halbrichtigen Werten oder nur selten sicher.

Aus diesem Beispiel könnte auch der Schluß gezogen werden, keine eigene Software herzustellen. Die Probleme, die heute existieren, können ermittelt und wie gezeigt auch teilweise abgestellt werden. Die Probleme, die durch den Einsatz von Mikros und ausschließlicher Standardsoftware kommen, kennt man indes noch gar nicht. Bei Betrachtung der heutigen Standardsoftware stellt man fest, daß die Belange der Anwendung und Abwicklung häufig ebensowenig berücksichtigt sind.

Welches Standardsystem läßt schon die Parametrierung der Bedienungslogik zu? Welches Standardsystem hat nicht ein eigenes Anmeldeverfahren? Welches Standardsystem läßt die flexible Einsatzsteuerung der Subsysteme und Transaktionen zu? Stellen Sie sich den Anwender vor, der von einem Bildschirm aus verschiedene Standardsysteme benutzen soll. Ein Mix aus Standardsoftware und eigenen Systemen sollte der richtige Weg sein.

Gute Informationssysteme werden im verstärkten Maße zum Überleben der Unternehmen im Konkurrenzkampf beitragen und Software, die jeder hat, gibt kaum einen Vorsprung.