Job Entry Subsystem 2/3 - Job Entry Subsystem 2/3

Das Job Entry Subsystem (JES) ist eine Komponente der MVS- Mainframe-Betriebssysteme von IBM , die für die Verwaltung von Batch- Workloads verantwortlich ist. In der heutigen Zeit gibt es zwei unterschiedliche Implementierungen des Job Entry Systems, JES2 und JES3 . Sie bieten eine effiziente Ausführung von Stapeljobs.

Die Auftragsabwicklung ist in mehrere Phasen unterteilt, um Parallelität durch Pipelining zu gewährleisten . Diese Phasen umfassen die Eingabeverarbeitung, in der Jobs gelesen und interpretiert werden, die Ausführungsphase, in der Jobs ausgeführt werden, und die Ausgabeverarbeitung, in der die Jobausgabe gedruckt oder auf DASD gespeichert wird . Jobs, die sich in derselben Ausführungsphase befinden, befinden sich normalerweise in einer bestimmten Warteschlange. Beispielsweise befinden sich Jobs, die gerade ausgeführt werden, in der Ausführungswarteschlange.

Um die E / A-Effizienz zu verbessern, führt JES ein Spooling durch , das mehreren Jobs den gleichzeitigen Zugriff auf ein gemeinsames Speichervolumen ermöglicht. JES verwendet eine Struktur, die als Prüfpunkt bezeichnet wird, um Informationen über aktuell ausgeführte Jobs und die zugehörige Ausgabe zu sichern. Der Prüfpunkt kann verwendet werden, um Jobs und Ausgaben bei unerwarteten Hardware- oder Softwarefehlern wiederherzustellen.

Obwohl JES2 und JES3 dieselbe Kernfunktionalität bieten, gibt es bestimmte Funktionen, die in einem JES vorhanden sein können, im anderen jedoch nicht. Aufgrund dieser Unterschiede kann bei bestimmten Kundeninstallationen ein JES dem anderen vorgezogen werden. JCL wird verwendet, um Jobs sowohl für JES2 als auch für JES3 zu definieren. In der Regel müssen jedoch kleine Änderungen an der JCL vorgenommen werden, damit ein Job geschrieben wird, damit ein JES auf dem anderen ausgeführt werden kann.

Geschichte

Vorläufer

Die Stapeljobverarbeitung von OS / 360 hatte eine begrenzte betriebliche Flexibilität und Leistung, die durch zwei vor Ort entwickelte Pakete behoben wurde, die als Houston Automatic Spooling Priority ( HASP ) und Attached Support Processor ( ASP ) bezeichnet wurden.

HASP

HASP wurde von Auftragnehmern der IBM Federal Systems Division im Johnson Space Center in Houston entwickelt . Ursprünglich wurden die Auftragsplanung sowie die Druck- und Lochausgabe für einen einzelnen OS / 360-Computer verwaltet. Die Multi-Access-Spool- Funktion wurde hinzugefügt, damit Peer-Computer eine gemeinsame Jobwarteschlange und Druck- / Lochausgabewarteschlangen gemeinsam nutzen können.

Mit der Einführung von System / 370 im Jahr 1972 schrieb IBM HASP neu, um ein Standardbestandteil des Systems zu werden, und benannte es in Job Entry Subsystem 2 um . JES2 wurde 1973 in OS / VS2 in Release 2, auch als MVS bekannt , eingeführt. Es dauerte viele Jahre, bis die HASP-Labels aus dem Quellcode entfernt wurden und den von JES2 ausgegebenen Nachrichten immer noch das Präfix vorangestellt wird $HASP . Mehrere JES2-Befehle unterstützen weiterhin die Angabe von JES2 oder HASP die Aufrechterhaltung der Abwärtskompatibilität .

ASP

ASP stand ursprünglich für Attached Support Processor und wurde entwickelt, um die effiziente Nutzung mehrerer OS / 360-Systeme mit einer gemeinsamen Arbeitslast zu ermöglichen. Es ermöglichte einem zentralen System, Jobs auf mehrere verbundene Systeme zu verteilen. ASP wurde im März 1967 angekündigt, und es wurde berichtet, dass dieses Jahr "sehr stabil läuft".

ASP entwickelte sich aus der Gestaltung des 7094 / 7040 direkt gekoppelten Systems Kanalkommunikation unter Verwendung von Datenkanal auf Daten. Durch den Anschluss eines IBM 7040 als Peripheriegerät wurde der Prozessordurchsatz mehr als verdoppelt.

In einer typischen Konfiguration ASP, ein kleiner Mainframe, wie ein 360/40 das genannten Stützsystem gesteuert einen oder mehr 360/65 oder größer Prozessoren genannt Hauptsysteme. Die Computer wurden über Auswahlkanäle auf jedem Host verbunden, die an Kanal-zu-Kanal-Adapter in einer frühen Form der Punkt-zu-Punkt-Computernetzwerke über kurze Entfernungen angeschlossen waren.

ASP erforderte den Kauf eines zusätzlichen Computers zur Verwaltung der Ein- und Ausgabe der Hosts, auf denen die Job-Workload ausgeführt wird. Dies war wirtschaftlich gerechtfertigt durch die hohen Kosten für eigenständige Byte-Multiplexer-Kanäle, die zum Ansteuern von Druckern und Lochkartenlesegeräten erforderlich sind. Die Systeme 360/50 und kleiner hatten einen eingebauten Byte-Multiplexerkanal, während die schnelleren Systeme 360/65 und größer eine relativ teure eigenständige Einheit erforderten. Durch die Verwendung von ASP konnten die Kosten des Byte-Multiplexerkanals vermieden werden, und durch die Verlagerung der Auftragsplanung, des Drucks und der Kartenverarbeitung wurden diese Funktionen auch von den größeren Computern entlastet.

Eine erhöhte Zuverlässigkeit war ein weiterer Vorteil, um die zusätzlichen Hardwarekosten auszugleichen. Ein oder mehrere Hauptsysteme könnten fehlschlagen oder für Wartungsarbeiten offline genommen werden , ohne dass die ganze Anlage , die hinunter.

ASP richtete sich in erster Linie an große Regierungsbehörden und Verteidigungsunternehmen, bei denen möglicherweise bis zu sechs 360/65-Flugzeuge von einer separaten ASP-Maschine geplant und verwaltet werden. Eine ungewöhnliche Variante, der lokale ASP ( LASP ), war ein einzelner großer Computer, auf dem die ASP-Funktionen auf demselben Computer ausgeführt wurden.

In den 1970er Jahren war eine bemerkenswerte Installation von ASP an der Princeton University, die einen IBM 360/91-Mainframe steuerte.

1973 schrieb IBM ASP neu und benannte es in JES3 um, wobei nur MVS unterstützt wurde.

Alternativen

Es gab auch ein JES in OS / VS1 , das oft als JES1 bezeichnet wurde . Darüber hinaus ist das Master- Subsystem ( MSTR ) in das moderne z / OS-Betriebssystem integriert, um Jobs zu starten, die außerhalb der Kontrolle von JES ausgeführt werden, einschließlich des primären JES selbst.

Anpassung

IBM Kunden erhielten sowohl für ASP als auch für HASP Quellcode, und viele Kunden haben diese Programme erheblich verbessert, von denen einige in das offizielle Produkt integriert wurden. Weit mehr Installationen verwendeten HASP als ASP, und in modernen z / OS-Systemen gibt es viel mehr JES2-Installationen als JES3. Aufgrund ihrer einzigartigen Historie liefert IBM im Gegensatz zu den meisten Komponenten des Betriebssystems weiterhin JES2- und JES3- Quellcode anstelle von Objektcode .

Um die Wartbarkeit und Wartungsfreundlichkeit von vom Benutzer geschriebenen Verbesserungen zu verbessern, bietet JES eine Reihe von Exit-Punkten, die die Steuerung vom JES an wichtige Verarbeitungspunkte an Benutzerprogramme übergeben. Diese Erweiterungen können benutzerdefinierte Funktionen wie spezielle Befehle, benutzerdefinierte Druckseitenüberschriften und nicht standardmäßige Auftragsverarbeitung bereitstellen.

Aktuelle Entwicklung

Im Jahr 2017 veröffentlichte IBM eine Richtungserklärung für JES2 als "strategisches" JES, was bedeutet, dass sich alle zukünftigen Entwicklungsbemühungen auf JES2 und nicht auf JES3 konzentrieren werden. IBM hat Kunden versichert, dass JES3 weiterhin unterstützt wird, bis ein Ende des Supports bekannt gegeben wird. Im Februar 2019 gab IBM bekannt, dass z / OS 2.5 (voraussichtlich 2021 veröffentlicht) die letzte Version von z / OS sein wird, die JES3 enthält. Im Oktober 2019 gab Phoenix Software International bekannt, dass sie den JES3-Quellcode von IBM lizenziert hat und dessen Wartung und Verbesserung übernehmen wird.

Siehe auch

• SDSF ( System Display and Search Facility ), das am häufigsten verwendete Dienstprogramm für die Interaktion mit JES2

Anmerkungen

Verweise

Externe Links

• "Was ist JES?", Z / OS-Konzepte (PDF) , z / OS-Informationszentrum für grundlegende Fähigkeiten, IBM, S. 80–81
• "JES2 im Vergleich zu JES3", z / OS-Konzepte (PDF) , z / OS-Informationszentrum für grundlegende Fähigkeiten, IBM, S. 91–92