DE3752196T2

DE3752196T2 - Vorrichtung für Datenverarbeitungsverteilung über eine Mehrzahl von Steuerungsorten

Info

Publication number: DE3752196T2
Application number: DE3752196T
Authority: DE
Inventors: Steward Allen Comer; Roger H Dev; John B Kam; Gabriel Steinberg
Original assignee: Kodak Ltd
Current assignee: Eistream Technologies Inc Dallas Tex Us
Priority date: 1986-12-19
Filing date: 1987-12-11
Publication date: 1999-02-04
Anticipated expiration: 2007-12-12
Also published as: US4932026A; JPS63239552A; EP0272561A3; JP2721672B2; EP0272561B1; EP0272561A2; AU600755B2; CA1286414C; DE3752196D1; AU7832287A

Description

Die vorliegende Erfindung betrifft Datenverarbeitungssysteme, insbesondere Datenverarbeitungssysteme mit einer Vielzahl Steuerungsorte. Viele herkömmliche Rechneranlagen weisen eine Vielzahl Steuerungsorte auf, d. h. es gibt mehr als eine Einheit in der Rechneranlage, die ein Programm ausführen kann. Die Beziehung zwischen den Steuerungsorten und der Anlagenhardware ändert sich von Anlage zu Anlage. Bei einigen Anlagen entspricht ein Steuerungsort direkt einem Teil eines körperlichen Systems. Beispielsweise kann bei einem durch ein Netzwerk verbundenen verteilten System jeder Steuerungsort ein Knoten im Netzwerk sein. Bei anderen kann der Steuerungsort eine Aufgabe sein, und eine oder mehrere Zentraleinheiten in einer Anlage können eine Vielzahl von Aufgaben im Multiplexbetrieb bearbeiten.
Anlagen mit einer Vielzahl von Steuerungsorten ermöglichen eine verteilte Datenverarbeitung, d. h. eine Datenverarbeitung, die mehr als einen Steuerungsort nötig macht. Beispielsweise kann ein Unternehmen eine Rechneranlage aufweisen, die aus einem Netzwerk mit Knoten in verschiedenen Zweigniederlassungen, regionalen Geschäftsstellen und dem Hauptsitz besteht. Die Verarbeitung von Spesenabrechnungen für das Unternehmen kann die Verarbeitung in den Zweigniederlassungen, weitere Verarbeitung in den regionalen Geschäftsstellen und noch weitere Verarbeitung am Hauptsitz umfassen.
Die Vorteile einer verteilten Datenverarbeitung sind offensichtlich. Sie entspricht mehr den normalen Geschäftsverfahren als eine zentrale Verarbeitung, die Durchlaufzeit ist auf jeder Stufe kürzer, und der Umstand, daß die Verarbeitung an vielen Steuerungsorten durchgeführt wird, mildert die Auswirkung eines an irgendeinem der Orte begangenen Fehlers. Die Anwendung der verteilten Datenverarbeitung ist jedoch dadurch begrenzt worden, daß beim Programmieren für mehr als einen Ort Schwierigkeiten auftauchen. Beim Programmieren für einen einzigen Ort braucht sich ein Programmierer nur um die Folge der auszuführenden Operationen kümmern; beim Programmieren für eine Vielzahl von Orten muß der Programmierer Befehle für jeden der Orte schreiben und ferner Informationsaustausche zwischen den Orten vorschreiben. Auch wenn die Orte Aufgaben sind, die in einer einzelnen Anlage ausgeführt werden, erfordert die Notwendigkeit, Informationsaustausche vorzuschreiben, Kenntnisse des Betriebssystems, die üblicherweise nicht bei Anwendungsprogrammierern anzutreffen sind. Sind die Orte Knoten in einem Netzwerk, sind die Austauschschwierigkeiten noch größer. Außerdem weisen die Knoten in vielen Fällen unterschiedliche Prozessor-Typen auf, und folglich erfordert das Schreiben einer verteilten Anwendung entweder einen Programmierer, der mit allen Prozessoren vertraut ist, oder eine Gruppe von Programmierern. Programmierer der an erster Stelle genannten Art sind selten und teuer, und die Kommunikation in einer Gruppe von Programmierern ist schwierig, insbesondere dann, wenn die Programmierer für unterschiedliche Maschinen programmieren und an geographisch verschiedenen Orten stationiert sind.
Herkömmliche Lösungen zur verteilten Verarbeitung haben Anlagen enthalten, bei denen die Verarbeitung zwar auf die Orte verteilt ist, aber zentral gesteuert wird, und Anlagen, bei denen die Verarbeitung lokal gesteuert wird. Ein Beispiel des ersten Anlagentyps ist das aktive Mailsystem, das in John Hogg, Stellos Gamvroulas "An Active Mail System" (Ein aktives Mailsystem), Sitzungsbericht SIGMOD 1984, Boston, 1984, S. 215-222 beschrieben ist.
Das in der Belegstelle beschriebene System ist ein aktives Mailsystem zur Verarbeitung von Nachrichten. Die Nachrichten sind nicht lediglich passiver Text, der an Empfänger geleitet wird. Statt dessen ist eine Nachricht aktiv und kann Funktionen ausführen, z. B. Informationen vom Empfänger empfangen und an den Absender leiten, oder die Informationen vom Empfänger zur Feststellung benutzen, wer der nächste Empfänger ist, und die Information an den nächsten Empfänger leiten. Auf S. 218 der vorstehend genannten Belegstelle erfährt man, daß die dort beschriebene Ausführungsform eines aktiven Mailsystems mittels eines einzelnen Zentralpoststellen-Verfahrens implementiert ist, das die Nachrichten an jeder Stelle steuert.
Ein Handelsprodukt, das die in der vorstehend genannten Belegstelle beschriebenen Grundsätze zu verwirklichen scheint, ist Staffware, ein Erzeugnis der FCMC, Inc., 2750 S. Wadsworth Blvd., Denver CO 80227. Staffware ist in den nachstehend angegebenen Veröffentlichungen beschrieben:
Staffware, Prospekt und Demo-Diskette, FCMC, Inc., Denver, Mai 1985
"Routine Automation" (Routineautomatisierung), The Seybold Report on Office Systems (Seybold-Bericht über Bürosysteme), Bd. 8, Nr. 6, 3. Juni 1985, S. 18
Kevin Townsend: "Corporate computing catches up with PCs" (Unternehmensweite Datenverarbeitung holt PC ein), Computer Weekly, 13. Febr. 1986
"Staffware", Which Computer?, März 1986.
Wie in den vorstehend angegebenen Veröffentlichungen beschrieben, ist Staffware ein zentralisiertes System zum Automatisieren von Geschäftsverfahren, bei denen die Verarbeitung an einem oder mehreren Plätzen stattfindet, auf welche das zentralisierte System Zugang hat. Ein anderes Produkt, das die gleichen Grundsätze zu verwirklichen scheint, ist die Workflo-Komponente des von der Filenet Corp., Costa Mesa, CA hergestellten Filenet-Dokumenten-Bild-Verarbeitungssystems.
Ein Beispiel eines Systems, bei dem die verteilte Verarbeitung mit lokaler Steuerung stattfindet, ist das Büro-Informationsleitsystem, das in Murray S. Mazer, Frederick H. Lochovsky:
"Logical Routing Specification in Office Information Systems" (Logische Leitwegspezifikation in Büroinformationssystemen), ACM Transactions on Office Information Systems (ACM-Sitzungsberichte Über Büroinformationssysteme), Bd. 2, Nr. 4, Okt. 1984, S. 303-330
beschrieben ist.
Bei diesem System definieren Anwender eine Leitwegvorschrift für einen Nachrichtentyp, z. B. ein Formular zur Entscheidung über die Zulassung eines Kandidaten zum Programm Philosophiedoktorat. Die Leitwegvorschrift beschreibt, auf welche Weise die Nachricht zwischen den Orten zu leiten ist, und kann den Leitweg je nach den Werten in Feldern der Nachricht ändern. Nach Fertigstellung der Leitwegvorschrift wird der sich auf einen bestimmten Ort beziehende Teil der Vorschrift diesem Ort zugesandt. Wenn in dem Ort eine Nachricht des Typs ankommt, der der Leitwegvorschrift entspricht, wird sie so verarbeitet, wie es in dem für diesen Ort zuständigen Teil der Leitwegvorschrift vorgeschrieben ist. Das System ermöglicht auch eine Leitwegkorrektur, bei der die Leitwegspezifikation für eine bestimmte Nachricht aufbereitet wird, die Nachricht mit der geänderten Spezifikation versehen wird, und der weitere Leitweg so wird, wie in der geänderten Spezifikation vorgeschrieben ist. Die Leitwegspezifikation schreibt keine weitere Verarbeitung außer dem Leitweg vor.
Eine sowohl dem herkömmlichen zentralisierten wie dem verteilten System gemeinsame Schwierigkeit besteht darin, daß das tatsächliche Routing zentral geschieht. Bei den Aktivnachrichten-Systemen kann der Empfänger der Nachricht die Verarbeitung der Nachricht zur Anpassung an seine Verhältnisse nicht ändern, und bei dem Mazer-Lochovsky-System wird die Leitwegspezifikation zentral definiert und Änderungen können nur mittels der Korrekturspezifikation ausgeführt werden. Die die Korrekturspezifikation erstellende Person muß über eine Kopie der Leitwegspezifikation verfügen und muß ferner wis sen, wo sich die Nachricht aktuell befindet (sh. Mazer und Lochovsky, S. 308-309). Korrekturen sind folglich teuer und können nicht normale Reaktionen auf die verschiedenen Situationen sein, die bei einem Geschäftsablauf eintreten, sondern müssen echten Ausnahmesituationen vorbehalten werden.
In der Veröffentlichung der europäischen Patentanmeldung 0 178 235 A wird die Verarbeitung einer Tätigkeit durch verteiltes Verarbeiten von die Tätigkeit definierenden Schritten auf viele Prozessoren offenbart, insbesondere auf Prozessoren, die der Verarbeitung eines zugehörigen Schrittes/Stufe dezidierte Operatoren aufweisen, wobei verschiedene Operatoren verschiedene Stufen ausführen. Ferner ist jede Operatorfunktion sowohl durch Befehle, die im Operatorspeicher permanent gespeichert sind, als auch durch Inhalte der Nachricht bestimmt. Daher ändert der aktuell arbeitende Aktor die aktive Nachricht, um einen Zustand "ausgeführt" für die Stufe anzugeben, die vom arbeitenden Aktor ausgeführt wird. Die geänderte aktive Nachricht wird dann zum nächsten Aktor geleitet, der die nächste Stufe ausführt. Somit sind Zustandsmeldungen nicht getrennt von der in Verarbeitung befindlichen aktiven Nachricht/Paket lokalisiert.
Ein zentral erstelltes Routing, das schwierig zu ändern ist, ist außerdem für Geschäftsabläufe nicht gut geeignet. Die Definition vieler Geschäftsabläufe geschieht in hierarchischer Weise, d. h. eine obere Managementebene gibt eine Gesamtdefinition des Ablaufs und das Management in den Abteilungen, die den Ablauf tatsächlich durchführen, steuert die Einzelheiten bei. Außerdem ist jeder Geschäftsvorgang tatsächlich einmalig, und folglich wird jede verteilte Datenverarbeitungsanlage, die für Geschäftsvorgänge eingesetzt wird, nur dann nützlich sein, wenn die Art und Weise, in der ein spezieller Vorgang behandelt wird, leicht zu ändern ist.
Eine weitere, den herkömmlichen Systemen gemeinsame Schwierigkeit besteht darin, daß die Nachrichtensysteme auf einen einzigen Datentyp, nämlich die Nachricht, beschränkt sind, wogegen viele Geschäftsvorgänge Informationen einer Vielzahl Typen erfordern. Beispielsweise kann eine geschäftliche Auftragsabwicklung eine Abbildung des Schreibens vom Kunden erfordern, der die Übertragung veranlaßt hat, interne Mitteilungen über Einzelheiten des Auftrags, und ein (mittels einer Kalkulationstabelle erstelltes) "Formular" für die Aufzeichnung der mit dem Vorgang verbundenen Daten. Ein im echten Sinne nützliches System muß nicht nur Daten solcher verschiedener Art an den Benutzer liefern, sondern muß es diesem erleichtern, mit jeder Art Daten in der durch die Art erforderlichen Weise zu arbeiten.
Schließlich besteht eine weitere Beschränkung der herkömmlichen Systeme darin, daß sie auf interaktives Verarbeiten begrenzt sind, d. h. sie können eine Nachricht einem Benutzer zur Verarbeitung zusenden, können aber auf die Nachricht nicht die allgemeinen Ressourcen des Ortes anwenden. Deshalb können die herkömmlichen Systeme für allgemeine verteilte Datenverarbeitung nicht genutzt werden.
Bei den herkömmlichen Systemen, bei denen die verteilte Verarbeitung zentral gesteuert wird, besteht eine Schwierigkeit in dem großen Umfang der Übertragungen, die zwischen der zentralen Steuerung und den Orten erforderlich sind, wo die Fernverarbeitung ausgeführt wird. Wegen des großen Übertragungsumfanges wird die Leistung solcher Systeme inakzeptabel, wenn die Orte durch ein Weitverkehrsnetz verbunden sind.
Schließlich besteht eine für die verteilten Systeme spezifische Schwierigkeit in der Verfolgung und Steuerung der Daten bei ihrer Verarbeitung an den verschiedenen Orten. Diese und weitere Schwierigkeiten des Standes der Technik werden durch die erfindungsgemäße Vorrichtung zum Verteilen der Verarbeitung von Daten auf eine Vielzahl von Steuerungsorten gelöst. Die Vorrichtung umfaßt ein Paket, das die zu verarbeitenden Daten und einen Verarbeitungsdeskriptor enthält, der den Da ten zugeordnet ist und vorschreibt, wie die Daten in mehr als einem der Orte zu verarbeiten sind, ein Nachrichtensystem zum Bereitstellen des Pakets an die Orte, und einen Interpretierer in jedem der im Verarbeitungsdeskriptor angegebenen Ort, der die Daten in der Weise verarbeitet, die für diesen Ort im Verarbeitungsdeskriptor vorgeschrieben ist. Die Verarbeitung kann interaktiv sein oder durch Ausführen eines Programms geschehen, wobei das nachfolgende Routing vom Ergebnis der Verarbeitung abhängig ist.
Gemäß weiteren Merkmalen der Erfindung schreibt der Verarbeitungsdeskriptor die Reihenfolge vor, in der die Orte die Daten verarbeiten sollen, senden die Interpretierer Zustandsdaten an einen speziellen Ort, der den Zustand der verteilten Verarbeitung registriert, kann die Zuordnung zwischen einem Verarbeitungsdeskriptor und den Daten durch den Datentyp bestimmt sein, und kann der unerledigte Teil des Verarbeitungsdeskriptors an einem Ort geändert werden.
Zu den Vorteilen der vorliegenden Erfindung gehören die Einfachheit der Programmierung der verteilten Datenverarbeitung durch eine Vielzahl von Steuerungsorten, die Einfachheit, wie die Art und Weise der Datenverarbeitung an einem Ort geändert werden kann, die Fähigkeit zur Behandlung von Daten einer Vielzahl von Typen, und die verbesserte Steuerung der verteilten Verarbeitung. Weitere Aufgaben und Vorteile der in den beigefügten Ansprüchen angegebenen vorliegenden Erfindung ergeben sich für den Fachmann aus der Bezugnahme auf die hier enthaltene detaillierte Beschreibung einer bevorzugten Ausführungsform und auf die Zeichnungen, in denen zeigt:
Fig. 1 einen logischen Überblick über die Vorrichtung 101 zum Verteilen der Verarbeitung von Daten,
Fig. 2 ein Blockschaltbild einer bevorzugten Ausführungsform der Vorrichtung 101,
Fig. 3 Einzelheiten eines Paketes 104 der Vorrichtung 101,
Fig. 3A Einzelheiten eines Kopfetiketts HDR 333 des Pakets 104,
Fig. 3B ein Diagramm einer Typ-Umgebung im Steuerungsort LC 109,
Fig. 4 Einzelheiten einer lokalen Steuerungsdatenbank,
Fig. 5 ein Diagramm des Steuerungsdatenbank-Systems in einer bevorzugten Ausführungsform,
Fig. 6 Einzelheiten einer Verarbeitungsinformation 318,
Fig. 7 ein Leitweg-Beispiel 315, und
Fig. 8 ein Diagramm von Domänen in einer bevorzugten Ausführungsform.
Bezugszeichen in den Figuren haben drei oder mehr Ziffern. Die beiden geringstwertigen Ziffern sind Bezugszeichen in einer Zeichnung, die höchstwertigen Ziffern stellen die Zeichnungsnummer dar. Beispielsweise bezeichnet das Bezugszeichen 417 das Bauteil 17, das zum ersten Mal in der Zeichnung 4 dargestellt ist.
Die nachstehende Beschreibung einer Bevorzugten Ausführungsform beginnt mit einem Überblick über die logische Struktur und die Arbeitsweise der erfindungsgemäßen Vorrichtung zum Verteilen der Verarbeitung von Daten und wird mit einer detaillierten Beschreibung einer bevorzugten Ausführungsform fortgesetzt.

1. Logischer Überblick über die Vorrichtung zum Verteilen von Daten; Fig. 1

Fig. 1 ist ein logisches Blockschaltbild der erfindungsgemäßen Vorrichtung zum Verteilen von Daten. Die Vorrichtung wird in einem System verwendet, das eine Vielzahl Steuerungsorte (LC; Abk. für engl. locus of control) 109(a...n) und ein Nachrichtensystem (MS; Abk. für engl. message system) 107 zum Übertragen von Daten zwischen den Steuerungsorten aufweist. Die LC 109 können einzelne Hardware-Prozessoren in einem Mehrprozessor-System, Knoten in einem Netzwerk, Aufgaben in einem Mehrprogrammsystem oder eine Kombination des Vorstehenden sein. Wenn die LC 109 Aufgaben sind, kann das MS 107 ein Inter-Task-Kommunikations-System sein; wenn sie Prozessoren in einem Mehrprozessor-System sind, kann es ein System zum Kommunizieren zwischen den Prozessoren sein; wenn sie Knoten in einem Netzwerk sind, kann das MS 107 das Netzwerk sein. Auch hier sind Kombinationen möglich. Wenn die LC 109 beispielsweise Aufgaben sind, die an Knoten im Netzwerk abgearbeitet werden, kann das MS 107 Inter-Task-Nachrichten sein, die über das Netzwerk gesendet werden.
Die in den LC 109 zu verarbeitenden Daten und die Befehle zu ihrer Verarbeitung sind in einem Paket (PKG; Abk. für engl. package) 104 enthalten. Daten 103 können in beliebiger Form vorliegen, in der Daten über das MS 107 übertragbar sind. In vielen Fällen können die Daten 103 eine Datei oder ein Satz mehrerer Dateien sein. Die Befehle, in welcher Weise die Daten 103 in den verschiedenen LC 109 zu verarbeiten sind, sind in einem Verarbeitungsdeskriptor (PD; Abk. für engl. processing descriptor) 105 enthalten. Der PD 105 kann auch von beliebiger Form sein, in der Daten über das MS 107 übertragbar sind, und wird in vielen Fällen eine Datei sein. Die Befehle geben wenigstens die in jedem LC 109 auszuführende Schrittfolge, die maximalen Zeitintervalle zwischen den Schritten und die Aktionen an, die bei Auftreten von Ausnahmebedingungen zu ergreifen sind. Zusätzlich kann die Ausführung bestimmter Befehle abhängig von Werten in den Daten 103 sein, und die Befehle können ferner angeben, welcher Benutzer des Systems für die Daten 103 verantwortlich ist, so daß Informationen über den Stand der Verarbeitung an ihn zurückgegeben werden können.
Jeder LC 109 weist einen Interpretierer (INT) 111 auf, der den PD 105 liest und veranlaßt, daß der LC 109 die für ihn im PD 105 enthaltenen Befehle ausführt. Ist eine weitere Verarbeitung an einem anderen LC 109 erforderlich, benutzt der INT 111 das MS 107, um das Paket 104 diesem LC 109 zuzusenden.
Jeder LC 109 kann, wenn er die Befehle ausführt, über den Stand der Verarbeitung an diesem LC 109 berichten, indem er Zustandsmeldungen über das MS 107 einem anderen, im PD 105 angegebenen LC 109 zusendet. Der vorgegebene LC 109, der in Fig. 1 als LC 109(a) bezeichnet ist, enthält ferner eine Zustandsregistriereinrichtung (SR; Abk. für engl. status recorder) 113, welche die Zustandsmeldungen empfängt und registriert, damit sie von der Person, die den im PD 105 spezifizierten Prozeß kontrolliert, überprüft werden können.
Die Arbeitsweise der Vorrichtung 101 ist folgende: Das Paket 104 wird von einem Benutzer eines der Steuerungsorte LC 109 erstellt. PD 105 beschreibt die Reihenfolge, in der die vom Prozeß betroffenen LC 109 Daten 103 im Paket 104 zu verarbeiten haben, und die in jedem LC 109 auszuführende Verarbeitung. Der INT 111 in dem LC 109, in dem das Paket 104 erstellt wird, liest den PD 105 und sendet das Paket 104 dem im PD 105 zuerst benannten LC 109 zu. Der INT 111 in diesem LC 109 führt die für ihn im PD 105 angegebene Verarbeitung aus und sendet dann das Paket 104 zum nächsten angegebenen LC 109 und so fort, bis die Verarbeitung beendet ist. Da der PD 105 die Reihenfolge beschreibt, in der die LC 109 die Daten 103 verarbeiten, kann es sein, daß ein bestimmter LC 109 im Laufe der Verarbeitung das Paket 104 mehr als einmal behandelt. Während der Verarbeitung erstellte Zustandsinformationen werden von der SR 113 an einem oder mehreren der LC 109 erfaßt.
Ein wichtiges Merkmal der Vorrichtung 101 ist, daß das Paket 104 ausschließlich von der Vorrichtung 101 verwaltet wird. Ein Paket 104 kann nur durch die Vorrichtung 101 erstellt werden. Je nach der Art des Zugriffs eines Benutzers der Vorrichtung 101 auf das Paket 104 kann ein Benutzer die Daten 103 zum Teil oder ganz ändern oder entfernen, Daten 103 aus dem Paket 104 heraus kopieren, Daten 103 in das Paket 104 kopieren, den PD 105 ändern oder entfernen oder einen zusätzlichen PD 105 hinzufügen, aber er kann alle diese Dinge tun und kann das PKG 104 zerstören nur mittels der Vorrichtung 101.
Auf diese Weise garantiert die Vorrichtung 101, daß die gesamte, für einen Geschäftsvorgang erforderliche Verarbeitung in der gesteuerten Umgebung der Vorrichtung 101 stattfindet.

2. Überblick über eine Erste Bevorzugte Ausführungsform der Vorrichtung 101; Fig. 2

Fig. 2 zeigt einen Überblick über eine bevorzugte Ausführungsform der Vorrichtung 101. Die Ausführungsform ist zur Verwendung in einer Rechneranlage bestimmt, in der einzelne LC 109 über Mailboxen zum Senden und Empfangen von Nachrichten über ein elektronisches Post- bzw. Mailsystem verfügen. Ein Beispiel eines solchen Systems sind die von Wang Laboratories, Inc. hergestellte VS-Mehraufgaben-Prozessoren, die durch Wangnet miteinander verbunden sind und über die Mail- Komponente von Wang Office miteinander kommunizieren. In Fig. 2 bedeuten Quadrate Datenstrukturen, Kreise Aufgaben und UWS 213 bezeichnet eine Benutzerarbeitsstation (user work station) mit Bildschirm und Tastatur. Pfeile geben den Informationsfluß zwischen den Komponenten der Vorrichtung an.
Es wird mit den Verarbeitungskomponenten begonnen: Das Paket- Vorbereitungs- und -Aufbereitungs-System (PPES; Abk. für engl. package preparation and editing system) 211 ist die allgemeine Anwenderschnittstelle zur Vorrichtung 101. Das PPES 211 läuft in der Anwenderaufgabe (UT; Abk. für engl. user task) 212 ab, die in Wechselwirkung mit der UWS 213 arbeitet und Nachrichten über das Mailsystem an andere Aufgaben sendet und von diesen empfängt. Mit dem PPES 211 kann ein Benutzer Pakettypen definieren, Pakete 104 erstellen, den Inhalt eines Pakets und die Art und Weise seiner Verarbeitung ändern und den Zustand eines Pakets 104 bestimmen. Ein Paket- Leit- und -Management-System (PRMS; Abk. für engl. package routing and management system) 215 ist eine Aufgabe, die den PD 105 im PKG 104 ausführt. Das verteilte Verfolgungs- und Steuerungs-System (DTCS; Abk. für engl. distributed tracking and control system) 225 ist eine Aufgabe, welche den aktuel len Standort und den aktuellen Zustand von Paketen 104 verfolgt und es den Benutzern der Vorrichtung 101 ermöglicht, die Verarbeitung mittels Steuerbefehlen asynchron zu steuern. Schließlich ist das Fehler-Meldungs- und -Korrektur-System (ENRS; Abk. für engl. error notification and recovery system) 229 eine Aufgabe, die den Benutzern des Systems Fehler mitteilt und Korrekturprozeduren ausführt. PRMS 215, DTCS 225 und ENRS 229 sind für jeden LC 109, der ein Paket 104 verarbeitet, zugänglich, und das PPES 211 ist für jeden LC 109 zugänglich, der ein Paket 104 erstellt oder aufbereitet. Die Übertragung zwischen der UT 212 und dem PRMS 215, dem DTCS 225 und dem ENRS 229, den Aufgaben, geschieht mittels Nachrichten, die über das Mailsystem gesendet werden. Aus der vorstehenden Beschreibung ergibt sich, daß PRMS 215, DTCS 225 und ENRS 229 eine erweiterte Ausführungsform von INT 111 und SR 113 darstellen.
Zurück zu den Datenstrukturen: PPES 211 erstellt ein PKG 104 in der PKGLIB 210, einer Datei-Systembibliothek am LC 109, auf die PPES 211, PRMS 215, DTCS 225 und ENRS 229 Zugriff haben. Zur Erstellung eines PKG 104 benutzt PPES 211 eine Prototypbibliothek (PTL; Abk. für engl. prototype library) 205, Programme zur Behandlung des Inhalts vom PKG 104 in TOOLS (Hilfsmittel) 208 und Benutzerdateien (UF; Abk. für engl. user file) 209. Die PTL 205 enthält einen Satz Prototypen (PTYP) 207. Jeder PTYP 207 ist ein Muster für einen bestimmten Typ des PKG 104. Als Reaktion auf einen PTYP 207 tritt das PPES 211 über die UWS 213 mit dem Benutzer in Wechselwirkung, um die Informationen zu bekommen, die für die Erstellung eines PKG 104 des vorgegebenen Type benötigt werden. Der Benutzer kann ganze UF 209 vorschreiben, die vom PPES 211 dann unter Benutzung von Programmen in TOOLS 218, die für den Typ der UF 209 spezifisch sind, in das PKG 104 kopiert. Der Benutzer kann auch Daten vorschreiben, die das PPES 211 entsprechend der Vorschrift in PTYP 207 zum Erstellen einer Datei im PKG 104 benutzen kann, ebenfalls unter Verwendung von Programmen in TOOLS 208. Wenn ein Benutzer eine Datei im PKG 104 bearbeiten möchte, bestimmt das PPES 211 automatisch den Dateityp und stellt dem Benutzer die Programme aus TOOLS 208 zur Verfügung, die für die Art der Datei geeignet sind, wenn der Benutzer diese bearbeiten möchte.
Das PPES 211 erstellt den PD 105 im PKG 104 aus Informationen, die es von der PTL 205 und einer Benutzerprofildatei (UPF; Abk. für engl. user profile file) 201, die Informationen über Benutzer der LC 109 enthält, bekommen hat, und kann weitere Informationen vom Benutzer erhalten. Das PPES 211 bearbeitet den PD 105 wie die übrigen Dateien unter Benutzung von Programmen aus TOOLS 208. In einigen Fällen kann der Benutzer einfach seinen eigenen PD 105 schreiben, unter Verwendung von Programmen, die ihm PPES 211 aus TOOLS 208 bereitstellt.
Sobald der Benutzer einen PTYP 207 spezifiziert hat, die zum Erstellen des PD 105 benötigten Informationen bereitgestellt und die richtigen UF 209 spezifiziert hat, erstellt das PPES 211 das PKG 104, das den aus dem PTYP 207 und Kopien von UF 209 erstellten PD 105 enthält. Während der Erstellung des PKG 104 empfängt das PPES 211 eine eindeutige Identifizierung für das PKG 104 aus dem DTCS 225. Das PKG 104 ist das alleinige PKG 104 in der Vorrichtung 101 mit dieser Identifizierung und behält die gleiche Identifizierung, bis die Verarbeitung beendet und das PKG 104 zerstört ist.
Wenn das PKG 104 fertiggestellt ist, sendet das PPES 211 eine Nachricht an das PRMS 215 zur Anzeige der Existenz des PKG 104. Das PRMS 215 beginnt dann mit der Ausführung der Schritte im PD 105. Schreibt ein Schritt vor, daß das PKG 104 einem anderen LC 109 zuzuleiten ist, sendet das PRMS 215 das PKG 104 über das Mailsystem 107 an diesen LC 109. Nach dem Übersenden des PKG 104 wird es aus der PKGLIB 210 entfernt. An diesem LC 109 reagiert das PRMS 215 auf die Ankunft des PKG 104 durch Kopieren desselben in die PKGLIB 210 im LC 109. Daraufhin kann der Empfänger des PKG 104 das PPES 211 zum Verarbeiten des PKG 104 in der Weise benutzen, die im Zusammenhang mit der Erstellung des PKG 104 beschrieben wurde. Als Folge der Aufbereitung können auf den empfangenden LC 109 bezügliche Schritte zum PD 105 hinzugefügt werden, und diese lokalen Schritte können vom PRMS 215 ausgeführt werden. Wie mit weiteren Einzelheiten weiter unten erläutert wird, steht das PRMS 215 in Wechselwirkung mit dem DTCS 225, um zu bestimmen, ob ein PKG 104 gültig ist und ob für das PKG 104 ein Steuerbefehl ansteht.
Bei der Ausführung von Schritten an einem LC 109 verwendet das PRMS 215 eine Benutzerprofildatei (UPF) 201, Aufgaben 216 und Anwenderprogramme (APPS; Abk. für engl. application program) 223. Wenn eine Aufgabe 216 oder ein Anwenderprogramm 223 interaktiv ist, gibt sie bzw. es Daten an die UWS 213 und empfängt Daten von dieser. UPF 201 ist eine Datei, die Benutzerprofildatensätze (UPR; Abk. für engl. user profile record) 203 für alle Benutzer des LC 109 enthält, die Nachrichten über das Mailsystem empfangen können. In den Datensätzen sind Informationen wie z. B. Titel des Benutzers und aktueller Supervisor enthalten. Somit kann der PD 105 die bei der Verarbeitung eines PKG 104 Beteiligten nach Titel oder Stellungsbeziehung angeben. Wenn das PRMS 215 den PD 105 verarbeitet, benutzt es die UPF 201, um Titel oder Stellungsbeziehungen in einen Benutzer des LC 109 aufzulösen. Der PD 105 kann eine Verarbeitung entweder direkt durch PRMS 215 oder durch eine Aufgabe 216 vorschreiben, mit der das PRMS 215 über das Mailsystem im Verkehr steht. Im erstgenannten Fall führt das PRMS 215 ein Programm aus den APPS 223 aus; im zweiten Fall sendet das PRMS 215 eine Nachricht an die Aufgabe 216, und die Aufgabe 216 führt die Verarbeitung aus. Häufig beinhaltet die Verarbeitung die Ausgabe von Schirmbildern mit Daten an einer UWS 213 und den Empfang von Daten von einer UWS 213. In beiden Fällen kann die Verarbeitung selbstverständlich zu Änderungen oder Ergänzungen der Daten 103 im PKG 104 führen. Der PD 105 kann ferner vorschreiben, daß das PRMS 215 Paketkopien (PKGC; Abk. für engl. package copy) 217 vom PKG 104 erzeugt, Sicherungspakete (PKGB; Abk. für engl. backup package) 219 vom PKG 104 oder Archivpakete (PKGA; Abk. für engl. archive package) 221 vom PKG 104. Die PKGC 217 werden in den Fällen benutzt, in denen eine parallele Verarbeitung nützlich ist. Jede PKGC 217 ist eine exakte Kopie des PKG 104 zum Zeitpunkt der Erstellung der Kopie, aber jede erhält eine eigene, eindeutige Kennzeichnung, die angibt, daß sie eine Kopie für die Parallelverarbeitung ist. Die Verarbeitung jeder der Kopien setzt sich ab dem Zeitpunkt, in dem die Kopien erstellt wurden, unabhängig fort. Sicherungspakete 219 sind Kopien des PKG 104, die vor kritischen Operationen oder um eine Korrekturmöglichkeit zu schaffen erstellt werden. Mißlingt eine Operation, nachdem eine PKGB 219 erstellt ist, findet das DTCS 225 die PKGB 219 auf und startet die Verarbeitung neu unter Verwendung der PKGB 219 anstelle des verlorenen oder beschädigten Original-PKG 104. Archivpakete 211 sind schließlich Kopien des PKG 104, die für Archivierungszwecke erstellt worden sind. Diese Kopien werden durch die Vorrichtung 101 nicht weiter verarbeitet.
Wie sein Name schon andeutet, hat das DTCS 225 sowohl Verfolgungs- als auch Steuerungsfunktionen. Als Teil der Verfolgungsfunktion vergibt das DTCS 225 das eindeutige Kennzeichen an das PKG 104, verfolgt das PKG 1ß4 während seiner Verarbeitung, bestätigt, daß eine Übertragung stattgefunden hat, pflegt die CTLDB 227, benachrichtigt das ENRS 229 über von ihm festgestellte Fehler und liefert Informationen über den Zustand von PKG 104 an Benutzer der Vorrichtung 101. Als Teil der Steuerungsfunktion empfängt das DTCS 225 Steuerbefehle von Benutzern, sendet sie an den LC 109, an dem das PKG 104 aktuell verarbeitet wird, und gibt die empfangenen Steuerbefehle an das PRMS 215 zur Ausführung weiter. Das PRMS 215 überprüft die Übereinstimmung mit DTCS 225 bezüglich Steuerbefehle bei Ankunft des PKG 104 am LC 109 und bevor es das PKG 104 zum nächsten LC 109 sendet. Im erstgenannten Fall führt das PRMS 215 die Steuerbefehle aus, bevor es eine weitere Verarbeitung am LC 109 vornimmt, und im an zweiter Stel le genannten Fall führt es die Steuerbefehle aus, bevor es das PKG 104 zum nächsten LC 109 sendet. Das PRMS 215 kann auf Steuerbefehle auch nach einem Zeitintervall überprüfen, das in einem Steuerbefehl oder im PD 105 angegeben ist.
Bei einer bevorzugten Ausführungsform enthalten die Steuerbefehle einen Beendigungsbefehl, auf den das PRMS 215 durch Beenden der Verarbeitung des PKG 1ß4 reagiert, einen Umsteuerungsbefehl, auf den das PRMS 215 durch Umleiten des PKG 104 an einen verschiedenen LC 109 reagiert, einen Sicherungsbefehl, auf den das PRMS 215 durch Erstellen eines PKGB 219 reagiert, einen Neustartbefehl, auf den das PRMS 215 durch Feststellen eines durch die Vorrichtung 101 erstellten Sicherungspakets 219 und durch Neustarten der Verarbeitung unter Verwendung dieses Sicherungspakets reagiert, Zeitbeschränkungsbefehle, die eine auszuführende Aktion vorschreiben, wenn eine bestimmte Zeitdauer verstrichen ist, einen Unterbrechungsbefehl, der die Ausführung des RT 315 unterbricht, einen Wiederaufnahmebefehl, der die Ausführung des RT 315 wiederaufnimmt, und einen Löschbefehl, der Verweise auf ein PKG 104 aus der CTLDB 227 entfernt. Andere Ausführungsformen können zusätzliche Steuerbefehle nötig machen.
Informationen über den Standort und den Zustand des PKG 104 sind in einer Steuerungsdatenbank (CTLDB; Abk. für engl. control data base) 227 enthalten. In jedem LC 109 besteht eine lokale CTLDB 227. Außerdem können bei einer bevorzugten Ausführungsform Gruppen von LC 109 eine Gruppen-CTLDB 227 aufweisen, und das gesamte System kann eine Zentral-CTLDB 227 haben. Die Gruppen- und Zentral-CTLDB 227 vereinigen die Informationen aus den lokalen CTLDB 227. An jedem LC 109 liefert das DTCS 225 Zustandsinformationen an eine UT 212 und empfängt von dieser Steuerbefehle von Benutzern über Nachrichten. Befindet sich das PKG 104 am lokalen LC 109, wird die Zustandsinformation direkt von der lokalen CTLDB 227 empfangen, und die Steuerbefehle werden direkt an das lokale DTCS 225 abgegeben. Befindet sich das PKG 104 anderswo, be nutzt das lokale DTCS 225 die Gruppen- und Zentral-CTLDB 227, um den LC 109 zu ermitteln, der aktuell das PKG 104 verarbeitet. Es verlangt dann von dem DTCS 225 an diesem LC 109 Zustandsinformationen oder gibt an es Steuerbefehle ab. Bei anderen Ausführungsformen kann zusätzlich zu den lokalen CTLDB 227 eine einzige Zentral-CTLDB 227 bestehen.
Das Fehler-Meldungs- und -Korrektur-System 229 behandelt Fehler, die vom PRMS 215, APPS 223, DTCS 225 oder von Benutzern im Laufe der Verarbeitung festgestellt werden. Zu Fehlern zählen Duplikat-PKG 104, beschädigte PKG 104 oder verlorengegangene PKG 104. Wenn ein Fehler festgestellt wird, benachrichtigt die Komponente der Vorrichtung 101, die den Fehler feststellt, das ENRS 229, das seinerseits dem DTCS die Art und Weise mitteilt, in der der Fehler zu behandeln ist. In einigen Fällen kann das ENRS 229 den Fehler ohne Hilfe behandeln; in anderen Fällen benötigt das ENRS 229 Hilfe von einem Benutzer, Hilfe, die es empfängt, indem es eine Nachricht an die richtige UT 212 sendet. Wenn beispielsweise ein PKG 104 verlorengegangen ist, wird dieser Umstand in der weiter oben beschriebenen Weise vom DTCS 225 im letzten LC 109 festgestellt, der das PKG 104 hätte weitersenden sollen. Dieses DTCS 225 informiert das ENRS 229, daß das PKG 104 verloren ist. Das ENRS 229 erfragt dann beim DTCS 225 den Ziel-LC 109 für das PKG 104. Ist das PKG 104 tot, oder wenn das DTCS 225 am Ziel-LC 109 einen Befehl erhalten hat, es zu beenden, bestimmt das ENRS 229 dann, ob das PKG 104 aus einer PKGB 219 neugestartet werden soll. Das ENRS 229 kann sich bei dieser Bestimmung Informationen bedienen, die dem Paket-Typ zugeordnet sind, oder durch Anfragen bei einem Benutzer über die UWS 213. Soll die PKGB 219 neugestartet werden, fordert das ENRS 229 das DTCS 225 auf, den Standort der allerletzten Sicherung festzustellen, und gibt dann einen Sicherungs- und Neustartbefehl, der dem DTCS 225 diese Sicherung mitteilt. Als Reaktion auf den Befehl ersetzt das PRMS 215 das verlorengegangene Paket durch die PKGB 219. Je nach den Umständen kann das PRMS 215 alle Schritte im PD 105 ausführen, die dem Schritt folgen, in dem die Sicherung erstellt wurde, oder kann einfach die PKGB 219 an die Stelle weiterleiten, an der das Originalpaket verlorengegangen ist.

3. Einzelheiten des PKG 104; Fig. 3, 3A und 3B

Fig. 3 ist ein Diagramm des PKG 104 in einer bevorzugten Ausführungsform der Vorrichtung 101. Das PKG 104 hat zwei Teile: Daten 103 und den Verarbeitungsdeskriptor (PD) 105. Um mit den Daten 103 zu beginnen: Diese bestehen aus Paketdatendateien (PDF; Abk. für engl. package data file) 301. Eine PDF 301 kann jede Art von Datei sein, die ein LC 109 im Rechnersystem behandeln kann. Zu Beispielen von PDF 301, die in einem üblichen PKG 104 vorhanden sein können, gehören Textverarbeitungsdokumente (WPDOC; Abk. für engl. word processing document) 323, Dokumentenabbilder (IMAGE) 325, Kalkulationstabellen (SS; Abk. für engl. spread sheet) 327, Datenbanktabellen (DBTAB; Abk. für engl. date base table) und Datenbankanfragen (DBQ; Ab. für engl. data base query) 330. Die Anfragen können auf Tabellen in der DBTAB 329 oder in den LC 109 laufen, die das PKG 104 verarbeiten werden. Ein PKG 1ß4 kann auch Dateien aufweisen, die der Verwendung durch die Vorrichtung 101 vorbehalten sind. Eine solche Datei ist eine Protokolldatei (LOG) 331, in der eine Liste der Empfänger für PKG 104 aufgezeichnet ist, deren Reaktionen auf das PKG 104, und die Zeitpunkte, an denen die Reaktionen geschehen sind. Unter Benutzung des PPES 211 kann der aktuelle Empfänger des PKG 104 in die LOG 331 einblicken, um festzustellen, wie andere Empfänger auf PKG 104 reagiert haben, und wenn der aktuelle Empfänger reagiert, wird seine Reaktion in der LOG 331 aufgezeichnet.
Wie bei anderen Dateien kann der Zugriff auf einzelne PDF 301 gesteuert werden. Beispielsweise kann es allen Empfängern eines PKG 104 erlaubt sein, eine bestimmte PDF 301 zu lesen, aber nur bestimmten Empfängern kann es erlaubt sein, die PDF 301 zu ändern. Operationen an den PDF 301 in den einzelnen LC 109 werden unter Benutzung der Hilfsmittel durchgeführt, die in den LC 109 für die Behandlung eines vorgegebenen Typs einer PDF 301 verfügbar sind. Wenn beispielsweise die PDF 301 ein WPDOC 323 ist, kann ein Empfänger, der den ordnungsgemäßen Zugriff hat, zum Aufbereiten der PDF 301 einen Textverarbeitungeeditor benutzen, und wenn die PDF 301 eine DBTAB 329 ist, kann der Empfänger das Datenbanksystem des LC 109 zum Bearbeiten der DBTAB 329 benutzen. Die PDF 301 werden in ein PKG 104 durch das PPES 211 eingebracht, das Dateien, die von einem Absender oder von Empfängern des PKG 104 vorgeschrieben sind, in das PKG 104 kopiert.
Weiter mit dem PD 105: In der bevorzugten Ausführungsform ist der PD 105 eine Datei. Die Datei enthält die nachstehend genannten Hauptkomponenten:
HDR 333, eine Information, nach der die Vorrichtung 101 ein spezielles PKG 104 im System erkennt.
PINFO 318, eine Information, die benutzt wird, um zu bestimmen, auf welche Weise das PKG 104 zu verarbeiten ist.
Das HDR (Abk. für engl. header; Kopfetikett) 333 ist mit Einzelheiten in Fig. 3A dargestellt. Es gibt drei Hauptkomponenten: Erkennungsinformation (IDINFO; Abk. für engl. identification information) 304, die Informationen enthält, an denen das PKG 104 von der Vorrichtung 101 erkannt wird; Prüfpfad (AT; Abk. für engl. audit trail) 321, der die Verarbeitung aufzeichnet, die das PKG 104 bis zum augenblicklichen Zeitpunkt erfahren hat, und PDIR 337, das ein Verzeichnis (engl. directory) der PDF 301 im PKG 104 ist.
Es sei mit IDINFO 304 begonnen: SYSNO 330 bezeichnet die Vorrichtung 101, in der das PKG 104 verarbeitet wird; HDRV 341 bezeichnet die Version vom HDR 333. PT 311 bezeichnet den Typ des PKG 104. Die Vorrichtung 101 benutzt den PT 311, um das PKG 104 einer Umgebung im LC 109 zuzuordnen, die für den vorgegebenen Typ des PKG 104 geeignet ist. PTV 343 ist eine Typ- Versionszahl. Die Verwendung der Versionszahl ermöglicht es den Benutzern der Vorrichtung 101, sich einen Typ zu merken, während neue Implementierung von ihm ausgeführt werden.
Die Beziehung zwischen einem Pakettyp und einer Umgebung ist in Fig. 3B dargestellt. Wenn ein PKG 104 eines bestimmten Typs in einem LC 109 verarbeitet wird, macht die Verarbeitung Anwenderprogramme, Prototypen, HILFE-Schirmbilder und eine Datenbank erforderlich. Die Anwenderprogramme sind in einer Anwenderprogramm-Bibliothek (APPL; Abk. für engl. application program library) 305 gespeichert, wobei Anwenderprogramme für einen speziellen Pakettyp in TAPPR 359 gespeichert sind. Ein Typindex (TI) 357 ermöglicht es dem PRMS 215 im LC 109, das TAPPR 359 aufzufinden. Auf ähnliche Weise ermöglicht der TI 357 in einer Prototyp-Bibliothek (PTL; Abk. für engl. prototype library) 361 das Auffinden von Typ-Prototypen (TPTYP) 363 für den Pakettyp; TI 357 in der HILFE-Bibliothek (HELPL) ermöglicht das Auffinden von THELP-Dateien 367, die Informationen enthalten, die von Benutzern von LC 109 benötigt werden, die PKG 104 des fraglichen Typs verarbeiten, und TI 357 in einer Datenbank-Bibliothek (DBL; Abk. für engl. data base library) 369 ermöglicht das Auffinden von Datenbanken im LC 109, auf die PKG 104 des Typs Zugriff haben und die hier als TDB 371 bezeichnet sind. TAPPR 359, TPTYP 363, THELP 367 und TDB 371 ergeben zusammen die Typumgebung (TENV; Abk. für engl. type environment) 353.
PKGKEY (Abk. für engl. package key; Paketschlüssel) 303 ist das eindeutige Kennzeichen, an dem die Vorrichtung 101 ein PKG 104 ab seiner Erstellung bis zu seiner Zerstörung erkennt. PKGKEY 303 hat drei Komponenten:
PKGID (Abk. für engl package identification; Paketkennzeichnung) 305 ist das eindeutige Kennzeichen, das das DTCS 225 dem PPES 211 bei der Erstellung des PKG 104 be reitstellt. Alle Kopien und Wiederanläufe des PKG 104 haben dieselbe PKGID 305.
PKGIX 307 ist der Index von PKG 104. Jede Kopie vom PKG 104, die zum Zwecke der weiteren Verarbeitung gemacht wird, wird vom Original und von anderen Kopien durch die Indexzahl in PKGIX 307 unterschieden.
PKGRV (Abk. für engl. package restart version; Paket- Neustartversion) 309 ist die Nummer der Paket-Neustartversion. Bei jedem Neustart des PKG 104 erhält das neue Paket eine verschiedene Versionsnummer im PKGRV 309.
Jede der vorstehend genannten Nummern wird von dem lokalen DTCS 225 vergeben, an dem das PKG 104 erstellt, geteilt oder neugestartet wird. Die Eindeutigkeit der Nummern ist dadurch gesichert, daß jedem LC 109 ein Kennzeichen gegeben wird, das im System, in dem die Vorrichtung 101 implementiert ist, nur einmal vorkommt, und daß das Kennzeichen des LC 109 als Vorsatz zu Zahlen verwendet wird, die ein Vorwärtszähler im LC 109 erzeugt.
Eingabeparameter (IP; Abk. für engl. input parameter) 313 sind Parameter, die Benutzer liefern, welche ein PKG 104 erstellen oder verarbeiten. Zweck der Parameter ist es, Namen zu vergeben, an denen Benutzer ein PKG 104 erkennen können; und die sie an das DTCS 225 geben können, wenn sie ein PKG 104 aufzufinden wünschen. Bei einem Bestell-Prozeß, beispielsweise, können zu den Parametern gehören der Name des Kunden, der die Bestellung aufgegeben hat, der Name seines Verkäufers, der Sitz des Verkaufsbüros, die Auftragsnummer usf.
AT 321 ist ein Prüfpfad für das PKG 104. Im At 321 bezeichnet PO (Abk. für engl. package originator) 345 den Absender des PKG 104, CRD (Abk. für engl. creation date) 347 den Zeitpunkt der Erstellung des PKG 104, und COMPD (Abk. für engl. comple tion date) 349 den Zeitpunkt der Beendigung der Verarbeitung vom PKG 104. Schließlich ist EXEC REC 351 eine Darstellung der am PKG 104 bereits ausgeführten Schritte und das Ergebnis der Ausführung der Schritte. War im Schritt eine Verzweigung erforderlich, gibt EXEC REC 351 für den Schritt an, welche Verzweigung tatsächlich ausgeführt wurde. Wenn bei der Ausführung eines Schrittes eine Fehlermeldung rückübertragen worden ist, wird die Fehlernummer für die Meldung dem Schritt in EXEC REC 351 zugeordnet. Der AT 321 wird vom PRMS 215 gepflegt und durch das DTCS 225 benutzt, um den gegenwärtigen Zustand des PKG 104 zu bestimmen.
Das Paketverzeichnis (PDIR) 337 ist ein Verzeichnis der Dateien im PKG 104. Es gibt für jede Datei den Titel, den Typ und den Dateinamen an. Alle zu einem PKG 104 gehörenden Dateien werden in einer Datei-Systembibliothek bewahrt, die für das PPES 211 und das PRMS 215 während der Bearbeitung eines PKG 104 in einem LC 109 zugänglich sind, und der Dateiname gibt diese Systembibliothek an.
Zurück zu Fig. 3 und weiter mit PINFO 318: Der Leitweg (RT; Abk. für engl. route) 315 schreibt die LC 109 vor, an die das PRMS 215 das PKG 104 leiten soll, und die Schritte, die an jedem LC 109 ausgeführt werden sollen. Im LC 109 kann das PRMS 215 einen Schritt direkt ausführen, indem es ein Programm von APPS 223 durchführt, oder den Schritt ausführen durch Senden einer Nachricht an eine Mailbox, die einer Aufgabe 216 im LC 109 zugeordnet ist, und durch Warten auf eine Rückmeldung. In vielen Fällen wird die Aufgabe 216 interaktiv sein, d. h. sie wird in Reaktion auf die Nachricht ein Programm abarbeiten, das an der UWS 213 ein Schirmbild anzeigt und Eingaben von der UNS 213 erhält. Daten, die sich aus der Operation ergeben, können dann an das PRMS 215 zur Verwendung bei der Bestimmung des als nächster auszuführenden Schrittes zurückgesandt werden. In Fig. 3 stellt CS 317 den laufenden, d. h. den Schritt im RT 315 dar, der vom PRMS 215 augenblicklich ausgeführt wird. Ein Streckenzähler (RC; Abk. für engl. route counter) 319 in den PINFO 318 gibt stets den Ort des CS 317 an und wird folglich am Ende der Durchführung jedes Schrittes aktualisiert, um auf den nächsten Schritt im RT 315 zu zeigen. Bei einer bevorzugten Ausführungsform können bestimmte Empfänger des PKG 104 Zugriff auf den RT 315 haben. Unter Benutzung einer Leitweg-Editor-Komponente des PPES 211 können solche Empfänger den Teil des RT 315 ändern, der noch nicht ausgeführt worden ist.

4. Einzelheiten der CTLDB 227; Fig. 4 und 5

Wie weiter oben erwähnt, bewahrt das DTCS 225 die Informationen, die es benötigt, um die Pakete PKG 104 in der Steuerungsdatenbank (CTLDB) 227 zu verfolgen und zu steuern. Bei der bevorzugten Ausführungsform ist die CTLDB 227 eine Datenbank-Hierarchie. Die Hierarchie ist in Fig. 5 dargestellt. Die unterste Ebene der Hierarchie ist eine lokale CTLDB (LCTLDB; Abk. für engl. local control data base) 401. Jeder LC 109 hat eine ihm zugeordnete LCTLDB 401, welche die Pakete PKG 104 verfolgt, die in der Vorrichtung 101 noch bestehen und die durch diesen LC 109 verarbeitet worden sind oder aktuell verarbeitet werden. Eine Anzahl LC 109 kann als eine Gruppe (GRP; Abk. für engl. group) 501 behandelt werden. Jeder GRP 501 ist eine Gruppen-CTLDB (GCTLDB) 503 zugeordnet, die verfolgt, welche LC 109 in der GRP 501 jedes PKG 104 verarbeitet haben oder verarbeiten, und die Reihenfolge festhält, in der sie das PKG 104 verarbeitet haben. Die GCTLDB 503 ist einem der LC 109 in der GRP 501 physikalisch zugeordnet. Die höchste Ebene der Hierarchie ist eine zentrale CTLDB (CCTLDB; Abk. für engl. central control data base) 505, die verfolgt, welche GRP 501 jedes PKG 104 verarbeitet hat oder verarbeitet, und die Reihenfolge dieser Verarbeitung festhält. Die CCTLDB 505 ist einem der LC 109 physikalisch zugeordnet und vervollständigt so das Gesamtsystem, in dem die Vorrichtung 101 implementiert ist.
Die Hierarchie wird zum Lokalisieren eines PKG 104 folgendermaßen benutzt: Das DTCS 225, das den Zustand des PKG 104 festzustellen versucht, sucht zuerst in der LCTLDB 401, die dem LC 109 des DTCS 225 zugeordnet ist. Liegt dort keine Aufzeichnung über das PKG 104 vor, sendet das suchende DTCS 225 eine Nachricht an das DTCS 225 an dem LC 109, der die GCTLDB 503 für die GRP 501 aufweist, zu der das suchende DTCS 225 gehört. Gemäß Fig. 5 enthält die GCTLDB 503 eine GVREC 507 für jedes PKG 104, das in der GRP 501 bearbeitet worden ist. Jede GVREC 507 enthält den PKGKEY 303 für das PKG 104, das durch die GVREC 507 dargestellt ist, und eine Liste (LCHLIST; Abk. für engl. locus of control list) 511 der LC 109, die das PKG 104 in der GRP 501 bearbeitet haben. Die Liste ist in der Reihenfolge angelegt, in der das PKG 104 in den LC 109 bearbeitet worden ist.
Liegt dort eine Aufzeichnung über das PKG 104 vor, sendet dieses DTCS 225 eine Nachricht an das suchende DTCS 225 zurück, in der der LC 109 angegeben ist, der aktuell verarbeitet. Liegt keine Aufzeichnung vor, sendet dieses DTCS 225 die Suchnachricht an das DTCS 225, das die CCTLDB 505 hat. In der CCTLDB 505 steht eine Aufzeichnung für jedes PKG 104, das gegenwärtig im System 101 aktiv ist. Die Aufzeichnungen in der CCTLDB 505 sind den GVREC 507 ähnlich, mit der Ausnahme, daß die Liste eine Liste von GRP 501 ist, in denen das PKG 104 bearbeitet worden ist. Die GCTLDB 503 und die CCTLDB 505 sind beide so ausgelegt, daß die Aufzeichnungen mit dem PKGKEY 303 für ein PKG 104 aufgefunden werden können.
Da die Aufzeichnung für das PKG 104 in der CCTLDB 505 die GRP 501 angibt, die das PKG 104 enthält, sendet das DTCS 225 die Nachricht weiter an das DTCS 225 für die GCTLDB 503 dieser GRP 501, und diese DTCS 225 sendet die Nachricht weiter an das DTCS 225 für den das PKG 104 gegenwärtig verarbeitenden LC 109, welches das PKG 104 in der LCTLDB 401 des LC 109 auffindet. In einigen Fällen kann das PKG 104 den LC 109 zu dem Zeitpunkt verlassen haben, wenn die Nachricht dort eintrifft; in diesem Falle gibt die Aufzeichnung über die Bearbeitung in der LCTLDB 401 den nächsten LC 109 an, und das DTCS 225 sendet die Nachricht zu diesem LC 109. Wenn die Nachricht angibt, daß das suchende DTCS 225 den Zustand des PKG 104 erfahren möchte, gibt das DTCS 225 für den das PKG 104 gegenwärtig verarbeitenden LC 109 den Zustand an das suchende DTCS 225 zurück; enthält die Nachricht einen Steuerbefehl, gibt das lokale DTCS 225 den Steuerbefehl in die LCTLDB 401 ein. Bei anderen Ausführungsformen können nur LCTLDB 401 vorhanden sein, und suchende DTCS 225 können ihre Nachricht einfach an alle anderen DTCS 225 übermitteln. Das DTCS 225 für den gegenwärtig das PKG 104 verarbeitenden LC 109 wird dann einfach die in der Nachricht vorgeschriebene Operation ausführen.
Fig. 4 zeigt ein detailliertes Schaubild einer LCTLDB 401. Die LCTLDB 401 besteht aus einer CTLDB-Datei (CTLDBFI; Abk. für engl. control data base file) 405, die Bearbeitungsaufzeichnungen (VREC; Abk. für engl. visit record) 407 enthält, die je eine einzelne Bearbeitung eines einzelnen PKG 104 in dem LC 109 darstellen, dem die LCTLDB 401 zugeordnet ist, und einen CTLDB-Index (CTLDBIX; Abk. für engl. control data base index) 402, der ein Index zu den Aufzeichnungen VREC 407 in der CTLDBFI 405 ist. Der CTLDBIX 402 hat zwei Ebenen. Die erste Ebene, Parameterindex (PIX) 427, bezieht sich auf die Eingabeparameter (IP) 313, die ein PKG 104, das im LC 109 bearbeitet worden ist, an dem PKGKEY 303 für das PKG 104 erkennen. Somit enthält jeder Parameterindexeintrag (PIE) 429 eine der Angaben Eingabeparameter (PAR) 431 und PKGKEY 303. Die PIE 429 im PIX 427 sind nach dem Wert der PAR 431 geordnet, und folglich kann ein PIE 429, der einen vorgegebenen PAR 431 enthält, auf einfache Weise mit in der Fachwelt bekannten Suchtechniken festgestellt werden. Sobald der PIE 429 aufgefunden ist, wird der PKGKEY 303 benutzt, um einen Schlüsselindexeintrag (KIE; Abk. für engl. key index entry) 404 im Schlüsselindex (KIX; Abk. für engl. key index) 403 aufzufinden. Der KIE 404 enthält den PKGKEY 303 und einen VPTR 425, einen Zeiger auf die erste VREC 407 in einer Kette von VREC 407, die Bearbeitungen des PKG 104 in LC 109 darstellen. Die KIE 404 sind im KIX 403 nach dem Wert des PKGKEY 303 geordnet, wodurch der KIE 404 für einen bestimmten PKGKEY 303 mittels verschiedener bekannter Suchtechniken einfach auffindbar ist. Auf GCTLDB 503 und CCTLDB 505 wird erst verwiesen, nachdem der PKGKEY 303 aus einer LCTLDB 401 erhalten worden ist, und folglich weisen diese Datenbanken nur einen KIX 403 auf.
Eine VREC 407 für eine bestimmte Bearbeitung eines PKG 104 durch einen LC 109 enthält die nachstehend angegebenen Informationen:
PKGKEY 303 für das durch den VREC 407 dargestellte PKG 104;
TOA 411 Zeitpunkt der Ankunft des PKG 104 für die durch den VREC 407 im LC 109 dargestellte Bearbeitung;
TOD 413 Zeitpunkt des Verlassens durch das PKG 104 nach der Bearbeitung;
DEST 415 der LC 109 und dessen Mailbox, wohin das PKG 104 weitergeleitet worden ist. Das DTCS 225 benutzt dieses Feld, um Nachrichten weiterzuleiten, die ankommen, nachdem das PKG 104 den LC 109 verlassen hat.
STALIST 417 die Liste der Mailboxen im LC 109, an die das PKG 104 durch das PRMS 215 während der Verarbeitung geleitet worden ist. Jeder Eintrag in der Liste enthält den Namen der Mailbox, den Zeitpunkt der Ankunft in der Mailbox, Zustandsmeldungen, die aus der Mailbox zurückgesandt worden sind, und der Zeitpunkt des Rücksprungs von der Mailbox;
PKGBLOC 419 die Standorte von Sicherungspaketen 219, die während der Bearbeitung erstellt worden sind;
CTLMESS 421 das PKG 104 betreffende, im DTCS 225 während der Bearbeitung empfangene Steuerungsnachrichten; und
NPTR 423 der Ort in der CTLDBFI 405 der VREC 407 für die nächste Bearbeitung des PKG 104 im LC 109.
Wenn ein PKG 104 in einem LC 109 ankommt, erstellt das DTCS 225 eine VREC 405 und notwendige Einträge im CTLDBIX 402 für das PKG 104. Außerdem sendet das DTCS 225 eine Nachricht an das DTCS 225, das der GCTLDB 503 der GRP 501 zugeordnet ist, zu welcher der LC 109 gehört, welche die Ankunft des PKG 104 beim LC 109 angibt. Schließlich, wenn die GCTLDB 503 angibt, daß das PKG 104 in der GRP 501 neu eingetroffen ist, sendet das DTCS 225, das der GCTLDB 503 zugeordnet ist, eine Nachricht an das der CCTLDB 505 zugeordnete DTCS 225, die das Eintreffen des PKG 104 in der GRP 501 anzeigt. Um die Arbeitsweise der Vorrichtung 101 wirkungsvoller zu gestalten, können diese Nachrichten nicht sofort an die betreffenden Datenbanken gesendet werden, sondern können gesammelt und in einem Schub gesendet werden. Die Datenbanken GCTLDB 503 und CCTLDB 505 werden folglich nicht immer auf dem laufenden sein, aber, wie weiter oben angegeben, das Feld DEST 415 in der VREC 407 für eine Bearbeitung ermöglicht es, daß eine Nachricht einem PKG 104, das einen bestimmten LC 109 bereits verlassen hat, folgen kann.
Aus den vorstehenden Beschreibungen ergibt sich, daß die CTLDB 227 es dem DTCS 225 nicht nur ermöglicht, Pakete PKG 104 an beliebiger Stelle im System der Vorrichtung 101 aufzufinden, sondern auch ein PRMS 215 zu veranlassen, einen Steuerbefehl auszuführen bei Ankunft eines PKG 104 im LC 109 oder beim Verlassen desselben durch das PKG 104, und ermöglicht es dem DTCS 225, die Prüfpfadinformation in AT 321 eines PKG 104 mit der Information in der VREC 407 zu vergleichen, um zu bestimmen, ob ein PKG 104 beschädigt worden ist oder ob es ein Duplikat ist. Wenn beispielsweise ein PKG 104 an einem LC 109 eintrifft, der bereits eine VREC 407 für das PKG 104 hat, vergleicht das DTCS 225 den AT 321 mit dem Inhalt der STALIST 417. Wenn der AT 321 eine vorherige Bearbeitung im LC 109, dessen Schritte die in der STALIST 417 vorgeschriebenen Mailboxen enthält, nicht angibt, kann das PKG 104 ein Duplikat sein. In dieser Situation blockiert das DTCS 225 eine weitere Verarbeitung des PKG 104 und benachrichtigt das ENRS 229 über die Fehlerbedingung. Das ENRS 229 kann dann an das DTCS 225 einen Steuerbefehl zur Beendigung des PKG 104 senden.

5. Einzelheiten der Verarbeitungsinformation (PINFO) 318; Fig. 6 und 7

Fig. 6 ist ein Diagramm der PINFO 318, dem Teil des Verarbeitungsdeskriptors 105, der vorschreibt, auf welche Weise das PRMS 215 in jedem vorgeschriebenen LC 109 das PKG 104 zu verarbeiten hat. In einer bevorzugten Ausführungsform hat PINFO 318 wenigstens die nachstehenden Komponenten: RT 315 und eine Steuerungsaufzeichnung (CTLREC; Abk. für engl. control record) 335. Der RT 315 enthält stets GRT 605, einen Teil des RT 315, der das PKG 104 zu jedem LC 109, der es bearbeiten will, begleitet und folglich die Verarbeitung des PKG 104 auf der höchsten Ebene vorschreibt. Zusätzlich können ein oder mehrere lokale Leitwege (LRT) 617 aus dem GRT 605 oder von einem anderen LRT 617 in einem LC 109 heraus ausgeführt werden.
Der GRT 605 und jeder LRT 617 besteht aus einer Folge von Anweisungen 607. Bei einer bevorzugten Ausführungsform sind die Anweisungen Folgen von ASCII-Zeichen, die vom PRMS 215 interpretiert werden. Die Anweisungen können Verweise auf Daten und Programme in APPS 223 enthalten. Bei einer bevorzugten Ausführungsform gibt es fünf Arten Verweise: gleichbleibende Verweise (CREF; Abk. für engl. constant reference) 609, die sich auf Werte beziehen, die bei jeder Ausführung eines Leitweges gleichbleiben; veränderliche Verweise (VREF) 615, die sich auf Werte beziehen, die sich während der Ausführung eines Leitweges verändern; Paketverweise (PREF) 611, die Nur- Lese-Verweise auf Datenfelder in einer oder mehreren der PDF 301 sind, die zusammen die Daten 103 im PKG 104 bilden; Kopfetikettenverweise (HREF; Abk. für engl. header reference) 608, die unter Benutzung vordefinierter Namen auf Felder im HDR 333 verweisen; Anwenderprogrammverweise (APPREF; Abk. für engl. application program reference) 614, die Anwenderprogramme in APPS 223 aufrufen, und Mailboxverweise (MBREF) 610, die auf Mailboxen (Briefkasten) im elektronischen Mailsystem verweisen.
Die Daten, auf welche CREF 609 und VREF 615 verweisen, stehen in der CTLREC 335. Stehen die CREF 609 und die VREF 615 im GRT 605, stehen die Werte im GRTVARS 633. Wenn die Ausführung eines LRT 617 die eigene lokale Speicherung von Variablen erfordert, geschieht dies in LRTVARS 639. Wie in Fig. 6 dargestellt, enthält somit GRTVARS 633 CVAL 637, dargestellt durch CREF 609, und WAL 635, dargestellt durch VREF 615. Hinsichtlich der übrigen Verweistypen enthält die CTLREC 335 Deskriptoren, die das Auffinden der Werte ermöglicht, die durch die Verweise in HDR 333, PDF 301 oder APPS 223 dargestellt sind. Somit enthält eine Kopfetikettverweisinformation (HREFINFO; Abk. für engl. header reference info) 623 Kopfetikettverweisdeskriptoren (HREFD) 625, die das Auffinden von Kopfetikettwerten (HDRVAL) 641 im HDR 333, z. B. das PO-Feld 345 ermöglichen. Auf ähnliche Weise enthält eine Paketverweisinformation (PREFINFO; Abk. für engl. package reference info) 627 Paketverweisdeskriptoren (PREFD) 629, die das Auffinden von Paketwerten (PVAL) 601, z. B. Tabellenverweise (TREF) 602 in DBTAB 329 ermöglichen, und eine Anwenderprogrammverweisinformation (APPREFINFO) 631 enthält Anwenderverweisdeskriptoren (APPREFD) 633, mit denen das PRMS 215 Anwenderprogramme (APPR) 603 in APPS 223 aufrufen kann. Die Verweisinformationen werden durch das PPES 211 in die CTLREC 335 eingegeben, wenn ein PKG 104 erstellt oder ein RT 315 geändert wird.
Der übrige Teil der CTLREC 335 enthält Verwaltungsinformationen (ADMININFO) 619 und eine Liste der Steuerungsorte (LCLIST; Abk. für engl. locus of control list) 621. Die ADMININFO 619 schließt eine Kennzeichnung des zentralen Verwalters für den durch das Paket dargestellten Typ des Pakets 104 ein, nämlich den Namen des LOG 331, und bei Ausführungsformen, bei denen das DTCS 225 eine einzelne zentrale CTLDB 227 statt einer Hierarchie aufweist, den Namen des LC 109, an dem die CTLDB 227 steht.
Die LCLIST 621 enthält eine Liste aller LC 109, in denen eine Umgebung für diesen speziellen Pakettyp verwaltet wird. Der Eintrag für jeden LC 109 in der Liste bezeichnet ferner den lokalen Paketverwalter für Pakete dieses Typs an dem bestimmten LC 109. Wenn ein Empfänger eines PKG 104 den RT 315 ändert, benutzt das PPES 211 die LCLIST 621, um sicherzustellen, daß der geänderte RT 315 das PKG 104 nicht an einen LC 109 sendet, der für diesen Pakettyp keine Umgebung bereit-· hält. In ähnlicher Weise benutzt das PPES 211 die CTLREC 335, um die Richtigkeit der Verweise im geänderten RT 315 zu prüfen. ADMININFO 619 und LCLIST 621 werden beide beim Erstellen des PKG 1ß4 in die CTLREC 335 eingegeben.
Fig. 7 zeigt ein einfaches Leitweg-Beispiel 701. Je nach der Komplexität des mit der Vorrichtung 101 zu behandelnden Prozesses kann der Leitweg 701 entweder ein GRT 605 oder ein LRT 617 sein. Der Leitweg 701 definiert einen Prozeß, bei dem ein Paket, das eine Spesenbericht-Datei enthält, zuerst zum Vorgesetzten des Absenders zur Genehmigung gesendet wird, und, wenn die Genehmigung erhalten ist, dann zu dem für den Absender in Finanzfragen Zuständigen und zur Kreditorenbuchhaltung Wenn das Paket von dem für Finanzfragen Zuständigen zurückkehrt, wird eine Sicherungskopie des Pakets angelegt, und in der Kreditorenbuchhaltung wird eine Archivkopie erstellt.
Die hauptsächlichen syntaktischen Strukturelemente des Leitwegs 701 sind Kommentare, Anweisungen (STA; Abk. für engl. statement) 607, Anweisungslisten und -gruppen. Ein Kommentar (COMM; Abk. für engl. comment) 705 ist ein Teil eines Leitwegs 701, der vom PRMS 215 nicht interpretiert wird. Bei einer bevorzugten Ausführungsform sind Kommentare von dem Zeichen "!" eingeschlossen. Eine Anweisung (STA) 607 ist eine Folge von Schlüsselwörtern, vordefinierten Namen, benutzerdefinierten Namen und Ausdrücken. Ein vordefinierter Name ist ein Name, dessen Bedeutung Teil der Leitwegsprache ist, und ein benutzerdefinierter Name ist ein Name, dessen Bedeutung durch den Benutzer festgelegt ist. Eine Anweisungsliste ist ein Folge von Anweisungen, die mit einem Punkt beendet ist. Eine Gruppe von Anweisungen ist eine benannte Folge von Anweisungen, die mit einer Anweisung GRUPPE beginnt und mit einer Anweisung ENDE endet. Gruppen dienen zur Unterteilung des Leitwegs 701 zum Zwecke des Steuerungsflusses und der Fehlerbehandlung.
Zu Namen im Leitweg 701 gehören Namen wie z. B. ORIGINATOR (Absender), ORIGINATOR'S MANAGER (Vorgesetzter des Absenders), ORIGINATOR'S FINANCE REPRESENTATIVE (Für Finanzen Zuständiger des Absenders), CURRENT LOCATION (aktueller Standort), und ROUTE ADMINISTRATOR (Leitweg-Verwalter). Alle diese Namen werden in Verweise MBREF 611 aufgelöst. ORIGINATOR wird durch Verweis auf das PO-Feld 315 des HDR 333 aufgelöst und ist daher HDRREF 608, die in einen MBREF 611 aufgelöst wird. ORIGINATOR'S MANAGER und ORIGINATOR'S FINANCE REPRESENTATIVE werden aus der Benutzerprofildatei (UPF) 201 am LC 109 heraus, an dem PKG 104 erstellt worden ist, aufgelöst. Die Werte von der UPF 201 werden in einen GRTVARS 633 gebracht. CURRENT LOCATION ist der LC 109, an dem das PKG 104 aktuell bearbeitet wird, und CURRENT LOCATION'S ROUTE ADMINISTRATOR (Leitweg-Verwalter des aktuellen Standorts) löst sich in die Mailbox des aktuellen LC 109 auf, den die UPF 201 für diesen LC 109 als den Leitweg-Verwalter vorschreibt. Die Werte werden in ähnlicher Weise in den GRTVARS 633 gebracht. Ein Ausdruck setzt sich zusammen aus literalen Konstanten, Namen, die Werte aufweisen, und Operatoren, z. B. arithmetische, Vergleichs- und logische Operatoren.
Zu benutzerdefinierten Namen gehören SUCCESSFUL (erfolgreich) und FAILURE (Fehler), die benannte Konstanten (CON) 702 sind, und "manager approval" (Leiter-Genehmigung), der eine Variable (VREF 615) ist. ERA-FORM FORM-ID ist ein Paketverweis (PREF) 611. ERA-FORM ist der Name eines Datensatzes in der PDF 301, und FORM-ID ist der Name eines Datenfeldes in diesem Satz. Wie weiter oben erwähnt, sind die PREF 611 nur lesbar, d. h. der Leitweg 701 kann Werte von DF (Abk. für engl. data field) 603 benutzen, die in den PREF 611 vorgeschrieben sind, kann aber solche Werte nicht setzen. Ein Empfänger eines PKG 104 kann jedoch die Werte setzen und folglich kann eine Verarbeitung eines PKG 104 durch Änderungen in den PDF 301 bestimmt werden.
Die Anweisungen des Leitwegs 701 sind folgende:
DEFINE definiert SUCCESSFUL als benannte Konstante und setzt deren Wert auf 1. Auf diese Anweisung reagiert PRMS 215 durch Erstellen eines Platzes für den Wert je nach Fall in GRTVARS 633 oder LRTVARS 639, und durch Setzen des Platzes auf den Wert.
GROUP init und END init definieren die Anweisungen zwischen ihnen als eine mit "init" bezeichnete Gruppe.
TO ORIGINATOR'S MANAGER schreibt vor, daß das PRMS 215 das PKG 104 zur weiteren Verarbeitung an die Mailbox senden soll, die durch den vordefinierten Namen ORIGINATOR'S MANAGER bezeichnet ist. TO (zu = Ziel) hat die allgemeine Form TO < location> (Ziel-Standort), worin sich < location> in den Namen einer Mailbox auflöst.
RETURNS manager approval gibt an, daß das PRMS 215, das die Ziel-Anweisung ausgeführt hat, weitere Verarbeitung stoppen soll, bis PKG 104 zurückgekehrt ist. Bei Rückkehr wird die Variable "manager approval" einen Wert enthalten, der angibt, ob der Besitzer der durch ORIGINATOR'S MANAGER bezeichneten Mailbox es genehmigt hat. RETURNS wird im Leitweg 701 allgemein dort benutzt, wo die Durchführung der nächsten Anweisung warten soll, bis die Durchführung der vorherigen Anweisung beendet ist.
IF manager approval EQUAL FAILURE ist eine Sprunganweisung. Wenn der Wert von manager-approval gleich dem für FAILURE definierten Wert 2 ist, führt PRMS 215 die Anweisungsliste TO ORIGINATOR TERMI- NATE (zum Absender Beenden) durch; andernfalls führt es die Anweisungen ab TO ORIGINATORS' FINANCE REPRESENTATIVE durch.
TERMINATE (Beenden) beendet die Ausführung des Leitweges 701. Als Reaktion auf die Anweisung TERMINATE beendet PRMS 215 die Ausführung des Leitweges 701, entfernt PKG 104 und zeigt DTCS 225 an, daß das PKG 104 entfernt worden ist. DTCS 225 aktualisiert die CTLDB 227 auf die Anzeige, daß PKG 104 entfernt worden ist, und entfernt später als Reaktion auf einen Löschbefehl Verweise auf das PKG 104 in der CTLDB 227.
BACKUP (Sicherung) veranlaßt PRMS 215, eine Sicherungskopie (PKGB 219) des PKG 104 anzulegen. RETURNS gibt an, daß PRMS 215 nicht fortfahren soll, bis die Sicherung erfolgreich angelegt ist.
CHECKPOINT (Prüfpunkt) veranlaßt PRMS 215, eine Nachricht, daß die Anweisung ausgeführt worden ist, an DTCS 225 zu senden, das die LCTLDB 401 auf Ausführung der CHECKPOINT-Operation durch den LC 109, die GCTLDb 503 und die CCTLDB 505 auf Steuerbefehle überprüft, bevor es die Steuerung an PRMS 215 zurückgibt. PRMS 215 wird dann auf beliebige Steuerbefehle tätig.
EXECUTE ARCHIVE RETURNS store-status (Ausführen Archiv Rückkehr Speicher-Zustand) schreibt vor, daß PRMS 215 das Programm ARCHIVE aus APPS 223 ausführen und mit dem Rücksprung warten soll, bis die Ausführung beendet ist.
ELSE (sonst) gibt den Sprung der IF-Anweisung an, der auszuführen ist, wenn store-status nicht gleich 1 ist.
MESSAGE ""Archive failed on form" ERA-FORM FORM-ID "with a status of "store-status" ACCOUNTS PAYABLE ROUTE ADMI- NISTRATOR (Nachricht "kein Archiv für Formular" ERA- FORM. FORM-ID "mit einem Zustand von store-status" Kreditorenbuchhaltung Leitweg-Verwalter) gibt an, daß PRMS 215 an die durch ACCOUNTS PAYABLE ROU- TE ADMINISTRATOR dargestellte Mailbox eine Nachricht mit dem ID des Spesenformulars, für das eine Archivkopie nicht zustande gekommen ist, und dem durch das Archi vierprogramm zurückgegebenen Wert senden soll. Die Angaben zwischen den "-Zeichen sind in der Nachricht benutzte Zeichenketten.
ERROR ANY init (irgendwelcher Fehler init) gibt die Aktion an, die PRMS 215 ausführen soll, wenn bei der Ausführung der Anweisungen in der "init"-Gruppe Fehler auftreten. Andere ERROR-Anweisungen können Aktionen für spezielle Fehler vorschreiben, die bei der Ausführung von "init" auftreten.
AFTER 02/00/00 init (nach 02/00/00 init) gibt die Aktion an, die PRMS 215 ausführen soll, wenn während der Ausführung der "init"-Gruppe mehr als 2 Tage verstreichen. 02/00/00 ist eine Zeitvorschrift des Typs DD/HH/mm (Tag/Stunde/Minute) für die Angabe der abgelaufenen Zeit.
Zu Anweisungen, die in dem Leitwegbeispiel 701 nicht verwendet werden, gehören:
eine Zuordnungs-Anweisung, auf welche PRMS 215 durch Zuordnen eines Wertes an eine Variable reagiert;
eine Anweisung EXIT < group name> (Austritt < Gruppenname> ), auf welche PRMS 215 reagiert, indem es zur Anweisung geht, die der END-Anweisung der benannten Gruppe folgt;
eine Anweisung CARBON COPY < file-list> TO < mailbox-list> (Durchschlag < Dateiliste> an < Mailboxliste> ) auf welche PRMS 215 reagiert, indem es von jeder PDF 301 vom PKG 104, die auf der Dateiliste steht, eine Kopie an jede der Mailboxen auf der Mailboxliste sendet;
eine Anweisung NOTIFY < mailbox> (Benachrichtigen < Mailbox> ), die eine Standardmailbox erstellt, die bei Fehlerbedingungen zu benachrichtigen ist;
eine Anweisung SPLIT COPY1 < statement-list> ... COPYn < statement-list> (Teilen Kopie1 < Anweisungsliste> Kopie2 < Anweisungsliste> ), auf die das PRMS 215 reagiert, indem es so viele Kopien von PKG 104 erstellt, wie in der Anweisung vorgeschrieben sind, und jede Kopie in der Art verarbeitet, die in der Anweisungsliste für die Kopie angegeben ist;
eine Anweisung WAIT CHECKPOINT FOR < time-specification> < statement-list> (Warten auf Prüfpunkt für < Zeitvorschrift> < Anweisungsliste> , auf welche das PRMS 215 reagiert, indem es einen Prüfpunkt an DTCS 225 sendet und auf eine Bestätigung für die in < Zeitvorschrift> spezifizierte Zeitdauer wartet. Kommt keine Bestätigung, wird die Anweisungsliste ausgeführt. In dieser Anweisung kann RETURN (Rückkehr) verwendet werden, um den Grund für die Nichterteilung der Bestätigung zu erfahren.
Wie aus Fig. 7 und der Beschreibung der Anweisungen zu erkennen ist, kann ein Leitweg 315 die Verarbeitung eines Pakets je nach den Werten in Feldern der PDF 301, nach Werten im HDR 333, nach während der Verarbeitung zurückgebenen Werten und nach der abgelaufenen Zeit ändern. Ferner kann er Sicherungs- Pakete PKG 219 erstellen, Kopien eines PKG 104 erstellen und an verschiedene Mailboxen senden, ein PKG 104 zur parallelen Verarbeitung aufteilen, Programme in APPS 223 ausführen, die Verarbeitung eines PKG 104 mit dem DTCS 225 koordinieren, und die Verarbeitung eines PKG 104 beenden. Ferner können im Leitweg 315 Fehlerbehandlungsprogramme für verschiedene Fehlerarten und verschiedene Abschnitte des Leitwegs 315 definiert werden.

6. Erweiterung und Änderung von Leitwegen 315; Fig. 8

Eine wichtige Eigenschaft eines Leitweges 315 besteht bei einer bevorzugten Ausführungsform darin, daß bestimmte Empfänger eines PKG 104 das Recht haben können, den Leitweg 315 zu ändern. Wenn einem solchen Benutzer mitgeteilt wird, daß ein PKG 104 eingetroffen ist, kann er das PPES 211 benutzen, um Schritte in den Leitweg 315 hinzuzufügen oder Schritte aus ihm zu entfernen. Das PRMS 215 führt dann den geänderten Leitweg aus. Eine Änderung des Leitweges 315 kann mittels eines Leitwegeditors im PPES 211 geschehen, kann aber auch in der gleichen Weise wie die Erstellung des Leitweges automatisiert werden. Das PPES 211 kann aus dem PT-Feld 311 des PD 105 den Typ des PKG 104 bestimmen und dann aus der PTL 205 für den Typ einen PTYP 207 erhalten, wobei Informationen in der UPF 201 benutzt werden, um vordefinierte Namen in dem PTYP 207 aufzulösen. Eine freie Änderung des Leitweges 315 ist in der Vorrichtung 101 möglich, weil das PRMS 215 streng als Interpretierer arbeitet, d. h. wenn es die Ausführung einer bestimmten Anweisung STA 607 beendet, führt es, unabhängig von der aktuellen STA 607, immer die nächste STA 607 aus, und bei jedem Verweis, auf den es in einer STA 607 trifft, löst es diesen Verweis entsprechend der gegenwärtigen Bedeutung des Verweises auf, die in der CTLREC 335 vorgeschrieben ist.
Bei anderen Ausführungsformen kann eine Änderung des Leitweges 315 auch die Form einer Ausführung eines lokalen Leitweges LRT 617 haben. Bei solchen Ausführungsformen ist der Leitweg 315 ein globaler Leitweg (GRT) 605, d. h. er schreibt nur die LC 109 vor, an denen Hauptteilbereiche der Verarbeitung eines PKG 104 beginnen. Ein solcher LC 109 ist in Fig. 8 als LC 109(m) dargestellt. Der LC 109(m) enthält eine Lokal- Unterprogramm-Bibliothek (LRL; Abk. für engl. local routine library) 805, die lokale Leitwege LRT 617 für Typen des PKG 104 enthält, für welche der LC 109(m) ein Haupt-LC 109 ist. Die LRL 805 ist nach einem Leitwegtyp-Index (RTI) 807 indiziert, der das Auffinden des LRT 617 für einen bestimmten Typ des PKG 104 nach Pakettyp ermöglicht. Die LRL 805 für einen bestimmten Pakettyp sind somit Teil der TENV 353. Bei Eintreffen des PKG 104 im LC 109(m) benutzt das PRMS 215 den PT 311, um den LRT 617 für das PKG 104 zu lokalisieren und führt dann den LRT 617 in der vorstehend beschriebenen Weise aus, wobei die anderen im LRT 617 spezifizierten LC 109 aufgerufen werden, bevor es zum nächsten, im GRT 605 vorgeschriebenen Haupt-LC 109 springt. In verschiedenen Ausführungsformen der Erfindung kann die Ausführung eines LRT 617 durch Aufruf oder Einfügung erfolgen. Im erstgenannten Fall, der einem Unterprogrammaufruf analog ist, kann die Ausführung des LRT 617 gegenüber anderen LC 109 "verborgen" sein. Während der Ausführung des LRT 617 kann die Ausführung eines GRT 605 unterbrochen sein, kann EXEC REC 351 nur eine Aufzeichnung des Aufrufs des LRT 617 enthalten, und GCTLDB 503 und CCTLDB 505 können Aufzeichnungen nur der Bearbeitung in dem LC 109 enthalten, an dem das LRT 617 aufgerufen worden ist, nicht aber von Bearbeitungen, die im Laufe der Ausführung des LRT 617 durchgeführt worden sind. Zusätzlich wird eine vorübergehende Speicherung von Variablen des LRT 617 im LRTVARS 639 vorgenommen. Im an zweiter Stelle genannten Fall werden die Anweisungen des LRT 617 lediglich als Teil eines GRT 605 eingefügt, und die Ausführung ist in keiner Weise verborgen.
Bei noch anderen Ausführungsformen kann ein LRT 617 mittels einer Anweisung im Leitweg 315 aufgerufen oder eingefügt werden. Eine Form einer solchen Anweisung ist eine Anweisung PERFORM < LRT-name> (Ausführen < LRT-Name> ). Der LRT-Name ist der Name eines LRT 617, der in dem LC 109 verfügbar ist, in dem ein PKG 104 aktuell bearbeitet wird, und als Reaktion auf die PERFORM-Anweisung lokalisiert das PRMS 215 den spezifizierten LRT 617 und führt ihn aus. Bei noch anderen Ausfüh rungsformen kann ein LRT 617 mit einem Steuerbefehl spezifiziert oder bereitgestellt werden. Wenn das PRMS 215 den Steuerbefehl ausführt, führt es den vorgeschriebenen LRT 617 aus.
Es gibt wenigstens zwei Gründe, weshalb es vorteilhaft ist, daß ein Leitweg 315 während der Ausführung geändert werden kann. Der erste Grund ist, daß es niemals möglich ist, alle Umstände vorauszusehen, die im Laufe der Durchführung eines Geschäftsvorganges eintreten können. In der Vorrichtung 101 können veränderte Umstände auf einfache Weise durch Ändern des Leitwegs 315 zur Anpassung an sie behandelt werden. Wenn es beispielsweise notwendig wird, alle PKG 104 eines bestimmten, aktuell verarbeiteten Typs zusammenzufassen, so kann dies auf einfache Weise durch Bereitstellen eines Steuerbefehls mit einem LRT 617 geschehen, der einen einzigen Zielort für alle PKG 104 des Typs vorschreibt. Wenn der Steuerbefehl für jedes PKG 104 ausgeführt wird, wird das PKG 104 zu dem im LRT 617 spezifizierten Zielort geleitet. Wenn es sich erweist, daß sich aus einem bestimmen PKG 104 Fragen ergeben, die es erforderlich machen, daß es weiteren Personen vorgelegt wird, kann der Benutzer in dem LC 109, in dem die Situation eintritt, in ähnlicher Weise den RT 315 für dieses PKG 104 so ändern, daß es diesen Personen zugeleitet wird. Aus den vorstehend genannten Beispielen ergibt sich, daß die Vorrichtung 101 Änderungen der Verarbeitung sowohl von einzelnen Paketen als auch von Pakettypen ermöglicht.
Der zweite Grund ist, daß die Definition eines Geschäftsvorganges selbst häufig auf mehreren Ebenen festgelegt wird. Beispielsweise kann der für die Verarbeitung von Spesenberichten verantwortliche höchste Vorgesetzte deren Verarbeitung nur in der Form "welche Abteilung tut was" beschreiben und die Definition der Verarbeitungsschritte in der einzelnen Abteilung der Leitung dieser Abteilung überlassen. Auch innerhalb der Abteilung kann die Definition mehr als eine Ebene erforderlich umfassen.
In der Vorrichtung 101 wird diese Art der Definition eines Prozesses gemäß Fig. 8 durch Erstellen von Domänen (Bereichen) behandelt. Eine Domäne 801 ist eine Gruppe von LC 109, die einer Teilfunktion, z. B. einer Abteilung entspricht, die für die Verarbeitung eines PKG 104 eines bestimmten Typs verantwortlich ist. Alle LC 109 sind miteinander und mit LC 109 in anderen Domänen durch das Nachrichtensystem 107 verbunden. Einer der LC 109 besitzt eine Domänenmailbox (DMB) 803, die alle PKG 104 empfängt, die durch die Domäne 801 zu verarbeiten sind. Die LRL 805 in diesem LC 109 enthält einen LRT 617, der von den Mitarbeitern der Domäne ausgelegt ist und die in dieser Domäne auszuführenden Schritte spezifiziert. Im GRT 605 eines PKG 104 ist die Verarbeitung eines PKG 104 durch TO-Anweisungen (Ziel-Anweisungen) gegeben, welche die DMB 803 von Domänen 801(a...n) für den Vorgang spezifizieren. Wenn das PKG 104 in einer DMB 803 eintrifft, wird der LRT 617 für diesen Typ PKG 104 in der vorstehend erwähnten Weise ausgeführt, und wenn die Ausführung beendet ist, wird das PKG 104 zur nächsten, im GRT 605 vorgeschriebenen DMB 803 weitergeleitet. Alternativ kann ein Empfänger an der DMB 803 die Verarbeitung innerhalb der Domäne 801(a) vorschreiben.
Die Kombination von veränderbaren RT 315 mit durch das DTCS 225 an das PRMS 215 bereitgestellten Steuerbefehlen schafft eine überragende Steuerung eines PKG 104. Steuerung durch Ändern der Leitwege RT 315 ist synchron mit der Ausführung von Schritten im RT 315 und wird durch den Empfänger eines PKG 104 an dem LC 109 ausgeführt, wo es aktuell verarbeitet wird. Somit ist ein Mechanismus geschaffen, durch den die Verarbeitung eines PKG 104 zur Behandlung von Bedingungen geändert wird, die auf einen LC 109 oder eine Domäne 801 zum Zeitpunkt der dort ausgeführten Verarbeitung beschränkt ist. Eine Steuerung mittels Steuerbefehlen kann von jedem beliebigen LC 109 aus zu jeder beliebigen Zeit ausgeführt werden, und somit ist ein Mechanismus geschaffen, durch den die Verarbeitung eines PKG 104 zur Anpassung an Bedingungen geändert werden kann, die von dem LC 109, der aktuell das PKG 104 verarbeitet, nicht wahrgenommen oder nicht behandelt werden können. Die beiden Steuerungsarten entsprechen ferner der Mehrebenen-Natur von Geschäftsvorgängen: eine Änderung des RT 315 ergibt eine Feinsteuerung auf der Ebene der tatsächlichen Verarbeitung, wogegen Steuerbefehle eine Grobsteuerung auf der Ebene derer schaffen, die für den Gesamtvorgang verantwortlich sind.

7. Arbeitsweise der Vorrichtung 101 in einer Bevorzugten Ausführungs form

Nachdem somit die Komponenten einer bevorzugten Ausführungsform der Vorrichtung 101 und ihre Beziehung untereinander beschrieben worden sind, setzt sich die Beschreibung der bevorzugten Ausführungsform mit einer Beschreibung der Arbeitsweise der Vorrichtung 101 fort, beginnend mit der Definition eines Pakettyps in der Vorrichtung 101 und dann mit der Anwendung der Vorrichtung 101 zur Verarbeitung des Pakets. Bei einer bevorzugten Ausführungsform rufen die Benutzer der Vorrichtung 101 an einem Paket auszuführende Operationen aus einem Paketmenü auf.
Ein Benutzer, der einen Pakettyp zu definieren wünscht und hierzu berechtigt ist, kann aus dem Menü die Pakettyp-Definition aufrufen. Die Definition eines Pakettyps beinhaltet die Definition eines Prototyps (PTYP) 207 für Komponenten der PKG 104 des Typs und die Definition der Typumgebung (TENV) 353. PTYP 207 enthält Informationen, die für alle PKG 104 gültig sind, die mit dem PTYP 207 erstellt wurden. Beispielsweise kann der PTYP 207 für das HDR 333 SYSNO 339, HDRV 341, PT 311, PTV 343 und den Dateitypbeschreibungsteil von PDIR 337 enthalten. Die im PTYP 207 enthaltene Informationsmenge ändert sich mit dem für den Typ ermöglichten Flexibilitätsgrad. Wenn beispielsweise alle PKG 104 des Typs stets denselben RT 315 benutzen, kann der PTYP 207 den gesamten RT 315 enthalten. Das Definieren von TENV 353 macht es erforderlich, daß die zum TENV 353 gehörenden Angaben gemacht werden, und daß diese den LC 109 zugeleitet werden, die das Paket verarbeiten.
Bei einer bevorzugten Umgebung kann TOOLS 208 Hilfsmittel zur Sicherung der Übereinstimmung zwischen den Komponenten des Pakettyps einschließen. Beispielsweise kann der Paket-Definitionseditor von TOOLS 208 den Paket-Definierer zuerst auffordern, die LC 109 aufzulisten, an welche der Pakettyp gesendet werden wird, sodann die LCLIST 621 in einem Prototyp von CTLREC 335 aus den Eingaben erstellen, sodann den Paket-Definierer anweisen, die TENV 353 zu definieren und Deskriptoren für Elemente der TENV 353 im Prototyp der CTLREC 335 zu erzeugen, sodann den Paket-Definierer anweisen, die Datensätze in den im Paket verwendeten PDF 301 zu definieren, und sodann Deskriptoren für die Datensätze im Prototyp von PREFINFO 627 von CTLREC 335 zu erstellen.
Als nächstes kann dann der Paketeditor dem Paket-Definierer das Schreiben eines Prototyps für den RT 315 ermöglichen. Wenn der Definierer im RT 315 HREF 608, MBREF 610, PREF 611 und APPREF 614 verwendet, überprüft sie der Paketeditor auf Übereinstimmung mit den Deskriptoren im Prototyp des CTLREC 335 und HDR 333; wenn der Definierer CREF 609 und VREF 615 im RT 315 schreibt, prüft der Paketeditor, ob sie bereits im Prototyp des CTLREC 335 spezifiziert sind, und wenn nicht, erstellt er Spezifikationen für sie.
Der Paketeditor kann es dem Paket-Definierer ferner ermöglichen, Schirmbilder an der UWS 213 zur Verwendung durch den PTYPE 207 für den Pakettyp zu definieren. Solche Schirmbilder können es Benutzern ermöglichen, Informationen an einen CTLREC 335 oder ein HDR 333 für ein PKG 104 bereitzustellen, unter einem bereits bestehenden Satz Dateien für PDF 301 auszuwählen, einen von mehreren RT 315 auszuwählen oder einen RT 315 zu ändern, Kopien ihrer eigenen Dateien in PDF 301 einzugliedern, oder Daten einzugeben, die das PPES 211 in eine PDF 301 eingibt. Beim Definieren von Schirmbildern überprüft der Paketeditor ihre Übereinstimmung mit den Deskriptoren im Prototyp der CTLREC 335. Bei Beendigung der Paketdefinition kann der Definitionseditor die Komponenten der TENV 353 an die in der Prototyp-LCLIST enthaltenen LC 109 senden. Hilfsmittel an diesen LC 109 ermöglichen die Erstellung der TENV 353 aus den Komponenten. Bei anderen Ausführungsformen können getrennte Hilfsmittel diese Funktionen erfüllen, und das PPES 211 kann ein Übereinstimmungsprüfprogramm enthalten, das abgearbeitet wird, wenn alle Komponenten der Paketdefinition erstellt worden sind, um festzustellen, ob die Komponenten miteinander übereinstimmen.
Ein Benutzer der Vorrichtung 101 in einer bevorzugten Ausführungsform, der ein PKG 104 erstellen möchte, ruft aus dem Menü die Option Paketerstellung auf. Das nächste Menü bietet dem Paketersteller einen Index von Pakettypen an. Der Ersteller wählt den Pakettyp aus, der dem von ihm durchzuführenden Geschäftsvorgang entspricht, und das PPES 211 wählt aus der PTL 205 den PTYP 207 für den Typ aus. Unter Benutzung von in PTYP 207 definierten Schirmbildern holt sich das PPES 211 zusätzliche Informationen vom Paketersteller, die für das Paket 104 erforderlich sind. Bei allen Paketen sind einige Informationen, z. B. eine Kennzeichnung für den Absender des Pakets, für das HDR 333 erforderlich. Wie weiter oben erläutert, können die Schirmbilder ferner den Ersteller auffordern, Dateien vorzuschreiben, die in die PDF 301 zu kopieren sind, oder Daten bereitzustellen, aus denen eine PDF 301 erzeugt werden kann. Wenn dem PKG 104 PDF 301 hinzugefügt werden, werden deren Titel, Typ und Dateiname in das PDIR 337 eingegeben.
Zusätzlich kann das PPES 211 es dem Ersteller ermöglichen, Informationen bereitzustellen, mit denen das PPES 211 den Leitweg 315 ändern kann. Beispielsweise kann der Prototyp des Leitweges 315, so wie er während der Pakettypdefinition erstellt worden ist, eine Standardliste von Empfängern vorschreiben, das PPES 211 kann dem Ersteller ein Schirmbild an zeigen, das ihm die Auswahl von Empfängern aus der Standardliste oder die Hinzufügung von Empfängern in die Liste ermöglicht, und das PPES 211 wird dann die Informationen benutzen, um einen Leitweg 315 aus einem Prototyp desselben zu erstellen. Bei der Bearbeitung des Inhalts eines PKG 104 benutzt das PPES 211 Programme aus TOOLS 208, wie sie durch den behandelten Dateityp erforderlich sind. Typinformationen, die zur Auswahl des richtigen Programms benötigt werden, kommen aus dem PDIR 337.
Am Ende des Erstellungsprozesses enthalten die Daten 103 alle PDF 301, die für den Beginn der Verarbeitung benötigt werden, und der PD 105 enthält den RT 315, das HDR 333 und die CTLREC 335, die für den Beginn der Verarbeitung ausreichend vollständig sind. Der Ersteller gibt dann mittels einer Funktionstaste o. dgl. in der UWS 213 dem PPEs 211 an, daß das PKG 104 gesendet werden soll. Das PPES 211 empfängt dann vom DTCS 225 eine PKGID 305 und gibt sie in das HDR 333 ein. Das DTCS 225 erstellt eine VREC 407 für das PKG 104 in der lokalen CTLDB 401, beschreibt das TOA-Feld 411 und das PKGKEY-Feld 303 und sendet eine Nachricht an das DTCS 225 für die Gruppen-CTLDB 503, in der die PKGID 305 und der Standort des PKG 104 angegeben sind. Weil in der GCTLDB 503 für das PKG 104 kein Datensatz vorhanden ist, sendet das DTCS 225 für die Gruppen-CTLDB 503 eine Nachricht hinsichtlich der Existenz des PKG 104 und dessen Standort an die zentrale CTLDB 505. Diese DTCS-Systeme erstellen dann Datensätze für das PKG 104 in den genannten Datenbänken. Nach dem Senden der Nachrichten bestätigt dann die lokale DTCS 225, daß das PKG 104 registriert worden ist, und das PPES 211 sendet eine Nachricht an das PRMS 215, die anzeigt, daß das PKG 104 bereit ist.
Das PRMS 215 führt jede Verarbeitung aus, die im RT 315 für den LC 109 vorgeschrieben ist, an dem das PKG 104 erstellt wurde, bei Bedarf unter Benutzung von Elementen im TENV 353 des Pakettyps. Ergebnisse der Verarbeitung werden im EXEC REC 351 des HDR 333 und in der STALIST 417 der VREC 407 regi striert. Vor dem Weitersenden des PKG 104 an den im RT 315 vorgeschriebenen nächsten LC 109 prüft das PRMS 215 das DTCS 225 auf übereinstimmende Steuerbefehle für das PKG 104. Sind Steuerbefehle vorhanden, führt sie das PRMS 215 aus; sind keine vorhanden, zeigt das DTCS 225 diesen Umstand an und das PRMS 215 benutzt das Mailsystem, um das PKG 104 an die im RT 315 vorgeschriebene Mailbox weiterzusenden. Das PRMS 215 benachrichtigt das DTCS 225 von der Absendung des PKG 104 und gibt den Zielort an; daraufhin zerstört das PRMS 215 das PKG 104 in der PKGLIB 210 dieses LC 109. Das DTCS 225 füllt das TOD-Feld 413 und das DEST-Feld 415 in der VREC 407 aus und wartet auf die Bestätigung durch das DTCS 225 am nächsten LC 109, daß das PKG 104 eingetroffen ist.
Wenn das PKG 104 im nächsten LC 109 eintrifft, reagiert das PRMS 215 in diesem LC 109 auf dessen Ankunft durch Kopieren des Inhalts vom PKG 104 in die PKGLIB 210 und gibt DTCS 225 den PKGKEY 303 und die Mailbox an, von der aus das PKG 104 gesendet worden ist. Das DTCS 225 macht eine VREC 407 für das PKG 104, sendet die Bestätigung dessen Ankunft an das DTCS 225 des vorherigen LC 109 und sendet eine Nachricht an das DTCS 225 für die GCTLDB 503, die den LC 109 angibt, an dem sich das PKG 104 gegenwärtig befindet. Gibt es keinen früheren Datensatz für das PKG 104 in der GCTLDB 503, sendet auch hier das DTCS 225 eine Nachricht an die CCTLDB 505.
Sobald diese Dinge erledigt sind, sendet das PRMS 215 eine Nachricht an die vorgeschriebene Mailbox in der TO-Anweisung, die das PKG 104 an den LC 109 gesendet hat. Die Nachricht gibt an, daß ein PKG 104 eingetroffen ist. Wenn der Besitzer der Mailbox auf die Nachricht antworten möchte, ruft er PPES 211 auf, das den Inhalt des PKG 104 und der TENV 353 benutzt, um in der beschriebenen Weise Schirmbilder für die Erstellung des PKG 104 an der UWS 213 bereitzustellen, die den Besitzer der Mailbox in der interaktiven Verarbeitung, die an dieser Stelle notwendig ist, leiten.
Die Verarbeitung kann die Behandlung von PDF 301, die Hinzufügung von Kopien von Dateien zum PKG 104 oder die Erstellung neuer Dateien in ihm je nach den Bestimmungen durch die TENV 353 und den Zugriffsberechtigungen, die der Besitzer der Mailbox hinsichtlich des Paketinhaltes hat, beinhalten. Die tatsächliche Bearbeitung wird durch Programme in TOOLS 208 entsprechend dem Bedarf für den Dateityp in dem verarbeiteten PKG 104 vorgenommen. Unter Verwendung von in der Fachwelt bekannten Techniken kann der Mailboxbesitzer vorsehen, daß die Verarbeitung im Hintergrund anstatt interaktiv stattfindet. Danach werden die weiteren, im RT 315 für den LC 109 vorgeschriebenen Schritte ausgeführt und nach Bedarf in der STA- LIST 417 der VREC 407 und im AT 321 aufgezeichnet. Wenn am LC 109 eine BACKUP-Anweisung ausgeführt wird, durch die ein Sicherungs-PKG 219 entsteht, wird der Standort des PKG 219 im PKGBLOC-Feld 419 der VREC 407 angezeigt.
Wenn eine Aufbereitung des RT 315 notwendig ist, kann der Besitzer der Mailbox die Aufbereitung innerhalb der Grenzen vornehmen, die ihm durch seine Zugriffsberechtigungen und durch TPTYP 363 der TENV 353 gesetzt sind. Die Aufbereitung geschieht mit Hilfsmitteln des PPES 211, wie sie für die Erstellung des RT 315 beschrieben wurden. Die Hilfsmittel können auf Übereinstimmung der neuen Elemente mit der CTLREC 335 prüfen. Die Aufbereitung kann den Bereich umfassen vom vollständigen Zugriff auf den RT 315 bis zur Auswahl zwischen mehreren lokalen RT 617 und der Auswahl zwischen verschiedenen Empfängerlisten. Alternativ, wenn die Mailbox eine Domänenmailbox 803 ist, wird der LRT 617 nach Eintreffen in der DMB 803 automatisch aufgerufen.
An jedem der im RT 315 vorgeschriebenen LC 109 setzt sich die Verarbeitung in der vorstehend beschriebenen Weise fort, bis alle Schritte ausgeführt sind, eine TERMINATE-Anweisung durchgeführt ist oder ein Steuerbefehl erhalten wird. Steuerbefehle können durch jeden Benutzer der Vorrichtung 101 ausgegeben werden, der hierzu berechtigt ist. Für die Ausgabe eines Steuerbefehls wählt ein Benutzer diese Option aus dem Menü der Vorrichtung 101. Als Reaktion auf die Option stellt das PPES 211 Menüs für den Steuerbefehl bereit. Wenn der Benutzer die Menüs benutzt hat, um wenigstens ein PKG 104 und den Steuerbefehl zu spezifizieren, liefert das PPES 211 den Befehl an das DTCS 225 am lokalen LC 109. Das lokale DTCS 225 und die DCTS 225 für die übrigen Teile der CTLDB 227 wirken dann in der weiter oben beschriebenen Weise zusammen, um den LC 109 zu lokalisieren, der aktuell das PKG 104 bearbeitet, und geben den Steuerbefehl an das DTCS 225 an diesem LC 109. Das DTCS 225 bringt den Befehl in die CTLMESS 421 der VREC 407 für das PKG 104, das PRMS 215 prüft auf Übereinstimmung mit dem lokalen DTCS 225 vor dem Absenden des PKG 104 zum nächsten LC 109, und wenn ein Steuerbefehl vorliegt, führt ihn das PRMS 215 aus.
Unter Verwendung des PPES 211 kann ein Benutzer der Vorrichtung 101 Anfragen an ein DTCS 225 bezüglich des aktuellen Zustandes eines PKG 104 richten. Wie weiter oben erläutert, wenn das PKG 104 sich aktuell an dem LC 109 des Benutzers befindet, erhält das DTCS 225 die Information von der VREC 407 in der lokalen CTLDB 401; andernfalls benutzt es die CTLDB 227 zum Lokalisieren des PKG 104 und empfängt dann die Zustandsinformation von der lokalen CTLDB 401 in diesem LC 109. Erhält ein Benutzer eine Fehlermeldung vom ENRS 229, kann der Benutzer schließlich das PPES 211 zur Überprüfung der Meldung benutzen, zur Bestimmung des aktuellen Zustandes des PKG 104, zur Überprüfung des PKG 104 und, wenn nötig, zur Ausgabe von Steuerbefehlen an das DTCS 225, die zur Korrektur der Situation erforderlich sind.

8. Schlußfolgerung

Im Vorstehenden wurde eine neuartige Vorrichtung zum Verteilen der Verarbeitung von Daten auf eine Vielzahl Steuerungsorte mittels eines Pakets offenbart, das die Daten und einen Verarbeitungsdeskriptor enthält, welcher die Art und Weise beschreibt, wie die Daten an jedem Ort zu verarbeiten sind, und es wurde dem Fachmann gezeigt, wie eine bevorzugte Ausführungsform von ihr in einem Mehraufgaben-Prozessor-System implementiert werden kann, in dem die Prozessoren durch ein Netzwerk verbunden sind und ein elektronisches Mailsystem das Senden von Nachrichten zwischen Aufgaben an den Prozessoren ermöglicht.
Bei einer bevorzugten Ausführungsform umfaßt die Vorrichtung ein Paket mit Datendateien verschiedener Typen und einem Verarbeitungsdeskriptor und Komponenten in jedem Steuerungsort, zu denen gehören: eine Komponente zum Erstellen und Ändern von Paketen, eine Komponente zum Ausführen der im Verarbeitungsdeskriptor definierten Schritte, eine Komponente zum Verfolgen und Steuern des Paketes, und eine Komponente zur Fehlererfassung. Andere Ausführungsformen können mehr oder weniger Komponenten aufweisen, und die Komponenten können mehr oder weniger Funktionen als die hier beschriebenen Funktionen ausführen. Insbesondere kann die Verfolgungs- und Steuer-Komponente Datenbanken verwenden, die verschieden von den hier beschriebenen ausgelegt sind. Außerdem können andere Ausführungsformen in Einaufgaben-Prozessoren oder in Netzwerken implementiert sein, die eine Kombination von Multi- und Singleprozessor-Prozessoren enthalten, oder in einem einzelnen Mehraufgaben-System.
Hinsichtlich des Pakets können andere Ausführungsformen verschiedene Mechanismen zum Definieren, Erstellen und Aufbereiten von Paketen aufweisen, verschiedene Darstellungen von Daten im Paket ermöglichen, im Leitweg verschiedene Anweisungen benutzen, mehr oder weniger Verweistypen enthalten und verschiedene Techniken zum Auflösen der Verweise anwenden. Ferner können es andere Ausführungsformen den Benutzern nicht ermöglichen, die Daten im Paket oder den Leitweg zu ändern. Andere Ausführungsformen können auch keine Steuerbefehle benutzen oder von den in der bevorzugten Ausführungsform verschiedene Steuerbefehle anwenden.

Claims

1. Vorrichtung zum Verteilen der Verarbeitung von Daten zwischen Orten in einem digitalen Verarbeitungssystem mit einer Vielzahl Steuerungsorten und einem Nachrichtensystem zum Übertragen zwischen den Orten, mit

einem Paket (104), das einen Verarbeitungsdeskriptor (105) enthält, der eine Reihe von Verarbeitungsstufen zum Ausführen einer Tätigkeit oder einer Operation vorschreibt, einschließlich der Angabe des Ortes, in dem jede Stufe ausgeführt werden soll, und

eine Interpretiereinrichtung (111) in jedem im Verarbeitungsdeskriptor vorgeschriebenen Ort, welche auf das Eintreffen des Pakets im Ort über das Nachrichtensystem in der Weise zu reagieren vermag, daß sie die Verarbeitungsstufe in diesem Ort ausführt und das Paket, wie im Verarbeitungsdeskriptor (105) vorgeschrieben, über das Nachrichtensystem an einen anderen Ort liefert, dadurch gekennzeichnet, daß

das Paket (104) die zu verarbeitenden Daten (103) enthält, der Verarbeitungsdeskriptor (105) den Daten zugeordnet ist und die Orte vorschreibt, in denen die Daten zu verarbeiten sind und auf welche Weise die Daten in den Orten zu verarbeiten sind, wobei der Verarbeitungsdeskriptor für jeden vorgeschriebenen Ort Befehle zum Verarbeiten der Daten enthält, wobei die Befehle eine Reihe von durch den Ort auszuführenden Arbeitsschritten zum Durchführen einer gewünschten Verarbeitung durch den Ort enthält,

die Interpretiereinrichtung (111) in jedem im Verarbeitungsdeskriptor (105) vorgeschriebenen Ort die Daten im Ort durch Ausführen des für den Ort vorgeschriebenen Teils des Verarbeitungsdeskriptors (105) verarbeitet, wobei dieses Ausführen durch Durchführen der Reihe von Arbeitsschritten direkt aus den Befehlen des Verarbeitungsdeskriptors (105) erfolgt und bei jedem Arbeitsschritt den Aufruf eines Programms (223) oder einer Aufgabe (216) enthält, das bzw. die die Interpretiereinrichtung (111) über das Nachrichtensystem überträgt, wobei die Interpretiereinrichtung (111) über das Nachrichtensystem an interaktive Programme und Aufgaben zu übertragen und Daten durch diese zu verarbeiten vermag,

wenigstens einer der Orte eine Zustandsregistriereinrichtung (113) zum Empfangen von Zustandsnachrichten und Registrieren derselben zur Überprüfung aufweist, und

in jedem Ort der Zustand der Datenverarbeitung durch diesen Ort durch die Interpretiereinrichtung gemeldet wird, die über das Nachrichtensystem eine Zustandsmeldung an die Orte mit der Zustandsregistriereinrichtung (113) gibt.

2. Vorrichtung zum Verteilen der Verarbeitung von Daten gemäß Anspruch 1, dadurch gekennzeichnet, daß der Verarbeitungsdeskriptor (105) vorschreibt, daß bestimmte Zustandsinformationen an die Zustandsregistriereinrichtung (113) gesandt werden, und daß die Interpretiereinrichtung (111) auf den Verarbeitungsdeskriptor (105) ferner durch Senden der bestimmten Zustandsinformation reagiert.

3. Vorrichtung zum Verteilen der Verarbeitung von Daten gemäß Anspruch 1, dadurch gekennzeichnet, daß bestimmte der Orte eine Einrichtung (211) zum Vorschreiben einer lokalen, im Ort definierten Folge aufweisen, und

daß die Interpretiereinrichtung (111) die lokale Folge ausführt, bevor sie mit der Ausführung der im Paket vorgeschriebenen Folge fortfährt.

4. Vorrichtung zum Verteilen der Verarbeitung von Daten gemäß Anspruch 1, gekennzeichnet durch eine Einrichtung (225) in jedem Ort zum Empfangen eines die Ausführung des Verarbeitungsdeskriptors (105) beeinflussenden Steuerbefehls und zum Weitergeben des Steuerbefehls an die Interpretiereinrichtung (111), wobei die Interpretiereinrichtung auf den Steuerbefehl anspricht und diesen ausführt, bevor sie das Paket an den nächsten Ort sendet.

5. Vorrichtung zum Verteilen der Verarbeitung von Daten gemäß Anspruch 4, gekennzeichnet durch eine Steuerbefehlsendeeinrichtung (225) in bestimmten der Orte zum Senden des Steuerbefehls an den Ort, an dem sich das Paket gegenwärtig befindet.