DE3855029T2 - Supervisorverfahren für ein Rechnerbetriebssystem - Google Patents

Description

• Diese Erfindung bezieht sich auf ein System und ein Verfahren für die verteilte Überwachung (einschließlich der selektiven Modifikation) eines auf Unterbrechungen ansprechenden Betriebssystems eines programmierbaren digitalen Computers.
• Betriebssysteme bestehen typischerweise aus ausgefeilten Computerprogrammen, welche Anweisungssätze aufweisen, die allgemein im generischen Sinne als Routinen bezeichnet werden, und zwar zum Behandeln der überwiegenden tatsächlichen Steuerung der Hardware eines Computers. Viele Betriebssystemroutinen sind so geschrieben, daß sie von anderen Programmen aufgerufen werden können. Mit anderen Worten und allgemein gesprochen veranlaßt eine geeignete Anweisung innerhalb eines solchen aufrufenden Programms, daß eine Betriebssystemroutine ausgeführt wird, und zwar mit der Wirkung, als ob die Betriebssystemroutine ein integraler Bestandteil des aufrufenden Programms selbst wäre.
• Die Verwendung solcher Routinen kann die Komplexität und die Zeit, die erforderlich ist, um andere Programme zu schreiben, reduzieren. Zum Beispiel kann ein Programmentwickler, der Daten von einer Speichervorrichtung lesen möchte, einen Aufruf auf eine bestehende Betriebssystemroutine für diesen Zweck verwenden, wodurch die Notwendigkeit, eine solche Routine erneut zu schreiben, vermieden wird.
• In der Vergangenheit sind verschiedene Verfahren und Einrichtungen für die Behandlung von Unterbrechungen in Computersystemen vorgeschlagen worden. Zum Beispiel ist eine Unterbrechungs-"Haken"-Technik in einem Dokument mit dem Titel "PC fixed disk usage during emulation" in IBM Technical Disclosure Bulletin, Bd. 28, Nr. 12, Mai 1986, Seiten 5326-5328 offenbart. Aufrufe an eine normale Unterbrechungsbehandler-(IH)-Routine werden durch Überschreiben des normalen IH-Adreßeintrags mit der Adresse einer Substitut-IH-Routine abgefangen.
• In einem anderen Dokument mit dem Titel "Intel's 386 unites UNIX and DOS software", von C. Purkiser in Mini-Micro Systems, Bd. XX, Nr. 4, April 1987, Seiten 113-114, 117-120, 123, 124 ist ein Unterbrechungsbehandler diskutiert, wobei V86-Unterbrechungen identifiziert werden und dann entweder zu DOS zurückrefiektiert werden oder an die geeigneten Routinen umgeleitet werden. Somit dient der V86-Unterbrechungsbehandler als ein "Verkehrspolizist" für alle Unterbrechungen des 386-Systems.
• Ein "Virtual interrupt mechanism" ist im IBM Technical Disclosure Bulletin, Bd. 29, Nr. 5, Oktober 1986, Seiten 1891-1895 offenbart. Der ausgeführte Mechanismus gewährleistet die Fähigkeit, eine Abbildung willkürlicher (Software- und Hardware)-Unterbrechungen in Aktionsroutinen für jede einzelne Programmumgebung festzulegen.
• Eine Unterbrechung kann breit als ein Ereignis definiert werden, was den Computer veranlaßt, seine gegenwärtige Operation aufzuhören und unter anderem eine oder mehrere vorbestimmte Unterbrechungsbehandlungs-(IH)- Routinen auszuführen, die in einem adressierbaren Speicher, wie z.B. einem Speicher (RAM) mit wahlweisem Zugriff oder einem virtuellen Speicher, gespeichert sind. Viele Computer sprechen auf Hardware-Unterbrechungen an, während einige andere Computer (entweder alternativ oder zusätzlich) Software-Unterbrechungen vorsehen können.
• Eine typische Verwendung von Unterbrechungen ist es, Betriebssystemdienste durch Aufruf spezifischer Betriebssystemroutinen anzufordern. Zum Beispiel könnte ein Anwenderprogramm eine Unterbrechung verwenden, um den Computer zu veranlassen, eine Routine auszuführen, die dazu führt, daß eine bestimmte Speichervorrichtung für das Anwenderprogramm verfügbar gemacht wird.
• Aus Flexibilitätsgründen wird ein Teil der Verarbeitung von Unterbrechungen allgemein unter Verwendung der Herangehensweise einer indirekten Adressierung behandelt. Der Computer wird allgemein programmiert (manchmal in Software, manchmal in Microcode), um eine Tabelle oder einen anderen Block formatierter Information nach Adressen für IH-Routinen als Teil seiner Antwort auf das Auftreten eines Unterbrechungsereignisses abzufragen. Jede solche Adresse wird allgemein als ein "Vektor" und die Tabelle von Vekto ren als eine "Vektortabelle" bezeichnet.
• Jeder Eintrag in einer solchen IH-Vektortabelle liefert die Adresse (d.h. die bestimmte Stelle im adressierbaren Speicher) einer IH-Routine für einen bestimmten Unterbrechungstyp. Mit anderen Worten dienen die verschiedenen IH-Vektortabelleneinträge als Zeiger zu den IH-Routinen, die beim Auftreten verschiedener Unterbrechungstypen ausgeführt werden sollen.
• Es ist das Ziel der vorliegenden Erfindung, ein verbessertes Verfahren zur verteilten Überwachung der Ausführung einer normalen Unterbrechungsbehandlungsroutine bereitzustellen, welche von einem aufrufenden Programm innerhalb einer Computersystem-Betriebsumgebung aufgerufen wurde, welches Verfahren durch die Schritte von Anspruch 1 gekennzeichnet ist.
• Die vorliegende Erfindung erlaubt die koordinierte Überwachung der Ausführung indirekt adressierter Unterbrechungsbehandlungsroutinen in einem Betriebssystem, und zwar durch eine willkürliche Anzahl von Überwacherprogrammen. Der Ausdruck "Transportmechanismus" wird aus Zweckmäßigkeit verwendet, um sich allgemein auf ein System und ein Verfahren gemäß der Erfindung zu beziehen, und wird darüber hinaus verwendet, um eine Verwirrung mit der weit verbreiteten Verwendung des Ausdrucks "System" zu vermeiden, um das Computersystem anstelle irgendeines bestimmten Programms zu bezeichnen, das auf dem Computersystem arbeitet.
• Kurz gesagt fängt der Transportmechanismus jeden Aufruf an einen überwachten Unterbrechungsbehandler ab, erzeugt ein Speichermodell der dann existierenden Umgebung, und übergibt die Steuerung im Ablauf an die Überwacherprogramme. Der Ausdruck "Umgebung" wird hier verwendet, um sich gemeinsam auf die verschiedenen Register und anderen Stellen (z.B. bestimmte Blöcke im RAM-Speicher) zu beziehen, die vom Betriebssystem des Computers beim Ausführen der Programme verwendet werden.
• Jedes Überwacherprogramm kann das Speichermodell sowohl untersuchen als es auch modifizieren. Wie man sehen wird, wird, wenn diese Fähigkeit von einem Überwacherprogramm ausgeübt wird, die Ausführung der aufgerufenen Unterbrechung schließlich auf eine für das aufrufende Programm transparente Weise geändert.
• Ein Überwacherprogramm kann eine Transportmechanismus-Serviceroutine aufrufen, was seinerseits zum Aufruf der normalen IH-Routine führt, nun jedoch im Kontext der vom Speichermodell (welches von einem Überwacherprogramm geändert worden sein kann) spezifizierten Umgebung. Einer solchen Ausführung folgt die Rückgabe der Steuerung an das Überwacherprogramm. Tatsächlich erlaubt dies jedem Programm, welches den Überwacher aufruft, die Umgebung zu untersuchen, deren Existenz sowohl vor als auch nach der Ausführung der normalen IH-Routine erwartet werden würde, und zwar durch Untersuchen von "Vor-" und "Nach-" Umgebungen dieser Routine, wie sie vom Transportmechanismus eingeleitet wurde.
• Der Transportmechanismus implementiert in der tatsächlichen Umgebung jegliche Abänderungen, die vom Überwacherprogramm bzw. von den Überwacherprogrammen angeordnet wurden: nachdem alle aufgerufenen Überwacherprogramme ihre Ausführung abgeschlossen haben und die Steuerung an den Transportmechanismus zurückgegeben haben, bringt der Transportmechanismus die tatsächliche Umgebung auf jene in Übereinstimmung, die vom Speichermodell angezeigt ist. Wenn kein Überwacherprogramm die Ausführung der aufgerufenen Unterbrechung aufgerufen hat, macht dies der Transportmechanismus.
• Der Transportmechanismus gibt dann die Steuerung an das Programm zurück, welches das Unterbrechungsereignis ursprünglich eingeleitet hat, so als ob das Unterbrechungsereignis normal ohne den Eingriff des Transportmechanismus ausgeführt worden wäre. Der Zustand der Umgebung nach der Ausführung kann sich jedoch signifikant von dem geändert haben, was ursprünglich erwartet worden wäre, und zwar durch die Interaktion der Überwacherprogramme mit dem Transportmechanismus. Der Transportmechanismus gewährleistet somit eine verteilte Überwachung auf eine Weise, die für das Anwenderprogramm transparent ist.
• Die neuen Merkmale der Erfindung zusammen mit weiteren Zielen und Vorteilen werden von der folgenden Beschreibung besser verstanden, wenn sie in Verbindung mit den begleitenden Zeichnungen betrachtet werden.
• In den Zeichnungen zeigen:
• Fig. 1 eine vereinfachte Blockdiagrammdarstellung eines Programmsteuerflusses für einen nicht überwachten Unterbrechungstyp.
• Fig. 2 eine logische Flußdiagrammdarstellung des Aufrufes eines Anwenderprogramms auf den Substitut-Unterbrechungsbehandler in Verbindung mit der Einleitung eines überwachten Unterbrechungsereignisses.
• Fig. 3 bis 8 Flußdiagramm-Blockdiagramme von Komponentenroutinen innerhalb des Substitut-Unterbrechungsbehandlers.
• Fig. 9 ein Flußdiagramm-Blockdiagramm einer Routine zum Installieren der Überwacherprogramme in einer Warteschlange zum Aufrufen durch die Melderoutine.
• In der folgenden detaillierten Beschreibung bezeichnen ähnliche Bezugszeichen ähnliche Elemente in allen Figuren der Zeichnung.
• Die folgende detaillierte Beschreibung bezieht sich auf die gemeinsame logische Struktur der Implementierung des Transportmechanismus auf einem willkürlichen Computersystem, allgemein gezeigt in Fig. 2. Der Fachmann wird erkennen, daß die Details der spezifischen bevorzugten Implementierungstechniken beträchtlich abhängig vom Computertyp und vom Betriebs system unter anderen Faktoren variieren werden.
• Wie gezeigt in Fig. 9 veranlaßt eine Überwacherprogramm-Installationsroutine, die von einem Überwacherprogramm nach seinem anfänglichen Betrieb aufrufbar ist, daß Überwacherprogramm-Statusinformation vom Transportmechanismus in einen formatierten Block eines adressierbaren Speichers, wie z.B. eines RAM, geschrieben wird. Dieser Informationsblock betrifft die aktiven Überwacherprogramme, die in der Betriebsumgebung des Computers vorhanden sind und dazu gedacht sind, an der verteilten Überwachung des Transportmechanismus teilzunehmen.
• Eine solche Information enthält vorzugsweise Information betreffend, welche spezifischen Unterbrechungsereignistypen von einem gegebenen Überwacherprogramm zu verarbeiten wären und welche Typen dadurch ignoriert würden.
• Wie in Fig. 3 gezeigt veranlaßt eine Substitut-IH-Installationsroutine, daß die Adresse einer Substitut-IH-Routine über den Eintrag in der IH-Adreßtabelle für jeden zu überwachenden Unterbrechungstyp geschrieben wird. Demzufolge führt jeder Programmaufruf an eine überwachte Unterbrechung dazu, daß die Substitut-IH-Routine anstelle der normalen IH-Routine des Betriebssystems ausgeführt wird. Der Transportmechanismus kopiert die Adresse der normalen IH-Routine zur zukünftigen Verwendung bei der tatsächlichen Ausführung einer überwachten Unterbrechung.
• Die Programmierung der Substitut-IH-Routine muß natürlich die Umgebungsstatusverarbeitung berücksichtigen, die für den abzufangenden Unterbrechungstyp erforderlich sein wird. Abhängig vom Vorzug des Programmierers kann die Unterbrechungsvektortabelle mit der Adresse einer einzelnen "Shell"- Substitut-IH-Routine überschrieben werden, die je nach Notwendigkeit zu anderen Unterroutinen verzweigt, oder mit der Adresse einer Substitut-IH- Routine überschrieben werden, die nach Bedarf für den bestimmten Unterbrechungstyp ausgewählt ist.
• Eine Substitut-IH wird vorzugsweise nur installiert, wenn die Überwacherprogramm-Statusinformation anzeigt, daß die fragliche Unterbrechung von einem oder mehreren aktiven Überwacherprogrammen verarbeitet werden würde. Somit würde bei einem Unterbrechungstyp, der von allen Überwacherprogrammen ignoriert werden würde, dessen normaler IH-Vektor nicht überschrieben werden; seine normale IH-Routine würde folglich bei einem Aufruf ausgeführt werden, anstelle vom Transportmechanismus blockiert zu werden. Dies hilft, die Änderungen, die vom Transportmechanismus an der Betriebsumgebung des Computers vorgenommen werden, zu minimieren.
• Wie aus Fig. 4 ersichtlich wird, immer wenn die Substitut-IH-Routine aufgerufen wird (als Folge der Einleitung eines überwachten Unterbrechungsereignisses, z.B. von einem Anwenderprogramm), seinerseits eine Umgebungsmodellier-Routine aufgerufen. Die Umgebungsmodellier-Routine schreibt Umgebungsstatusinformation in das Speichermodell in einem vorbestimmten Format aus (und in ein Sicherungsmodell, soweit verwendet), und zwar zur zukünftigen Bezugnahme durch die Überwacherprogramme und durch den Transportmechanismus selbst.
• Die Umgebungsstatusinformation, die von der Umgebungsmodellier- Routine ausgeschrieben wurde, enthält ein Flag, welches anzeigt, ob die normale IH- Routine des Betriebssystems tatsächlich ausgeführt worden ist oder nicht, wie unten diskutiert. Aus Zweckmäßigkeit kann dieses Flag eine Speicherzelle an einem willkürlichen, spezifischen Offset innerhalb des Speichermodells sein. Dieses Flag wird natürlich anfänglich ausgeschaltet sein, weil die normale IH-Routine nicht ausgeführt worden sein wird.
• Wie in Fig. 5 veranschaulicht wird beim Fortfahren mit der Antwort des Transportmechanismus auf eine überwachte Unterbrechungseinleitung nach der Umgebungsmodellier-Routine eine Melderoutine aufgerufen. Die Melderoutine ruft nacheinander eines oder mehrere der Überwacherprogramme in einer Liste aktiver Überwacherprogramme auf, wobei jedem aufgerufenen Überwacherprogramm als ein Argument die Adresse des formatierten Umgebungsstatus-Informationsblocks übergeben wird.
• In vielen Implementierungen wird es wünschenswert sein, daß bei der Rückgabe der Steuerung an die Melderoutine jedes Überwacherprogramm jegliche ausstehende Betriebssystem-Fehlercodes als Argumente oder einfach die Tatsache, daß ein solcher Fehler ausstehend ist, übergibt. Es wird für die Melderoutine ebenso wünschenswert sein, ein Flag zu unterhalten, welches anzeigt, ob eine solche Rückgabe durchgeführt wurde. Eine solche Rückgabe zeigt an, daß die Fehlerbehandlungseinrichtungen des Überwacherprogramms darin gescheitert sind, mit einem Fehler umzugehen. Wie unten diskutiert kann die Absicherungsausführung-Routine des Transportmechanismus so entworfen werden, um diese Möglichkeit zu berücksichtigen.
• Wie in den Fig. 6A und 6B gezeigt, kann ein Überwacherprogramm einen Entscheidungszweig aufweisen, der nach der Untersuchung der Umgebung ruft, deren Existenz nach der Ausführung der aufgerufenen Unterbrechung erwartet werden würde. Insoweit ist eine Unterbrechungsausführung-Dienstroutine für den möglichen Aufruf durch ein Überwacherprogramm vorgesehen, um den Effekt der aufgerufenen Unterbrechung zu duplizieren.
• Wie in Fig. 7 veranschaulicht, führt die Unterbrechungsausführung-Routine zu den folgenden Ergebnissen in der angegebenen Reihenfolge: (a) die Konformität der Umgebung des Computers mit dem Zustand, der durch das Speichermodell dargestellt wird, welches vom Überwacherprogramm geändert worden sein kann; (b) der Aufruf der normalen IH-Routine des Betriebssystems; (c) die Aktualisierung des Speichermodells, um die Umgebung nach der Ausführung wiederzuspiegeln; (d) das Setzen des vorgenannten Flags im Speichermodell, um anzuzeigen, daß die Unterbrechung ausgeführt worden ist; und (e) die Rückgabe der Steuerung an das aufrufende Überwacherprogramm.
• Es wäre natürlich möglich, andere Transportmechanismus-Dienstroutinen bereitzustellen, durch die ein Überwacherprogramm jegliche gewünschte Manipulation des Speichermodelis durchführen könnte, so daß eine solche Manipulation nicht direkt vom Überwacherprogramm gemacht zu werden bräuchte. Ob ein solches Merkmal in einer bestimmten Implementierung wünschenswert wäre, hinge von Faktoren, wie z.B. der Komplexität der Parameter, die in Verbindung mit den überwachten Unterbrechungen manipuliert werden müssen, dem Ausmaß, in dem eine aufzurufende Manipulation des Speichermodells zu erwarten ist und dem Bedarf nach einem Steuerzugriff auf das Speichermodell zu Integritätszwecken, ab.
• Es wird dem Fachmann mit Hilfe dieser Offenbarung erkenntlich, daß die Programmierung eines Überwacherprogramms Anweisungen zum Untersuchen oder Manipulieren der Umgebungsstatusinformation im Speichermodell sowohl vor der Ausführung als auch nach der Ausführung enthalten kann, da die Steuerung an ein aufrufendes Überwacherprogramm nach Aufruf der normalen IH-Routine durch den Transportmechanismus zurückgegeben wird.
• Jedoch kann bis zu dem Zeitpunkt, zu dem einem bestimmten Überwacherprogramm die Steuerung durch den Transportmechanismus gegeben wird, die normale IH-Routine bereits ausgeführt worden sein. Gegen eine solche Möglichkeit (angezeigt durch das Flag "Unterbrechung ausgeführt" im Speichermodell) kann das Überwacherprogramm entworfen werden, um das Sicherungsmodell (oder die Betriebssystem-Steuerblöcke, wenn das Sicherungsmodell nicht implementiert ist) nach Information über den Umgebungsstatus vor der Ausführung zu übertragen.
• In einer verwandten Art kann ein bestimmtes Überwacherprogramm so entworfen sein, um einen Zugriff auf eine Umgebung nach der Ausführung zu erfordern, bei dem die Umgebung vor der Ausführung seit der Zeit der Unterbrechungseinleitung durch das Anwenderprogramm unverändert war.
• Gegen eine solche Möglichkeit ist es wünschenswert, die Liste oder Warteschlange von Überwacherprogrammen, die von der Melderoutine aufgerufen werden, in Prioritätsklassen zu organisieren, wobei "passive" Überwacherprogramme zuerst aufgerufen werden. Ein Überwacherprogramm, welches einen Blick auf ein unverändertes Umgebungsmodell vor der Ausführung erfordert, könnte sich somit in der frühesten Prioritätsklasse in der Warteschlange einreihen.
• In alternativer Weise kann ein Überwacherprogramm so entworfen sein, um eine Sicherungskopie des Speichermodelis zu machen; das Speichermodell auf den unveränderten Zustand vor der Ausführung unter Verwendung der Information vom Sicherungsmodell (oder den Betriebssystem-Steuerblöcken) wiederherzustellen; die Unterbrechungsausführung-Routine aufzurufen; jegliche zusätzliche gewünschte Verarbeitung auszuführen; und das Speichermodell auf den Zustand wiederherzustellen, in welchem es das Überwacherprogramm vorfand, bevor die Steuerung an die Melderoutine zurückgegeben wird. Jedoch würde dies wahrscheinlich beträchtlich mehr Programmierung für ein Überwacherprogramm als die oben beschriebene Herangehensweise des früh in die Warteschlange Einreihens erfordern und würde ferner das Risiko einer Speichermodell-Verfälschung erhöhen.
• Wie in Fig. 8 gezeigt prüff, nachdem alle Überwacherprogramme von der Melderoutine des Transportmechanismus abgefragt worden sind, die Versicherungsausführung-Routine des Transportmechanismus das Speichermodell- Flag, um zu bestimmen, ob der Aufruf der normalen IH-Routine von irgendeinem Überwacherprogramm angeordnet wurde. Wenn dem nicht so ist, ruft die Versicherungsausführung-Routine die Unterbrechungsausführung- Routine auf die oben beschriebene Weise auf.
• Als ein Sicherheitsmerkmal kann die Versicherungsausführung so program miert sein, um das Flag zu prüfen, welches anzeigt, ob irgendein Überwacherprogramm einen Fehlercode zurückgegeben hat, wie oben diskutiert. Eine Weise der Behandlung eines solchen Ereignisses wäre es, die Sicherungsmodell-Information (oder andere Steuerblockzustände) zu verwenden, um das Speichermodell auf seinen Zustand vor dern Aufruf der Melderoutine wiederherzustellen, anstelle die Unterbrechungsausführung-Routine aufzurufen. Tatsächlich würde dies alle von den Überwacherprogrammen vorgenommenen Aktionen auffieben und die Ausführung der normalen IH-Routine verursachen, als ob die überwachte Unterbrechung nie abgefangen worden wäre.
• Nach der Versicherungsausführung-Routine schreibt der Transportmechanismus an die Steuerblöcke des Anwenderprogramms (erzeugt vom Betriebssystem nach der Einleitung der ersten Unterbrechung durch das Anwenderprogramm), um anzuzeigen, daß die Unterbrechung ausgeführt wurde. Die Steuerung wird dann an das Anwenderprogramm zurückgegeben. Die Operationen des Transportmechanismus und der verschiedenen Überwacherprogramme sind somit für das Anwenderprogramm transparent.
• Als eine zweckmäßige Veranschaulichung wird hier eine bestimmte Implementierung beschrieben, die sich auf Computer bezieht, die unter dem weit verwendeten MVS-Multiprogrammier-Betriebssystem von IBM arbeiten. Der Entwurf und das Betriebsverfahren des MVS-Betriebssystems sind umfangreich in einer Anzahl von Veröffentlichungen dokumentiert, die von der IBM Corporation, Programming Publications, Department D58, Building 706-2, P.O. Box 390, Poughkeepsie, New York 12602, erhältlich sind.
• Die in der veranschaulichenden MVS-Implementierung interessierenden Unterbrechungen werden in der MVS-Dokumentation als Überwacheraufrufe (Supervisor Calls, SVCs) bezeichnet. Das MVS-Betriebssystem unterhält eine Vektortabelle von Unterbrechungsbehandlungsroutinen-Adressen, die zu den SVCs (die SVCTABLE) gehören, und stellt zusätzlich eine SVCUPDTE- Funktion bereit, welche das Überschreiben des IH-Vektortabelleneintrags für jeden gegebenen SVC erlaubt. Die Überschreibprozedur wird im Detail auf den Seiten 2-386 if. von "SPL: System Macros and Facilities Volume 2", veröffentlicht von IBM, beschrieben.
• In der veranschaulichenden MVS-Implementierung kann vom Subsystem Interface (SSI) des Systems Gebrauch gemacht werden. Das MVS-Betriebssystem erlaubt es Programmen, die bestimmten Protokollanforderungen genügen, als Subsysteme installiert zu werden, welche tatsächlich als residen te Erweiterungen zum Betriebssystem wirken. Beispiele typischer Subsysteme umfassen Druck-Spooler, wie z.B. JES2 und JES3.
• Das SSI spielt eine Hauptrolle in der veranschaulichenden MVS-Implementie rung. Es gewährleistet jedoch eine zweckmäßige und weithin bekannte Standardarchitektur und ein Verfahren, durch die Subsysteme oder andere Programme mit anderen Subsystemen eine Schnittstelle bilden können.
• Allgemein gesprochen muß jedes Programm, welches Gebrauch vom SSI macht, dies so tun, indem ein Paar Steuerblöcke in einem adressierbaren Speicher erzeugt wird und formatierte Information dorthin geschrieben wird. Diese Standardsteuerblöcke sind ein Subsystem-Informationsblock (SSIB) und ein entsprechender Subsystem-Optionsblock (SSOB). Der SSIB identifiziert das Programm, welches den SSI verwendet, um das Zielsubsystem aufzurufen. Der SSOB enthält einen Zeiger auf die Adresse im adressierbaren Speicher einer Parameterliste im Standardformat, bekannt als Erweiterungsblock. Diese Technik der indirekten Adressierung, die sich im SSOB wiederspiegelt, erlaubt einem Programm, den SSI zu benutzen, um eine willkürliche Anzahl von Parametern an ein Subsystem unter Verwendung eines SSOB fester Größe zu übergeben.
• In der veranschaulichenden MVS-Implementierung installiert sich der Transportmechanismus selbst als ein Subsystem unter MVS gemäß den gewöhnlichen SSI-Prozeduren. Der Transportmechanismus ruft die GETMAIN-Dienstroutine auf, um einen Speicher im Systemwarteschlangenbereich (System Queue Area, SQA), für den Steuerblock zu erhalten, der erforderlich ist, um dern Betriebssystem den Transportmechanismus als ein Subsystem zu identifizieren. Dieser Steuerblock, bekannt als die Subsystem-Steuertabelle (Subsystem Control Table, SSCT), wird vom Transportmechanismus initialisiert und am Ende der existierenden SSCT-Warteschlange des SSI unter Verwendung einer Vergleiche- und Vertausche-Logik eingereiht (oder durch das alternative Verfahren der SSCT-Erzeugung, das in der IBM-Veröffentlichung GC28-1 149, "MVS/Extended Architecture Systems Programming Library: Initialization and Tuning" dokumentiert ist).
• Der Transportmechanismus erzeugt auch eine SSI-Standard-Subsystem-Vektortabelle (SSVT), auf dessen Adresse von der SSCT gezeigt wird. Die SSVT enthält formatierte Information betreffend, welche Typen von Computerumgebungsereignissen zu einem SSI-Aufruf an eine bezeichnete Transportmechanismus-Routine führen sollen. Der Transportmechanismus ruft die GETMAIN- Dienstroutine auf, um einen Speicher im erweiterten gemeinsamen Speicherbereich (Common Storage Area, CSA) für die SSVT zu erhalten. Die SSVT wird mit Steuerfeldern und -vektoren initialisiert, die für den Transportmechanismus erforderlich sind, um seine Steuerblöcke und Verarbeitungsroutinen zu navigieren, und zwar gemäß Standard MVS-Prozeduren. Die SSVT wird aus der zuvor installierten SSCT unter Verwendung von Vergleiche- und Vertausche-Logik aufgestellt.
• Beim Aufruf der GETMAIN-Routine fordert der Transportmechanismus ausreichenden Raum nicht nur für die "Basis"-SSVT, die durch das SSI- Protokoll festgelegt ist, sondern ebenso für eine Erweiterung zur SSVT an. Beim Betrieb des Transportmechanismus, wie unten beschrieben, schreibt er Information in diesen Erweiterungsraum betreffend seiner eigenen Zuteilung von Speicherbetriebsmitteln während des sequentiellen Aufrufs der Überwacherprogramme. Wenn die nichtbiockierte Ausführung der normalen IH- Routine zu einer anormalen Beendigung ("Absturz") des Programms, das die SVC eingeleitet hat (hiernach als ein Anwenderprogramm bezeichnet), geführt haben würde, verwendet der Transportmechanismus diese Information zur Freigabe zugeteilten Speichers zurück zum freien Speicher. Das Schreiben dieser Information in eine Steuerblockerweiterung anstelle in einen separaten Steuerblock ist vorteilhaft, weil es nur einen Aufruf für eine Zuteilung von Speicher erfordert, wobei somit die Software-Wartungslast reduziert wird.
• Der Transportmechanismus ruft das MSTR-Subsystem des Betriebssystems unter Verwendung der IEFSSREQ-Dienstroutine auf, um sicherzustellen, daß die SSCT von den SSI-Routinen erkannt werden kann. Ein SSOB, der sich im privaten Speicherbereich des Transportmechanismus befindet, ist für den IEFSSREQ-Dienst vorgesehen und fordert die Verifizierung des für den Transportmechanismus zu verwendenden Subsystems an. Ein erfolgreicher Abschluß des Dienstes zeigt an, daß der Transportmechanismus richtig installiert ist.
• In der veranschaulichenden MVS-Implementierung installiert sich jedes Überwacherprogramm, wie der Transportmechanismus, selbst als ein MVS- Subsystem unter Verwendung von Standard-SSI-Prozeduren. Das Überwacherprogramm ist darüber hinaus so entworfen, um die GETMAIN-Dienstroutine zu verwenden, um Speicher für eine erweiterte Unterbrechungsüberprüfungstabelle (Interrupt Screening Table, XST) zu gewinnen, die diesem Überwacherprogramm eigen ist.
• Das Überwacherprogramm initialisiert die XST mit formatierter Information über die Typen von SVCs, die vom Überwacherprogramm verarbeitet werden, und zusätzlich über die Adressen der dem Überwacherprogramm eigenen Unterberechungshandhabungs-Routinen (Supervisor Program's Interrupt Handling, SPIH) zur Verarbeitung bestimmter Typen von SVCs. Die XSTs für alle aktiven Überwacherprogramme werden, wie unten beschrieben, in eine Warteschlange eingereiht, und ihre Information wird von der Melderoutine des Transportmechanismus beim sequentiellen Aufruf der Überwacher programme in Antwort auf ein SVC-Ereignis verwendet.
• Normalerweise wird ein XST pro Überwacherprogramm erzeugt, die Information über alle Typen von SVCs enthält, die vom Überwacherprogramm verarbeitet werden. Jedoch erlaubt es das warteschlangenorientierte Verfahren der Verarbeitung von XSTs des Transportmechanismus, unten beschrieben, einem Überwacherprogramm eine Vielzahl von XSTs zu erzeugen und aufzustellen.
• Eine solche Vielzahl von XSTs kann z.B. nützlich sein, wenn ein Überwacherprogramm mehr als einmal in Antwort auf einen gegebenen SVC-Typ aufgerufen werden soll (z.B. sowohl vor jeglichem anderen Überwacherprogramm als auch nach allen anderen Überwacherprogrammen). Als ein anderes Beispiel könnte ein Überwacherprogramm einen Entscheidungszweig aufweisen, dessen ein Ausgang eine Bestimmung ist, daß ein zusätzlicher SVC-Typ verarbeitet werden muß, immer wenn der neue SVC-Typ nachfolgend eingeleitet ist. In einem solchen Fall kann ein zusätzlicher XST erzeugt werden und auf die gewöhnliche Weise aufgestellt werden. Bei den meisten MVS-Systemen gibt es keine ernste Begrenzung in der Anzahl von XSTs, die in der XST-Warteschlange des Transportmechanismus installiert werden können.
• Drei unterschiedliche SPIH-Routine-Adressierverfahren sind unter MVS verfügbar, die jeweils die direkte Adresse der Routine, die indirekte Adresse (das bevorzugte Verfahren zur Wartung und für andere Zwecke) oder eine Adresse, die von der MVS-"Programm Call"-Einrichtung Gebrauch macht, verwenden. Nur ein Adressierverfahren kann in einer einzelnen XST wegen MVS-Systembeschränkungen verwendet werden, wie vom Fachmann mit der Kenntnis dieser Offenbarung anerkannt werden wird.
• Jedoch können mehrere XSTs, die zu einem Überwacherprogramm gehören, unterschiedliche Adressierverfahren verwenden. Nach Erzeugung seiner XST(s) installiert sich das Überwacherprogramm selbst als ein Anwender der Melderoutineneinrichtungen des Transportmechanismus durch Installieren seiner XST auf der Warteschlange von XSTs des Transportmechanismus. Das Überwacherprogramm initialisiert ein SSIB/ SSOB-Steuerblockpaar im privaten Adreßraum des Überwacherprogramms. Das SSIB/SSOB-Paar wird an das SSI und durch das SSI an den Transportmechanismus (auch ein Subsystem) übergeben, und zwar durch einen IEFSSREQ-Aufruf vom Überwacherprogramm. Eine solche Verwendung des SSI erübrigt die Notwendigkeit für die Überwacherprogramme, eine zuvor bestehende Kenntnis der Steuerblockstruktur des Transportmechanismus zu haben, um Zugriff auf die Installationsroutine des Transportmechanismus zu gewinnen.
• Die Überwacherprogramm-Installationsroutine des MVS-Transportmechanismus verarbeitet die spezifische Initialisierungsinformation, die in das SSIB/SSOB- Paar geschrieben ist; die Verarbeitung beinhaltet das Ausführen irgendwelcher erwünschter Validierungsprüfungen. Die Initialisierungsinformation enthält die Warteschlangenposition, die vom Überwacherprogramm für die XST gewünscht ist. Wenn die XST alle Validierungsprüfungen übergibt, wird das Überwacherprogramm in der Warteschlange der aktiven Überwacherprogramme des Transportmechanismus eingereiht.
• Falls erwünscht, kann das Warteschlangen-Positonierungsschema des Transportmechanismus in Prioritätsklassen eingerichtet werden, wobei XSTs in der Reihenfolge ihrer Prioritätsklasse in die Warteschlange und innerhalb jeder Klasse in der Reihenfolge der Installation eingereiht werden.
• Der Aufruf von SSI-Subsystem-Installationsprozeduren durch das Überwacherprogramm führt zur Erzeugung einer SSCT und einer zugehörigen SSVT für das Überwacherprogramm, wie oben in Verbindung mit dern Transportmechanismus beschrieben. Wie der Transportmechanismus ist das Überwacherprogramm programmiert, um ausreichenden Raum für eine Erweiterung zu ihrer SSVT anzufordern. Aus Zweckmäßigkeit wird dieser Erweiterungsraum vom Überwacherprogramm verwendet, um formatierte Information über die Arten von Umgebungszustandsinformation zu schreiben, die von den SPIH-Routinen des Überwacherprogramms nachgeschlagen wird. Zum Beispiel kann die SPIH-Routine aus dieser Information in der SSVT-Erweiterung herausfinden, daß die SPIH-Routine vom Zustand bestimmter Register Gebrauch machen soll, um die Terminal-ID-Nummer zu bestimmen, die zu dern Anwenderprogramm gehört, welches den SVC eingeleitet hat.
• In der veranschaulichenden MVS-Implementierung wird die Substitut-IH- Installationsroutine des Transportmechanismus in Verbindung mit der Installierung einer neuen XST eines Überwacherprogramms aufgerufen. Die Routine macht vom Standard-SVC-UPDTE-Merkmal des MVS-Betriebssystems Gebrauch.
• Der Transportmechanismus verwendet die Information, die vom gerade installierten Überwacherprogramm in die neue XST geschrieben wurde, um zu bestimmen, welche Typen von SVCs von diesem Überwacherprogramm verarbeitet werden. Für jeden solchen SVC-Typ befragt der Transportmechanismus eine Tabelle von abfangbaren SVC-Typen, welche sie unterhält, um zu bestimmen, ob der entsprechende SVCTABLE-Eintrag bereits mit der Adresse der entsprechenden Substitut-IH-Routine des eigenen Transportmechanismus überschrieben worden ist.
• Aus reiner Zweckmäßigkeit wird diese Transportmechanismus-Tabelle innerhalb des adressierbaren Speichers gehalten, der für eine CONTROL-SVC- Unterbrechungsbehandlungs-Routine zugeteilt ist, der seinerseits vom veranschaulichenden MVS-Transportmechanismus als eine Sicherheitsmaßnahme verwendet wird. Diese Tabelle enthält auch die gesicherten Adressen der normalen IH-Routinen für die überwachten Unterbrechungen.
• Die Tabelle wird während der Installierung des Transportmechanismus erzeugt, welcher die Adresse einer CONTROL-SVC-IH-Routine in die SVCTABLE durch Überschreiben eines bestehenden SVCTABLE-Eintrags unter Verwendung der SVCUPTDTE-Funktion installiert (wobei somit der SVC des Betriebssystems aufgegeben wird, auf welchen ursprünglich durch diesen SVCTABLE-Eintrag gezeigt wurde). Der zu überschreibende Eintrag wird vom Anwender während der Installierung des Transportmechanismus ausgewählt, vorzugsweise vom Anwender-SVC-Bereich (SVCs Nr. 200-255 einschließlich), beschrieben in IBM-Veröffentlichung GC28-1150-2. Die CONTROL-SVC-Routine arbeitet in Verbindung mit der Unterbrechungausführung-Routine des Transportmechanismus, wie unten beschrieben.
• Um die Wahrscheinlichkeit von Integritätsproblemen zu vermindern, ist die CONTROL-SVC-Routine vorzugsweise so entworfen, um sofort die Steuerung an das aufrufende Programm ohne Ausführung des SVC zurückzugeben, wenn ein präzises Protokoll (z.B. ein Zugangswort oder eine spezielle Parameterliste) bei der Abgabe des Aufrufs nicht verwendet wird. Mit einem solchen Protokollerfordernis werden andere Programme, die zufällig den CONTROL-SVC oder anderweitig aufrufen, keine unerwarteten Ergebnisse hervorrufen.
• Wenn der SVCTABLE-Eintrag für den zu überwachenden SVC nicht bereits überschrieben worden ist, veranlaßt der Transportmechanismus ein solches Überschreiben unter Verwendung der SVCUPDTE-Funktion und bemerkt diese Tatsache in der CONTROL-SVC-Tabelle. Ansonsten gibt die Substitut-IH-Installationsroutine die Steuerung an das aufrufende Programm zurück.
• Bei der veranschaulichenden MVS-Implementierung macht, wenn ein SVC von einem Programm eingeleitet wird, die Umgebungsmodellier-Routine Gebrauch vom bereits gut dokumentierten SSIB/SSOB-Protokoll des SSI beim Erzeugen eines formatierten Speichermodells, wobei somit die Aufgabe des Schreibens von Überwacherprogrammen für jene, die mit diesem Protokoll vertraut sind, erleichtert wird. (Ein separates Sicherungsmodell wird in der MVS-Implementierung nicht verwendet, weil der Überwacheranforderungsblock (Supervisor Request Block, SVRB) und andere wohlbekannte Steuerblöcke des MVS-Systems die erforderliche Information in angemessener Weise liefern.)
• Nach Einleitung eines SVC beschafft die Umgebungsmodellier-Routine adressierbaren Speicherraum unter Verwendung des GETMAIN-Dienstes und erzeugt einen SSIB und einen SSOB im Standard-SSI-Format. Dieser SSIB wird jedoch verwendet (während des Betriebs der Melderoutine), um das gerade aufgerufene Überwacherprogramm zu identifizieren, anstelle das aufrufende Programm zu identifizieren, wie es normalerweise beim SSI- Protokoll vorgenommen werden würde. Die Steuerblöcke, Register und andere Felder, die von der Umgebungsmodellier-Routine kopiert werden, werden in den IEFJSSIB- und IEFJSSOB-Elementen des im MVS-Betriebssystem enthaltenen SYS1.MACLIB-Datensatzes definiert.
• Der vom Transportmechanismus geschriebene SSOB zeigt zur Adresse des Speichermodells, welches ein Erweiterungsblock ist, der von der Umgebungsmodellier-Routine erzeugt und durch diese beschrieben wurde und als eine erweiterte Überwachertabelle (Extended Supervisor Table, SXSS) bezeichnet wird. Wie beschrieben durch die Umgebungsmodellier-Routine enthält die SXSS eine ausführliche Beschreibung der Umgebungszustandsinformation, die zu dem SVC-Ereignis gehört, das eingetreten ist, z.B. die Werte bestimmter Register. Diese Beschreibung enthält Information vom SVRB, der, wie der Fachmann erkennen wird, vom Betriebssystem in Antwort auf die Ausgabe des SVC durch das einleitende Programm erzeugt wird. Die Werte von sowohl dem Programmstatuswort-(PSW)- und der Allgemein-Register, die zum Zeitpunkt der Ausgabe des SVC vorlagen, werden in die SXSS kopiert, genauso wie die Adressen von sowohl dem Aufgabensteuerblock (Task Control Block, TCB) und dern SVRB. Die spezifischen Steuerblöcke, Register usw., die kopiert werden sollen, sind in den IKJTCB- und IHARB- Makros des im MVS-Betriebssystem enthaltenen SYS 1. AMODGEN-Datensatz definiert.
• Darüber hinaus wird die Adresse der Unterbrechungausführung-Dienstroutine des Transportmechanismus in die SXSS gelegt, um den Überwacherprogrammen ein zweckmäßiges Mittel zum Anfordern der Ausführung der aufgerufenen Unterbrechung zu geben, falls erwünscht.
• In der veranschaulichenden MVS-Implementierung prüft die Melderoutine ein Flag an einem SVC-spezifischen Offset in jeder XST, um zu bestimmen, ob die entsprechende SPIH aufgerufen werden soll oder nicht, deren Adresse ebenso an einem SVC-spezifischen Offset im SVC enthalten ist. Demzufolge können einige Überwacherprogramme (deren Flags auf OFF gesetzt sind) nicht in Antwort auf einen gegebenen SVC-Typ aufgerufen werden.
• Die Programmierung jeder SPIH-Routine eines Überwacherprogramms ist willkürlich und kann die direkte Manipulation des Speichermodells beinhalten (im Gegensatz zur Manipulation durch Aufruf der Transportmechanismus- Dienstroutinen). In der gerade beschriebenen, veranschaulichenden Implementierung ist herausgefunden worden, daß die direkte Manipulation wegen der relativen Seltenheit der Manipulation und der Komplexität des Entwurfs solcher Dienstroutinen für alle möglichen SVCs bevorzugt ist. Bei direkter Manipulation müssen nur die gerade überwachten SVCs berücksichtigt werden, und die Programmierung für die Manipulation kann bis zu den Entwurfsphasen eines Überwacherprogramms zurückgestellt werden, welches eine solche Manipulation durchführen wird.
• Wenn die Unterbrechungsausführung-Routine des Transportmechanismus von einem Überwacherprogramm aufgerufen wird, leitet diese Routine ein CON- TROL-SVC-Unterbrechungsereignis gemäß dem oben beschriebenen, erforderlichen Protokoll ein. Nach Einleitung der CONTROL-SVC-Unterbrechung erzeugt das MVS-Betriebssystem routinemäßig einen separaten SVRB, der Programmstatusinformation über das Unterbrechungsereignis enthält, genauso wie es das getan hat, als das Anwenderprogramm die überwachte Unterbrechung eingeleitet hat. Die an den CONTROL-SVC-Unterbrechungsbehandler übergebenen Argumente lauten: (a) ein Zeiger zu einer spezifischen Adresse der normalen IH-Routine des überwachten SVC und (b) ein Zeiger zur SXSS.
• Der CONTROL-SVC-Unterbrechungsbehandler seinerseits (1) führt Datenschreiboperationen nach Notwendigkeit aus, um die Umgebung mit dem im Speichermodell (d.h. die SXSS) wiedergespiegelten Status konform zu machen; und (2) ruft die normale IH-Routine des überwachten SVC auf.
• Nach Beendigung der normalen IH-Routine für den überwachten SVC kehrt die Steuerung danach an den CONTROL-SVC-Unterbrechungsbehandler zurück, welcher die SXSS aktualisiert, um den laufenden (nach der Ausführung) Zustand wiederzuspiegeln. Die Steuerung wird dann zurück zur Unterbrechungsausführung-Routine des Transportmechanismus übergeben, welcher die CONTROL-SVC-Routine aufgerufen hat, und schließlich zurück zum Überwacherprogramm übergeben, welches die Unterbrechungsausführung- Routine aufgerufen hat.
• Der normale Unterbrechungsbehandler für den überwachten SVC wird somit endlich aufgerufen. Jedoch kann die Umgebung beträchtlich seit der Zeit geändert worden sein, als der SVC ursprünglich eingeleitet wurde. Weiterhin besteht die Rückgabe der normalen IH nicht in der Rückgabe an das Anwenderprogramm, welches diese ursprünglich aufgerufen hat, sondern in der Rückgabe an den CONTROL-SVC-Unterbrechungsbehandler und seinerseits an die Unterbrechungsausführung-Routine und wiederum ihrerseits an das aufrufende Überwacherprogramm.
• Tatsächlich hat dadurch die Unterbrechungsausführung-Routine des Trans portmechanismus die Ausführung des SVC, der vom Anwenderprogramm aufgerufen wurde, unter seiner eigenen (des Transportmechanismus) Steuerung und innerhalb einer durch seine SXSS, welche von einem Überwacherprogramm beabsichtigt modifiziert worden sein mag, spezifizierten Umgebung veranlaßt, bevor die Steuerung an das aufrufende Überwacherprogramm für weitere Maßnahmen zurückgegeben wird.
• Die Unterbrechungsausführung-Routine des Transportmechanismus ist vorzugsweise unterschiedlich von der CONTROL-SVC-IH-Routine, welche eigentlich die Ausführung des SVC veranlaßt. Wie oben angemerkt kann aus Integritätsgründen die CONTROL-SVC-IH-Routine so entworfen sein, um eine Konformität mit einem Protokoll für eine normale IH-Routinenausführung als Ergebnis zu erfordern. In der Tat mögen manche Computersystem-Verwalter bevorzugen, die Details des Protokolls preiszugeben, wobei somit Entwickler von Überwacherprogrammen die Verwendung der Unterbrechungsausführung-Dienstroutine erforderlich wird, welche zusätzliche Sicherheitsmaßnahmen oder Fehlerverfolgungsmerkmale aufweisen kann, wie gewünscht.
• In der veranschaulichenden MVS-Implementierung ist ein Sicherungsmodell nicht notwendig. Dies liegt daran, daß ein separater SVRB, der sich von dem des aufrufenden Programms unterscheidet, ganz selbstverständlich vom Betriebssystem geschrieben wird, wenn die Unterbrechungsausführung-Routine die CONTROL-SVC-Unterbrechung einleitet, um die normale IH-Routine auszuführen. In ähnlicher Weise werden eigenständige PSWs und andere Steuerblöcke ebenso für die CONTROL-SVC-Unterbrechung geschrieben. Dies beläßt die Steuerblöcke, die ursprünglich vom Anwenderprogramm, welches das SVC-Ereignis einleitete, geschrieben wurden, unverändert und verfügbar zur Bezugnahme.
• Der veranschaulichende MVS-Transportmechanismus gibt die Steuerung an das aufrufende Anwenderprogramm unter Verwendung von Standard-MVS- Register-Wiederherstellungsprotokollen zurück. Diese Protokolle sind auf den Seiten 191-196 der zuvor erwähnten technischen Referenz GC28-1 150-2 von IBM dokumentiert.
• Ein Fachmann mit der Kenntnis dieser Offenbarung wird anerkennen, daß diese Erfindung angesehen wird, als für eine Anwendung in einer großen Vielfalt anderer Situationen fähig zu sein.
• Zum Beispiel wird einem Durchschnittsfachmann mit der Kenntnis dieser Offenbarung erkenntlich sein, daß ein Überwacherprogramm so entworfen sein kann, praktisch jegliche Art von Maßnahme zu treffen, wenn es vom Transportmechanismus aufgerufen wird. Für einen gegebenen Unterbrechungsereignistyp könnte ein Überwacherprogramm eine komplexe Logik und einen Satz verfügbarer Maßnahmen aufweisen, welche durch verschiedene Faktoren oder Kombinationen von Faktoren im Umgebungsstatus bestimmt sein würden.
• Als ein hypothetisches Beispiel könnte ein Überwacherprogramm, welches Plattendaten-Schreiboperationen überwacht, denkbar entworfen werden, um alle Anforderungen für solche Operationen, die von bestimmten Terminals herstammen, aber nicht von anderen Terminals, abzufangen. Daten, die gerade unter der Steuerung solcher Terminals aüf Platte geschrieben werden, könnten dann über einen Verschlüsselungsalgorithmus verarbeitet werden. Durch die Manipulation der Adreßregister des Speichermodells und anderer Information könnten die Daten, die tatsächlich auf Platte geschrieben werden, die gespeicherte Ausgabe des Verschlüsselungsalgorithmus anstelle der ursprünglich unverschlüsselten Daten sein. Die Verwendung der Speichermodell-Umgebungsdaten als ein zentraler Referenzpunkt verleiht somit einem Überwacherprogramm eine beträchtliche Flexibilität.
• Ferner kann die Umgebungsstatusinformation, die im Speichermodell und/oder Sicherungsmodell gespeichert ist, eine wertvolle Hilfe zur Fehlerbeseitigung im Falle einer anormalen Beendigung eines Anwenderprogramms oder des Betriebssystems selbst sein.

Claims (5)

1. Verfahren für verteilte Überwachung der Ausführung einer normalen Unterbrechungsbehandlungsroutine, die von einem Aufrufprogramm innerhalb einer Computersystem-Betriebsumgebung aufgerufen wird, welches folgende Schritte aufweist:

A. Abfangen jedes Aufrufes an die normale Unterbrechungsbehandlungsroutine;

B. Nach jedem solchen Aufruf, Erzeugen eines Speichermodells in einem adressierbaren Speicher des dann existierenden Zustandes des Informationsinhalts ausgewählter Register und Speicherblökke, auf was als Umgebung Bezug genommen wird;

C. Übergeben eines Zeigers an das Speichermodell als ein Argument in einem Aufruf an ein Überwachungsprogramm;

D. Nach jedem Aufruf durch das Überwachungsprogramm zur Ausführung der normalen Unterbrechungsbehandlungsroutine, Bestimmen des dann existierenden Zustandes des Speichermodells und Aktualisieren der Umgebung, um den dann existierenden Zustand des Speichermodells widerzuspiegeln;

E. Aufrufen der normalen Unterbrechungsbehandlungsroutine;

F. Aktualisieren des Speichermodells, um den dann existierenden Zustand der Umgebung widerzuspiegeln;

G. Zurückgeben der Steuerung an das aufrufende Überwachungsprogramm;

H. Zurückübernehmen der Steuerung vom aufrufenden Uberwachungsprogramm;

I. Wenn kein Überwachungsprogramm die Ausführung der normalen Unterbrechungsbehandlungsroutine aufgerufen hat, Aufrufen der Ausführung;

J. Die Umgebung mit dem existierenden Zustand des Speichermodells in Übereinstimmung bringen; und

K. Zurückgeben der Steuerung an das aufrufende Programm.

2. Verfahren gemäß Anspruch 1, welches weiterhin den Schritt des Erzeugens eines Sicherungsspeichermodels nachfolgend der Erzeugung des Speichermodells und vor der Übergabe des Arguments an das Überwachungsprogramm aufweist.

3. Verfahren gemäß Anspruch 1, welches weiterhin die Ausführung der Schritte C. bis H. für eine Vielzahl der Überwachungsprogramme vor der Ausführung der Schritte I. bis K. aufweist.

4. Verfahren gemäß Anspruch 3, wobei jedes Überwachungsprogramm gemäß einem Prioritätsschema aufgerufen wird.

5. Verfahren gemäß Anspruch 1, wobei die in Schritt B. erzeugten Speichermodelle vom Überwachungsprogramm verwendet werden, um die Umgebung zu untersuchen, welche vor und nach der Ausführung der normalen Unterbrechungsbehandlungsroutine erwartet würde.