MÜNCHEN - Der Rückgriff auf Vorhandenes (Kompatibilität!) verstellt meist den Weg in die Zukunft. Man muß, so Anwender Jens Christopher Ruhsert, Geschäftsführer der Wilhelm Gienger GmbH, München, und verantwortlich für den Bereich Information und Logistik, von statischen Organisationsstrukturen abrücken. Dies führt jedoch zu Anforderungen an die Software, die herkömmliche Konzepte auf der Basis von Cobol, RPG oder Basic nicht erfüllen können. Hier drohen Fehlinvestitionen in Millionenhöhe. Ruhsert warf vor einigen Jahren die Gienger-Software auf den Müll und begann mit dem Datenbankbetriebssystem "Mumps" von vorn.

Das Ergebnis dieses Erfahrungsberichts sei hier vorweggenommen und in verschiedenen Thesen zusammengefaßt:

- Die Datenverarbeitung ist eine Servicefunktion für die operierenden Geschäftsbereiche. Sie muß deren Bedürfnisse erfüllen, nicht umgekehrt. Das erfordert die flexible Anpassung der Datenstruktur an geänderte Organisationsstrukturen, jederzeit und schnell. Diese selbstverständliche Forderung ist sehr viel seltener erfüllt, als man sich überhaupt bewußt macht.

- Die Datenverarbeitung muß im Stande sein, die Rationalisierungsreserven im Bürobereich auszuschöpfen. Sie darf nicht der Engpaß der Organisationsentwicklung sein.

- Die Datenverarbeitungskosten werden maßgeblich von der Leistungsfähigkeit der Programmierwerkzeuge bestimmt. Sicher muß jeder Einzelfall geprüft werden. Vermutlich ist es teurer, weiter mit ungeeigneten Programmierwerkzeugen zu arbeiten, als das bestehende unzureichende Softwareinvestment abzuschreiben. Gienger ist diesen Weg gegangen. Ergebnis: Die Realisierung des sehr komplexen Anwendungspakets hat nur zwei Mann-Jahre Programmieraufwand erfordert: Die Programmwartungskosten liegen bei monatlich 500 Mark für die Telefonbereitschaft.

- Für die Auswahl geeigneter Programmierwerkzeuge gibt es acht Beurteilungskriterien: 1. Reifegrad, 2. operatorloser RZ-Betrieb, 3. Antwortzeitverhalten, 4. flexible Anpassung der Datenstruktur an geänderte Organisationsstrukturen, 5. Speicherplatzbedarf, 6. wirtschaftliche Programmierung, 7. Datenschutz und 8. Ferndiagnose bei Softwarewartung.

- Diese Beurteilungskriterien für Programmierwerkzeuge erfüllen die weitverbreiteten Programmiersprachen wie Cobol, RPG oder Basic nicht.

Chancen geopfert

Wer seinen Gutenberg richtig gelesen hat (den Betriebswirt, nicht den Drucker), weiß, daß der Restwert bestehender Anlagen bei Investitionsentscheidungen eine untergeordnete Rolle spielt; vielmehr zählen die laufenden Kosten. Man gewinnt häufig den Eindruck, daß diese betriebswirtschaftliche Regel beim Informationsinvestment außer Kraft gesetzt wird. Wie viele Chancen der Organisationsentwicklung wurden nicht bereits auf dem Altar der Kompatibilität zu vorhandener Hardware oder vor allem Anwendersoftware geopfert?

Niemand käme auf die Idee, mit technologisch veralteten Maschinen zu fertigen. Bei der Datenverarbeitung fehlt dagegen oft der Mut, eine überholte Ablauforganisation zu verschrotten und durch ein zeitgemäßes Organisationskonzept zu ersetzen. Eine stapelorientierte Ablauforganisation wird noch nicht dadurch zu einer dialoggestützten Betriebsorganisation, daß man Bildschirme zur Datenerfassung einsetzt.

Und eine dialoggestützte Betriebsorganisation erfordert eine völlig andere dialogorientierte Hard- und Software, weil das Papier als handlungsauslösender Informationsträger weitgehend durch den Bildschirm als "elektronischer Kugelschreiber" ersetzt wird. Dieser wichtige Zusammenhang wird durch Stichworte wie "beleglose Transaktionen" und "Informationsservicequote", die ständige Auskunftsbereitschaft der Datenbank, beschrieben. Daher verstellt der Rückgriff auf Vorhandenes (und das heißt "Kompatibilität") meist den Weg in die Zukunft.

Hinzu kommt ein zweites: Zielführende Organisationsstrukturen haben heute nur noch eine Lebensdauer von drei bis fünf Jahren. Schnelle Marktentwicklungen erzwingen eine hohe Anpassungsgeschwindigkeit der Betriebsorganisation. Daher sollte die Unternehmensführung selbst sicherstellen, daß hier die Datenverarbeitung und Organisation nicht zum Engpaß und Bremsklotz werden. Darüber hinaus erweist sich das herkömmliche Verfahren des Reißbrettentwurfs von Ablauforganisationen im Hinblick auf dialoggestützte Betriebsorganisationen als weniger erfolgversprechend.

Vielmehr ist die frühzeitige Einbeziehung der Fachabteilungen beim Organisationsdesign erforderlich, um Änderungswiderstände bei angestrebter hoher Bildschirmdichte von vornherein abzubauen und vor allem praxiserprobte Lösungen einzuführen. Das erforderliche Know-how für die Einbindung ihrer vielen handlungsorientierten Ideen können die Praktiker in den Fachabteilungen aber nur aus dem praktischen Umgang mit den "Neuen Technologien" gewinnen.

Das praxiserprobte Verfahren des "Inside-out"-approach für die Einführung dialoggestützter Betriebsorganisationen geht daher andere Wege: anstelle der langwierigen Realisierung komplexen Gesamtprojekte rasche Bereitstellung einer praktisch nutzbaren Basislösung; Berücksichtigung der Erfahrungen aus dem praktischen Betrieb der ersten Realisierungsstufe (integrierbaren Insellösung) bei Konzeption und Realisierung der Folgestufen. Diese Vorgehensweise bewirkt einen beschleunigten Return-on-Investment (ROI) und gleichzeitig eine erhöhte Anpassungsgeschwindigkeit der Betriebsorganisation an geänderte Verhältnisse.

Wenn diese Analyse richtig ist, erfordert dies zweierlei: Erstens muß die Fixierung auf die Restwerte des bestehenden Organisationsinvestments (Kompatibilität) aufgegeben werden. Zweitens gilt es, von der Fixierung auf statische, langlebige Organisationsstrukturen und Organisationsabläufe abzurücken. Das zielführende Organisationskonzept der dialoggestützten Betriebsorganisation geht von einem lebendigen Prozeß einer zukunftsweisenden Organigationsentwicklung aus ("lnsideout"-approach). Dieser Ansatz erzwingt ein Umdenken auf eine langfristige Zielsetzung und Strategie der Unternehmensführung selbst zur Koordination und Integration der gesamten innerbetrieblichen Kommunikationstechnologien mit drei Schwerpunkten:

Erstens erfordert die dialoggestützte Betriebsorganisation als Sicherheitskonzept den Einsatz fehlertoleranter Rechnersysteme, weil mit steigender Bildschirmdichte das Ausfallrisiko steigt. Einsatzabhängig kann der Systemausfall zum Stillstand der Gesamtorganisation führen (siehe CW Nr. 21/1984, Seite 40). Die Kosten des erforderlichen Hard- und Softwareinvestments müssen als Prämien einer Betriebsunterbrechungsversicherung bewertet werden.

Zweitens darf sich die DV-Kostenkontrolle nicht auf die Hardwarekosten (mit Ausnahme der Plattenkapazität, siehe unten) konzentrieren. Bei sorgfältiger Planung sind die Hardwarekosten weitestgehend durch Menügerüst und Problemlösung bestimmt und kaum beeinflußbar. Wer eine dialoggestützte Betriebsorganisation anstrebt, muß im Grundsatz jeden Schreibtischarbeitsplatz mit einem Bildschirm ausstatten.

Entscheidend ist allein, daß das angestrebte Organisationskonzept überhaupt zielführend ist und mit auskömmlichen Antwortzeiten verwirklicht werden kann. Der Schwerpunkt der DV-Kostenkontrolle liegt daher beim operationslosen Rechenzentrumbetrieb (Realisierung der bedingten Job-Verkettungen für die Stapelverarbeitung im operatorlosen Nachtbetrieb und Start der Dialogfunktionen durch die Anwender in den Fachabteilungen) und bei den Softwarekosten.

Programmierung darf kein Engpaß werden

Die Softwarekosten können erheblich dadurch beeinflußt werden, daß die Softwareerstellung und die Softwarewartung als Auftragsprogrammierung oder durch Kauf von Standardsoftware an Systemhäuser übertragen wird. Die komplexen Dialogsysteme erfordern ein derartig hohes Qualitätsniveau der Programmierer, die ein Unternehmen im Normalfall auf die Dauer weder halten noch wirtschaftlich auslasten kann.

Von entscheidender Bedeutung für die Kontrolle der Softwarekosten ist jedoch die Auswahl der geeigneten Programmierwerkzeuge, um häufige Organisationsänderungen und -verbesserungen schnell und wirtschaftlich realisieren zu können. Diese Programmierwerkzeuge haben auch maßgeblichen Einfluß auf die laufenden Softwarewartungskosten (Systemstabilität und Änderungsfreundlichkeit).

Drittens darf die Programmierung nicht - wie meistens der Fall - zum Engpaßfaktor der Organisationsentwicklung werden. Auch die Anpassungsgeschwindigkeit der Betriebsorganisation PV-Organisation) ist weitgehend durch die richtigen Programmierwerkzeuge bestimmt.

Software-Fehlinvestitionen in Millionenhöhe

Auf dem Hintergrund dieses Anforderungsprofils lautet die zentrale Aussage, daß nur interpretierende, relationale Datenbankbetriebssysteme diesen hohen Anforderungen an derartige Programmierwerkzeuge genügen. Eines der leistungsfähigsten derartigen Datenbankbetriebssysteme ist das DSM-11 Digital Standard Mumps (Massachusetts General Hospital Utility Multi Programming System), zumindest wenn man von realisierten, komplexen Dialogsystemen wie dem dieses Erfahrungsberichts ausgeht. Die gebräuchlichen Programmiersprachen wie Basic, Cobol oder RPG erfüllen dieses Anforderungsprofil nicht. In der Praxis bedeutet das bei vielen Unternehmen Fehlinvestitionen im Softwareinvestment in Millionenhöhe. Diese provozierende Aussage muß begründet werden.

Das Ergebnis eines Vergleichslaufs (Benchmark-Test) soll zunächst eine

Größenordnung vermitteln (siehe CW Nr. 21/1984, Seite 10). An dem Benchmark-Test beteiligt waren vor allem IBM 38/5 mit RPG III, HP 3000 mit Fortran (Image), DG MV6000 mit

Cobol (Infos), Nixdorf 8890/30 mit Cobol (Nidos) 6/92 mit Cobol (Tps-6) und DEC PDP-11/44

mit Mumps (DSM-11) beziehungsweise VAX- 11/750 mit Mumps (M/VX). Die Ergebnisse lassen sich zu einer eindeutigen Aussage zusammenfassen:

1. Auf identischer Hardware (VAX11/780) ist Mumps gegenüber Cobol mindestens doppelt so schnell bei Datenbank-Generierung und Datenbankabfrage (Antwortzeitverhalten).

2. Bereits die PDP- 11/44 zeigt unter Mumps in den meisten Tests eine bessere Leistung als die meisten 32-Bit-Rechner und die gleichen wie VAX-11/750 mit Mumps (Antwortzeitverhalten).

3. Mumps benötigt nur etwa ein Viertel des Speicherbedarfs von RPG, Cobol oder Fortran.

4. RPG erfordert den fünffachen, Cobol mindestens den sechsfachen, Fortran den fünfzehnfachen und Basic (Reality 2000 von Microdata) den doppelten Programmieraufwand wie Mumps.

Reifegrad entscheidend

Ausgehend von der empfohlenen schwerpunktverlagerung bei den

Handlungsparametern der Unternehmensführung hinsichtlich der Datenverarbeitung gibt es acht Beurteilungskriterien, von denen drei im Benchmark-Test angesprochen sind:

1. Für kommerzielle Anwendungen ist der Reifegrad des Programmierwerkzeugs entscheidend weil hier im Gegensatz zu technisch-wissenschaftlichen Anwendungen die Ein-/ Ausgabeprozeduren und die Dateiverwaltung im Vordergrund stehen. Mumps wurde bereits 1966 vom Bostoner MIT entwickelt und seit fast 20 Jahren im praktischen Einsatz verbessert. 1970 bis 76 wurden allein vom National Center for Health Services Research (NCHSR) zehn Millionen Dollar in Mumps-Projekte investiert. 1977 wurde Mumps als dritte Programmiersprache standardisiert (ANSI-Norm X11.1). Trotz geringer Verbreitung verfügt Mumps über eine solide Benutzerbasis mit weltweiter Unterstützung durch Benutzervereinigungen.

2. Voraussetzung für den operatorlosen RZ-Betrieb (Personalkosten) ist ein selbstverwaltendes Datenbanksystem mit einer dynamischen Speicherverwaltung für variable Datei-, Satz- und Feldgrößen, die eine Datenbankreorganisation überflüssig

macht. Wie wichtig diese Selbstverwaltung ist, wird bei Tag- und Nachtbetrieb im Containerterminal der Hamburger Hafen- und Lagerhaus AG (HHLA) deutlich. Ein anderes Beispiel: Vor anderthalb Jahren mußte die sehr komplexe Gienger-Datenbank neu geladen werden - dieser Vorgang erforderte volle drei Tage.

3. Bei komplexen Dialogsystemen werden riesige vernetzte Datenbestände ständig im Zugriff gehalten. Die Datenspiegelung bei fehlertoleranten Systemen verdoppelt diese Plattenkapazität noch einmal. Damit gewinnt der geringe Speicherbedarf des Mumps einen erheblichen Einfluß auf die Hardwarekosten. Bei Gienger im Fallbeispiel würde bei anderer Datenspeicherung als Mumps eine Plattenkapazität von etwa 10 000 MB erforderlich (statt der installierten 2500 MB). Verantwortlich für diesen geringen Speicherbedarf ist die bereichsdynamische Speicherverwaltung mit der Speicherplatzoptimierung.

Keine Reservierung ohne Dateninhalt

Ein weiterer Grund ist in der dynamischen Länge der Datenspeicherung zu sehen (globale Variable oder globals). Im Mumps bezeichnet ein global eine Datei. Jeder Datensatz dieser Datei besteht aus einer Anzahl Datenfelder. Jedes Datenfeld ist definiert mit Globalname, Schlüsselindex, Feldlänge und Dateninhalt, wobei Globalname und Schlüsselindex entsprechend der binären Baumstruktur in komprimierter Form gespeichert werden. Daher ist solange keine Speicherplatzreservierung erforderlich, wie dem symbolischen Feld kein Dateninhalt zugeordnet ist.

4. Die dynamische Speicherverwaltung und die Globalstruktur ermöglichen auch das gute Antwortzeitverhalten (Hardwarekosten) von Mumps. Dies ist in der geringen Plattenzugriffshäufigkeit begründet: Nur acht Prozent der logischen Dateizugriffe führen zu physikalischen Plattenzugriffen. Dies wird durch zwei Faktoren erreicht: Die "Balanced-Tree"-Methode stellt sicher, daß für jeden Plattenzugriff der gleiche Zeitbedarf erforderlich ist (anders als beim Überlaufbereich indexsequentieller Speicherung.

Mehr Information im Plattenpuffer

Außerdem werden durch die globalen Variablen mehr logische Informationen bei physikalischer Übertragung in den Plattenpuffer im Hauptspeicher (disk cache) bereitgestellt. Diese Durchsatzsteigerung durch Mumps ermöglicht im Fallbeispiel den Anschluß von 60 Bildschirmen und etwa zehn Druckern an eine PDP-11/70 bei hervorragenden Antwortzeiten - was unter normalen Betriebssystemen überhaupt nicht funktionieren würde.

5. Die Flexibilität in der Anpassung der Datenstrukturen an Änderungen der Organisationsstrukturen (Anpassungsgeschwindigkeit) bestimmt ein entscheidendes Beurteilungskriterium für Programmierwerkzeuge.

Die Leistungsfähigkeit des Mumps wird durch den Dateizugriff auf Feldniveau und nicht auf Satzebene erreicht. Das ermöglicht problemlos beliebige Einfügungen in bestehende Datenbankstrukturen. Andere Datenbanksysteme bestehen aus drei Komponenten: der Datendefinitionssprache, der Datenmanipulationssprache (Lesen und Schreiben) und einer Gastprogrammiersprache (zum logischen oder arithmetischen Verknüpfen von Daten).

Das Mumps dagegen stellt eine integrierte Einheit von Betriebssystemen, Dateiverwaltung und Programmiersprache dar. Dadurch wird aus einem Datenbankzugriff eigentlich ein Zugriff auf einen internen Arbeitsspeicher des Rechners. Unterstützt wird dies durch die binäre Baumstruktur der Datenspeicherung, auf die in mehrfacher Weise (anders als bei den reinen relationalen Datenbanken) zugegriffen werden kann ("multi-way"-balanced Tree): physikalisch erfolgt die Datenspeicherung hierarchisch über den primären Ordnungsbegriff (binäre Baumstruktur).

Anwendungsbezogen kann der Zugriff auch relational über Schlüsseldateien erfolgen (beliebige Tabellenanzahl von Sekundärindizes). Darüberhinaus ist ein logischer Dateizugriff möglich über die Datenbankvernetzung, das heißt wahlweise hierarchisch von oben nach unten und/ oder horizontal.

6. Das sechste Beurteilungskriterium ist die Wirtschaftlichkeit der Programmierung (Softwareerstellungskosten). Die Integration der Dialogverarbeitung bewirkt die Befehlstärke des Interpretors sowohl zum Benutzer hin (geringe Lines-of-code gegenüber Cobol) wie beim Datenbankzugriff (vor allem beim Mehrfachzugriff).

Die Befehlsstärke des Interpretors bewirkt die Schnelligkeit der Programmentwicklung. Umstellungsbedingt war bei der Gienger-Anwendung die Vergleichbarkeit mit dem sehr leistungsfähigen Business Basic von MAI gegeben: Ergebnis war, daß die Programmierzeit für vergleichbare Problemstellungen bei Basic etwa fünfmal so lang war wie bei Mumps; bei besonders Datei-intensiven Programmen sogar noch länger.

Gleichzeitig wirksam

Außerdem stellt das parametrierte Dateiverwaltungsprogramm mit freiprogrammierbarer Abfragesprache (Query), List-Generator und integrierter Textverarbeitung sicher, daß alle Programme nur über einen zentralen Filemanager auf die Datenbank zugreifen. Damit wird eine einmalige Änderung der Satzparameter für alle Programme gleichzeitig wirksam, die diese Datei ansprechen.

Die außergewöhnliche Flexibilität des Mumps bei der Anpassung der Datenbankstruktur an geänderte Organisationsstrukturen ist darauf zurückzuführen, daß bei Mumps der Datenbankzugriff grundsätzlich auf Datenfeldniveau und nicht auf Datensatzniveau erfolgt.

7. Der Zugriff auf Feldniveau ist auch die Voraussetzung für die hohen Anforderungen an den Datenschutz (Vermögenssicherung), die bei komplexen Dialogsystemen unerläßlich sind. Bei Mumps kann dadurch unabhängig von der Absicherung der einzelnen Dialogfunktionen über die Berichtigungscodes jedem Datenfeld eine Absicherungsstufe (user level) zugeordnet werden, und zwar getrennt nach Auskunftsbereitschaft (lesen) und Fortschreiben (update). Verfügt der Benutzer bei einer Dialogfunktion über den Berechtigungscode, aber für ein individuelles Datenteld nicht über die ausreichende Absicherungsstufe, dann kann er zwar die Dialogfunktion ausfahren und auch auf das Datenfeld der Datei grundsätzlich zugreifen, nur nicht auf den Inhalt dieses individuellen Datensatzes.

Je höher die Bildschirmdichte bei einer dialoggestützten Betriebsorganisation wird, um so unverzichtbarer wird ein derartiges Datenschutzkonzept; sonst kann entweder das Konzept des "elektronischen Kugelschreibers" (wahlfreier Zugriff vieler auf die Datenbank) nicht realisiert werden, oder es muß auf einen ausreichenden Datenschutz verzichtet werden. So gab es bei der Gienger-Anwendung durch die unzureichende Datenschutzkonzeption des herkömmlichen Basic früher erhebliche Probleme.

8. Das letzte Beurteilungskriterium für die Leistungsfähigkeit der Programmierwerkzeuge ist - last, not least - die Ferndiagnose bei der Softwarewartung (Softwarewartungskosten). Dies muß einerseits im Zusammenhang gesehen werden mit der Zweckmäßigkeit, komplexe Dialogsysteme in Auftragsprogrammierung an Systemhäuser zu vergeben. Andererseits sinkt mit dem Integrationsgrad einer Dialoganwendung die zulässige Reaktionszeit für die Behebung von Softwarefehlern oder Mängeln der Systemanalyse. Je mehr die Ablauforganisation von der Auskunftsbereitschaft der Datenbank abhängt, um so nachhaltiger und vor allem unkontrollierbarer wirkt sich jeder Softwaremangel aus.

Strukturmängel in der Systemanalyse

Als bei Gienger die Hochregalsteuerung über die zweistufige Sammelkommissionierung mittels Etiketten eingeführt wurde, stellten sich erhebliche Strukturmängel in der Systemanalyse heraus, die nur im Echtlauf erkennbar waren; der Rückgriff auf die bisherige Ablauforganisation war jedoch nach Systemanlauf nicht mehr möglich. Wenn hier nicht innerhalb weniger Tage einschneidende Eingriffe in die gesamte Programmlogik hätten erfolgreich realisiert werden können, wäre ein Zusammenbruch des Warenflusses zu befürchten gewesen.

Jeder Programmabbruch kann jederzeit eine derartige Situation wieder heraufbeschwören. Für die Funktionssicherheit einer dialoggestützten Betriebsorganisation ist daher die Ferndiagnose bei der Programmwartung unerläßlich.

Bleibt nur zu fragen, warum Mumps dann nicht weiter verbreitet ist. So leistungsfähig erfolgreiche Mumps-Installationen auch sein mögen, so klein ist die Exotengemeinde der Anwender. Vielleicht steht gelegentlich sogar in der Datenverarbeitungsbranche die fachliche Kompetenz im umgekehrten Verhältnis zur Lockerkeit, mit der das EDV-Chinesisch über die Lippen kommt. Selbst Digital Equipment, der Hersteller der wohl populärsten und erfolgreichsten Version, bekämpft den Mumps-Einsatz zugunsten der eigenen Software. Verständlich nur, wenn dabei vergleichbare Ergebnisse erzielt werden. Den Exoten bleibt ein Trost. Sie befinden sich in erlesener Gesellschaft: Für hauseigene Anwendungssoftware setzt Digital Equipment Mumps ein, ebenso erfolgreich wie die DEC Medical Systems Group. Sollte hier die Rechte nicht wissen, was die Linke erfolgreich tut?

Das Unternehmen

Firma

Wilhelm Gienger GmbH München mit Filialen in Erlstätt (Chiemsee), Memmingen (Allgäu) und Wolfratshausen (Starnberger See)

Branche

Technischer, lagerhaltender Sortimentsgroßhandel für Sanitär- und Heizungsmaterial

Liefergebiet

Oberbayern und südliches Niederbayern

Zentrallager

Lagerhäuser mit zirka 17 000 Quadratmeter Grundfläche und computergestützter Hochregal-Lagersteuerung

Fuhrpark

30 Lkw mit einer Gesamtnutzlast von 125 Tonnen und einer Transportleistung von

- 1,2 Millionen Jahres-Kilometerleistung

- 90 000 Anlieferungen pro Jahr

- 14 000 Jahres-Tonnenleistung

Mengengerüst

- 1000 Aufträge pro Tag

- 5000 Auftragszeilen pro Tag

- 25 000 Artikel im Lagersortiment

- 3000 Stammkunden

Die Anwendung

Anwendungspaket

Integriertes Dialogsystem für Angebotsverwaltung, Auftragsabwicklung, Bestellwesen mit Bedarfsprognose, Lagerbewirtschaftung mit Hochregal-Lagersteuerung (zweistufige Sämmelkommissionierung, mittels Etiketten) und Tourenverwaltung mit Fuhrparkformationssystem (selbstverständlich Finanzbuchhaltung und Personalverwaltung)

Bildschirmdichte

75 Prozent der Büro-Arbeitsplätze

Informations-Servicequote

70 Prozent der Transaktionen sind Datenbankauskünfte (nur noch 30 Prozent Datenerfassung für spätere Stapelverarbeitung)

Betriebssystem

Interpretierendes relationales Datenbankbetriebssystem Mumps (mit der ANSI-Spezifikation X11.1 1977) und fehlertolerantes Betriebssystem Visos

Softwareerstellung

Schlüsselfertig durch Systemhaus mit Softwarewartung im Bildschirmdialog

Die Konfiguration

Fehlertolerantes Duplex-System

für die Warenwirtschaft von Digital Equipment (DEC); zur Zeit auf PDP-11/70 - Basic mit Rechnerkoppelung über Hochgeschwindigkeitkanal (DMC)

Stand-alone-System

VAX-11/750 von DEC; zur Zeit für Verwaltung (zur Vorbereitung der Vernetzung des Gesamtsystems (Cluster) auf VAX-Basis)

Datenbank

Datenspiegelung der gesamten Datenbank; zirka 2500 MB Plattenkapazität wechselseitig umschaltbar auf jedes System (dual port)

Terminals

- zirka 150 Bildschirme (mikroprozessorgesteuert umschaltbar bei Systemausfall)

- zirka 25 Drucker

Datenfernverarbeitung

3 Abhollager über Standleitung angeschlossen; Anschluß der Filialen (Stadleitungsanschluß vorgesehen) sowie Hardware- und Softwarewartung über Wählleitungen

Systemverfügbarkeit

- 99,9 Prozent des Gesamtsystems bei 24-Stunden-Betrieb im ganzen Jahr (das heißt maximal 8 Stunden pro Jahr Wartungsausfall )

- eine Viertelstunde Wiederanlaufzeit bei Ausfall von Systemkomponenten

Operatorloser RZ-Betrieb

durch bedingte Job-Verkettung für Stapelverarbeitung im operatorlosen Nachtbetrieb des Rechenzentrums (Start der Dialogfunktionen erfolgt ohnehin durch die Anwender selbst)