CMS -Pipelines
 | |
| Paradigma | Datenflow -Programmierung |
|---|---|
| Entworfen von | John P. Hartmann (IBM) |
| Entwickler | IBM |
| Erstmals erschienen | 1986 |
| Stabile Version | 1.1.12 / 0012 / 2020-06-03 |
| Plattform | IBM Z -System |
| OS | Z/VM 7.1 |
| Webseite | http://vm.marist.edu/~pipeline |
| Beeinflusst von | |
| Pipeline (UNIX) | |
CMS -Pipelines implementiert die Pipeline Konzept unter dem VM/CMS Betriebssystem. Die Programme in einer Pipeline arbeiten mit einem sequentiellen Strom von Datensätzen. Ein Programm schreibt Datensätze, die vom nächsten Programm in der Pipeline gelesen werden. Jedes Programm kann mit jedem anderen kombiniert werden, da das Lesen und Schreiben über eine unabhängige Geräteschnittstelle erfolgt.
Überblick
CMS -Pipelines Bietet einen CMS -Befehl, ROHR. Die Argument -Zeichenfolge an die ROHR Befehl ist die Pipeline -Spezifikation. Pipe wählt Programme aus, die ausführen und ketten sie in einer Pipeline zusammen, um Daten durchzupumpen.
Weil CMS -Programme und -Verträge kein Gerätein unabhängig bieten Stdin und Stdout Schnittstelle, CMS -Pipelines hat eine integrierte Programmbibliothek, die in einer Pipeline-Spezifikation aufgerufen werden kann. Diese integrierten Programme werden zum Betriebssystem übertragen und führen viele Dienstprogrammfunktionen aus.
Daten zu CMS sind in logischen Datensätzen und nicht in einem Strom von Bytes strukturiert. Für Textdaten entspricht eine Textzeile einem logischen Datensatz. Im CMS -Pipelines Die Daten werden zwischen den Stufen als logische Datensätze übergeben.
CMS -Pipelines Benutzer geben Pipeline -Befehle aus dem Terminal oder in EXEC -Prozeduren aus. Benutzer können Programme schreiben in Rexx Dies kann zusätzlich zu den integrierten Programmen verwendet werden.
Beispiel
Ein einfaches Beispiel, das eine Festplattendatei liest und Datensätze, die die Zeichenfolge "Hallo" von denen enthält, von denen enthält, die dies nicht tun. Die ausgewählten Datensätze werden geändert, indem die Zeichenfolge "Welt!" Angemessene angeht. zu jedem von ihnen; Die anderen Aufzeichnungen werden in den oberen Fall übersetzt. Die beiden Streams werden dann kombiniert und die Datensätze in eine neue Ausgabedatei geschrieben.
Rohr (Ende?) <Eingabe txt | A: Suchen Sie / Hallo / | Einfügen / Welt! / Nach | I: Faninany | > Newfile txt a? A: | xlate ober | ich:
In diesem Beispiel die < Bühne liest die Eingabediskatei und übergibt die Datensätze in die nächste Stufe in der Pipeline. Das Lokalisieren Die Stufe trennt den Eingangsstrom in zwei Ausgangsströme. Der primäre Ausgang von Lokalisieren (Aufzeichnungen mit Hello) übergeben die Aufzeichnungen an die Einfügung Bühne. Das Einfügung Die Stufe modifiziert die Eingabeaufzeichnungen, die in ihren Argumenten angegeben sind, und übergeben sie an ihre Ausgabe. Der Ausgang ist an verbunden mit Faninany Dies kombiniert Datensätze aus allen Eingangsströmen, um einen einzelnen Ausgabestream zu bilden. Die Ausgabe wird in die neue Datenträgerdatei geschrieben.
Die sekundäre Ausgabe von Lokalisieren (gekennzeichnet durch das zweite Vorkommen der a: Etikett) enthält die Datensätze, die das Auswahlkriterium nicht erfüllen. Diese Aufzeichnungen werden in den oberen Fall übersetzt (von der xlate Stufe) und an den sekundären Eingangsstrom von übergeben Faninany (gekennzeichnet durch das zweite Vorkommen der ich: Etikett).
Die Pipeline -Topologie in diesem Beispiel besteht aus zwei verbundenen Pipelines. Das Endcharakter (das ? In diesem Beispiel) trennt die einzelnen Pipelines in der Pipeline -Menge. Datensätze, die aus der Eingabedatei gelesen wurden, passieren einen der beiden Routen der Pipeline -Topologie. Weil keines der Routen Stufen enthält, in denen die Aufzeichnungen gepuffert werden müssen, CMS -Pipelines stellt sicher, dass Aufzeichnungen eintreffen Faninany in der Reihenfolge, in der sie durchkamen Lokalisieren.
Die Beispielpipeline wird in "Porträtform" mit den einzelnen Stufen in getrennten Zeilen dargestellt. Wenn eine Pipeline als CMS -Befehl eingegeben wird, werden alle Stufen in einer einzigen Zeile geschrieben.
Merkmale
Das Konzept einer einfachen Pipeline wird auf diese Weise erweitert:
- Ein Programm kann eine Subroutine -Pipeline definieren, um eine Funktion für alle oder einen Teil ihrer Eingabedaten auszuführen.
- Ein Netzwerk von sich überschneidenden Pipelines kann definiert werden. Die Programme können gleichzeitig in mehreren Pipelines stattfinden, wodurch der Programmzugriff auf mehrere Datenströme ermöglicht wird.
- Daten von einer Stufe zur nächsten sind als Datensätze strukturiert. Auf diese Weise können Phasen mit einem einzelnen Datensatz arbeiten, ohne dass eine beliebige Pufferung von Daten nicht erforderlich ist, um Sonderzeichen zu scannen, die die einzelnen Zeilen trennen.
- Stufen haben normalerweise auf den Eingangsdatensatz im Locate -Modus zugreifen und erstellen Sie die Ausgabeaufzeichnungen, bevor Sie den Eingangsdatensatz konsumieren. Dieser Sperr-Schritt-Ansatz vermeidet nicht nur das Kopieren der Daten von einem Puffer zum nächsten. Es ermöglicht es auch, den Fluss von Datensätzen in Multi-Stream-Pipelines vorherzusagen.
- Ein Programm kann die Pipeline -Topologie dynamisch neu definieren. Es kann sich durch eine andere Pipeline ersetzen, es kann ein Pipeline -Segment vor oder nach sich selbst oder beides einfügen. Ein Programm kann Daten in der Pipeline verwenden, um Pipeline -Spezifikationen zu erstellen.
CMS -Pipelines Bietet mehrere Funktionen, um die Robustheit von Programmen zu verbessern:
- Ein Syntaxfehler in der gesamten Pipeline -Struktur oder in einem Programm führt dazu, dass die gesamte Pipeline unterdrückt wird.
- Das Start der Programme in der Pipeline und Zuordnung von Ressourcen wird von der koordiniert CMS -Pipelines Dispatcher. Einzelne Programme können an dieser Koordination teilnehmen, um sicherzustellen, dass irreversible Maßnahmen auf einen Punkt verschoben werden, an dem alle Programme in den Pipelines die Möglichkeit hatten, die Argumente zu überprüfen und Daten zu verarbeiten. Wenn die Pipeline beendet wird, stellt der Dispatcher sicher, dass die Ressourcen erneut veröffentlicht werden.
- Fehler, die auftreten, während der Datenfluss in der Pipeline von allen teilnehmenden Programmen erkannt werden kann. Beispielsweise wird eine Festplattendatei möglicherweise unter solchen Umständen nicht ersetzt.
Geschichte
John Hartmann von IBM Dänemark begann die Entwicklung von CMS -Pipelines 1980.[1] Das Produkt wurde von vermarktet von IBM Als separates Produkt in den 80ern und in VM/ESA Ende 1991 integriert. Mit jeder Veröffentlichung von VM die CMS -Pipelines Der Code wurde ebenfalls aktualisiert, bis er 1997 auf der Ebene von 1,1,10 in VM/ESA 2.3 funktional eingefroren wurde. Seitdem die neueste Ebene von CMS -Pipelines wurde von der heruntergeladen CMS -Pipelines Homepage für Benutzer, die neue Funktionen erkunden möchten.
Die aktuelle Ebene von CMS -Pipelines ist in der enthalten Z/VM Veröffentlicht erneut seit Z/VM 6.4, der seit dem 11. November 2016 erhältlich ist.
Eine Implementierung von CMS -Pipelines zum Tso wurde 1995 als Batchpipeworks in der veröffentlicht Batchpipes/MVs Produkt.Die aktuelle TSO-Implementierung war bis 2010 als Serviceangebot von IBM Dänemark verfügbar.
Beide Versionen werden von einer einzelnen Quellcode -Basis aufrechterhalten und allgemein als als bezeichnet CMS/TSO -Pipelines.Die Spezifikation ist in der Ausgabe des Autors erhältlich.[2]
Siehe auch
Verweise
- ^ VM und die VM Community, Melinda Varian
- ^ CMS/TSO -Pipelines Autor Edition des Autors Ausgabe des Autors