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.

16.04.1982 - 

Autonome Rechner greifen auf gemeinsames Archiv zu:

Klinik-Verwaltung mit mehrstufigem Mini-Netz

23 Minicomputer im Netzverbund, aufgebaut im Laufe von vier Jahren mit einem Installationswert von etwa 10 Millionen Mark dienen der Stadt Wien zur Verwaltung ihrer 23 kommunalen Kliniken und Krankenhäuser. Wie diese Applikation, bei der Daten grundsätzlich lokal verarbeitet und höhere hierarchische Ebenen des Netzverbundes nur wenn notwendig konsultiert werden, gewachsen ist, beschreibt dieser Beitrag.

Am Anfang stand Mitte der 70er Jahre ein zentraler IBM-Großrechner für die Zuteilung der Krankenhausbetten, an den via Telephonleitung Terminals angeschlossen waren. Es folgte in Phase zwei die Installation einiger dezentral operierender Rechner unter zentraler Steuerung und mit zentraler Programmentwicklung.

Statt simpler Telephonleitungen benötigte man jetzt bereits bestimmte, einfache Netzfunktionen. Auswerteprogramme auf dem Zentralrechner wurden von da ab direkt von den Satellitenrechnern mit Informationen gespeist. Allerdings vorerst noch in der Form, daß Magnetbänder zunächst von einem Konzentrator beschrieben und dann der Zentralmaschine übermittelt wurden.

Das war auf Dauer allerdings doch zu umständlich, und steigende Datenvolumina erforderten ohnehin die Installation eines Kanal-Kopplers zwischen Konzentrator und IBM-Rechner. Außerdem entwickelten die Wiener Krankenhaus-Computeure im Bereich der patientenorientierten Verwaltung zusehends mehr Anwendungen, weshalb auch die Bettenverwaltung den dezentralen Computern übertragen werden mußte. Schritt für Schritt wurden die alten Terminals daher vom Zentralrechner abgekoppelt, dessen Anwendungsprogramme nunmehr über das Netz auf die verteilt gespeicherten Daten zugriffen.

Immer wieder Fehler

Doch auch mit diesem verfahren war man in Wien noch nicht zufrieden. Die periodisch notwendigen Datentransfers vorn und zum Zentralrechner führten nämlich immer wieder zu Fehlern, wie man in Wien bekümmert feststellen mußte. Außerdem wuchsen die Anwendungen munter weiter, und bald gab es vor Ort, bei den dezentralen Rechnern, keinen Platz mehr für die Installation der dringend benötigten zusätzlichen Speichereinheiten. Der Ausweg:- Man schuf sich ein zentrales Archivsystem, an das alle Daten, die in den lokalen Rechnern verändert wurden, automatisch über das Netz übertragen werden. Sie gelangen über den Kanal-Koppler zur IBM 370158 und finden ihren endgültigen Platz in einer ADABAS-Datenbank.

Was ist der Vorteil dieser Lösung? Nach Auskunft der Wiener DV-Manager kann man nun erstens auf Datenschutzmaßnahmen bei den dezentralen Rechnern verzichten, und zweitens eliminiert die automatische Übertragung sämtliche Handling-Probleme. Außerdem werden die Daten während der Übertragung nun automatisch einheitlich formatiert, was ihre unmittelbare erneute Verwendung problemlos macht.

Die zentrale Datenbank ist auf unbegrenztes Wachstum ausgelegt, wodurch alle Informationen stets präsent sein können, wann immer der Anwender sie auch benötigen mag. Gleichzeitig konnten die lokal en Systeme nun ohne Speichererweiterungen mit weiteren Anwendungen betrachtet werden. Spezielle Softwareroutinen gestatten den lokalen Systemen dabei durch Rekonstruieren der benötigten Informationen vor Ort einen raschen Online-Zugriff auch zu den Informationen, die zuvor schon in Richtung Datenbank verabschiedet worden waren.

In den letzten Jahren kamen immer wieder neue Anwendungen aus dem Bereich der medizinischen Versorgung hinzu, wie beispielsweise Radiologie, Labor und dergleichen mehr. Hierfür müssen die Patientendaten mit kürzesten Antwortzeiten greifbar sein. Gleichzeitig stellten die Wiener Rechen-Chefs sich auch die Aufgabe, alle alten Programme trotz Hardware-Erweiterungen unverändert weiterbetreiben zu können. Sie erweiterten daher das ganze System um eine neue Basis-Stufe, nämlich um lokale Rechner-Subsysteme in den einzelnen Krankenhäusern.

Diese Erweiterung erforderte wiederum die Implementierung neuer Netzeigenschaften, mit dem Ziel, die Kommunikation der Rechner untereinander weiter zu beschleunigen: Stichworte dazu heißen "Ethernet", "PC- 1 1 " und "Hyperchannel".

Fünf Funktionsebenen

So stellt sich die Wiener Krankenhaus-Rechnerei heute als fünfstufiges Schichtenmodell dar, deren unterste Stufe die lokalen Subsysteme bilden. Sie unterstützen jeweils eine klar definierte organisatorische Einheit an Ort und Stelle - eben Radiologie, Labor etc. - und können außerdem untereinander kommunizieren. Auf dieser Ebene wird sich in den kommenden Jahren übrigens die Hauptentwicklung vollziehen, wobei die Wiener VAX- und vielleicht auch andere 32-Bit-Minis installieren wollen.

Schicht zwei sind die lokalen Systeme, zuständig für die typischen Jobs einer Krankenhausverwaltung. Sie müssen über das Netz auf lokal und zentral gespeicherte Daten zugreifen können. Dazu arbeiten die Rechner, es handelt sich um PDP- 11 Maschinen, mit einem selbst entwickelten Online-System namens "COSMOS" unter dem Betriebssystem RSX. In etwa ein bis zwei Jahren soll die gesamte hier anvisierte Konfiguration endgültig ausgebaut sein, plant die Stadtverwaltung der Donaumetropole.

Als dritte logische Ebene kann das Netz selber aufgefaßt werden, das alle für das Management der einzelnen Operationen sowie für die Datenkommunikation erforderlichen Komponenten umfaßt. Hardwareseitig wird diese wichtige Konzentratorfunktion von einem PDP-11/70 Rechner wahrgenommen, der auch zentral den Betriebsablauf zu steuern gestattet.

Auf der vierten Ebene vollzieht sich das funktionelle Management (PDP- 11 und VAX) , wobei die Wiener drei Gebiete unterscheiden. Einmal die zentralen Funktionen des Sektors Anwendungsprogramme, wie beispielsweise die zentrale Bettenbelegung, die Leitstelle für die Rettungsautos, die Abrechnung samt Direktabrechnung mit den Versicherungen etc. Diese Systeme können über das Netz online auf alle Daten in den lokalen Systemen sowie im Archivsystem zugreifen. Der zweite Bereich ist die zentrale Programmentwicklungsunterstützung, und der dritte schließlich umfaßt die ganze Backup-Organisation. Hierbei gibt es für manche Anwendungen Programme, mit deren Unterstützung man in reduziertem Modus auf einem zentral aufgestellten Back-up-Rechner arbeiten kann, der bei einem Fehler im lokal installierten System einspringt. Mit dem Back-up-Rechner werden die wichtigsten Terminals dabei über Telephonleitungen verbunden.

Und nun noch Ebene fünf, jene also, in der aus allen "weiter unten" gesammelten Daten über besondere Programme die Informationen aufbereitet werden, die letztlich von der zentralen Krankenhausverwaltung sowie von den Politikern benötigt werden. Die hier eingesetzten Programme holen sich ihre Informationen unmittelbar aus dem zentralen Archiv und können so "sehr leicht" beispielsweise Statistiken erstellen, loben Wiener Fachleute das Konzept.

Genau besehen ...

Nach der generellen Darstellung des vorliegenden Systems beziehungsweise des Kurzfrist-Erweiterungskonzeptes nun noch einige interessante Details des Wiener Minicomputer-Netzes: Software entwickeln die Wiener auf drei PDP-11 Rechnern, von denen zwei zum Programmtest dienen und einer allein zum Editieren und Kompilieren bereitsteht: Das beschleunigt die Arbeiten. Die beiden Testrechner arbeiten nur - mit Testdateien und Task-Images, was besondere Maßnahmen zum Schutz "echter" Dateien überflüssig macht.

Die Rechner der lokalen Subsysteme arbeiten zum Zweck der Datensicherung nach dem Konzept der Schatten-Satz-Aufzeichnung ("shadow recording"), während auf der Ebene der lokalen Systeme, also bei der patientenorientierten Verwaltung, anders vorgegangen wird. Hier wird jeder geänderte oder neu aufgenommene Satz in einer besonderen Datei zwischengespeichert und über das Netz nach spätestens einigen Minuten dem zentralen Archivrechner übermittelt. Die Zwischenspeicherungs-Datei ist so beimessen, daß sie notfalls den Datenanfall von zwei Tagen aufnehmen kann, sollte das Netz einmal nicht arbeiten (die Verfügbarkeit der Rechner liegt nach den bisherigen Erfahrungen allerdings bei mehr als 99 Prozent).

Die fortwährende Übertragung der Daten von den lokalen Systemen zum zentralen Archiv erleichtert und beschleunigt das Wiederherstellen der Daten nach einem möglichen Headcrash und erlaubt überdies, den Speicher der lokalen Systeme relativ knapp zu bemessen: Denn sobald ein User-Terminal bestimmte, bereits in das Archiv abgeschickte Daten benötigt, kann es sie Über das Netz schnell wieder aus dem Archiv abrufen.

Die lokalen Systeme ( PDP- 11 -Maschinen) arbeiten neben dem RMS-Betriebssystem noch mit zusätzlichen, komplexen Software-Routinen, mit den Hilfe sich beispielsweise Transaktionen durchfuhren lassen, die bis zu einem Dutzend Datensätze ändern. Dabei garantiert dieses System, daß die Dateien nach einen möglichen Programmfehler oder Maschinenversager wieder automatisch den Status erhalten, auf dem sie vor der Transaktion waren.

Kurze Responsezeiten

Im Interesse kurzer Antwortzeiten wird beim Terminal-Dialog zunächst jeder vom Anwender geänderte Satz in einer Zwischendatei (log-file) aufgezeichnet; so entfallen die zum Modifizieren der Datenbank sonst erforderlichen Verzögerungen. Erst nach Abschluß aller Transaktionen werden die geänderten Sätze in die Datenbank übermittelt, wobei besondere Routinen die logische Korrektheit der Prozedur überwachen.

Was die physikalische Realisierung des Netzes betrifft, sind die lokalen Systeme mit ihren zugehörigen Subsystemen über Decnet gekoppelt, doch sollen später Ethernet, PC-11 und andere Kommunikationswege implementiert werden. Mit den zentralen Systemen korrespondieren die lokalen Systeme wiederum auf der Basis von Decnet über Telefonleitungen (19200 Baud). Zwischen dem Konzentrator und dem IBM-Rechner ist ein IBM-Kanal geschaltet.

Da alle Netzkomponenten von Haus aus auf kürzeste Antwortzeiten ausgelegt wurden, werden längere Ausdrucke und andere typische Batch-Aufgaben, obwohl das möglich wäre, nicht im Realtime-Modus ausgeführt. Online werden in Wien nämlich nur Batch-Anforderungen (von einem speziellen Batch-Handler) entgegengenommen, der dann die entsprechenden Berechnungen im Hintergrund ablaufen läßt. Dabei kann man die Batch-Anforderungen wahlweise als dringend deklarieren, worauf ihre Bearbeitung sofort nach Freiwerden von Kapazität beginnt, oder in Normalmodus abwarten, bis die Sache, beispielsweise über Nacht, erledigt worden ist.

Für die Wiener hat diese vollautomatische Batch-Steuerung den Vorzug, die Rechner mit minimalem Personalaufwand laufen lassen zu können. Generell arbeiten die Wiener Rechner auf der Ebene der lokalen Systeme und Subsysteme ja ohne Operatoreingriff Tag und Nacht.

Reduzierter Notfall-Betrieb

Ein spezielles Problem, wohl die Folge des schrittweisen Netzausbaus, besteht darin, mit unterschiedlichen Programmversionen und unterschiedlichen Rechnern arbeiten zu müssen. Die Wiener EDV-Mannen entwickelten daher spezielle Software-Module zur korrekten Verfolgung der diversen Programmversionen.

Das Back-up-System in Wien unterstützt nur die wichtigsten Funktionen; so etwa die Patientenverwaltung. Dazu können die Hauptterminals über zusätzliche Telefonverbindungen jederzeit direkt an den Backup-Rechner gekoppelt werden.

Im Back-up-Betrieb lassen sich die Dateien der lokalen Systeme nicht erreichen (nur bestimmte Ausdrucke werden erstellt), und deshalb gelangen beim Restart des lokalen Rechners alle vom Back-up-System inzwischen gesammelten Informationen über das Netz automatisch zu ihm. Dort werden die Daten-Sätze erst auf herkömmliche Art und Weise getestet, ehe sie endgültig überstellt werden.

Cobol-ähnliche Makrosprache

Was die Software des Wiener Rechnernetzes betrifft, ist unter anderem erwähnenswert, daß kein Anwender sich je über die Multi-Terminaleigenschaften seiner Application-Task - sie steuert den Anwenderdialog - Gedanken machen muß; selbst dann nicht, wenn mehrere User an verschiedenen Terminals gleichzeitig mit der gleichen Task arbeiten.

Zum Erstellen von Anwendungsprogrammen dient eine Cobol-ähnliche Makrosprache, die auf dem PDP1 1-Makro-Assembler aufbaut. Auch mit Cobol selber läßt sich arbeiten, doch soll, so hört man aus Wien, dann die Leistung der Maschinen leiden.

Das Softwarepaket "Cosmos" unterstützt im übrigen sämtliche Decnet-Funktionen und erlaubt es, Programme auf einer Maschine zu schreiben und zu testen und sie später in Teile zu gliedern, die auf unterschiedlichen Maschinen laufen.

98 Prozent Up-time

Was die bisherigen Erfahrungen mit ihrem Netz betrifft, loben die Wiener Spitals-Computeure vor allem die hohe Verfügbarkeit ihres Systems, die bei mehr als 98 Prozent "Uptime" liegen soll - gemessen im Tag-und-Nacht-Betrieb ohne Pause. Diese Verfügbarkeit sei, kann man hören, vor allem der strengen Trennung zwischen Softwareentwicklung auf der einen Seite und dem produktiven Betrieb auf der anderen Seite zu verdanken.

Gemessen an Mainframe-Installationen hat das Netz der 23 Minis aber natürlich auch Nachteile: So ist es ein Problem, jeweils gleichzeitig auf allen Rechnern die gerade richtigen" Programmversionen einzusetzen. Denn inzwischen wird bereits mit mehr als 500 einzelnen Programmen gearbeitet und immer wieder kommen neue oder modifizierte Routinen hinzu. Kein Wunder, daß die Übertragung von Daten vor der Installation des zentralen Archivs eine Quelle immer neuen Ärgers war.

Ein bißchen Lehrgeld mußte man in Wien auch zahlen, als die ersten dezentralisierten Computerräume für Operator-freien Betrieb eingerichtet wurden: Es zeigte sich bald, daß man diese Räume mit automatischer Klimatisierung, sowie mit Feuer-, Rauch- und Wasser-Alarmsystemen ausrüsten muß, will man beruhigt schlafen gehen, während die Rechner arbeiten.

_AU:Egon Schmidt