DE4033336A1 - Verfahren zum erzeugen einer ausfallmeldung und mechanismus fuer ausfallmeldung - Google Patents

Description

Die Erfindung betrifft eine Ausfallmeldung in einem Computernetzwerk, wobei mehrere zusammenwirkende Abschnitte bzw. Teile eines Anwenderprogrammes jeweils auf unterschiedlichen Knoten des Computernetzwerkes laufen.

Bei einer modernen Computerdatenverarbeitung wird eine verbesserte Effizienz bei der Durchführung eines Anwenderprogrammes oft durch Aufteilen des Programmes in mehrere zusammenwirkende Teile und durch Laufenlassen jedes der Teile auf einer anderen CPU innerhalb eines Computernetzwerkes erreicht. Jeder Teil des Anwenderprogrammes läuft jeweils als ein abgetrennter Prozeß bzw. Vorgang auf einer bestimmten CPU. Von den Teilen kann z. B. zu einem Zeitpunkt einer aktiv sein, wohingegen die anderen Teile bzw. Anteile inaktiv in einem "standby"-Modus sind, oder sie können alle zum gleichen Zeitpunkt als zusammenwirkende Teile des Gesamtdatenverarbeitungsbetriebes aktiv sein.

Für eine zuverlässige Ausführung des gesamten Anwenderprogrammes bzw. Applikationsprogrammes muß jede CPU, die einen Teil des Anwenderprogrammes fährt, während der gesamten Verarbeitung des Teiles richtig funktionieren. Wenn ein Teil des Anwenderprogrammes wegen eines CPU-Ausfalls ausfällt, ist es unbedingt notwendig, daß eine Meldung des Fehlers bzw. des Ausfalls bzw. der Störung gemacht wird, um einem Netzwerkmanager zu ermöglichen, geeignete Korrekturvorgänge zu implementieren. Z. B. kann der Netzwerkmanager den ausgefallenen Teil des Anwenderprogrammes einer anderen CPU des Netzwerkes zur Durchführung zuführen.

Das Überwachen eines richtigen Netzwerkbetriebes ist eine wichtige, noch zeitverbrauchende Funktion, die typischerweise von Netzwerkmanagern oder Operatoren ausgeführt wird. Bei einem CPU-Ausfall muß der Netzwerkmanager ermitteln, ob die CPU einen zusammenwirkenden Teil des Applikationsprogrammes ausgeführt hat, das Applikationsprogramm und den Teil, der auf der ausgefallenen CPU läuft, identifizieren und dann geeignete Schritte unternehmen, um das Applikationsprogramm wieder zu starten.

Dementsprechend besteht die Aufgabe der vorliegenden Erfindung darin, einen automatischen, zuverlässigen Mechanismus anzugeben, um einen Fehler unter den Netzwerkkomponenten, die zusammenwirkende Teile eines Applikationsprogrammes abarbeiten, zu detektieren und um eine wirksame, informative Meldung des Ausfalls zu liefern.

Diese Aufgabe wird durch das Verfahren nach Anspruch 1 gelöst.

Die vorliegende Erfindung liefert einen automatischen Ausfallmeldungsmechanismus, der sehr durchsichtig für Anwenderprogrammentwickler ist und leicht implementiert werden kann, indem ein Unterprogrammaufrufbefehl (call subroutine instruction) in jedem Teil eines Applikationsprogrammes eingefügt wird. Der Mechanismus umfaßt einen Satz von verbundenen Unterprogrammen, die von jedem Teil des Applikationsprogrammes aufgerufen werden und durch den Gebrauch eines verteilten Sperrmanagers (lock manager) arbeiten, um die verschiedenen Teile des verteilten Applikationsprogrammes zu verbinden und umgekehrt zu verbinden. Der Ausfallmeldungsmechanismus verwendet die Verbindungen und Umkehrverbindungen, um eine Ausfallkommunikation beim Zusammenbruch bzw. Ausfall bzw. Crash einer CPU auszulösen, die einen Teil des Applikationsprogrammes ausführt. Die Ausfallkommunikation bzw. Fehlerkommunikation umfaßt Informationen, die ausreichen, um eine automatische Rückkehr nach dem Ausfall ohne der Notwendigkeit eines manuellen Einschreitens durch einen Netzwerkoperator oder Manager auszulösen.

Ein verteilter Sperrmanager, wie z. B. der VMS-verteilte- Sperrmanager (vertrieben von der Firma DIGITAL EQUIPMENT CORPORATION), ist ein Mechanismus zum Koordinieren eines netzwerkweiten Zugriffs auf Dateien und ihre einzelnen Datensätze und zum Synchronisieren von Zwischenverarbeitungsereignissen bzw. -vorgängen innerhalb des gesamten Netzwerkes. Im allgemeinen erlaubt der Sperrmechanismus einem Programmentwickler, jede Quelle im Netzwerk zu benennen, ganz gleich ob physikalisch oder logisch, und von einem Applikationsprogramm zu verlangen, das auf einer CPU (d. h. einem Prozeß) läuft, eine Sperre für diese Quelle vor dem Zugriff auf die benannte Quelle nachzufragen. Z. B. kann eine Datenbank oder ein Untersatz dergleichen solch eine Quelle sein und eine Sperre kann in einem von mehreren Sperrmodi vorliegen, die von dem Sperrmanager erkannt werden. Sperrmodi können verschiedene exklusive oder geteilte Schreib- und Lesezugriffsprivilegien für die Quelle enthalten, um einen Zugriff mit anderen Prozessen zu teilen oder einen Zugriff durch andere Prozesse zu verhindern.

Der Sperrmanager behält auch gewährte und wartende Schlangen bzw. Reihen für Sperrnachfragen für jede benannte Quelle bei und bedient wartende Nachfragen in der Art und Weise, daß diejenige Nachfrage, die zuerst kommt, auch zuerst bedient wird. Eine Sperrnachfrage (lock request) wird in einer gewährten Schlange bzw. Warteschlange plaziert, wenn die Nachfrage gewährt wird, und wird in einer Warteschlange plaziert, wenn die Sperrnachfrage unverträglich mit einer bereits gewährten Sperrnachfrage ist. Jeder Prozeß, der auf einem Netzwerk läuft, kann Sperrnachfragen einer Sperrnachfrageschlange in eine Warteschlange einreihen oder aus dieser entnehmen (freigeben) und desweiteren eine asynchrone Systemfalle in der Sperrnachfrage spezifizieren.

Eine asynchrone Systemfalle ist ein Programm, das einen laufenden Prozeß bei dem Auftreten eines Ereignisses unterbricht und mit der Ausführung beginnt. Beim Sperrmechanismus können die Ereignisse bzw. Vorgänge das Gewähren einer Sperrnachfrage oder das Machen einer Sperrnachfrage enthalten, die unverträglich bzw. inkompatibel mit einer bereits gewährten Sperrnachfrage ist. Wenn eine asynchrone Systemfalle durch die Gewährtung einer Sperrnachfrage aufgerufen wird, wird sie als Abschluß-AST bezeichnet. Wenn eine asynchrone Systemfalle durch das Durchführen einer Sperrnachfrage aufgerufen wird, die inkompatibel mit einer bereits gewährten Sperrnachfrage ist, wird sie als Sperr-AST bezeichnet. Ein Prozeß bzw. ein Vorgang, der eine AST (asynchronous system trap = asynchrone Systemfalle) mit seiner Sperrnachfrage spezifiziert, wird durch das Programm, das der spezifizierten AST zugeordnet ist, unterbrochen werden, wenn die Sperrnachfrage gewährt wird, und zwar in dem Fall einer Abschluß-AST, oder wenn ein anderer Prozeß eine Nachfrage für einen Sperrmodus macht, der inkompatibel mit dem Sperrmodus bzw. Verriegelungsmodus ist, der dem Prozeß gewährt worden ist, und zwar im Fall einer Sperr-AST.

Zusätzlich kann ein Sperrmanager eine Kommunikationseigenschaft haben, die einen Sperrwertblock, der mit den Sperrschlangen für den Quellennamen verbunden ist, aufweisen kann. Ein Sperrwertblock kann z. B. 16 Bytes an Informationen enthalten, die von einem Prozeß über das Einreihen in eine Warteschlange und über das Entnehmen aus einer Warteschlange von Sperrnachfragen eingegeben und/oder gelesen werden können. Die Informationen können Zwischen-Prozeßnachrichten bzw. Nachrichten, die zwischen Prozessen ausgetauscht werden, aufweisen.

Die vorliegende Erfindung liefert einen Ausfallmeldungsmechanismus durch Benennen gewisser logischer Quellen, die Prozessen zugeordnet sind, die die Teile eines verteilten Applikationsprogrammes bilden, und durch den Einsatz eines gewissen Satzes von geordneten kompatiblen und inkompatiblen Sperrnachfragen für diese Quellen, um die Prozesse über die Sperrnachfragewarteschlangen zu verbinden und umgekehrt zu verbinden bzw. in beiden Richtungen zu verbinden. Die vorliegende Erfindung spezifiziert abschließende und blockierende, asynchrone Systemfallen in den Sperrnachfragen, um die Ausgabe von umgekehrt verbindenden Sperrnachfragen zu verursachen und eine Ausfallmeldung beim Ausfall einer CPU zu erzeugen, die einen der Teile des Applikationsprogrammes abarbeitet bzw. ausführt.

Die logischen Quellen bzw. Systemelemente umfassen eine "SPECIAL" Quelle, eine "BROADCAST" Quelle, eine "PERMISSION TOTALK Quelle, und eine Quelle, die individuell für jeden der Teile des Applikationsprogrammes bezeichnet bzw. benannt ist. Die SPECIAL-Quelle ist der Prozeß, der ausgewählt ist, um eine Ausfallmeldung zu empfangen, wann immer einer der anderen Teile des Applikationsprogrammes ausfällt, und um eine Korrekturhandlung vorzunehmen. Die BRODCAST-Quelle benützt die Kommunikationseigenschaft des Sperrmanagers, um die SPEZIAL-Quelle zu unterrichten, wenn ein Teil des Applikationsprogrammes in das Netzwerk eingetreten ist oder das Netzwerk verläßt. Die PERMIS- SIONTOTALK-Quelle arbeitet in Verbindung mit der BROADCAST- Quelle, um eine Übertragung von Nachrichten zwischen den Prozessen sicherzustellen. Schließlich benennt jeder Prozeß, der einen Teil des Applikationsprogrammes ausführt, eine Quelle, die individuell den Teil identifiziert, z. B. kann der Quellenname auf dem Knotennamen basieren, wo der Prozeß innerhalb des Netzwerkes lokalisiert ist.

Der Ausfallmechanismus wird durch einen einzigen Unterprogrammaufrufbefehl aktiviert, der in jedem Teil eines Anwenderprogrammes von einem Programmentwickler eingefügt wird. Der Unterprogrammaufrufbefehl ruft ein SETUP-Programm auf. Das SETUP-Programm erzeugt alle Sperrnachfragen und verbundenen, asynchronen Systemfallenaufrufe, die notwendig sind, um den Ausfallmechanismus vorzubereiten bzw. zu rüsten. Der Einsatz des SETUP-Programmes, das resident im Netzwerk vorhanden ist und für alle Applikationsprogramme erhältlich ist, macht den Ausfallmechanismus für den Applikationsentwickler transparent bzw. durchschaubar. Das SETUP-Programm macht drei Sperraufrufe im Namen des Prozesses, der sie aufrief, und zwar wie folgend:

• 1. Eine Nachfrage nach einer Sperre bezüglich der BROAD- CAST-Quelle in einem CONCURRENT-READ-Sperrmodus (das SETUP- Programm wartet auf die Gewährung dieser Sperrnachfrage);
• 2. Eine Nachfrage nach einer Sperre bezüglich der Quelle, die nach dem bestimmten Teil des Applikationsprogrammes benannt worden ist und im weiteren als SERVERxxx-Quelle (wobei x individuell den Teil des Applikationsprogrammes identifiziert, der dem aufrufenden Prozeß entspricht) in einem PROTECTED-WRITE-Sperrmodus (das SETUP-Programm wartet auf Gewährung dieser Sperrnachfrage) bezeichnet wird; und
• 3. Eine Nachfrage nach einer Sperre bezüglich der SPECIAL- Quelle in einem EXCLUSIVE-Sperrmodus

Die Sperrnachfrage nach der SPECIAL-Quelle in EXCLUSIVE spezifiziert eine Abschluß-AST, die SPEZIALAST genannt wird. Da die Nachfrage nach einem EXCLUSIVE-Sperrmodus ist, wird nur einem der Prozesse des Applikationsprogrammes, der im allgemeinen der Erste ist, der die Nachfrage gemacht hat, die Sperrnachfrage gewährt werden. Die anderen Prozesse des Applikationsprogrammes haben ihre jeweiligen Sperrnachfragen in einer LOCK-REQUEST-FOR-SPECIAL-IN-EXCLUSIVE- MODE-WAITING-Schlange zu plazieren. Der Prozeß, dem die EXCLUSIVE-Modus-Nachfrage gewährt worden ist, wird dann von dem SPECIALAST-Abschlußprogramm unterbrochen, die diesen Prozeß dazu veranlaßt, die Verantwortung zum Empfangen und zum Handeln auf eine Ausfallmeldung hin (Prozeß, dem der EXCLUSIVE-Sperre gewährt wird, wird als Spezial-Bedieneinheit (special server) bezeichnet) anzunehmen.

Genauer gesehen benützt das SPECIALAST den Sperrmanager, um eine Liste von allen Prozessen in der LOCK-REQUEST-FOR- SPECIAL-IN-EXCLUSIVE-WAITING-Schlange zu erhalten. Die Liste, die von der LOCK-REQUEST-FOR-SPECIAL-IN-EXCLUSIVE-WAITING- Schlange abgeleitet wird, entspricht allen anderen Prozessen des Applikationsprogrammes. Somit liefert die Liste eine Vorwärtsverbindung (forward link) zwischen Prozessen, denen eine Verantwortlichkeit für das Empfangen einer Ausfallmeldung zugeordnet worden ist, und den anderen Prozessen des Applikationsprogrammes, und zwar über die LOCK-REQUEST- FOR-SPECIAL-IN-EXCLUSIVE-WAITING-Schlange.

Das SPECIALAST wird dann eine Sperrnachfrage in EXCLUSIVE für jede der SERVERxxx-Quellen ausgeben, entsprechend den Prozessen in der Warteschlangenliste. Da die Sperrnachfrage in EXCLUSIVE inkompatibel mit den PROTECTED-WRITE-Sperren, die den aufgelisteten Prozessen entsprechend den SERVERxxx- Quellen gewährt worden sind, wird jede der Sperrnachfragen, die von dem SPECIALAST im Namen der Spezial- Bedieneinheiten erzeugt worden sind, in jeweiligen LOCK- REQUEST-FOR-SERVERxxx-IN-EXCLUSIVE-WAITING-Schlangen plaziert, und zwar jeweils in einer für jeden Prozeß in der Liste. Die Sperrnachfrage in EXCLUSIVE für jeden SERVERxxx spezifiziert auch ein Abschluß-AST, das FAILAST genannt wird.

Somit erzeugen die exklusiven Sperrnachfragen, die im Namen der Spezial-Bedieneinheit von dem SPECIALAST gemacht worden sind, umgekehrte Verbindungen zwischen der Spezial-Bedieneinheit und allen anderen Teilen des Applikationsprogrammes über die Warteschlangen der SERVERxxx-Quellen.

Immer wenn eine bestimmte CPU ausfällt, wird die gewährte Sperre für den SERVERxxx des Prozesses, der auf dieser CPU läuft, aus der gewährten Schlange durch den Sperrmanager entfernt, und die EXCLUSIVE-Sperrnachfrage, die von der Spezial-Bedieneinheit erzeugt worden ist, wird dann gewährt. Dementsprechend unterbricht das FAILAST-Abschlußprogramm das Laufen bzw. die Ausführung des Prozesses bezüglich der Spezial-Bedieneinheit. Das FAILAST führt ein Programm aus, um festzustellen, welcher Prozeß ausgefallen ist, und zwar über den Einsatz des individuellen Namens der SERVERxxx-Quelle, für die die Spezial-Bedieneinheit die EXCLUSIVE-Sperre gewährt bekommen hat, und kann z. B. entweder eine Nachricht an eine spezifizierte Mailbox abgeben oder ein Programm aufrufen, das von dem Entwickler des Applikationsprogrammes ausgearbeitet worden ist, um automatisch einen Fehler bzw. einen Ausfall eines Teils des Programmes abzuhandeln.

Der Einsatz von Vorwärtsverbindungen und umgekehrten Verbindungen über die Sperrmanager-Schlangen mit den SPECIALAST und FAILAST-Abschlußprogrammen stellt einen automatischen Ausfallmeldungsmechanismus dar, der bequemerweise durch die Einfügung eines einzigen Unterprogrammaufrufbefehls in jedem der verschiedenen Teile des Applikationsprogrammes implementiert werden kann.

Weitere Vorteile, Anwendungsmöglichkeiten und vorteilhafte Weiterbildungen der vorliegenden Erfindung sind aus der nachfolgenden Beschreibung von Ausführungsformen der vorliegenden Erfindung in Verbindung mit den Zeichnungen und den weiteren Ansprüchen ersichtlich. Es zeigen:

Fig. 1 ein Blockdiagramm eines Computernetzwerkes;

Fig. 2 ein Blockdiagramm des Computernetzwerkes nach Fig. 1, das eine Illustration eines Programmes, das auf verschiedenen Komponenten des Computernetzwerkes läuft, umfaßt,

Fig. 3 ein Detail eines Auftragsdatensatzes (job record), der in der Datei (auf der Magnetplatte) (disc file) des Computernetzwerkes nach Fig. 2 gespeichert ist;

Fig. 4 ein Flußdiagramm eines SETUP-Programms gemäß der vorliegenden Erfindung;

Fig. 5 ein Flußdiagramm eines SPECIALAST-Programms gemäß der vorliegenden Erfindung;

Fig. 6 ein logisches Blockdiagramm von mehreren Teilen bzw. Abschnitten eines Applikationsprogrammes, die miteinander über Sperrmanager-Schlangen gemäß der vorliegenden Erfindung verbunden und umgekehrt verbunden sind;

Fig. 7 ein Flußdiagramm eines FAILAST-Programmes gemäß der vorliegenden Erfindung;

Fig. 8 Flußdiagramme für die CLUSTERBROADCAST und MSGAST-Programme gemäß der vorliegenden Erfindung, und zwar nebeneinander angeordnet.

In Fig. 1 ist ein Computernetzwerk dargestellt, das mehrere CPU's 10, 11, 12, 13, ein Benutzerinterface bzw. eine Benutzerschnittstelle 14 und eine Datenbankdatei (disc file database) 15 aufweist. Die CPU's 10, 11, 12 und 13, das Benutzerinterface 14 und die Datenbankdatei 15 sind alle zusammen miteinander durch einen gemeinsamen Bus 16 verbunden. Jede der CPU's 10, 11, 12 und 13 weist eine eingebaute Datenverarbeitungseinheit mit eigenem Hauptspeicher auf und kann mit den anderen Komponenten des Netzwerks über den gemeinsamen Bus 16 kommunizieren. Die Datenbankdatei 15 ist eine geteilte Quelle, die für alle CPU's 10, 11, 12, 13 und das Benutzerinterface 14 zugreifbar ist.

Nach den Fig. 2 und 3 enthält die Datenbankdatei 15 einen Auftragsdatensatz 16 für jedes Applikationsprogramm des Netzwerks. Wie in Fig. 3 angegeben wird, ist der Auftragsdatensatz 16 ein Datenfeld, das Informationen enthält, die das Programm identifizieren und die wichtige Attribute bzw. Eigenschaften des Programmes angeben, wie z. B. einen Programmlaufbefehl, eine Nachfrage für einen Programmlauf, ein CPU-Feld, um die CPU's 10, 11, 12, 13 zu identifizieren, wo das Programm laufen soll, eine Verteilliste, um festzustellen bzw. zu identifizieren, welche Teile des Programmes in seperaterweise auf den verschiedenen CPU's 10, 11, 12 und 13 laufen sollen, eine Handlung, die bei dem Ausfall irgendeiner der CPU's stattfinden soll, einen Datenausgangsdateiort, einen Mailboxort (soge. Briefkasten), um Nachrichten und irgendwelche anderen Informationen, die erforderlich sind, um das Programm auf dem Netzwerk auszuführen, zu empfangen. Um ein Programm laufen zu lassen, verwendet ein Netzwerkoperator das Benutzerinterface 14, um auf den Auftragsdatensatz 16 für das Programm in der Datenbankdatei 15 zuzugreifen, und fügt eine Nachfrage, um das Programm auszuführen, in das Feld für die Nachfrage für den Programmlauf des Auftragsdatensatzes 16 ein. Der Netzwerkoperator befiehlt dann einer Programmausführeinheit 17 z. B. der CPU 10, sich den Auftragsdatensatz 16 des Applikationsprogrammes anzuschauen.

Die Programmausführeinheit 17 liest die Daten in dem Auftragsdatensatz 16, der die Nachfrage für die Ausführung des Programmes enthält, welche von dem Netzwerkoperator eingefügt worden ist, und implementiert die Ausführung des Applikationsprogrammes in Übereinstimmung mit den Informationen, die in dem Auftragsdatensatz 16 enthalten sind. Z. B. kann das Programm ein Stapeldatenverarbeitungsprogramm aufweisen, das in seinem Verteilungsfeld spezifiziert, daß drei unterschiedliche Teile 18, 19, 20 des Applikationsprogramms gleichzeitig laufen sollen, und zwar jeweils ein Teil auf jeweils einer der CPU's 11, 12, 13.

Gemäß einem Merkmal der vorliegenden Erfindung ist der verteilte Sperrmanager 21 und eine Objektbibliothek 22 auf jeder CPU 10, 11, 12 und 13 lokalisiert. Die Objektbibliothek 22 enthält eine Serie von Unterprogrammen, die von jedem Teil 18, 19 und 20 des Applikationsprogrammes aufgerufen werden können. Die Unterprogramme arbeiten durch den Einsatz des Sperrmanagers 21, um eine Meldungsverantwortlichkeit einem der Teile 18, 19 und 20 (im weiteren als Spezial- Bedieneinheit bezeichnet) zuzuordnen, und bilden Verbindungen und umgekehrte Verbindungen zwischen der Spezial- Bedieneinheit und den anderen Teilen 18, 19 und 20 des Applikationsprogrammes.

Der verteilte Sperrmanager 21 kann einen VMS-verteilten Sperrmanager aufweisen, der einem Prozeß erlaubt, eine Quelle zu benennen und eine spezifizierte "Sperre" bezüglich des Quellennamens nachzufragen. Die Quelle kann irgendeine logische oder physikalische Quelle des Computernetzwerkes sein und die Sperre gibt ein Schreib- und Lesezugriffsprivileg an die Quelle. Ein spezifischer Typ der Sperre wird als Sperrmodus bezeichnet. Die verschiedenen Sperrmodi, die auf dem VMS-verteilten Sperrmanager erhältlich sind, sind die folgenden:

Die Lockmodi geben eine Möglichkeit den Zugriff auf eine Quelle unter vielen Prozessen, die innerhalb eines Computernetzwerkes laufen, zu koordinieren. Z. B. sorgt der EXCLUSIVE-Sperrmodus dafür, daß ein Prozeß der Besitzer einer benannten Quelle ist, da kein anderer Prozeß von der Quelle lassen bzw. in die Quelle schreiben kann, während der besitzende Prozeß in dem EXCLUSIVE-Sperrmodus ist. Andererseits ist ein PROTECTED-WRITE-Sperrmodus weniger einschränkend, da, während nur ein einziger Prozeß auf die benannte Quelle schreiben kann, es anderen Prozessen freigestellt ist, von der benannten Quelle zu lesen. Die anderen Sperrmodi sind weniger restriktiv bzw. einschränkend, und umfassen unterschiedliche Grade von gleichzeitigen bzw. parallelen und exclusiven Lese- und Schreibzugriffsprivilegien auf eine benannte Quelle.

Der Sperrmanager 21 setzt das Sperrschema nicht aktiv in Kraft, sodaß es wichtig, daß jeder Prozeß eine geeignete Sperrnachfrage macht, bevor er beabsichtigt, auf eine Quelle zuzugreifen, und zwar für einen richtigen Betrieb des Sperrschemas. Das Inkraftsetzen des Sperrschemas wird durch Inkrafttreten einer Vereinbarung implementiert, wobei z. B. immer ein Prozeß eine geeignete Sperrnachfrage für eine benannte Quelle vornimmt und dem Prozeß erlaubt wird, nur fortzufahren, wenn die Sperrnachfrage gewährt wird.

Wenn z. B. ein Prozeß von einer Datenbank, die eine benannte Quelle ist, lesen will, fragt der Prozeß nach einer CONCURRENT- READ-Sperre für die Datenbank nach. Wenn diese Datenbank bereits durch einen gewährten EXCLUSIVE-Sperrmodus besetzt ist, ist die Gewährung der Nachfrage für den CONCURRENT- READ nicht kompatibel mit dem bereits gewährten EXCLUSIVE- Sperrmodus für die Quelle. Damit wird der Sperrmanager 21 die Nachfrage nach dem CONCURRENT-READ nicht gewähren.

Die nachfolgende Tabelle gibt die Kompatibilität zwischen den verschiedenen Sperrmodi des Sperrmanagers 21 an:

Sperrmodus-Kompatibilität

Der Sperrmanager 21 arbeitet mit den Prozessen, die auf den verschiedenen CPU's des Computernetzwerkes laufen, über gewissen Systemdienste zusammen, die für die Prozesse erhältlich sind, und zwar die folgenden:

Sperrmanager-Dienste

Der Sperrmanager 21 hält eine Sperrdatenbank aufrecht, die eine Vielzahl von Schlangen aufweist, die Sperrnachfrageinformationen enthalten. Jede benannte Quelle hat eine Serie von Schlangen für jeden Sperrmodus, die für jeden Sperrmodus umfassen: eine Warteschlange, die unerledigte Nachfragen durch Prozesse auflistet, die nicht gewährt worden sind, weil der nachgefragte Sperrmodus inkompatibel mit einer anderen, bereits gewährten Sperrnachfrage ist, und eine Umwandlungsschlange, die Sperrnachfragen auflistet, die für einen Modus gewährt worden sind und auf die Umwandlung in einen anderen Sperrmodus warten.

Der Sperrmanager 21 arbeitet jede Sperrnachfrage mit Bezug auf die Sperrdatenbank ab, um die Kompatibilität mit bereits gewährten Nachfragen zu überprüfen, und fährt dann damit fort, entweder die Sperrnachfrage zu gewähren oder die Nachfrage in einer Warteschlange zu plazieren. Wenn ein Prozeß einen gewährten Sperrmodus freigibt, durchsucht der Sperrmanager 21 die Warteschlange nach diesem Sperrmodus und gewährt dann den Sperrmodus auf der Basis, daß der zuerst kommende auch zuerst bedient wird, der nächsten Sperrnachfrage in der Warteschlange.

Der Sperrmanager 21 behält ebenfalls einen Sperrstatusblock für jede Sperre für einen Quellennamen bei, um anzuzeigen, in welcher Schlange die Sperrnachfragen für diese Sperre plaziert worden sind. Ein Sperreventilblock (lock valve block) ist mit jedem Sperrstatusblock verbunden. Der Sperrventilblock kann z. B. 16 Byte an Informationen aufweisen, die entweder gelesen oder durch die Prozesse geschrieben werden können, denen die Sperrnachfrage für diese Sperre gewährt worden ist. Der Sperrventilblock ist für einen nächsten Prozeß erhältlich, wenn diesem Prozeß die Sperrnachfrage für den Sperrmodus der benannten Quelle gewährt worden ist. Somit kann der Sperrventilblock als Kommunikationseigenschaft bzw. Möglichkeit benützt werden, um 16 Byte-Nachrichten zwischen Prozessen zu übertragen.

Desweiteren kann jede Sperrnachfrage ein Abschluß-AST oder eine Blockier-AST spezifizieren, um einen Quellenzugriff unter den Prozessen, die auf dem Computernetzwerk laufen, zu synchronisieren. Wie oben erläutert, unterbricht ein Abschluß- AST einen Prozeß, wenn eine Sperrnachfrage, die von dem Prozeß durchgeführt wurde, gewährt wird. Eine Blockier- AST unterbricht den Prozeß, wenn ein anderer Prozeß eine Sperrnachfrage durchführt, die inkompatibel mit der Sperrnachfrage ist, die bereits einem anderen Prozeß gewährt worden ist.

In Übereinstimmung mit einem Merkmal der vorliegenden Erfindung enthält die Objektbibliothek 22, die in jeder der CPU's 11, 12, 13 vorhanden ist, einen Satz von verbundenen Unterprogrammen, die direkt oder indirekt von den jeweiligen zusammenwirkenden Teilen 18, 19, 20 des Applikationsprogrammes, die jeweils auf den CPU's 11, 12, bzw. 13 laufen, aufgerufen werden. Die Unterprogramme sind SETUP, CLUSTERBROADCAST, MSGAST, SPECIALAST, FAILAST, LISTSERVER, SHOWSERVER und UPDATEINFO. Die Unterprogramme benützen den Sperrmanager 21, um die zusammenwirkenden Applikationsteile 18, 19, 20 zu verbinden bzw. umgekehrt zu verbinden, indem logische Quellen, die sich auf die Applikationsteile 18, 19 und 20 beziehen, benannt werden und indem eine Serie von kompatiblen und inkompatiblen Sperrnachfragen bezüglich der benannten Quelle durchgeführt werden, um die Teile 18, 19 und 20 über die Sperrschlangen, die von dem Sperrmanager 21 aufrecht erhalten werden, zu verbinden. Wie erläutert, umfassen die Quellen SPECIAL, BROADCAST, PERMISSIONTOTALK und eine SERVER xVERSION- Quelle, entsprechend jedem Teil 18, 19, 20 des Applikationsprogrammes.

Der Entwickler des Applikationsprogrammes kann den Ausfallmechanismus der vorliegenden Erfindung benützen, in-dem er einen einzigen Unterprogrammaufrufbefehl in jedem Teil 18, 19 und 20 des Applikationsprogrammes einfügt, um das SETUP- Programm der Objektbibliothek 22 in der CPU 11, 12, 13 aufzurufen, wo der Teil gerade läuft. Der Unterprogrammaufrufbefehl spezifiziert das SETUP-Programm und erzeugt ein Argument, um individuell das Applikationsprogramm zu identifizieren, zu dem der Teil gehört, der das Unterprogramm gerade aufruft. Der Unterprogrammaufrufbefehl kann ebenfalls ein Argument erzeugen, das einen existierenden Mailbox-Kanal in dem Netzwerk zum Empfangen von Nachrichten des Ausfallmechanismusses identifiziert. Eine Null-Anzeige des Mailbox-Kanals veranlaßt das SETUP-Programm, den Mailbox- Kanal für das Applikationsprogramm zu öffnen. Alternativerweise kann das Argument eine asynchrone Systemfalle spezifizieren, die von dem Programmentwickler geschrieben worden ist, das Applikationsprogramm unterbrechen soll und bei einer Ausfallmeldung laufen soll. Die asynchrone Systemfalle kann Korrekturhandlungen spezifizieren.

All die Unterprogramme, die auf einer bestimmten CPU 11, 12, 13 des Netzwerkes laufen bzw. installiert sind, wirken zusammen, um einen gemeinsamen Speicherraum bzw. Speicherbereich in dem Hauptspeicher der jeweiligen CPU 11, 12, 13 zu bilden, um Informationen bezüglich des Ausfallmechanismuses zu speichern, der für das bestimmte Applikationsprogramm vorgesehen ist. Der gemeinsame Speicherraum wird automatisch von dem SETUP-Programm vorbereitet bzw. gerüstet und ist für alle Programme in der Objektbibliothek 22 zugreifbar. Alle Namen der Quellen für ein spezifisches Applikationsprogramm enthalten ein Präfix bzw. eine Vorsilbe, die dem spezifischen Applikationsprogramm zugeordnet ist, d. h., daß das Präfix beim Aufruf als Argument zu dem SETUP- Programm befördert wird. Der gemeinsame Speicherraum speichert Informationen, die sich auf die Teile 18, 19 und 20 beziehen, welche auf der bestimmten CPU 11, 12, 13 laufen. Die Informationen zeigen an, daß der Teil 18, 19 und 20 SETUP aufgerufen hat und im Ausfallmechanismus ist und desweiteren, ob der Teil eine Spezial-Bedieneinheit ist.

In Fig. 4 ist ein Flußdiagramm des SETUP-Programmes dargestellt. Der SETUP-Aufrufbefehl 100 ist, wie angegeben, in jedem Teil 18, 19, 20 des Applikationsprogrammes vorhanden, sodaß das Programm getrennt für jeden Teil 18, 19 und 20 ablaufen kann. Das SETUP-Programm fängt an, indem es eine Nachfrage für die BROADCAST-Quelle in einem CONCURRENT-READ-Sperrmodus 101 im Namen des Teiles macht, der das SETUP-Programm gerufen hat, indem der $ENQW-Dienst des Sperrmanagers 21 eingesetzt wird. Das SETUP-Programm wartet dann darauf, daß der Sperrmodus gewährt wird 102. Der $ENQW-Dienst wartet automatisch auf die Gewährung der Sperre. Die Schleife, die in dem Flußdiagramm dargestellt ist, ist für Erläuterungszwecke vorhanden, um anzugeben, daß das Programm solange nicht fortfährt, bis die Sperre gewährt wird. Die Sperre wird gewährt werden, da alle SETUP-Programme CONCURRENT- READ nachfragen, die kompatibel miteinander sind. Die Nachfrage nach der BROADCAST-Quelle spezifiziert auch das MSGAST-Programm, das ein Blockier-AST ist, wie genauer weiter unten beschrieben wird.

Nach dem Gewähren der Nachfrage nach der BROADCAST-Quelle, führt das SETUP-Programm dann eine Nachfrage 103 nach einer Quelle durch, die es in der Nachfrage benennt, z. B. nach dem Knoten (d. h. der CPU 11, 12, 13, wo jeweils die Teile 18, 19, 20 laufen), z. B. SERVERCPU 11 in einem PROTECTED- WRITE-Sperrmodus. Das VMS-System, das in der wiedergegebenen Ausführungsform gemäß der vorliegenden Erfindung verwendet wird, stellt einen Dienst zur Verfügung, der $GETSYI heißt, der von irgendeinem Prozeß aufgerufen werden kann, um den Knoten in dem Netzwerk zu identifizieren, wo der Prozeß gerade läuft. Alternativerweise kann die SERVERxxx-Quelle direkt nach dem Teil 18, 19, 20 benannt werden, der das SE- TUP-Programm aufgerufen hat. All dies ist erforderlich, da der Quellenname individuell bzw. einzigartig für den spezifischen Teil 18, 19, 20 des Applikationsprogrammes sein soll. Das SETUP-Programm benützt den $ENQW-Dienst des Sperrmanagers 21 wiederum. Das SETUP-Programm wartet dann 104 darauf, daß die Nachfrage nach dem SERVERxxx gewährt wird. Diese Nachfrage wird ebenfalls gewährt, da jeder SE- TUP-Programm einen PROTECTED-WRITE-Sperrmodus bezüglich einer spezifischen Quelle nachfragt, die nach seinem entsprechenden Knoten benannt worden ist, welcher unterschiedlich zu den Quellennamen ist, für die eine Sperre durch die anderen SETUP-Programme nachgefragt worden ist.

Das SETUP-Programm macht dann eine Nachfrage über den $ENQ- Dienst nach der SPECIAL-Quelle in einem EXCLUSIVE-Sperrmodus 105. Die Nachfrage nach der SPECIAL-Quelle spezifiziert die SPECIALAST, die eine Abschluß-AST ist. Da alle SETUP- Programme eine Nachfrage in EXCLUSIVE machen, kann nur einem einzigen der SETUP-Programme, für gewöhnlich demjenigen, das zeitlich zuerst die Nachfrage gemacht hat, der EXCLUSIVE-Sperrmodus gewährt werden. Die anderen Nachfragen, die von den anderen SETUP-Programmen, welche auf dem Netzwerk laufen, gemacht worden sind, sind jeweils inkompatibel mit dem gewährten EXCLUSIVE-Sperrmodus. Diese Nachfragen werden dann in einer REQUEST-FOR-SPECIAL-IN-EXCLUSIVE- WAITING-Schlange durch den verteilten Sperrmanager 21 plaziert. Wie angegeben, wird derjenige Teil 18, 19, 20, dem der EXCLUSIVE-Sperrmodus gewährt worden ist, als Spezial- Bedieneinheit bezeichnet und das SETUP-Programm für diesen Teil 18, 19, 20 setzt ein Bit in den jeweiligen gemeinsamen Speicherraum ab, um den Spezial-Bedieneinheit- Status anzuzeigen.

Nach Durchführen der Nachfrage nach der SPECIAL-Quelle in einem EXCLUSIVE-Sperrmodus, überprüft das SETUP-Programm den gemeinsamen Speicher, um zu sehen, ob der entsprechende Teil 18, 19, 20 die Spezial-Bedieneinheit 106 ist. Wenn der entsprechende Teil 18, 19, 20 die Spezial-Bedieneinheit ist, gibt das SETUP-Programm die Steuerung an den Teil 18, 19, 20 zurück 107. Wenn der entsprechende Teil 18, 19, 20 nicht die Spezial-Bedieneinheit ist, fährt das SETUP-Programm fort, das CLUSTERBRODCAST-Programm 108 aufzurufen, das genauer weiter unten zusammen mit dem verwandten MSGAST-Blockierprogramm und der BROADCAST-Quelle erläutert wird.

Da jedes SETUP-Programm das SPECIALAST-Abschlußprogramm in der Nachfrage nach der SPECIAL-Quelle spezifiziert, wird derjenige Teil 18, 19, 20 dem die SPECIAL-Quelle in einem EXCLUSIVE-Sperrmodus über das aufgerufene SETUP-Programm gewährt worden ist, durch das SPECIALAST-Programm unterbrochen.

In Fig. 5 ist ein Flußdiagramm des SPECIALAST-Abschlußprogrammes dargestellt. Das SPECIALAST-Programm verwendet anfänglich den $GETLKIW-Dienst 201 des Sperrmanagers 21, um eine Liste aller Prozesse zu erhalten, die gegenwärtig in der REQUEST-FOR-SPECIAL-IN-EXCLUSIVE-WAITING- Schlange sind. Das SPECIALAST macht dann eine Nachfrage 202 nach einem EXCLUSIVE-Sperrmodus über den $ENQW-Dienst des Sperrmanagers 21 für jede der SERVERxxx-Quellen, die den Prozessen in der Liste, die von dem $GETLKIW-Dienst erhalten worden sind, zugeordnet sind. Das SPECIALAST kann entweder auf den Auftragsdatensatz 16 zugreifen oder den $GETSYI-Dienst einsetzen, um den Teil 18, 19, 20 mit dem Knotennamen zu korrelieren, wo der Teil gerade läuft. Somit kann das SPECIALAST die SERVERxxx-Namen der Quellen, für die es die Nachfragen nach einer EXCLUSIVE-Sperre macht, formulieren.

Jede Nachfrage nach dem SERVERxxx spezifiziert das FAILAST-Blockierprogramm. Wie zu sehen ist, wird jede Nachfrage nach den SERVERxxx-Quellen, die von der SPECIALAST durchgeführt wird, inkompatibel mit dem PROTECTED- WRITE-Sperrmodus sein, der bereits jedem Prozeß auf der Liste (siehe 103, 104 Fig. 4) gewährt worden ist. Somit wird jede Nachfrage, die von dem SPECIALAST im Namen des SPECIAL SERVERS gemacht wird, in einer jeweiligen REQUEST-FORSERVERxxxEXCLUSIVE- WAITING-Schlange von dem Sperrmanager 21 plaziert. Nachdem alle Nachfragen 202 ausgeführt worden sind, gibt das SPECIALAST die Steuerung dem Teil 18, 19, 20 zurück, der die Spezial-Bedieneinheit gemacht hat 203.

In Fig. 6 ist ein logisches Blockdiagramm der Teile 18, 19, 20 des Applikationsprogrammes gezeigt, wenn es verbunden und umgekehrt verbunden durch das Laufen der SETUP- und SPECIALAST-Programme ist. Wie obenstehend hingewiesen, speichert jedes der verschiedenen SETUP-Programme, die von den Teilen 18, 19, 20 aufgerufen werden, Informationen bezüglich der entsprechenden Teile 18, 19, 20 in einen gemeinsamen Speicherraum in der jeweiligen CPU 11, 12, 13 ab. Das SPECIALAST-Programm für den Teil 18, 19, 20, dem der EXCLUSIVE-Sperrmodus für SPECIAL-Quelle gewährt worden ist, setzt ein Bit in das Feld des gemeinsamen Speicherraums, der den Informationen bezüglich der entsprechenden Teile 18, 19, 20 zugeordnet ist, um den Spezial-Server-Status anzuzeigen.

Angenommen, daß dem Teil 18 der EXCLUSIVE-Sperrmodus für die SPECIAL-Quelle gewährt worden ist, dann ist die entsprechende Sperrnachfrage, die vom Teil 18 über das SETUP- Programm in der Objektbibliothek 22 ausgeführt worden ist, die resident in der CPU 11 vorhanden ist, auf welcher der Teil 18 gerade läuft, in der gewährten Schlange 51 für den EXCLUSIVE-Sperrmodus der SPECIAL-Quelle vorhanden, welche von dem verteilten Sperrmanager 21 aufrecht erhalten wird. Die Schlangenliste 51 und das SPECIAL SERVER Status Bit verbinden 50 den Teil 18 mit dem Sperrmanager 21.

Eine Vorwärtsverbindung zwischen dem special server und den anderen Teilen 19, 20, denen der EXCLUSIVE-Sperrmodus auf SPECIAL nicht gewährt worden ist, wird durch die REQUEST- FOR-SPECIAL-IN-EXCLUSIVE-WAITING-Schlange 53 bewerkstelligt, auf die durch die Spezial-Bedieneinheit über den $GETLKI-Dienst des Sperrmanagers 21 (siehe Fig. 5) zugegriffen werden kann 54.

Eine umgekehrte Verbindung 55 zwischen der Spezial-Bedieneinheit und jedem anderen Teil 19, 20 des Applikationsprogrammes wird von den REQUEST-SERVERxxx-EXCLUSIVE-WAITING- Schlangen 56 bewerkstelligt, die von dem Sperrmanager 21 auf das Ausführen der EXCLUSIVE-Nachfragen im Namen der Spezial-Bedieneinheit (Teil 18) durch das SPECIALAST 202 (Fig. 5) hin, gesetzt worden sind. Natürlich hat jede SERVERxxx- Quelle eine entsprechende Gewährungsschlange 57 für den PROTECTED-WRITE-Modus, die die Nachfragen enthält, die von den SETUP-Programmen im Namen der entsprechenden Teile 18, 19, 20 gemacht worden sind. Die Gewährungsschlangen 57 vervollständigen die umgekehrte Verbindung 55 über die Verbindung 58 zwischen jedem Teil 19, 20 und der entsprechenden Gewährungsschlange 57.

Die gestrichelte Linie für einen vierten Teil des Applikationsprogrammes gibt einen zusätzlichen Teil wieder, der in das Netzwerk nach dem Ausführen des SPECIALAST eintritt. Das Aufstellen der umgekehrten Verbindung zwischen der Spezial- Bedieneinheit und dem neuen Teil wird weiter unten in Verbindung mit der BROADCAST-Quelle erläutert.

Die LISTSERVER, UPDATEINFO und SHOWSERVER-Programme in der Objektbibliothek 22 sind alle vorgesehen als Dienste für jeden Applikationsentwickler, so daß ein Applikationsentwickler jedes der Programme aufrufen kann, um die Dienste des Sperrmanagers 21 mit Bezug auf die Quellen, die von dem Ausfallmechanismus benannt worden sind, zu benützen.

Z. B. kann jedes Teil 18, 19, 20 das UPDATEINFO-Programm aufrufen, um Informationen bezüglich des Teils wie z. B. Software ID, Nummer der Version, Schritt, der gegenwärtig ausgeführt wird, usw. in den Sperrwertblock (lock value block) einzuschreiben, der mit der Sperre für die zugeordnete SERVERxxx-Quelle verbunden ist. Das UPDATEINFO-Programm erlaubt einem Applikationsentwickler, die Sperrwertblockmöglichkeit des VMS-Sperrmanagers 21 zu benützen.

Das SHOWSERVER-Programm ermöglicht jedem Prozeß, der auf dem Netzwerk läuft, den Sperrwertblock des SERVERxxx jedes Teils 18, 19, 20 zu erhalten und zu lesen, um die Informationen in dem Sperrwertblock zu erhalten. Desweiteren ermöglicht das LISTSERVER-Programm jedem Prozeß, der auf dem Netzwerk läuft, die Nachfragen in den Sperrmanagerschlangen aufzulisten, um dadurch Informationen bezüglich der Teile des spezifischen Applikationsprogrammes und bezüglich dem Ort, wo sie laufen, zu erhalten.

Eine Möglichkeit bzw. eine Eigenschaft bzw. ein Merkmal des VMS-verteilten-Sperrmanagers enthält eine Überwachungsfunktion des Betriebs der Komponenten innerhalb des Netzwerks. Wenn eine z. B. der CPU's 11, 12, 13 ausfällt, macht der verteilte Sperrmanager 21 die Sperrnachfragen ungültig, die von den Prozessen der ausgefallenen CPU gemacht worden sind, und bildet die Schlangen dementsprechend neu.

Somit wird die gewährte Schlange für den SERVERxxx des Teils 19, 20, das auf der ausgefallenen CPU läuft, entleert und der Sperrmanager 21 sucht nach und gewährt die Wartenachfrage für EXCLUSIVE bezüglich des SERVERSxxx, der von der SPECIALAST im Namen der Spezial-Bedieneinheit gemacht wurde. Das FAILAST-Abschlußprogramm, das von der EXCLUSIVE- Nachfrage (siehe Fig. 5) spezifiziert worden ist, wird dann die Ausführung des Teils 18 unterbrechen und ablaufen.

Fig. 7 stellt ein Flußdiagramm des FAILAST-Abschlußprogrammes dar. Das FAILAST ruft zuerst die wild card bzw. den Joker $GETLKIW 300 auf, um Informationen bezüglich der spezifischen EXCLUSIVE-Nachfrage zu erhalten, die der Spezial- Bedieneinheit gewährt worden ist. Die wild card $GETLKIW gibt die Informationen bezüglich aller Sperrnachfragen eines Prozesses und gibt deshalb die Informationen bezüglich aller SERVERxxx-Quellen-Schlangen zu dem Teil zurück, der die Spezial-Bedieneinheit ist. Derjenige, bei dem die Spezial-Bedieneinheit der Halter des EXCLUSIVE- Lockmoduses ist, entspricht dem Teil 19, 20, das auf der CPU 12, 13 läuft, die ausgefallen ist. Der Name der Quelle ermöglicht dem FAILAST, den Teil 19, 20 zu identifizieren, der wegen einer Fehlfunktion der CPU ausgefallen ist bzw. fehlerhaft ist. Z. B. kann das FAILAST in der hier beschriebenen Ausführungsform den Auftragsdatensatz 16 für das Applikationsprogramm durchsuchen und den Knotennamen, der verwendet wird, um den SERVERxxx zu benennen, mit dem Teil 18, 19, 20, der auf dem Knoten läuft zu korrelieren.

Das Programm FAILAST meldet dann 301 der Spezial-Bedieneinheit entweder durch Schreiben einer Fehlernachricht, die den ausgefallenen Teil identifiziert, in die Mailbox, die in dem Unterprogrammaufrufbefehlsargument spezifiziert worden ist, welches in dem Programmteil eingefügt worden ist, oder ruft eine asynchrone Systemfalle auf, die von dem Applikationsentwickler spezifiziert worden ist. Ganz gleich wie, die Informationen bezüglich des Ausfallens bzw. des Fehlers des Programmteils des Applikationsprogrammes werden automatisch dem Applikationsprogramm auf solche Art und Weise zugeführt, daß ein Korrekturvorgang bzw. eine Korrekturhandlung ausgeführt werden kann. Z. B. kann die asynchrone Systemfalle, die in dem Aufruf für das SETUP-Programm spezifiziert worden ist, das Auftragsdatensatzfeld 16 lesen, das die bei einer Ausfallinformation vorzunehmende Handlung enthält.

In Fig. 8 sind Seite an Seite Flußdiagramme für die CLU- STERBROADCAST und MSTAST-Programme der Objektbibliothek 22 dargestellt. Die CLUSTERBROADCAST und MSGAST-Programme laufen in Verbindung mit dem Sperrungsschema für die BROAD- CASTQuelle und die PERMISSIONTOTALK-Quelle ab, um eine Kommunikationsmöglichkeit zwischen den Teilen 18, 19, 20 des Applikationsprogrammes zu ermöglichen. Wie in Fig. 1 angegeben, ruft das SETUP-Programm das CLUSTERBROADCAST- Programm 106 unmittelbar nach Ausführung einer Nachfrage nach einer EXCLUSIVE-Sperre auf SPECIAL 105 auf, wenn der zugeordnete Teil bzw. Programmteil 18, 19, 20 nicht die Spezial-Einheit ist.

In dem Fall, daß ein Teil, der nicht die Spezial-Einheit ist (siehe z. B. die gestrichelte Linie in Fig. 6) zu laufen beginnt, nachdem das SPECIALAST-Programm beendet worden ist, würde die Spezial-Bedieneinheit nicht eine Nachfrage für die SERVERxxx-Quelle, zugeordnet dem neuen Teil, enthalten. Und zwar deshalb, weil das SETUP-Programm, das von dem neuen Teil aufgerufen worden ist, eine Nachfrage nach der SPECIAL-Quelle in EXCLUSIVE nicht machen würde, bis das SPECIALAST-Programm abgelaufen ist, und somit würde die Nachfrage, die von dem neuen Teil gemacht worden ist, nicht in der REQUEST-FOR-SPECIAL-IN-EXCLUSIVE-WAITING- Schlange sein.

Das CLUSTERBROADCAST-Programm wird verwendet, um zwei Typen von Nachrichten zu senden. Einer der Typen ist eine vordefinierte Nachricht, welche das MSGAST-Programm erkennt und auf die das MSGAST-Programm bestimmte Aktionen bzw. Handlungen in Antwort auf die Nachricht durchführt. Beispiele für vordefinierte Nachrichten sind eine Nachricht, die von dem SETUP-Programm bei dem Eintritt eines neuen Programmteils in das Netzwerk abgegeben wird, und eine Nachricht, die von dem SPECIALAST-Programm gesendet wird, wenn ein neuer Programmteil die Spezial-Bedieneinheit wird. Der andere Typ von Nachricht kann direkt dem Applikationsprogramm zugeführt werden, z. B. zu der Mailbox, die in dem Unterprogrammaufrufargument spezifiziert ist. Das CLU- STERBROADCAST-Programm macht anfänglich eine Nachfrage für die PERMISSIONTOTALK-Quelle in dem EXCLUSIVE-Sperrmodus 400. Das CLUSTERBROADCAST-Programm wartet 401, bis die Nachfrage gewährt worden ist, und schaut dann, um zu sehen, ob es bereits eine Sperre bezüglich der BROADCAST-Quelle 402 hat. Das kann durch Nachsuchen in dem gemeinsamen Speicher, der von dem SETUP-Programm eingerichtet worden ist, ausgeführt werden, um zu sehen, ob der Prozeß, der vorher das CLUSTER-BROADCAST-Programm aufgerufen hat, das SETUP- Programm gerufen hat.

Wenn der Teil der das CLUSTERBROADCAST-Programm aufgerufen hat, eine Sperre bezüglich der BROADCAST-Quelle hat, d. h. die CONCURRENT-READ-Sperre, die von dem SETUP-Programm erhalten wird, dann fährt das CALLBROADCAST-Programm fort eine Umwandlung des CONCURRENT-READ-Sperrmodus in den EXCLUSIVE-Sperrmodus für das BROADCAST 403 nachzufragen.

Wenn der Teil, der das CLUSTERBROADCAST aufgerufen hat, eine Sperre für das BROADCAST nicht hat, führt das CLU- STERBROADCAST-Programm eine neue Nachfrage nach der BROADCAST- Quelle in den EXCLUSIVE-Sperrmodus 404 aus. Diese Eigenschaft des CLUSTERBROADCAST-Programmes führt dazu, daß die Kommunikationseigenschaft für jeden Prozeß, der auf dem Netzwerk läuft, erhältlich ist, ganz gleich, ob er ein Teil des Applikationsprogrammes ist oder nicht. Somit kann jeder Prozeß eine Nachricht an das Applikationsprogramm schicken, auch wenn er nicht ein Teil des Applikationsprogramms ist.

Sobald entweder eine Nachfrage nach der Umwandlung oder eine neue Nachfrage nach der BROADCAST-Quelle gemacht worden ist, unterbricht das MSGAST-Blockierprogramm, das von jedem Teil 18, 19, 20 des Applikationsprogrammes (siehe 101, Fig. 5) spezifiziert worden ist, den jeweiligen Teil 18, 19, 20 und führt 500 aus. Das Blockierprogramm läuft zu diesem Zeitpunkt, da die EXCLUSIVE-Nachfrage, die von dem neuen Teil gemacht worden ist, inkompatibel mit dem CONCURRENT- READ-Sperrmodus ist, der vorhergehend jedem Teil (siehe 102, Fig. 5) gewährt worden ist. Das MSGAST-Programm macht anfänglich eine Nachfrage, um die CONCURRENT- READ-Sperre auf der BROADCAST-Quelle in den NULL-Modus umzuwandeln, der kompatibel mit dem EXCLUSIVE-Sperrmodus ist, der von dem neuen Teil nachgesucht wird.

Nachdem die Nachfrage für die Umwandlung gemacht worden ist, verwendet das MSGAST-Programm den $GETLKI-Dienst 502 des Sperrmanagers 21, um Informationen bezüglich der gewährten EXCLUSIVE-Sperrschlange des BROADCAST-Programms zu erhalten, um zu sehen, ob dem neuen Teil der EXCLUSIVE- Sperrmodus 503 gewährt worden ist. Wenn der Lock-Sperrmodus nicht gewährt worden ist, kehrt die Routine in einer Schleife 504 zurück, z. B. alle 100 ms zu 502, bis der EXCLUSIVE- Sperrmodus gewährt worden ist. Sobald der EXCLUSIVE- Sperrmodus gewährt worden ist, macht das MSGAST-Programm eine Nachfrage, um den NULL-Modus für BROADCAST zurück in den CONCURRENT-READ-Modus 505 zu wandlen.

Inzwischen wartet 405 das CLUSTERBROADCAST darauf, daß der EXCLUSIVE-Sperrmodus gewährt wird. Sobald dieser gewährt wird, schreibt das CLUSTERBROADCAST-Programm eine Nachricht 407 in den Sperrwertblock, der der BROADCAST-Sperre zugeordnet ist. Wenn der Prozeß, der als CLUSTERBROADCAST- Programm bezeichnet wird, ein neuer Teil ist, wird die Nachricht der Spezial-Bedieneinheit zugeführt und identifiziert den neuen Teil des Applikationsprogrammes.

Nach dem Abschließen bzw. Beendigen des Nachrichtenschreibens schaut das CLUSTERBROADCAST-Programm nach, um zu sehen, ob der aufrufende Prozeß eine Sperre BROADCAST vor dem Aufrufen des CLUSTERBROADCAST-Programmes 408 hat, d. h., ob der Prozeß ein Teil des Applikationsprogrammes ist und eine Nachfrage bezüglich einer BROADCAST-CONCURRENT-READ-Sperre über das SETUP-Programm gemacht hat oder ob er ein nicht zugeordneter Prozeß ist, der eine Nachricht an das Applikationsprogramm sendet. Wenn der Prozeß anfänglich keine Sperre auf das BROADCAST gehabt hat, entnimmt das CLUSTERBROADCAST- Programm die EXCLUSIVE-Nachfrage 409. Wenn der Prozeß eine CONCURRENT-READ-Sperre gehabt hat, macht das CLUSTERBROADCAST-Programm eine Anfrage, um den Sperrmodus von EXCLUSIVE to CONCURRENT READ 410 zurückzuverwandeln.

Das MSGAST-Programm, das eine Nachfrage gemacht hat, um den Sperrmodus von NULL in CONCURRENT READ 505 umzuwandeln, wartet dann auf die Umwandlung 506, die nach der CLUSTERBROADCAST- Nachfrage gewährt wird, um EXCLUSIVE 409, 410 zu entnehmen oder umzuwandeln, bis diese gewährt wird bei 507. Das MSGAST-Programm erhält dann und liest dann in 508 den Sperrwertblock.

Eine Vereinbarung kann in dem Sperrwertblock eingesetzt werden, um eine Nachricht zu addressieren. Z. B. kann ein Adressenfeld, das in dem Sperrwertblock vorhanden ist, einen Knotennamen angeben, um eine Nachricht für einen bestimmten Teil des Applikationsprogrammes zu spezifizieren. Dann kann ein Sternchen (asterisk) in dem Adressenfeld angeben, daß die Nachricht all den Teilen 18, 19, 20 zugeführt wird, und ein Leerzeichen (blank) in dem Adressenfeld kann anzeigen, daß die Nachricht für die Spezial-Bedieneinheit ist. Wenn die Nachricht 509 nicht für den Teil 18, 19, 20 ist, der durch das MSTAST-Programm unterbrochen worden ist, gibt das MSGAST-Programm die Steuerung an den entsprechenden Teil 18, 19, 20 zurück.

Wenn die Nachricht für die Spezial-Bedieneinheit ist, d. h. ein Leerzeichen im Adressenfeld des Sperrwertblocks vorhanden ist, schaut das MSGAST-Programm auf das Spezial-Bedieneinheit- Status-Bit in dem gemeinsamen Speicher, und wenn es sieht, daß es gesetzt ist, fährt es damit fort 510, die Nachricht zu lesen. Die Nachricht wird die vordefinierte Nachricht sein, die von dem SETUP-Programm gesendet worden ist, was anzeigt, daß ein neuer Programmteil in das Netzwerk eingetreten ist. Das MSGAST-Programm antwortet auf die vordefinierte Nachricht, indem es eine Nachfrage nach einem EXCLUSIVE-Sperrmodus für die SERVERxxx-Quelle entsprechend dem neuen Teil 511 macht. Bevor die Nachfrage gemacht wird, kann das MSGAST-Programm jedoch den $GETLKI- Dienst des Sperrmanagers 21 benützen, um zu verifizieren, ob eine EXCLUSIVE-Sperrmodus-Nachfrage bezüglich des SERVERxxx bereits von der Spezial-Bedieneinheit gemacht worden ist. Das wird auftreten, wenn der neue Teil tatsächlich das Netzwerk kurz nach der Spezial-Bedieneinheit betreten hat, z. B. mit den Teilen 19, 20, und die entsprechende Nachfrage nach SPECIAL-IN-EXCLUSIVE in der REQUEST-FOR-SPECIAL- IN-EXCLUSIVE-WAITING-Schlange war, während das SPECIALAST- Programm gelaufen ist. Nach dem Verifizieren und Ausführen der Nachfrage nach EXCLUSIVE bezüglich der SERVERxxx- Quelle entsprechend dem neuen Teil gibt das MSGAST-Programm die Steuerung an die Spezial-Bedieneinheit (Teil 18) 512 zurück.

Inzwischen schließt das CLUSTERBROADCAST-Programm ab, indem es $GETLKI für den BROADCAST NULL-Modus 411 aufruft. Das CLUSTER-BROADCAST-Programm überprüft dann, um zu sehen, ob irgendeiner der anderen Prozesse noch in dem NULL-Modus 412 ist, d. h., daß die Nachfrage zum Umwandeln noch nicht gewährt worden ist (505, 506) 413. Wenn eine der Nachfragen noch nicht gewährt worden ist, kehrt das CLUSTERBROADCAST- Programm in einer Schleife 414 zurück zu dem $GETLKI-Befehl 411, z. B. alle 100ms, bis es keinen Teil mehr gibt, der noch auf eine Umwandlung vom NULL-Modus in den CONCURRENT- READ-Modus wartet. Zu diesem Zeitpunkt 415 entnimmt das CLUSTERBROADCAST-Programm den PERMISSIONTOTALK-EXCLUSIVE- Sperrmodus 416 und gibt die Steuerung an den neuen Teil 417 zurück.

Somit stellt das CLUSTERBROADCAST-Programm sicher, und zwar über die EXCLUSIVE-Sperre bezüglich der PERMISSION TOTALK-Quelle 400 und durch die Warteschleife 414, 504, daß die Nachricht, die in den Sperrwertblock eingeschrieben worden ist, von dem zuständigen Teil des Applikationsprogrammes empfangen wird, z. B. der Spezial-Bedieneinheit. Die PERMISSIONTOTALK-Quelle bestellt Nachrichten, da nur ein einziger Prozeß zu einem Zeitpunkt eine Nachricht wegen dem EXCLUSIVE-Sperrerfordernis für die PERMISSION TOTALK-Quelle senden kann. Alle anderen Prozesse, die eine Nachricht zur gleichen Zeit senden wollen, werden in einer Warteschlange für die EXCLUSIVE-Sperre bezüglich der PERMISSIONTOTALK-Quelle plaziert. Die Nachfragen werden nacheinander gewährt, und zwar immer eine zu einem Zeitpunkt, und so, daß die zuerstgekommene auch zuerst bedient wird, bis jede Nachricht gesendet worden ist.

Desweiteren kann das CLUSTERBROADCAST-Programm verwendet werden, um die Spezial-Bedieneinheit zu unterrichten, wenn ein Teil das Netzwerk vor dem Rest der Teile des Applikationsprogrammes verlassen will. Um ein Verlassen des Übertragungsnetzwerkes durchzuführen, müßte der Applikationsprogrammentwickler einen CLUSTERBROADCAST-Aufrufbefehl in den Teil, der das Netzwerk verlassen will, einfügen, um eine Nachricht der Spezial-Bedieneinheit zuzusenden, um z. B. die EXCLUSIVE-Nachfrage für den SERVERxxx entsprechend dem abgehenden Teil zu entnehmen.

Das CLUSTERBROADCAST-Programm kann auch von dem SPECIAL AST-Programm eingesetzt werden, um eine Nachricht anderen Teilen 19, 20 des Applikationsprogrammes einzuschreiben, um anzuzeigen, daß es die Spezial-Bedieneinheit ist. Das ist eine andere vordefinierte Nachricht, die ein Sternchen (asterisk) (Nachricht für alle Teile) verwendet, das jedes MSGAST-Programm veranlaßt, die Identifizierung der Spezial-Bedieneinheit in die jeweiligen gemeinsamen Speicherräume einzuschreiben.

Im Falle, daß die CPU, auf der die Spezial-Bedieneinheit (Teil 18 in unserem Beispiel) läuft, ausfallen sollte, entfernt der Sperrmanager 21 die EXCLUSIVE-Sperre bezüglich SPECIAL, die von der Spezial-Bedieneinheit gehalten wird, und gewährt die EXCLUSIVE-Sperre dem ersten Teil 19, 20 in der REQUEST-FOR-SPECIAL-IN-EXCLUSIVE-WAITING-Schlange. Das SPECIAL-AST-Abschlußprogramm unterbricht dann den Teil 19, 20, dem die EXCLUSIVE-Sperre gewährt worden ist, und läuft ab, wie es obenstehend beschrieben worden ist, um die umgekehrten Verbindungen zwischen der neuen Spezial-Bedieneinheit und den verbleibenden Teilen des Applikationsprogrammes zu bilden. Das SPECIALAST-Programm kann auch das CLUSTER BROADCAST-Programm aufrufen, um eine Nachricht jedem der verbleibenden Teile zuzusenden, um anzuzeigen, daß es nun die Spezial-Bedieneinheit für die Aktualisierung des jeweiligen gemeinsamen Speicherraumes ist. Zusätzlich kann SPECIALAST in dem gemeinsamen Speicherraum für den zugeordneten Teil, der jetzt die Spezial-Einheit ist, nachschauen, um zu sehen, ob er Informationen bezüglich einer vorhergehenden Spezial-Bedieneinheit hat, d. h. eine Nachricht von einer vorhergehenden Spezial-Bedieneinheit, wie oben erläutert. Wenn der gemeinsame Speicherraum für die neue Spezial-Bedieneinheit hat, zeigt dies der SPECIALAST an, daß es eine vorhergehende Spezial-Bedieneinheit gegeben hat und zeigt somit auch einen Fehler an. Das SPECIALAST würde dann ein Programm aufrufen, das die Ausfallinformationen auswertet, wie es von dem FAILAST gemacht wird.

Ein Applikationsprogrammentwickler kann auch einen bestimmten Teil 18, 19, 20 spezifizieren, daß er die Spezial-Bedieneinheit ist, und zwar durch den Einsatz einer anderen vordefinierten Nachricht. Der Applikationsprogrammentwickler kann die vordefinierte Nachricht jedem Teil 18, 19, 20 des Applikationsprogrammes zusenden, indem er CLUSTER BROADCAST aufruft. Die vordefinierte Nachricht spezifiziert, welcher Teil die Spezial-Bedieneinheit sein soll, und die MSGASTs agieren, die spezifizierte Spezial-Bedieneinheit zu implementieren, wie folgt.

Wenn der Teil 18, 19, 20, der auf der CPU 11, 12, 13 läuft, wo das MSGAST untergebracht ist, entweder die Spezial-Bedieneinheit oder die Spezial-Bedieneinheit nicht ist, aber die Spezial-Bedieneinheit sein sollte, geben die MSGASTs einfach die Steuerung an den Teil zurück.

Wenn der Teil die Spezial-Bedieneinheit ist und nicht die Spezial-Bedieneinheit sein soll, entnimmt die MSGAST die EXCLUSIVE-Sperre bezüglich der SPECIAL-Quelle und entnimmt alle Sperren für die SERVERxxx-Quellen. Das MSGAST wird dann noch einmal eine Sperre in EXCLUSIVE bezüglich der SPECIAL-Quelle nachfragen und dann aussteigen.

Wenn der Teil nicht die Spezial-Bedieneinheit ist und auch nicht der Teil ist, der von dem Applikationsprogrammentwickler vorgesehen ist, die Spezial-Bedieneinheit zu sein, wird die MSGAST die Nachfrage für SPECIAL-IN-EXCLUSIVE entnehmen und dann erneut eine Nachfrage für SPECIAL-IN- EXCLUSIVE in die Warteschlange einreihen, bevor die Steuerung an diesen Teil zurückgegeben wird.

Die Freigabe der Sperrnachfrage nach SPECIAL durch jeden der Teile 18, 19, 20, die nicht der Spezial-Bedieneinheit entsprechen, überläßt es dem einen Teil , der von dem Applikationsentwickler bestimmt worden ist, entweder bereits die EXCLUSIVE-Sperre für die SPECIAL-Quelle zu halten oder alleine in der Warteschlange mit keiner Nachfrage in der gewährten Schlange zu sein. Im Fall des letzteren wird der Sperrmanager 21 die EXCLUSIVE-Sperre für den Teil 18, 19, 20, der vom Applikationsentwickler bestimmt worden ist, dann gewähren. Das Ausführen einer Nachfrage bezüglich SPECIAL- IN-EXCLUSIVE bei den anderen Teilen 18, 19, 20, nachdem alle Sperrnachfragen für SPECIAL freigegeben worden sind, findet statt, nachdem der Teil 18, 19, 20 der vom Applikationsentwickler bestimmt worden ist, die EXCLUSIVE- Sperre für SPECIAL erhalten hat. Somit werden die anderen Teile in der REQUEST-FOR-SPECIAL-IN-EXCLUSIVE-WAITING- Schlange plaziert.

Claims (2)

1. Verfahren zum Erzeugen einer Ausfallmeldung in einem Computernetzwerk, das eine Vielzahl von Knoten hat, wobei eine vorgegebene Anzahl von Knoten jeweils einen Teil eines Anwendungsprogramms verarbeitet und das Verfahren die folgenden Schritte aufweist:
Ausführen einer ersten Nachfrage nach einem exklusiven Zugriffsprivileg auf einen vorausgewählten Betriebsmittel- oder Quellennamen, und zwar für jeden Teil des Anwendungsprogramms;
Ausführen einer zweiten Nachfrage nach einem vorausgewählten Zugriffsprivileg auf einen entsprechenden Betriebsmittelnamen, der einen Namen hat, welcher auf dem Teil basiert, und zwar für jeden Teil des Anwendungsprogramms;
Gewähren der ersten Nachfrage nach einem exklusiven Zugriffsprivileg für nur einen einzigen Teil des Anwendungsprogramms;
Gewähren der zweiten Nachfrage für jeden Teil des Anwendungsprogramms;
Ausführen einer dritten Nachfrage im Namen des einen einzigen Teils des Anwendungsprogramms für jeden Betriebsmittelnamen, der einen Namen hat, welcher auf dem entsprechenden Teil des Anwendungsprogramms basiert, und zwar auf einem anderen als dem einen einzigen Teil, wobei die dritte Nachfrage nach einem Zugriffsprivileg ist, das inkompatibel mit der zweiten Nachfrage ist;
Betreiben des Computernetzwerks um:

• (i) die Informationen bezüglich jeder dritten Nachfrage für jeden Betriebsmittelnamen, der einen Namen hat, welcher auf einen entsprechenden Teil des Anwendungsprogramms beruht, und zwar einem anderen als dem einen einzigen Teil, zu speichern und
• (ii) bei einem Fehler eines der Knoten aus der vorgegebenen Anzahl, der einen Teil des Anwendungsprogramms verarbeitet, automatisch die zweite Nachfrage eines Teils ungültig zu machen, der auf dem einen der vorgegebenen Anzahl von Knoten verarbeitet wird, und um automatisch die dritte Nachfrage zu gewähren, die im Namen des einen einzigen Teils des Anwendungsprogramms für den Betriebsmittelnamen, der einen Namen hat, der auf dem Teil beruht, der auf dem einen der vorgegebenen Anzahl von Knoten läuft, gemacht worden ist;

wobei die Gewährung der dritten Nachfrage nach dem Betriebsmittelnamen, der einen Namen hat, welcher auf dem Teil basiert, der auf dem einen der vorgegebenen Anzahl von Knoten verarbeitet wird, dazu verwendet wird, um zu verursachen, daß eine Nachricht erzeugt wird, die den Teil, der auf dem einen der vorgegebenen Anzahl von Knoten verarbeitet wird, identifiziert.