DE3884504T2

DE3884504T2 - Eingabe-Dienstsubsystem zur dynamischer Arbeitsplanung für ein Computersystem.

Info

Publication number: DE3884504T2
Application number: DE88109619T
Authority: DE
Inventors: Kenneth Alan Kahn; Robert Matthew Martinez; Juha Pentti Vainikainen
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-07-31
Filing date: 1988-06-16
Publication date: 1994-05-11
Anticipated expiration: 2008-06-17
Also published as: DE3884504D1; JPH0820963B2; EP0301221A3; EP0301221B1; US4918595A; EP0301221A2; JPS6455648A

Description

Die vorliegende Erfindung betrifft allgemein ein Verfahren zur Beseitigung des Engpasses, der in einer großen interaktiven Computersystemumgebung auftritt, wenn einer Komponente eines Betriebssystems Aufträge schneller übergeben werden, als die Komponente diese empfangen kann. Insbesondere betrifft sie eine verbesserte interne Leserfunktion des Betriebssystems zur dynamischen und effizienten Verarbeitung von Eingabeströmen, die von Aufträgen erzeugt werden.
Ein interner Leser (INTRDR) ist eine Subsystemfunktion des Betriebssystems IBM Multiple Virtual Storage/Extended Architecture (MVS/XA). Insbesondere ist ein interner Leser eine Funktion des Auftragseingabe-Subsystems (JES3, Job Entry Subsystem) eines interaktiven Computersystems.
Die von MVS/XA verwaltete Umgebung: Die Computersysteme, die MVS/XA verwaltet, wie etwa die Modelle des Komplexes IBM 3090, sind zum Mehrprogrammbetrieb in der Lage, können also viele Programme gleichzeitig ausführen. So können zum Beispiel zeitgleich Hunderte von Aufträgen für Benutzer im Time-Sharing-Betrieb ausgeführt werden, die sich an geographisch weit entfernten Orten befinden können. Die Computersysteme, die MVS/XA verwaltet, sind außerdem auch zum Mehrprozessorbetrieb in der Lage, also zum gleichzeitigen Betrieb von von zwei oder mehr Prozessoren, die die verschiedenen Geräte der Systemhardware gemeinsam benutzen. MVS/XA bietet jedem Benutzer einen eindeutigen Adreßbereich (virtuelle Speicheradressen) und erhält die Unterscheidung zwischen dem Code und den Daten aufrecht, die zu den einzelnen Adreßbereichen gehören.
MVS/XA plant jeden Auftrag in einem System in Form von Aufgaben und versucht jeweils, diese zu verarbeiten. Die Aufgaben für einen einzelnen Auftrag konkurrieren in der Regel miteinander und mit Aufgaben, die zu anderen Aufträgen gehören, um die Nutzung der Systemressourcen. Eine Komponente des Betriebssystems, der Supervisor, steuert das Fortschreiten der Aufgaben durch das System. Der Supervisor weist die Ressourcen zu (außer Eingabe-/Ausgabegeräten (I/O- Geräten)) und führt aktuelle Informationen über die einzelnen Aufgaben, damit die Verarbeitung nach einer Unterbrechung an dem entsprechenden Punkt wieder aufgenommen werden kann.
Module des Betriebssystems MVS/XA speichern normalerweise die Informationen, die zur Steuerung einer bestimmten Aufgabe oder zur Verwaltung einer Ressource erforderlich sind, in definierten Bereichen, die als Steuerblock bezeichnet werden. Steuerblöcke, die viele Aufgaben desselben Typs vertreten, können gemeinsam in eine Warteschlange gestellt werden, so daß jeder Steuerblock also die Startadresse des nächsten in der Kette enthält (auf den nächsten Block "weist"). Ein Programm kann dann in der Warteschlange nach den Daten für eine bestimmte Aufgabe oder Ressource suchen. Dabei kann es sich handeln um: eine Adresse eines Steuerblocks oder einer erforderlichen Routine, tatsächliche Daten (Wert, Parameter oder Name) und/oder Statusflags. Alle Felder in einem Steuerblock sind vorbestimmt.
Die Kommunikation zwischen MVS/XA-Komponenten oder -Subsystemen (Programmen) erfolgt aufgrund der Verwendung gemeinsamer Makroanweisungen. Diese Anweisungen rufen Segmente des Programmcodes auf, die häufig benutzte Steuerblöcke abbilden oder häufig benutzte Systemfunktionen ausführen. Makros bestehen für solche Funktionen wie das Öffnen und Schließen von Datendateien, das Laden und Löschen von Programmen und das Senden von Meldungen an den Bediener des Systems.
Das Auftragseingabe-Subsystem (JES3): Ein Subsystem wie JES3 12 kommuniziert mit MVS/XA über eine Subsystem-Komponente, die als Subsystemschnittstelle (551, Subsystem Interface) 14 bezeichnet wird, wie in Fig. 1a gezeigt. MVS/XA verwaltet während der Ausführung jeden Auftrag (einen JCL-Befehl in einem Eingabestrom), während das Auftragseingabe-Subsystem des Betriebssystems jeden Auftrag vor und nach der Ausführung verwaltet. In diesem Fall benötigt das Betriebssystem MVS/XA das JES3, um jeden einzelnen Auftrag zu verarbeiten. JES3 liest einen Eingabestrom (eine Sammlung von Aufträgen), die durch einen JCL-Befehl bezeichnet werden, und leistet Arbeit, um diese Aufträge auf die Ausführung vorzubereiten. Diese Arbeit kann zu einem bestimmten Auftrag aus dem Eingabestrom gehören, oder sie kann zu der Arbeit gehören, die JES3 aufgrund seiner Zuständigkeit für die Koordinierung der Vorbereitung vieler Aufträge auf die Ausführung durch MVS/XA ausführen muß. Es kann spezielle Arten von JES3-Aufträgen geben, an denen keine JCL beteiligt ist. JES3 liest jeden Auftrag im Eingabestrom und legt ihn auf mindestens einem Direktzugriffs-Speichergerät (DASD, Direct Access Storage Device) ab, auch bekannt als Spulengerät. Ein Spulengerät dient als: Puffer zwischen Eingabegeräten und Routinen, die Eingabedaten lesen, und zwischen Routinen, die Ausgabedaten und auf Ausgabegeräte schreiben; Speicherplatz für die Steuerblöcke und Daten, die JES3 zur Verarbeitung von Aufträgen aufbaut; und als Sammelpunkt für Daten, die auf die einzelnen Prozessoren in einer Mehrprozessorumgebung verteilt werden sollen. Der SPOOL-Betrieb ist die zeitweilige Speicherung von Aufträgen und auftragsbezogenen Daten in Zwischenstadien der Verarbeitung auf dem Spulengerät, damit auf sie leicht zugegriffen werden kann. Da jeder Auftrag eine Auftragsklasse, eine Priorität und eine Ausgabeklasse besitzt, wählt JES3 die Aufträge von dem Spulengerät so zur Ausführung aus, das die effiziente Nutzung der Systemressourcen gefördert wird.
Die Verarbeitung durch JES3 erfolgt in sechs Stufen: Eingabe, Konversion/Interpretation, Gerätezuweisung, Planung eines Auftrags zur Ausführung, Ausgabe und Löschung. Bei der Eingabe liest JES3 eine Sammlung von Aufträgen von einem Eingabe-/Ausgabegerät wie einem Kartenleser, einem entfernten Terminal, einem anderen MVS- oder MVS/XA-System, einem Bandlaufwerk oder einem DASD. Jeder Auftrag könnte selbst Eingabeströme erzeugen. Durch Aufträge erzeugte Eingabeströme werden von einem internen Leserprogramm des JES3 verarbeitet. Im allgemeinen überträgt der interne Leser einen Eingabestrom von einem Ausgabedienst, also einer Ausgabe-Warteschlange, zu dem zu verarbeitenden Eingabedienst des JES3, also einer Eingabe-Warteschlange. Jeder Auftrag, der in MVS/XA ausgeführt wird, kann mit anderen Worten einen internen Leser verwenden, um einen Eingabestrom, der von dem Auftrag erzeugt wurde, an JES3 zu leiten, und JES3 kann über mehrere interne Leser gleichzeitig mehrere von Aufträgen erzeugte Eingabeströme empfangen. Der von Aufträgen erzeugte Eingabestrom wird nicht von einem Gerät wie einem Kartenleser, einem entfernten Terminal oder einem Direktzugriffsgerät eingegeben. Statt dessen wird der Eingabestrom von einem Auftrag als Ausgabedatenmenge erzeugt, also als Datenmenge mit Auftragssteuersprache (JCL, Job Control Language) und/oder Daten und/oder JES3-Steuerbefehlen und Kommentaren.
JCL ist eine spezielle Stapelsprache, die zur Erstellung von MVS/XA-Datenmengen dient. Ein spezieller JCL-Befehl dient zur Zuweisung einer Datenmenge zu dem internen Leser des JES3. Ein Auftrag erstellt mit anderen Worten eine Ausgabedatenmenge und fordert deren Verarbeitung als Auftrag an, indem er das Ziel als SYSOUT=(*, INTRDR) in der Datenmenge codiert, die den Befehl (DD) bezeichnet. Der Befehl hat die Form //ddname DD SYSOUT = (*,INTRDR), wobei "ddname" der Name ist, den das Stapelprogramm verwendet, um die Datenmenge zu öffnen, darauf zuzugreifen und sie zu schließen. "DD" dient dazu, eine neue oder eine bereits bestehende Datenmenge zuzuweisen. "SYSOUT" bezeichnet diese Datenmenge als Systemausgabedatenmenge, also als SYSOUT- Datenmenge. "INTRDR" zeigt JES3 an, daß die SYSOUT-Datenmenge als Eingabeauftragsstrom an den internen Leser des JES3 geschickt werden soll. (SYSOUT ist eine von JES3 verwaltete Datenmenge und wird unten erörtert.) Dadurch entfällt die Notwendigkeit, von Aufträgen erzeugte Eingabeströme in herkömmlicher Weise mit Hilfe eines I/O-Gerätes neu einzugeben. Im allgemeinen überträgt das interne Leserprogramm des JES3 einen von Aufträgen erzeugten Eingabestrom (eine Ausgabedatenmenge wie etwa SYSOUT) direkt an Eingabedienstprogramme des JES3, die normalerweise Aufträge verarbeiten, die sie von I/O-Geräten erhalten. Wenn JES3 den Eingabestrom liest, weist es jedem Auftrag (im Eingabestrom) eine eindeutige Auftragskennung zu und plaziert die JCL, die optionelen JES3-Steuerbefehle und die Eingabedaten der einzelnen Aufträge in Spulen-Datenmengen. Die Aufträge des Eingabestroms werden dann aus den gespulten Datenmengen zur Verarbeitung und späteren Ausführung ausgewählt.
Stapelaufträge werden von JES3 als Reaktion auf Arbeitsanforderungen der Initiatorfunktion des MVS/XA- Auftragsplaners ausgewählt. Sie laufen im Adreßbereich des Initiators. (Ein Initiator ist ein Programm des MVS/XA- Systems, das entweder vom Bediener oder von JES3 gestartet wird, um Stapelaufträge, die über JES3 übergeben werden, anzufordern und dann auszuführen.) Aufträge, die von TSO LOGON, dem MOUNT-Befehl oder dem START-Befehl (nachstehend erörtert) erzeugt werden, werden zur Verarbeitung ausgewählt, wenn sie durch einen Prozeß eingegeben werden, der als "Bedarfsauswahl" bekannt ist. Diese Aufträge laufen jeweils in ihrem eigenen Adreßbereich ab.
In der C/I-Stufe (Konversion/Interpretation) analysiert JES3 mit Hilfe eines Konvertierprogramms die JCL-Befehle der einzelnen Aufträge (des Eingabestroms). Der Konvertierer nimmt die JCL und konvertiert sie in internen Text, der von JES3 und den Auftragsplanungsfunktionen von MVS/XA erkannt wird. JES3 ruft dann die Interpreterfunktion auf, um die JCL weiter zu analysieren und Steuerblöcke zu bilden. Sowohl der interne Text als auch die Steuerblöcke werden dann in der Spulen-Datenmenge gespeichert.
Wenn ein Auftrag läuft, muß er im allgemeinen I/O-Geräte wie Bänder oder DASDs und Datenmengen verwenden. Über eine Funktion, die als "Gerätezuweisung" bezeichnet wird, weist MVS/XA Aufträgen diese Ressourcen zu. Die Gerätezuweisung nutzt die Informationen in dem JCL-Befehl des Auftrags, um dem Auftrag die richtigen Ressourcen zuzuweisen. Dann wird der Auftrag an einen MVS/XA-Initiator weitergeleitet.
Die Planungsphase reagiert auf Auftragsanforderungen der MVS/XA-Auftragsinitiatorfunktion. JES3 wählt einen Auftrag aus einer Auftragswarteschlange auf einer Spulen-Datenmenge und stellt ihn dem Initiator zur Verfügung.
JES3 steuert die gesamte Verarbeitung der Systemausgabe (SYSOUT). SYSOUT-Daten werden bei der Ausführung von Aufträgen erzeugt. Während der Ausführung kann ein Auftrag Systemmeldungen erzeugen, die gedruckt werden müssen, sowie Datenmengen, die gedruckt oder gelocht werden müssen. Nach Beendigung des Auftrags analysiert JES3 die Merkmale der Ausgabe des Auftrags auf ihre Ausgabeklasse und ihre Einrichtungserfordernisse und verarbeitet die Ausgabe entsprechend. Insbesondere sammelt JES3 die Ausgabedaten nach Ausgabeklasse, Geräteverfügbarkeit und Prozeßmodus und reiht sie zur Verarbeitung die Ausgabe dann vorübergehend in die SYSOUT-Datenmenge auf dem Spulengerät ein. MVS/XA erzeugt also auf dem Spulengerät eine vorübergehende SYSOUT- Datenmenge, die die Sätze enthält, die in die SYSOUT- Datenmenge geschrieben wurden. (Nach der Ausführung des Auftrags druckt oder locht JES3 die SYSOUT-Daten auf das entsprechende Ausgabegerät. Die Drucker und Locher sind JES3- Geräte, die während der Systeminitialisierung als solche identifiziert werden.)
Im Stadium des Löschens, wenn die gesamte Verarbeitung für einen Auftrag beendet ist, gibt JES3 den Spulbereich, der dem Auftrag zugewiesen war, frei und stellt ihn dadurch für die Zuweisung zu folgenden Aufträgen zur Verfügung.
JES3-Eingabedienstprogramme: JES3-Programme, die als dynamische Unterstützungsprogramme (DSP, Dynamic Support Programs) bezeichnet werden, erledigen die Arbeit, die JES3 leisten muß, um Aufträge auf die Ausführung vorzubereiten, die sich im Eingabestrom befinden. Es gibt drei Typen von DSPs:
1. Residente DSPs, die ein fester Bestandteil der JES3- Verarbeitung sind.
2. DSPs, die durch einen Befehl des Bedieners aufgerufen werden (* CALL DSP name).
3. DSPs, die Arbeitseinheiten (oder -elemente) verarbeiten, die von einem Auftrag benötigt werden.
Wenn JES3 einen Auftrag verarbeitet, ist das Endergebnis die Ausführung eines oder mehrerer DSPs. Im allgemeinen bearbeitet DSP 18, wie in Fig. 1b gezeigt, eine Arbeitseinheit und erfüllt eine bestimmte Funktion, doch seine Arbeit wird durch ein Paar JES-Module erzielt, nämlich ein Treibermodul 20 und ein Daten-CSECT 22. (Das Daten-CSECT enthält Arbeitsbereiche, Konstanten und gemeinsame Routinen, die von dem Treibermodul und anderen Modulen, die das Treibermodul aufruft, verwendet werden. Nicht alle DSPs erfordern jedoch ein eigenes Daten-CSECT.) JES3 verwendet Routinen des dynamischen Unterstützungsprogramms für interne Leser (INTRDR-DSP), um die Übertragung der von Aufträgen erzeugten Eingabeströme zum JES3-Eingabedienst zu bearbeiten. Wenn ein Auftrag erzeugt wird, der über Planungselemente verfügt, wird automatisch ein DSP initiiert. Das DSP ist selbst eine JES3-Aufgabe. JES3 sorgt mit Hilfe des DSP für seine eigene interne Abfertigung. Der Bediener ruft mit Hilfe des Befehls *,INTRDR so viele dynamische Unterstützungsprogramme für interne Leser auf, also Kopien des INTRDR-DSP, wie erforderlich sind, um mit der aktuellen Belastung durch die von JES3-Aufträgen erzeugten Eingabeströme fertigzuwerden, die zu dem Eingabedienst übertragen werden sollen.
Im allgemeinen werden alle DSPs mit Hilfe der JES3- Hauptabfertigungswarteschlange abgefertigt, die als Funktionssteuertabellenkette (FCT-Kette, Function Control Table Chain) 24 bezeichnet wird, wie in Fig. 1b gezeigt. Jedem DSP entspricht einer oder mehrere FCT-Einträge in der FCT-Kette, wie durch die Linie 26 angedeutet wird, die das DSP 18 mit dem FCT-Eintrag 24a "verbindet". JES3 fertigt einen FCT-Eintrag sehr ähnlich ab, wie MVS/XA einen Aufgabensteuerblock (TCB, Task Control Block) abfertigt. Der FCT-Eintrag, der für ein DSP steht, ist ein Element in einer Kette von Elementen, aus denen die FCT-Kette besteht. Die Elemente der FCT-Kette sind nach der Priorität, die dem DSP zugeordnet ist, von der höchsten bis zur niedrigsten Priorität geordnet. Im allgemeinen stellen FCT-Einträge von JES3 abzufertigende Arbeitseinheiten für alle Aufträge dar.
Es gibt zwei Typen von FCT-Einträgen: residente und nichtresidente FCTs. Residente FCT-Einträge werden nicht dynamisch in die Abfertigungswarteschlange aufgenommen oder aus ihr entfernt. Diese residenten FCT-Einträge stehen für DSPs, die benötigte JES3-Funktionen wie Bedienerkommunikation und Ausgabedienste erfüllen. Nicht-residente FCT-Einträge werden bei Bedarf in die Abfertigungswarteschlange aufgenommen oder aus ihr gelöscht. Diese nicht-residenten FCT-Einträge erfüllen Bediener-Dienstprogrammfunktionen sowie die Kernverarbeitung des JES3.
Ein JES3-Auftrag wird durch einen Steuerblock definiert, der als Auftragssteuertabelleneintrag (JCT-Eintrag, Job Control Table Entry) 30 bezeichnet wird, wie in Fig. 1c dargestellt. Die JCT-Auftragsstruktur wird von JES3 erzeugt. (Ein MVS/XA- Auftrag, der durch den Befehl JCL JOB definiert ist, ist analog zu einem JES3-Auftrag, der durch einen JCT-Eintrag definiert ist.) Jeder JCT-Eintrag enthält den auszuführenden JES3-Auftrag, also die Merkmale des Auftrags sowie ein Planungselement für jede Arbeitseinheit, die (in Folge) erledigt werden muß, um diesen besonderen Auftrag zu verarbeiten. Wie in Fig. 1c gezeigt, stellt ein Planungselement ein Stadium des zu verarbeitenden JES3- Auftrags dar, also das C/I-Stadium (32), das MAIN-Stadium oder Gerätezuweisungsstadium (34), das SYSOUT- Ausgabeverarbeitungsstadium (36) und das Löschstadium (38). Diese Planungselemente, die für Arbeitseinheiten stehen, werden sequenziell verarbeitet, und jedes ist auf der FCT- Kette durch ein DSP vertreten, das die Arbeit erledigt, die für dieses spezielle Planungselement erforderlich ist. Im allgemeinen stellen die Planungselemente in einem JCT-Eintrag Arbeitseinheiten für einen speziellen MVS/XA-Auftrag dar. Ein Auftragssegmentplaner (JSS, Job Segment Scheduler) wählt Planungselemente aus, die zur Verarbeitung bereit sind, und baut Einträge auf der FCT-Kette 24 auf, wie in Fig. 1d gezeigt, so daß DSPs, die diese Planungselemente (32-38) vertreten, abgefertigt werden, um die Arbeit zu tun, die von diesen Planungselementen verlangt wird. Der JSS durchsucht die Auftragswarteschlange (die FCT-Kette) in der Reihenfolge der Prioritäten, findet einen Auftrag, der ein zu verarbeitendes Planungselement aufweist, baut einen residenten Warteschlangenelement-Steuerblock (RSQ, Resident Queue Element Control Block) für dieses Planungselement auf und verbindet die residente Warteschlange mit einem FCT- Eintrag, der dem DSP entspricht, das zur Erfüllung der Funktion abgefertigt wird, die von diesem Planungselement verlangt wird. Für jedes DSP, das nicht durch einen residenten FCT-Eintrag vertreten ist, wird von dem JSS ein FCT-Eintrag aufgebaut und in die FCT-Kette aufgenommen. Dieser "neue" FCT-Eintrag vertritt dann auch ein DSP, das die von einem Planungselement verlangte Arbeit erledigt.
Der JSS plant die Arbeit für JES3, die im Namen eines MVS/XA- Auftrags getan werden muß, der durch Planungselemente definiert ist. (Die Planung, die von dem JSS geleistet wird, entspricht der Abfertigung, die von dem Multifunktionsmonitor (MFM) vorgenommen wird. Zeiger von dem JCT-Eintrag auf die anderen Steuerblöcke des Auftrags werden in den RSQ plaziert. Der RSQ, ein großer, nur im Speicher liegender Steuerblock, ist ein Speicherbereich für Statusflags, Auftragsinformationsfelder und Warteschlangenzeiger. RSQs bestehen nur so lange wie ein Planungselement.
Der MFM, der tatsächliche Abfertiger des JES3, durchsucht die FCT, um die entsprechende FCT abzufertigen, um die Arbeit des Planungselementes zu erledigen. Wenn der MFM einen FCT- Eintrag findet, der abgefertigt werden kann, stellt er die DSP-Umgebung aus dem FCT-Eintrag wieder her und übergibt dann die Steuerung zur Verarbeitung an das DSP-Treibermodul. Das DSP leistet dann seinen Dienst, und der MFM verzichtet auf die Steuerung, bis das DSP sie ihm wiedergibt. Der MFM speichert dann die DSP-Umgebung (Registerinhalte usw.) in dem FCT-Eintrag für die nächste Abfertigung des DSP. Der MFM beginnt dann, die FCT noch einmal zu durchsuchen. Mit Hilfe der JCT-FCT-Strukturen kann JES3 die Arbeit nach Aufträgen (JCT-Einträge) verfolgen und planen und die Arbeit nach Arbeitseinheiten (innerhalb eines Auftrags) abzufertigen (FCT-Einträge). Das JSS liefert die Schnittstelle zwischen JCT und FCT mit Hilfe der Planungselemente in der JCT und eines DSP in der FCT-Kette (das die Arbeit eines Planungselementes erledigt, das durch mindestens einen FCT- Eintrag vertreten wird).
Quellen der JES3-Aufträge: Es gibt verschiedene Quellen von JES3-Aufträgen: normale Aufträge, die entweder von dem internen Leser von MVS/XA oder von lokal angeschlossenen Geräten wie Kartenlesern und DASDs oder entfernt angeschlossenen Geräten oder (in einer Netzwerkumgebung) von einem anderen JES3-Knoten eingegeben werden; "Bedarfsauswahl"-Aufträge, die auftreten, wenn ein Bediener die MVS-Befehle START oder MOUNT gibt oder der Benutzer einer Time-Sharing-Option (TSO) einen LOGON-Befehl gibt; und "aufgerufene Aufträge", die durch eine Bedieneranforderung als Reaktion auf einen JES3-Befehl * CALL erzeugt werden.
Aufträge für interne Leser: Ein Auftrag wird im allgemeinen auf eine von zwei Arten an den internen Leser des JES3 (unten erörtert) übergeben. Die eine Art besteht in der Verwendung eines CLOSE-Makros zum Schließen einer SYSOUT-Datenmenge, das z. B. dem internen Leser mit SYSOUT=(*,INTRDR) zugewiesen ist. Als Reaktion auf das CLOSE-Makro ruft MVS/XA die Routine CLOSE SVC auf, die Informationen der Datenmenge des Auftrags (JDS, Job Data Set) für interne Leser, also der SYSOUT- Datenmenge, über die Subsystemschnittstelle (SSI, Subsystem Interface) an JES3 schickt. Es wird ein Zwischenspeicherbereich (STA, Staging Area) eingerichtet, zu dem ein Zeiger auf den Eintrag der SYSOUT-Datenmenge, also der JDS, gehört. Der STA wird über die SSI zu dem JES3- Adreßbereich geschickt. Die andere Möglichkeit besteht, wenn ein Benutzer einer Time-Sharing-Option (TSQ) mit dem TSO- Befehl SUBMIT interaktiv einen Auftrag übergibt (Bedarfsauswahlaufträge). Das Format zu dem SUBMIT-Befehl lautet SUBMIT dsn, wobei dsn eine Datenmenge ist, die einen Auftragseingabestrom enthält. Als Ergebnis des SUBMIT-Befehls des Benutzers erzeugt TSO dynamisch eine Datenmenge für interne Leser oder weist diese zu und schreibt die Sätze der Auftragssteuersprache (JCL) über die SSI auf den internen Leser. Insbesondere weist JES3 der Datenmenge für interne Leser 2 bis 9 Spulenspurgruppen zu. Die Datenmenge wird als JES3-Mehrsatzdatei (MRF, Multiple Record File) verarbeitet. In dem Adreßbereich des TSO-Benutzers wird ein Ressourcenzuweisungsblock (RAB, Resource Allocation Block) angelegt. Dieser Block wird von JES3 verwendet, um Lese- und Schreibanforderungen im Adreßbereich des Benutzers zu verarbeiten, und enthält Zeiger auf alle Spulenspurgruppen, die der Datenmenge zugeordnet sind. JES3 erstellt einen Eintrag in der Auftragsdatenmenge (JDS) für die Datenmenge für interne Leser. Der JDS-Eintrag enthält einen Zeiger auf den ersten Satz der Datenmenge auf der Spule. Dieser JDS- Eintrag ist Teil des JDS-Blocks, der dem Auftrag für interne Leser entspricht, der den TSO-Benutzer vertritt. TSO liest alle Sätze von der durch den SUBMIT-Befehl angegebenen Datenmenge ein und schreibt sie zurück in die Datenmenge für interne Leser. Wenn alle Sätze übertragen sind, schickt TSO die Datenmenge für interne Leser in den JES3-Adreßbereich. Es wird ein Zwischenspeicherbereich angelegt, der einen Zeiger auf den JDS-Eintrag der Datenmenge für interne Leser umfaßt. Der STA wird über die SSI in den JES3-Adreßbereich geschickt. In beiden Fällen wird die SSI-Anforderung zur Verarbeitung von Datenmengen in den JES3-Adreßbereich geschickt. Ein Modul (IATMSGC) empfängt die Anforderung und ruft ein anderes Modul (IATDMJA) auf, um die Anforderung zu verarbeiten, also den STA zu verarbeiten. Das IATDMJA-Modul bekommt eine Auftragsnummer (AJOBNUM) und gibt dann ein SPINOFF-Makro aus. Das IATDMJA-Modul ruft das IATOSDR-Modul auf, um die Datenmenge für interne Leser zu verarbeiten, auf die der STA als Spinoff-Datenmenge zeigt. Das IATOSDR-Modul kopiert also den JDS-Eintrag des neuen Eingabeauftragsstroms (indem es letztlich die Datenmenge für interne Leser hinzufügt) in einen JOB0-JDS-Block (der unten erörtert wird).
Intern behandelt der Ausgabedienst mit anderen Worten eine Datenmenge, z. B. eine SYSOUT-Datenmenge, die für einen internen Leser bestimmt ist, als Spinoff-Datenmenge, die JES3 verarbeiten kann, während der Auftrag (der die Datenmenge erzeugt hat) noch ausgeführt wird. Dabei nimmt der Ausgabedienst einen Eintrag (der der Datenmenge entspricht) in den JDS-Block auf, der einen Pseudoauftrag (JOB0) vertritt, der während der Initialisierung von JES3 erzeugt wird. JOB0 dient strikt dazu, Spinoff-Datenmengen zu verfolgen, die von DSPs des JES3 erzeugt werden. Der Ausgabedienst baut dann ein Ausgabedienstelement (OSE, Output Service Element) für die Datenmenge auf und stellt das OSE in die Warteschlange zum Halten des Ausgabedienstes. An diesem Punkt stoppt die Verarbeitung, bis eine Kopie eines internen Lesers (INTRDR DSP) abgefertigt ist. Sind keine freien Kopien des Programms INTRDR DSP vorhanden, geschieht nichts, bis der Bediener einen internen Leser mit dem Befehl *,INTRDR aufruft. Interner Leser des JES3-JOB0
JOB0 ist ein spezieller "Pseudoauftrag", der während der Initialisierung des Ausgabedienstes von JES3 auf einem DASD erzeugt wird. JOB0 vertritt den Auftragsstrom mit dem Befehl DD. Diese Auftragsstruktur des "Pseudoauftrags wird mit folgenden Steuerblöcken erzeugt. (Diese Steuerblöcke in Bezug zu dem JCT-Eintrag sind in Fig. 1e gezeigt.)
Ein Auftragsbeschreibungs- und Buchungsblock (JDAB, Job Description and Accounting Block) 40 wird gleichzeitig mit dem JCT-Eintrag 30 aufgebaut. JDABs liefern den DSPs Daten über Aufträge und machen JCT-Zugriffe überflüssig. Im allgemeinen werden Einträge, die die einzelnen Planungselemente in einer JCT vertreten, an den JDAB angehängt, um eine DSP-Buchung für jedes für den Auftrag erforderliche DSP zu liefern.
Ein Steuerblock für die Auftragsdatenmenge (JDS) 42 wird während der Verarbeitung des JES3-Eingabedienstes aufgebaut und enthält zunächst die Datenmenge, die die JCL für den Auftrag (JESJCL), zwei Meldungsdatenmengen für vom System erzeugte Meldungen und von DSPs erzeugte Meldungen (JESMSG) sowie alle SYSIN-Daten für den Auftrag (JESIN) enthält. Einträge für die (bereits erörterten) SYSOUT-Datenmengen (die auf diese Datenmengen zeigen) werden in die JDS aufgenommen, wenn die Datenmengen während der Ausführung von MVS/XA geöffnet werden. Diese Auftragsdatenmenge enthält auch die Sätze, die in die SYSOUT-Datenmenge geschrieben wurden.
Ein Auftragsverwaltungssatz (JMR, Job Management Record) 44 wird während der Verarbeitung des Eingabedienstes aufgebaut und enthält die Auftragsbuchungsinformationen.
Ein Steuerblock für das Ausgabedienstelement (OSE) 46 wird erzeugt, um eine Menge von Merkmalen von SYSOUT-Datenmengen aufzunehmen, die sich auf eine oder mehrere Datenmengen beziehen, die während der Verarbeitung des Eingabedienstes verwaltet werden sollen. Das erste OSE für einen Auftrag wird während der Verarbeitung des Eingabedienstes aufgebaut und auf einen Spulendatenträger geschrieben. Später, während der Verarbeitung des Ausgabedienstes, wird dieses OSE vollendet, und andere können für den Auftrag erzeugt werden. Diese Elemente werden zur "Ausgabewarteschlange".
Eine Auftragsspurzuweisung (JTAT, Job Track Allocation) 48 wird erzeugt und ist eine Liste der Spulenspurgruppen, die einem Auftrag zugewiesen sind.
Es gibt auch andere auftragsbezogene Steuerblöcke, deren Erörterung für ein Verständnis der Implementierung der hier beschriebenen Erfindung nicht unbedingt erforderlich ist.
Da bei JOB0 kein JCT erzeugt wird, kommt JOB0 nicht für die Planung durch das JSS in Frage, da es keine Planungselemente gibt. (Der JDAB verfügt nämlich nicht über Planungselemente, mit denen das JSS Einträge in der FCT aufbauen kann.) JES3 verwendet JOB0 nur, um Spinoff-Datenmengen zu speichern, die von den nachstehend genannten Quellen geliefert werden, bis sie von dem Ausgabedienst verarbeitet werden können:
1. alle Datenmengen für interne Leser;
2. Spinoff-Datenmengen, die von JES3-DSPs erzeugt wurden; und
3. Aufträge, die von anderen Systemen über eine Systemnetzwerkarchitektur bzw. ein Netzwerkauftragseintragsnetzwerk übergeben wurden.
Die Spinoff-Datenmengen, die von Aufträgen erzeugt wurden, die in MVS/XA ablaufen, und auf JOB0 gespeichert werden, werden mit Hilfe des internen Leserprogramms direkt dem JES3- Ausgabedienst übergeben.
Verarbeitung für interne Leser: MVS/XA verarbeitet Datenmengen, die dem internen Leser zugewiesen sind, indem es sie über die SSI, die die Kommunikationsschnittstelle zwischen MVS/XA und einem oder mehreren Subsystemen wie JES3 darstellt, an JES3 schickt. Letztlich fordert MVS/XA mit Hilfe der SSI Dienste von JES3 an. Einige Anforderungen können vollständig von JES3-SSI-Modulen im Adreßbereich des Aufrufers bearbeitet werden. In den meisten Fällen sind für die Anforderung jedoch die Dienste des JES3-Adreßbereichs erforderlich. Im JES3-Adreßbereich wird die SSI-Anforderung von dem Modul IATMSGC verarbeitet, das wiederum das Modul IATDMJA aufruft. IATDMJA übergibt die Datenmenge, wie oben beschrieben, über das JES3-SPINOFF-Makro an die Spinoff- Verarbeitung.
Das SPINOFF-Makro wird von dem Modul IATOSDR verarbeitet. IATOSDR liest jede Einzelsatzdatei (SRF, Single Record File), also jeden Eintrag, der zu JOB0 gehörenden JDS von dem Spulengerät ein. IATOSDR hält an, sobald es einen freien JDS- Eintrag findet oder wenn es bei der letzten SRF in der JDS- Kette, d. h. SRF-Kette, angelangt. Wird ein freier JDS-Eintrag gefunden, kopiert IATOSDR die Datenmenge (für interne Leser) in den JDS-Eintrag. Andernfalls wird in der letzten SRF der verketteten SRFs ein neuer JDS-Eintrag angelegt, und die Datenmenge wird in den "neuen" JDS-Eintrag kopiert.
Der interne Leser des JES3 (INTRDR) ist ein "aufgerufener Auftrag" (eine Anforderung), der nicht durch die JCL definiert ist. (Dieser aufgerufene Auftrag wird intern von JES3 als Reaktion auf den Befehl *CALL erzeugt.) Der JCT- Eintrag, der diesem aufgerufenen Auftrag entspricht, enthält ein INTRDR-Planungselement, das das für diese Anforderung (zum Verarbeiten der Datenmenge in einem JOB0-JDS-Eintrag) benötigte DSP, also INTRDR-DSP, sowie ein Löschplanungselement darstellt. Wenn das INTRDR DSP abgefertigt wird, liest es das OSE für die Datenmenge, sucht den entsprechenden Eintrag in der JDS von JOB0 und ruft den JES3-Eingabedienst auf, um die Datenmenge als Eingabestrom zu verarbeiten. Das von dem JSS erzeugte Treibermodul für das INTRDR-DSP ist IATISIR. IATISIR ruft den normalen JES3- Eingabedienst-DSP-Treiber IATISDV auf, um die Datenmenge zu verarbeiten. IATISDV gibt das IATXOSPC-Makro aus, das eine JES3-Ausgabedienstroutine zum Durchsuchen der JOB0-JDS-Kette nach einem JDS-Zeiger auf eine Datenmenge für interne Leser (Spinoff-Datenmenge) auf JOB0 aufruft. Wenn sie eine findet, wird ein Zeiger auf den JDS-Eintrag auf JOB0 an IATISDV zurückgeleitet, das dann ein anderes Modul (IATISLG) lädt und verarbeitet, um die Datenmenge auf JOB0 zu verarbeiten, als käme sie von einem physischen Kartenleser. Der Eingabedienst baut dann die üblichen Auftragssteuerblöcke für die Datenmenge auf, darunter eine neue JDS für den Auftrag, und befreit den JDS-Eintrag, der der ursprünglichen Ausgabedatenmenge entspricht, von dem JDS des JOB0. Wenn die Datenmenge oder der Auftragsstrom in dem JOB0-JDS-Eintrag verarbeitet ist, also nach der Rückgabe von dem IATISLG- Modul, gibt IATISDV wieder das IATXOSPC-Makro aus, um mehr Arbeit für den internen Leser zu finden. Wenn noch ein JDS- Eintrag gefunden wird, wird die Steuerung zum Verarbeiten der Datenmenge auf JOB0 an das IATISLG-Modul zurückgegeben. Der obige Vorgang setzt sich fort, bis der JES3-Ausgabedienst keine weiteren JOB0-JDS-Einträge für den internen Leser findet. Die Steuerung wird also an das IATISIR-Modul zurückgegeben, das dann in einen Wartezustand geht. IATISIR bleibt in diesem Wartezustand, bis von IATDMJA eine weitere Datenmenge für interne Leser erzeugt wird. In diesem Falle zwingt IATOSDR IATISIR zum Verlassen des Wartezustands, nachdem es den JDS-Zeiger auf die Datenmenge in einen JOB0- JDS-Eintrag aufgenommen hat. IATISIR ruft dann IATISDV auf und geht dann nach der Verarbeitung von mindestens einer weiteren Datenmenge für interne Leser wieder in den Wartezustand. Dieser Vorgang setzt sich fort, bis der Auftrag für interne Leser aus dem System entfernt wird.
Aufträge für interne Leser werden manuell von Systembedienern gestartet und beendet. Um einen internen Leser zu starten, gibt der Systembediener von einer Systemkonsole aus den Befehl *X, INTRDR. Daraufhin geht die Steuerung auf den Treiber (IATISIR) für interne Leser über. (Um einen Auftrag für interne Leser zu entfernen, würde der Systembediener von einer Systemkonsole aus den Befehl für interne Leser *C INTRDR geben.) Dieser manuelle Vorgang bedeutet, daß der Systembediener bestimmen (raten) muß, wieviele dieser Aufträge erforderlich wären, um mit einer bestimmten Arbeitsbelastung fertigzuwerden. Wenn er zu niedrig liegt, gibt es nicht genug interne Leser, um mit der Arbeitsbelastung effektiv fertigzuwerden. Liegt er zu hoch, müßte das System den zusätzlichen Aufwand treiben, einen oder mehrere untätige interne Leser zu verwalten, von denen jeder durch eine FCT vertreten wird, die von dem MFM durchsucht werden muß, um festzustellen, daß er nicht hätte geplant werden müssen.
Der obige Vorgang erzeugt einen "Engpaß" in einer großen interaktiven Computersystemumgebung, wenn Aufträge (Anforderungen) schneller an den JES3-Eingabedienst übergeben werden, als JES3 sie aufnehmen kann. Natürlich verkürzt sich die Warteschlange jedes Mal, wenn eine Anforderung verarbeitet wird, doch wenn Anforderungen schneller eingehen, als sie verarbeitet werden können, kann die Warteschlange sehr lang werden. Dies führt zu einer sehr langen JOB0-JDS- Kette, die einen Rückstau in der Ausgabedienstauswahlverarbeitung verursacht, weil für den Zugriff auf jeweils einen Eintrag (Satz) in der Kette eine zeitaufwendige I/O erforderlich ist und die gesamte Kette gelesen werden muß, um festzustellen, wo bei Bedarf ein "neuer" Satz eingefügt wurde. Alle Anforderungen zur Verarbeitung von Hintergrundaufträgen aus allen Quellen werden mit anderen Worten in eine einzige (lange) plattenresidente JDS-Warteschlange gestellt, die in einem speziellen permanenten Auftrag "verankert" ist, der als JOB0 bezeichnet wird. Infolgedessen verlängert sich die Zeit zur Ausführung von Aufträgen, die TSO-Benutzer an Terminals, die als Vordergrundsitzungen laufen, zur Ausführung dem Hintergrund übergeben. Wenn dies geschieht, werden die Benutzer frustriert, weil ihr Auftrag zur Verarbeitung angenommen wurde, z. B. durch den SUBMIT-Befehl der Time- Sharing-Option (TSO), aber nicht lokalisiert werden kann. Bevor der Auftrag eine Auftragsnummer bekommt, kann der Benutzer also nicht des Status seines Auftrags feststellen, z. B. mit dem TSO-Befehl STATUS oder dem Bedienerbefehl INQUIRY.
Ein weiteres Problem ist die Verzögerung der Verarbeitung von Bedarfsauswahlaufträgen, z. B. TSO LOGONs und gestartete Aufgaben (Initiator). Dies liegt an folgenden Faktoren:
1. Wenn mehr Aufträge in JOB0 aufgenommen werden, nimmt seine JDS durch die Aufnahme verketteter Sätze (SRF-Sätze) größenmäßig proportional zu. Dies führt bei der Suche nach verketteten Sätzen zu längeren Suchzeiten, wenn die Zahl der Eingabe-/Ausgabe-Aufrufe (I/O-Aufrufe) steigt, weil jeder SRF-Satz vom Plattenspeicher gelesen und, wenn er sich geändert hat, wieder auf den Plattenspeicher zurückgeschrieben werden muß. Das Programm, das die lange JDS-Kette verarbeitet, ist auch für die Verarbeitung der TSO LOGONs verantwortlich.
2. Das Modul IATMSGC steuert die Verarbeitung der JOB0-JDS (über Aufrufe an ein anderes Modul (IATDMJA)). Das Modul IATMSGC ist jedoch auch direkt an der Verarbeitung von Bedarfsauswahlanforderungen beteiligt, also dem TSO LOGON, dem MOUNT-Befehl und dem START-Befehl. Da das Modul IATMSGC ein DSP-Treiber mit maximal einer DSP- Verwendung ist, kann es nur eine Anforderung (einen Auftrag) gleichzeitig verarbeiten. Dadurch entsteht Konkurrenz um Verarbeitungszeit zwischen Aufträgen für interne Leser und Bedarfsauswahlanforderungen. Dies führt natürlich dazu, daß es für TSO-Benutzer viel zu lange dauert, sich bei dem System anzumelden. Wenn das Modul IATDMJA während der Verarbeitung von Aufträgen für interne Leser unverhältnismäßig lange mit I/O beschäftigt ist, werden Bedarfsauswahlaufträge verzögert oder sogar beendet, wenn die JOB0-JDS in Gebrauch ist. (Selbst ohne Unterstützung für interne Leser von JOB0, so haben Leistungsstudien ergeben, verursacht das Modul IATDMJA einen schweren I/O-Leistungsengpaß.)
Wenn deterministisch eine bestimmte Zahl interner Leser ausgewählt wird, die sich jederzeit in dem System befinden soll, kann diese Zahl abhängig von der Arbeitsmenge, der Systemgröße, der Benutzerzahl usw. zu hoch oder zu niedrig sein. Wenn sie zu niedrig ist, kommt es wieder zu dem "Engpaß". Wenn sie zu hoch ist, verbrauchen die auf Arbeit wartenden internen Leser Systemressourcen, virtuellen und realen Speicherplatz und vor allem Zyklen, die der Abfertiger benötigt, um die Warteschlange mit Aufträgen zu durchsuchen, die tatsächliche Arbeit zur Abfertigung suchen. Mit Blick auf die Zukunft könnte außerdem eine bestimmte Zahl von Aufträgen für interne Leser, die für heutige Systeme "optimal" gewählt sind, einen "Engpaß" in einem künftigen System verursachen, das viel schneller als das heutige System ist und mit einer höheren Arbeitsbelastung fertig wird. Dies wäre besonders der Fall, wenn die I/O-Geschwindigkeiten nicht mit den Verbesserungen der Prozessorgeschwindigkeiten Schritt halten.
Es ist daher ein Ziel dieser Erfindung, den Engpaß zu beseitigen, der durch Aufträge verursacht wird, die schneller an eine Betriebssystemkomponente übergeben werden, als die Komponente sie annehmen kann.
Es ist ein Ziel dieser Erfindung, dynamisch, also automatisch und kontinuierlich, Aufträge für interne Leser zu erzeugen und zu löschen, die zur Verfügung stehen, um die ständig wechselnde Zahl von Eingabeauftragsströmen zu verarbeiten, und zugleich einen zu großen Systemaufwand und ein Durchgehen zu vermeiden.
Ein Ziel dieser Erfindung ist es, für die Bediener die Notwendigkeit zu beseitigen, Aufträge für interne Leser manuell zu starten oder zu löschen, wenn die Zahl der zu verarbeitenden Datenmengen mit der Zeit schwankt.
Es wird ein interaktives Computersystem beschrieben und beansprucht, das über ein Betriebssystem verfügt, das mit einem Subsystem kommuniziert, das einen Auftrag auf die Ausführung durch das Betriebssystem vorbereitet. Das Computersystem umfaßt ferner ein Unterstützungsprogramm, das eine von dem Auftrag benötigte Arbeitseinheit, eine Funktionssteuertabellenkette, in der ein Eintrag in der Kette dem Unterstützungsprogramm entspricht, ein Planungselement in dem Auftrag, das der Arbeitseinheit entspricht, die zur Verarbeitung des Auftrags ausgeführt werden muß, sowie eine Datenmenge mit einem von dem Auftrag erzeugten Eingabestrom verarbeitet. Der verbesserte Subsystemeingabeprozeß umfaßt die Übertragung der Datenmenge direkt an einen Auftragsdatenmengen-Steuerblock, der zu einem dynamisch erzeugten internen Leser gehört, die Erzeugung eines Unterstützungsprogramms für interne Leser und dessen Aufnahme in einen Funktionssteuertabelleneintrag, das einem Planungselement in dem Auftrag für interne Leser entspricht und den Funktionssteuertabelleneintrag plant, sowie die Abfertigung des Unterstützungsprogramms für interne Leser und die Verarbeitung der Datenmenge.

Kurze Beschreibung der Zeichnungen

Figs. 1a-1e sind schematische Diagramme der Betriebssystemumgebung und der Eingabe- und Ausgabe-Dienstsubsysteme nach dem Stand der Technik im Hinblick auf die Funktion der internen Leser;
Fig. 2 ist ein schematisches Blockdiagramm des STA und der JDS eines Auftrags, in dem ein Eintrag in der JDS zum STA kopiert wird;
Fig. 3 ist ein schematisches Blockdiagramm der FCT- Kette, in der ein durch IATMSGC erzeugter FCT- Eintrag auf den STA zeigt;
Fig. 4 ist ein schematisches Blockdiagramm der Auftrags-JDS, von der ein Eintrag in der JDS direkt zu dem Subsystem übertragen wird;
Fig. 5a ist ein schematisches Blockdiagramm eines IRA und der IRE-Kette, die die internen Leser verfolgen, die die durch den zum Subsystem übertragenen JDS-Eintrag bezeichnete Datenmenge verarbeiten;
Fig. 5b ist ein schematisches Blockdiagramm einer JCT für interne Leser und einer entsprechenden JDS für interne Leser, die den zum Subsystem übertragenen JDS-Eintrag annimmt;
Fig. 6 ist ein schematisches Blockdiagramm, das die Beziehung zwischen einer untätigen IRE, einem RSQ, einer FCT, einer JCT für interne Leser und einer JDS für interne Leser zeigt;
Fig. 7 ist ein schematisches Blockdiagramm, das zeigt, wie eine IRE durch IATISIR erzeugt und in die IRE-Kette aufgenommen wird, wenn ein Auftrag für interne Leser verarbeitet werden soll;
Fig. 8 ist ein schematisches Blockdiagramm, das die Entfernung einer IRE nach der Löschung eines FCT durch IATISIR zeigt;
Fig. 9 ist ein schematisches Blockdiagramm mit Komponenten der Funktion der internen Leser zur Aufnahme von SEs, zusätzlichen Aufträgen für interne Leser und ihrer Zugehörigkeit zu FCTs;
Fig. 10 ist ein Ablaufdiagramm, das zeigt, welche Schritte unternommen werden, um festzustellen, ob untätige FCTs für die Verarbeitung einer Datenmenge vorhanden sind, auf die ein Eintrag in einer JDS für interne Leser weist; und
Fig. 11 ist ein Ablaufdiagramm, das zeigt, welche Schritte unternommen werden, um festzustellen, ob ein Auftrag für interne Leser gelöscht werden soll, sowie die Zustände Löschen/Anschlag oder Warten/Anschlag.
Die Funktion der internen Leser von MVS/XA wurde verbessert, um die Probleme und Unzulänglichkeiten der oben beschriebenen Funktion der internen Leser auszuräumen. Insbesondere wird der einzelne JOB0 nicht mehr für Aufträge für interne Leser verwendet, und der JES3-Eingabedienst (Prozeß) ist verbessert, wodurch der oben beschriebene "Engpaß" entfällt. Sobald Datenmengen mit den neuen, von Aufträgen erzeugten Eingabeströmen (während der Hauptdienstverarbeitung) dem JES3 von MVS/XA über die SSI zur Verfügung gestellt werden, wird im allgemeinen ein verbesserter JES3-Eingabedienst aufgerufen, der mehrere dynamisch (automatisch) erzeugte Aufträge für interne Leser (INTRDR JCTs) umfaßt, auf denen Auftragsanforderungen in eine Warteschlange gestellt werden. Der verbesserte JES3-Eingabedienst umfaßt die verbesserten Module IATISDV und IATISIR und das neue Modul IATISCD, die unten erörtert werden. Die Funktion des Moduls IATISCD umfaßt das Kopieren einer Datenmenge direkt zu einer INTRDR-JCT.
IATISCD erzeugt bei Bedarf auch INTRDR-FCTs und nimmt sie in die Warteschlange (oder Kette) der JES3-Aufträge (FCTs) als abfertigungsfähige Aufgaben auf. Sobald ein entsprechendes INTRDR-DSP abgefertigt ist, lokalisiert es die Datenmenge mit Hilfe seiner eigenen JDS. Das INTRDR-DSP ruft dann den Eingabedienst (IATISDV) auf, um die Datenmenge als von einem Auftrag erzeugten Eingabestrom zu verarbeiten. Ein Zähler für die Benutzung der internen Leser (in einem hier erörterten Ankerblock) und ein Zähler der Maximalbenutzung (im DSP- Wörterbuch), also die DSP-Max-Zählung, werden während der JES3-Initialisierung gesetzt. Das IATDMJA-Modul wurde geändert, damit es seine eigenen I/O-Anforderungen asynchron zu dem IATMSGC-Modul verarbeitet.
Wenn ein Eingabestrom an den internen Leser von JES3 übergeben wird, erzeugt MVS/XA dynamisch eine Datenmenge für interne Leser. Dazu gehört im allgemeinen die Zuweisung von Spulenplatz für die Datenmenge in Form von Spurgruppen (auf einem Direktzugriffsspeichergerät) und das Erzeugen eines JDS-Eintrags im JDS-Steuerblock, der einen Stapel- oder TSO- Benutzer-Auftrag (JCT) vertritt (zu ihm gehört). Wie oben erörtert, zeigt der JDS-Eintrag in dem JDS-Steuerblock auf die Spulenplätze, die die Datenmenge enthalten. Wenn MVS/XA zur Übergabe des Eingabeauftragsstroms, der in der Datenmenge für interne Leser enthalten ist, an JES3 bereit ist, wie in Fig. 2 dargestellt, so erzeugt es einen Zwischenspeicherbereich (STA) 13 im Adreßbereich des Benutzers. Dieser STA 13 enthält alle Informationen, die der JES3-Adreßbereich benötigt, um die SSI-Anforderung, z. B. den Zielcode, verarbeiten zu können. Die Adresse des JDS-Eintrags 15 der Datenmenge für interne Leser wird in den STA 13 kopiert, wie durch die Linie 3 in Fig. 2 dargestellt. Dieser Eintrag in STA 13 wird von dem JDS-Steuerblock 17 kopiert, der zu einem Stapel- oder TSO-Benutzer-Auftrag 19 gehört. Der STA 13 wird dann über die SSI 21 zu dem JES3-Adreßbereich übertragen. Das IATMSGC-Modul bekommt die Adresse des STA 13 und verarbeitet sie in dem JES3-Adreßbereich. Wie in Fig. 3 gezeigt, erzeugt und plant das IATMSGC-Modul 27, anstatt zur Verarbeitung des JDS-Eintrags das IATDMJA-Modul aufzurufen, einen neuen FCT-Steuerblock 23. Der neu erzeugte FCT-Block wird initialisiert, so daß er mit IATDMJA 25 als DSP- Treibermodul läuft. Der neue FCT-Block 23 wird von dem IATMSGC-Modul 27, wie in Fig. 3 dargestellt, entsprechend seiner Priorität in die bestehende FCT-Kette eingesetzt und enthält einen Zeiger auf den STA im JES3-Adreßbereich, speichert also die Adresse des STA in der FCT. (Dies ist eine Ausnahme von der üblichen Verarbeitung, bei der FCTs von dem JSS als Reaktion auf Planungselemente in der JES3-JCT erzeugt und in die bestehende FCT-Kette aufgenommen werden.) Das IATMSGC-Modul sucht dann nach einem anderen STA, um ihn in dem JES3-Adreßbereich zu verarbeiten. Die neue FCT, also FCT 23, wird schließlich von dem MFM abgefertigt.
Das IATDMJA-Treibermodul 25 läuft asynchron zu dem IATMSGC- Modul 27, indem es zuerst den STA abruft, den JDS-Eintrag (INTRDR) 15 der Datenmenge für interne Leser, also die JDS 17 des Stapels oder TSO-Benutzers, von der Spule abruft, eine lokale Kopie des Eintrags 15, also die INTRDR-Kopie 31, anfertigt, wie in Fig. 4 dargestellt, und den ursprünglichen JDS-Eintrag (INTRDR) 15 löscht oder "ausnullt". Dadurch wird letztlich das "Eigentum" an der Datenmenge für interne Leser, die anfänglich entweder von dem Stapel- oder dem TSO- Benutzer-Auftrag erzeugt wurde, (direkt) auf JES3 übertragen. Es wird eine Auftragsnummer besorgt, und das Modul IATDMJA ruft dann das Modul IATISCD auf, um den JDS-Eintrag (INTRDR- Kopie 31) zu verarbeiten, der den Eingabeauftragsstrom enthält.
In Fig. 5a erzeugt und initialisiert das Modul IATISCD einen neuen Ankerblock für interne Leser (IRA, Internal Reader Anchor), sofern ein solcher noch nicht vorhanden ist. Der IDLE-Zähler 35 in dem IRA-Block gibt an, bei wie vielen Elementen des internen Lesers (IRE, Internal Reader Elements) das Untätigkeits-Flag gesetzt ist, wobei jedes untätige IRE einem Auftrag für interne Leser entspricht, der im Wartezustand (Warten auf Arbeit) in der Arbeitswarteschlange gehalten wird. Wenn der Inhalt des IDLE-Zählers größer als Null ist, durchsucht IATISCD die IRE-Kette, auf die der IRA- Block zeigt, nach dem ersten IRE-Block mit gesetztem IDLE- Flag, also IDLE*, wie in Fig. 5a gezeigt. Von den drei in Fig. 5a gezeigten IRE-Blöcken ist nur einer, nämlich IRE 37, "untätig", wie durch das IDLE-Flag und durch den Inhalt des IDLE-Zählers 35 angezeigt. Das gesetzte IDLE-Flag in IRE 37 zeigt an, daß die INTRDR-FCT, also FCT 24 in Fig. 6, die zu dem (untätigen) IRE 37 gehört, die Verarbeitung eines ihr zugewiesenen Eingabeauftragsstroms beendet hat und (verfügbar) auf mehr Arbeit wartet, also auf einen weiteren Eingabeauftragsstrom. Die ITNRDR-FCT 24 ist untätig oder befindet sich im Wartezustand. Wenn sich keine INTRDR-JCT im Wartezustand in der Warteschlange befindet (kein untätiges IRE gefunden wird), erzeugt das IATSCD-Modul die INTRDR-JCT 53 gemeinsam mit den zugehörigen Steuerblöcken JMR 55, JDS 57 und JDAB 59 (oben beschrieben), wie in Fig. 5b dargestellt. Der JDS-Eintrag, also die INTRDR-Kopie 31, wird in den neuen (und einzigen) JDS-Eintrag (zweite INTRDR-Kopie 61) kopiert, der der neu erzeugten INTRDR-JCT 53 entspricht. Das IATISCD- Modul nimmt dann die INTRDR-JCT in die bestehende JCT-Kette (Auftragswarteschlange) auf, wo sie schließlich vom JSS geplant wird. Das IATISCD-Modul inkrementiert auch den ACTIVE-Zähler 43 in dem IRA (dargestellt in Fig. 5a) um Eins. Die neue INTRDR-JCT 53 umfaßt ferner zwei Planungselemente, nämlich das INTRDR-Planungselement 63 und das PURGE- Planungselement 65, die auf der FCT-Kette durch DSPs vertreten sind, die die von den Planungselementen angeforderte Arbeit erledigen.
IATISCD kopiert also den JDS-Eintrag (die INTRDR-Kopie 31) in die JDS eines (bestehenden) Auftrags für interne Leser in JES3. Wenn keine Aufträge für interne Leser verfügbar sind, erzeugt IATISCD einen und nimmt ihn in die JES3-JCT- Warteschlange (Auftragswarteschlange) auf. Wenn das IATISCD- Modul mit einem Fehler zurückgegeben wird, wird die für den neuen Auftrag besorgte Auftragsnummer für den neuen Auftrag zurückgegeben. In jedem Falle wird der STA an das aufrufende Modul zurückgegeben, und die IATDMJA-FCT 24 wird aus der FCT- Kette entfernt. (Das SPINOFF-Makro wird nicht aufgerufen, da IATDMJA die Datenmenge nicht zur Spinoff-Verarbeitung übergibt.) Infolgedessen werden zwischen der Zeit, zu der die ursprüngliche Datenmenge erzeugt wird, und der Zeit, zu der ein interner Leser sie verarbeitet, JOB0 (und seine JDS- Kette) und der Ausgabedienst nicht verwendet, um einen Auftrag für interne Leser zu planen und zu "verfolgen". Nur der JES3-Eingabedienst bearbeitet also die Datenmengen direkt, die zu internen Lesern geleitet werden. Datenmengen, die für den internen Leser bestimmt sind, werden nicht in die Ausgabedienst-Haltewarteschlange eingereiht. Das IATISIR- Modul erzeugt also keinen Arbeitsauswahlparameterbereich.
Wie in Fig. 5a dargestellt, zeigt auf den IRA-Block 33 die JES3-Übertragungsvektortabelle (TVT, Transfer Vector Table) 39 im JES3-Adreßbereich. (Die TVT enthält die Adressen der meisten Steuerblöcke im JES3-Adreßbereich, die Eintragspunktadressen der meisten JES3-Dienste und die Statusinformationen für alle JES3-Funktionen.)
Der IRA enthält Informationen, die JES3 benötigt, um die Planung der Aufträge für interne Leser zu steuern, und dient als Anker für (weist auf) die Kette aus IRE-Blöcken, wie durch den Pfeil 41 angezeigt wird. Er enthält eine Angabe darüber, wie viele Aufträge für interne Leser (JCTs) von dem IATISCD-Modul erzeugt wurden, (den Inhalt des ACTIVE-Zählers 43) sowie eine Angabe darüber, wie viele dieser Aufträge auf Arbeit warten (den Inhalt des IDLE-Zählers 35).
Jeder IRE-Block in der in Fig. 5a dargestellten IRE-Kette entspricht einem nachfolgenden in JES3 gefundenen DSP für interne Leser, also für jede INTRDR-FCT, die eine vom JSS als Reaktion auf ein INTRDR-Planungselement, das in einem zuvor von dem IATISCD-Modul erzeugen INTRDR-JCT gefunden wurde, geplantes DSP vertritt. Ein IRE-Block gehört zu einem INTRDR- FCT. Der IRE-Block enthält Informationen, die von JES3 bei der Steuerung der Planung einzelner DSPs für interne Leser verwendet werden.
Wie oben angedeutet, durchsucht IATISCD die gesamte IRE- Kette, beginnend mit dem ersten IRE-Block, auf den der IRA- Block weist, bis es ein IRE, z. B. den IRE-Block 37, findet, der einen untätigen FCT für interne Leser vertritt, z. B. den FCT-Block 23. Wie in Fig. 6 dargestellt, weist der untätige IRE-Block 37 auf die RESQUEUE (RSQ) 43, die auf die untätige INTRDR-FCT 23 weist. Die RSQ wird verwendet, um die JDS für einen Auftrag zu lokalisieren, wenn die INTRDR-FCT untätig wird. Das Treibermodul für die INTRDR-FCT ist das IATISIR- Modul 49. Das Untätigkeits-Flag in IRE 37 zeigt an, daß IATISIR mit der Verarbeitung einer früheren Datenmenge für interne Leser fertig ist und auf die nächste wartet. Dieses Warten erfolgt über eine WAIT/POST-Schnittstelle, die in Block 280 in Fig. 11 dargestellt ist. IATISIR geht in den Wartezustand, indem ein Byte 45 des Speichers als sein WAIT BYTE festgelegt und mit Null initialisiert wird. JES3 plant die INTRDR-FCT erst neu, wenn sich dieses Byte ändert. Wenn sich das Byte ändert, wird es als POSTING bezeichnet. Jedes Bit in dem Byte kann für eine andere Posting-Bedingung stehen. So hat etwa das Wartebyte für IATISIR ein Arbeit-zuerledigen-Bit und ein Löschen-Bit. Die Adresse des WAIT BYTE für die INTRDR-FCT, die zu der gewählten untätigen INTRDR-FCT gehört, befindet sich in den zugehörigen IRE-Blöcken, wie in Fig. 6 dargestellt.
Wenn eine untätige INTRDR-FCT gefunden ist, kopiert das IATISCD-Modul den JDS-Eintrag (INTRDR-Kopie 31) der Datenmenge für interne Leser in den ersten (und einzigen) JDS-Eintrag (zweite INTRDR-Kopie 61) der INTRDR-JCT 53, auf die RSQ 43 weist. Das IATISCD holt sich die Adresse des WAIT BYTE 45 von IRE 37 und schlägt IATISIR 49 mit einer Arbeitzu-erledigen-Anforderung (binär 01000000) an. Das IATISCD- Modul schaltet das IDLE-Flag in IRE 37 dann "aus" (setzt es zurück) und dekrementiert den IDLE-Zähler 35 in IRA 33. Die INTRDR-FCT 24 kann dann von dem MFM neu geplant werden, um die Datenmenge für interne Leser, also einen Eingabedatenstrom, zu verarbeiten, auf den der JDS-Eintrag weist.
Wenn der JSS das INTRDR-Planungselement 63 in der INTRDR-JCT 53 verarbeitet, erzeugt er eine INTRDR-FCT 75, wie in Fig. 7 dargestellt. Das Treibermodul für die INTRDR-FCT ist IATISIR 71. Wenn die INTRDR-FCT zunächst vom MFM geplant wird, erzeugt IATISIR einen IRE-Block 73, der sie vertreten soll (wie konzeptuell in Fig. 7 dargestellt). Dieses IRE wird am Anfang der IRE-Kette hinzugefügt. Das IATISIR-Modul ruft dann den JES3-Eingabedienst auf, also das IATISDV-Modul, um den Eingabeauftragsstrom zu verarbeiten, auf den der JDS-Eintrag der INTRDR-JCT (zweite INTRDR-Kopie 61) weist. Wenn der JES3- Eingabedienst (IATISDV) fertig ist, gibt er die Steuerung an IATISIR zurück. IATISIR stellt dann fest, ob die INTRDR-FCT, die es vertritt, erforderlich ist, um mit der aktuellen Arbeitsbelastung des Systems fertigzuwerden. Genaues darüber, wie IATISIR diese Feststellung trifft, ist unten angegeben.
Sobald die Arbeit zugewiesen ist, also ein Auftrag für interne Leser durch den JSS geplant ist, wird das IATISDV- Modul geladen und von dem IATISIR-Modul aufgerufen, die Arbeit zu verarbeiten. Zu beachten ist, daß das IATISDV-Modul kein Makro (IATXOSPC) ausgibt, um von dem Ausgabedienst wie vorher Arbeit, d. h. eine Datenmenge für interne Leser, zu erhalten. Statt dessen kann der JDS-Eintrag, also die Daten für das IATISDV-Modul, direkt und unmittelbar von der JDS des Auftrags für interne Leser (zweite INTRDR-Kopie 61, wie in Fig. 5b dargestellt) bezogen werden statt von dem Ausgabedienst, also statt von der JOB0-JDS. Nach der Rückgabe von dem IATISDV-Modul (wenn die Verarbeitung des Auftragsstroms beendet ist) wird die Steuerung an das IATISIR-Modul zurückgegeben, das den internen Leser löscht, wenn die INTRDR-FCT vom Bediener oder von dem IATISCD-Modul aufgrund von JDS-Problemen gelöscht wurde oder wenn die Zahl der untätigen Aufträge für interne Leser über einer vorbestimmten Grenze liegt oder wenn die Zahl der aktiven INTRDR-FCT größer ist als die maximale INTRDR-DSP-Zählung. (Diese letztere Löschung erfolgt, um zu vermeiden, daß Aufträge für interne Leser, die nicht geplant werden können, auf der JES3-Auftragswarteschlange warten.) Wird festgestellt, daß die INTRDR-FCT noch erforderlich sein könnte, um mit der aktuellen Arbeitsbelastung des Systems fertigzuwerden, und nicht gelöscht werden sollte, geht IATISIR in den Wartezustand. Wenn eine neue Datenmenge erzeugt wird, kopiert das IATISCD-Modul ihren JDS-Eintrag (INTRDR-Kopie 31) auf die JDS (zweite INTRDR-Kopie 61) des Auftrags für interne Leser (INTRDR-JCT 53) und zwingt IATISIR zum Verlassen des Wartezustands. IATISIR ruft dann IATISDV auf und wiederholt den obigen Prozeß. Wenn keine Arbeit zu tun ist, wird die INTRDR-FCT gelöscht. Das Löschen des Auftrags für interne Leser umfaßt das Entfernen des IRE- Blocks aus der Kette, das Dekrementieren des ACTIVE-Zählers im IRA und die Rückgabe der Steuerung an den JSS. Zu beachten ist, daß das IATDMJA-Modul nicht mehr von dem IATMSGC-Modul zur Verarbeitung von JOB0 aufgerufen wird, das vorher die von JES3-DSPs erzeugten Spinoff-Datenmengen verfolgt hat. Infolge der Verbesserungen an der Funktion der internen Leser wurde die Planung und "Verfolgung" der Aufträge für interne Leser optimiert, während gleichzeitig die Zahl der Schritte gesenkt wurde, die bei der Verarbeitung von Aufträgen aufgerufen werden.
Mit Hilfe des IATISCD-Moduls werden Aufträge für interne Leser jetzt dynamisch (automatisch und kontinuierlich) erzeugt (und geplant) und gelöscht. Der Bediener muß nicht mehr raten, wie viele interne Leser geplant werden müssen. Wenn die Arbeitsbelastung des Systems steigt, erzeugt JES3 durch IATISCD automatisch neue interne Leser (Aufträge) oder weist die Arbeit bereits erzeugten internen Lesern (Aufträgen) zu, die mit ihrer Verarbeitung fertig sind und warten. Um mit der dynamischen Verarbeitung von Datenmengen fertigzuwerden, wurde die oben beschriebene Steuerblockstruktur erzeugt, um die Aufträge für interne Leser zu verfolgen.
Fig. 9 kombiniert alle wichtigen Elemente der verbesserten Funktion der internen Leser, die oben im einzelnen beschrieben ist. Ein IRA-Block 90 weist auf eine IRE-Kette 92, wobei jeder IRE-Block in der Kette auf einen RSQ weist. Jeder RSQ weist auf eine FCT für interne Leser, nämlich die INTRDR-FCT 94, die Teil der FCT-Kette ist. Jedes Planungselement, also das INTRDR-SE 98, ist auf der FCT-Kette durch ein DSP vertreten, das die Arbeit erledigt, die für dieses spezielle Planungselement in der JCT für interne Leser erforderlich ist, z. B. die INTRDR-JCT 96. Jeder Auftrag für interne Leser verfügt über eine JDS, z. B. die JDS 100, die der INTRDR-JCT 96 entspricht, die einen Eintrag enthält, der auf die Datenmenge mit dem von Aufträgen erzeugten Eingabestrom weist, der verarbeitet werden soll. Der JSS wählt jedes Planungselement, das bereit ist, verarbeitet zu werden, indem er das DSP abfertigt, um die von dem Planungselement angeforderte Arbeit zu erledigen. In diesem Falle überträgt das INTRDR-SE 98 einen von Aufträgen erzeugten Eingabestrom, der durch einen Eintrag in der JDS 100 gekennzeichnet ist, direkt zur Verarbeitung zu den JES3- Eingabedienstprogrammen, z. B. IATISDV. Das Treibermodul für jedes zu einem INTRDR-Planungselement gehörende DSP ist IATISIR.
Zusammenfassend stellt, wie in dem Ablaufdiagramm in Fig. 10 gezeigt, das IATISCD-Modul, das von IATDMJA bei Block 110 aufgerufen wird, in Block 120 fest, ob der IRA-Block vorhanden ist. (Ist der IRA-Block nicht vorhanden, erzeugt und initialisiert IATISCD ihn, wie bei Block 130 dargestellt.) Das IATISCD-Modul durchsucht dann die aktuelle Kette der IRE-Steuerblöcke (IATYIREs), auf die der IRA weist, und sucht einen untätigen Auftrag für interne Leser (INTRDR- FCT), wie durch den Entscheidungsblock 140 dargestellt. Wenn ein untätiger Auftrag für interne Leser gefunden wird, wird die "neue" Datenmenge in dem JDS-Eintrag in die JDS des zuvor untätigen Auftrags für interne Leser aufgenommen (kopiert). Der IDLE-Zähler wird dekrementiert, und das IDLE-Flag wird in dem IRE zurückgesetzt, wie durch den Block 150 dargestellt. Das Arbeit-zu-erledigen-Flag wird gesetzt, IATISIR wird angeschlagen, und normalerweise erfolgt die Rückkehr zu dem IATDMJA-Modul, wie durch den Block 160 dargestellt. Wenn jedoch ein Auftrag für interne Leser nicht gefunden wird, erzeugt das IATISCD-Modul einen neuen Auftrag für interne Leser, indem es mehrere JES3-Auftragssteuerblöcke erzeugt und initialisiert, wie durch den Block 170 dargestellt. Für den Auftrag für interne Leser wird jetzt eine JCT erzeugt und initialisiert und in die JCT-Auftragswarteschlange aufgenommen, wie durch Block 180 dargestellt. Alle neuen Steuerblöcke werden ausgeschrieben, und die neue Auftragsstruktur für interne Leser wird in den JES3- Eingabedienst (die Auftragswarteschlange) aufgenommen. Der ACTIVE-Zähler wird dann in dem IRA inkrementiert. Wenn in einem der obigen Schritte ein Fehler gefunden wurde, erfolgt die Rückkehr zu dem IATDMJA-Modul.

IATISIR

Eine Optimierung erfolgt, wenn IATISIR die Steuerung von IATISDV erhält und feststellt, ob die kürzlich verwendete INTRDR-FCT noch benötigt wird, um mit der aktuellen Arbeitsbelastung des Systems fertigzuwerden. Um diese Feststellung zu treffen, führt IATISIR, das in dem Ablaufdiagramm in Fig. 11 dargestellt ist, den folgenden Prozeß durch:
Das IATISCD-Modul erzeugt und initialisiert für den geplanten Auftrag für interne Leser in JES3 (der dann in die bestehende IRE-Kette aufgenommen wird) einen neuen Block (IATTIRE) mit Elementen interner Leser (IRE), wie durch die Blöcke 200 und 210 in Fig. 11 dargestellt ist.
1. Wenn der JSS ein Planungselement findet, das ein DSP vertritt, das sich bereits bei der maximalen DSP-Zählung befindet, also bei der Höchstzahl der zulässigen FCTs, plant er nicht das Planungselement. Wenn IATISIR feststellt, daß die Zählung der aktiven internen Leser (ACTIVE-Zähler 43 in Fig. 5a) größer ist als die aktuelle Zählung der maximalen DSP-Verwendung, wie durch den Block 220 in Fig. 11 dargestellt, dann gibt es zumindest einen Auftrag für interne Leser (zumindest eine INTRDR-JCT) in der JES3- Auftragswarteschlange, der nicht geplant wird (bis der INTRDR-DSP-"Verwendungs"-Zähler durch Löschen eines aktiven Auftrags dekrementiert wird) IATISIR entscheidet dann, ob sein interner Leser (INTRDR-FCT) gelöscht werden soll und ob eine andere (wartende) INTRDR-FCT, die geplant werden soll, ermöglicht wird (ob dafür Platz geschaffen wird), wie durch die Blöcke 240 und 250 in Fig. 11 dargestellt wird. Andernfalls existiert INTRDR-JCT auf der JCT-Kette, die nicht von dem JSS geplant werden kann, bis einer oder mehrere aktuell laufende INTRDR-FCTs gelöscht werden. (Die maximale DSP-Zählung (Verwendungszählung) gibt die Höchstzahl der FCTs an, die der JSS jeweils gleichzeitig erzeugen und planen kann. Die ACTIVE-Zählung gibt die Zahl der INTRDR-JCTs an, die durch IATISCD erzeugt und geplant werden.)
2. IATISIR stellt den Prozentsatz der Aufträge für interne Leser fest, die untätig sind (INTRDR-FCTs), also das Verhältnis zwischen der Zählung der untätigen (INTRDR-FCTs) und der Zählung der aktiven (INTRDR-JCTs). Wenn der Prozentsatz der untätigen Aufträge für interne Leser dadurch, daß der aktuelle Auftrag für interne Leser, also der INTRDR- FCT, untätig gemacht wird, größer als fünfzig Prozent ist, wie durch den Block 230 in Fig. 11 dargestellt, dann fährt IATISIR fort, diesen Auftrag für interne Leser (INTRDR-FCT) zu löschen, wie durch den Block 240 in Fig. 11 dargestellt. In einem solche Falle geht IATISIR davon aus, daß die verbleibenden INTRDR-FCTs (die nicht gelöscht wurden) ausreichen, um mit der aktuellen Arbeitsbelastung des Systems fertigzuwerden. Wenn jedoch das Löschen der INTRDR-FCT dazu führt, daß die aktive INTRDR-FCT unter eine vorbestimmte Untergrenze, z. B. 2, sinkt, dann wird die INTRDR-FCT nicht gelöscht, um zu gewährleisten, daß stets genug INTRDR-FCTs verfügbar sind, um mit plötzlichen Änderungen in der Arbeitsbelastung des Systems fertigzuwerden. IATISCD hält immer eine Mindestzahl von Aufträgen für interne Leser aufrecht. Dies gilt auch dann, wenn der Prozentsatz der untätigen Aufträge für interne Leser über fünfzig liegt. (Bei diesem Ausführungsbeispiel beträgt die Mindestzahl zwei.)
Das IATISIR-Modul löscht auch die INTRDR-FCT, wenn es einen Löschanschlag (binär 10000000) in seinem WAIT BYTE empfängt, z. B. in dem in Fig. 6 dargestellten WAIT BYTE 45 und in Block 215 in dem Ablaufdiagramm in Fig. 11. Dies kann vorkommen, wenn der Systembediener die INTRDR-FCT über die Systemkonsole löscht, während IATISDV noch die Datenmenge für interne Leser verarbeitet. Die Verarbeitung zum Löschen der INTRDR-FCT ist in Fig. 8 dargestellt. Das IRE 81, das einer gelöschten INTRDR-FCT 83 entspricht, wird aus der IRE-Kette entfernt. Der ACTIVE-Zähler 43 für interne Leser im IRA 33 wird um Eins dekrementiert. Wenn die INTRDR-FCT untätig war, wenn sie gelöscht wurde, wird auch der IDLE-Zähler 35 für interne Leser um Eins dekrementiert. Die Steuerung wird dann an den JSS zurückgegeben, der das PURGE-Planungselement von der INTRDR-JCT plant. (Ein PURGE-Planungselement 65 ist in Fig. 5b als Teil der INTRDR-JCT 53 dargestellt.)
Wenn eine der obigen Bedingungen dazu führt, daß der interne Leser (INTRDRD FCT) durch IATISIR gelöscht wird, wird das IRE aus der IRE-Warteschlange (IRE-Kette) entfernt, und alle Zähler werden entsprechend aktualisiert, wie durch Block 260 in Fig. 11 dargestellt. Die Rückgabe erfolgt an den JSS, der bei Block 220 in Fig. 11 die INTRDR-FCT aus der FCT-Kette entfernt, den INTRDR-DSP-"Verwendungs"-Zähler dekrementiert und das INTRDR-JCT-Löschplanungselement verarbeitet. Andernfalls befindet sich IATISIR im Wartezustand und wartet auf mehr Arbeit (eine weitere Datenmenge zur Verarbeitung) von IATISCD (oder für einen Löschanschlag), wie durch Block 250 in Fig. 11 dargestellt. Nach der Entscheidung, die INTRDR-FCT zu behalten, um mit der aktuellen Arbeitsbelastung des Systems fertigzuwerden, setzt IATISIR sein WAIT BYTE auf Null, setzt sein Flag IRE IDLE, inkrementiert den IDLE-Zähler (im IRA) um Eins und wartet auf einen Arbeit-zu-erledigen- oder einen Löschanschlag. Wenn IATISIR ein Arbeit-zuerledigen-Anschlag entdeckt (siehe Fig. 6), ruft IATISIR wieder den JES3-Eingabedienst, also IATISDV, auf, um den neuen Eingabeauftragsstrom zu verarbeiten, und wiederholt dann den oben beschriebenen Prozeß. Wenn der Systembediener während der Verarbeitung dieser neuen Datenmenge einen Löschbefehl (INTRDR) gibt, entdeckt IATISIR ein Löschanschlag und löscht die INTRDR-FCT.
Da jede Datenmenge, die einem internen Leser übergeben wird, direkt einer JDS eines Auftrags für interne Leser zugewiesen wird, ist der zeitliche Abstand zwischen der Übergabe einer Datenmenge und der Möglichkeit, die Datenmenge zu lokalisieren, z. B. durch den TSO-Befehl STATUS, viel kürzer als nach dem Stand der Technik. Der tatsächliche zeitliche Abstand ist eine Funktion der maximalen DSP-Zählung für INTRDR-DSPs und der Gesamtaktivität des Betriebssystems. Beide Variablen beeinflussen die Zahl der DSPs, die geplant werden, und die Geschwindigkeit, mit der sie geplant werden.) Da die Verarbeitung von JOB0 für interne Leser beseitigt wurde und das IATDMJA-Modul nicht mehr von dem IATMSGC-Modul aufgerufen wird, entfällt außerdem auch die Konkurrenz zwischen der JOB0-Verarbeitung und den Bedarfsauswahlaufträgen. In großen interaktiven Systemen wird die durchschnittliche Zeit für ein TSO LOGON erheblich reduziert.
Es wurde klar gezeigt, daß eine INTRDR-FCT vom Betriebssystem (und nicht vom Bediener) in Abhängigkeit von der Arbeitsbelastung dynamisch und optimal aufgerufen und geplant wird. Die Höchstzahl der INTRDR-FCTs, die von dem Auftragsplanungssubsystem (JSS, Job Scheduler Subsystem) geplant werden, wird durch die maximale Zählung der INTRDR- DSPs bestimmt.

Verbesserung von JOB0

Wie oben angedeutet, liefert JOB0 keine JDSs mehr an interne Leser. Infolgedessen nimmt der Umfang der Spulen-I/O während der Verarbeitung von Datenmengen für interne Leser ab, und Verzögerungen aufgrund der Verwendung einer JDS durch andere Aufträge kommen nicht mehr vor. Auf das Spulengerät muß also nicht mehr wegen jedes SRF-Satzes in der JOB0-JDS-SRF-Kette zugegriffen werden. Daher wurde der JOB0-Durchsatz für andere JES3-DSP-Datenmengen gesteigert, denn es gibt keinen "Engpaß" mehr, der durch das Vorhandensein von Datenmengen für interne Leser auf der JOB0-JDS hervorgerufen wird. Weitere Vorteile der JOB0-Verbesserung sind die verminderte Durchschnittszeit für TSO LOGON in größeren interaktiven Umgebungen sowie die erhöhte Zugänglichkeit von Aufträgen, die dem internen Leser übergeben werden. Im letzteren Falle ist der Auftragsstatus bei Benutzer- und Systemanfragen schneller festzustellen, weil jedem Auftrag eine dynamische FCT für interne Leser zugewiesen wird. Im ersteren Falle vermindert sich, obwohl JOB0 weiter verfügbar ist, um andere DSP-Datenmengen (Spinoff-Datenmengen) zu verarbeiten, die Konkurrenz zwischen ihm und der Verarbeitung von TSO LOGON. Daher wird die LOGON- Verarbeitung nicht durch unmäßige Spulen-I/Os gebremst, die für die Durchsuchung der verketteten SRF-Sätze der JDS von JOB0 auf einem peripheren Speichergerät benötigt werden. Wenn ein Auftrag mit Hilfe des TSO-Befehls SUBMIT übergeben wird und dieser Auftrag wiederum einen anderen Auftrag übergibt, also mit SYSOUT=(*INTRDR) eine Ausgabedatenmenge angibt, die durch einen internen Leser bearbeitet werden soll, werden die TSO-Benutzerinformationen für jeden nachfolgenden Auftrag übernommen.
Mit der bloßen Erzeugung eines Auftrags ist ein bestimmtes Maß an Verarbeitungsaufwand verbunden. Dieser Aufwand lohnt sich, wenn plötzlich eine Schwankung in der Arbeitsbelastung auftritt, mit der die bestehenden Aufträge für interne Leser nicht fertigwerden können. Sobald die gesamte verfügbare Arbeit verarbeitet ist, kann sich ein Auftrag für interne Leser aufgrund der Implementierung dieser Erfindung beenden, anstatt zu warten, bis ein neuer Auftrag abgefertigt wird. Wenn jedoch die Arbeit mit einer solchen Geschwindigkeit eingeht, daß ein neuer interner Leser erzeugt werden muß, sobald ein anderer sich beendet hat, gilt das System als durchgegangen. Das Durchgehen ist mit einem unangemessenen Softwareaufwand verbunden. Es liegt im Wesen dieser Erfindung, daß sie diesen Zustand eliminieren kann.
Zu den weiteren Vorteilen der Erfindung zählt, daß Aufträge für interne Leser leicht gestartet und gestoppt werden können, daß Aufträge für interne Leser auf Arbeit warten oder untätig werden können, daß Aufträge für interne Leser sich beenden können, daß die Zahl der aktiv verarbeitenden Aufträge für interne Leser bestimmbar ist und daß die Zahl der untätigen Aufträge für interne Leser bestimmbar ist.
Allgemein steigert und senkt die hier beschriebene Erfindung dynamisch die Zahl der Aufträge für interne Leser, die zur Bearbeitung des sich verändernden (zu- und abnehmenden) Arbeitsflusses zur Verfügung stehen, während sie gleichzeitig einen allzugroßen Systemaufwand und das Durchgehen verhindert. Die Erfindung verbessert die Systemleistung, ohne die Komplexität des Systems für den Programmierer oder den Bediener zu steigern, indem sie z. B. die Zahl der externen Programmteile erhöht.
Als Ergebnis der hier beschriebenen und beanspruchten Erfindung müssen Bediener interne Leser nicht mehr nach einem JES3-Kaltstart starten oder zusätzliche interne Leser starten, wenn sich in der JES3-Halte-Warteschlange ein Rückstau der Datenmengen für interne Leser zu bilden beginnt. Ein geplanter Auftrag wird nun durch den Eingabedienst unter der Steuerung einer INTRDR-FCT in das System eingelesen. Ein wichtiger Vorteil besteht darin, daß das System nun die Möglichkeit hat, mehrere parallel laufende I/O-Operationen mit mehreren Warteschlangen zu initiieren, da die mehreren Aufträge zum Mehrprogrammbetrieb in der Lage sind.

Claims

1. Ein Verfahren zum Betrieb eines Computersystems mit einem Betriebssystem (MVS/XA), das mit einem Subsystem (12) kommuniziert, das einen Auftrag zur Ausführung durch das Betriebssystem vorbereitet, einem Unterstützungsprogramm (DSP, 18), das eine von dem Auftrag benötigte Arbeitseinheit verarbeitet, einer Kette (24) von Funktionssteuertabellen, in der ein Eintrag in der Kette dem Unterstützungsprogramm entspricht, einem Planungselement (32-38) in dem Auftrag, das auf der Funktionssteuertabellenkette durch das Unterstützungsprogramm vertreten ist, das der Arbeitseinheit entspricht, die durch die Verarbeitung des Auftrags ausgeführt werden muß, und einer Datenmenge (JDS, 42) mit einem Eingabestrom, der von dem Auftrag erzeugt wurde, wobei das Verfahren folgende Schritte umfaßt:

a) Verbindung der Datenmenge (JDS) direkt mit einem Auftragsdatenmengensteuerblock (17), der mit einem dynamisch erzeugten und dynamisch beendbaren Auftrag für interne Leser (INTRDR-JCT) verbunden ist;

b) Erzeugung eines Unterstützungsprogramms für interne Leser (INTRDR-DSP), das einem Planungselement in dem Auftrag für interne Leser entspricht und in dem Eintrag in der Funktionssteuertabelle einen Auftrag in der richtigen Reihenfolge zur Ausführung, Ausgabe oder Löschung geplant, und Aufnahme dieses Unterstützungsprogramms in einen Eintrag in einer Funktionssteuertabelle (FCT) in der Funktionssteuertabellenkette;

c) Übergabe der Steuerung an das Unterstützungsprogramm für interne Leser und Verarbeitung der Datenmenge, die direkt mit dem Auftragsdatenmengensteuerblock verbunden wurde; und

d) automatisches Löschen des Funktionssteuertabelleneintrags, wenn Überlaufbedingungen auftreten.

2. Das Verfahren nach Anspruch 1, wobei der Subsystemeingabeprozeß den Funktionssteuertabelleneintrag automatisch löscht, wenn die Zahl der aktiven Aufträge für interne Leser größer ist als die Höchstzahl der zulässigen Funktionssteuertabelleneinträge, wodurch ein wartender Funktionssteuertabelleneintrag geplant werden kann.

3. Das Verfahren nach Anspruch 2, wobei der Subsystemeingabeprozeß den Funktionssteuertabelleneintrag automatisch löscht, wenn der Prozentsatz der untätigen Funktionssteuertabelleneinträge größer ist als fünfzig Prozent und die Zahl der verbleibenden Funktionssteuertabelleneinträge nach der Löschung des Funktionssteuertabelleneintrags eine vorbestimmte Zahl überschreitet.

4. Das Verfahren nach Anspruch 1, wobei der Auftrag für interne Leser nach der Verarbeitung der Datenmenge untätig wird und sich auf einer Auftragswarteschlange (JCT-Kette) im Wartezustand befindet.

5. Das Verfahren nach Anspruch 4 mit einer Kette (92) aus Elementen interner Leser, die einen Block (37) aus Elementen interner Leser umfaßt, der dem Auftrag für interne Leser auf der Auftragswarteschlange entspricht.

6. Das Verfahren nach Anspruch 5, wobei der Block aus Elementen interner Leser ein Untätigkeits-Flag umfaßt, das in der Auftragswarteschlange gesetzt wird.

7. Das Verfahren nach Anspruch 6, wobei der Block aus Elementen interner Leser auf einen untätigen Funktionssteuertabelleneintrag in der Funktionssteuertabellenkette weist, der dem Auftrag für interne Leser entspricht, der sich auf der Auftragswarteschlange im Wartezustand befindet.

8. Das Verfahren nach Anspruch 7, wobei der Funktionssteuertabelleneintrag, auf den der Block aus Elementen interner Leser mit gesetztem Untätigkeits-Flag weist, neu geplant wird, um eine andere Datenmenge zu verarbeiten, wenn die andere Datenmenge direkt an einen Auftragsdatenmengensteuerblock übertragen wird, der mit dem untätigen Auftrag für interne Leser verbunden ist, und das Untätigkeits-Flag in dem Block aus Elementen interner Leser, das dem untätigen Auftrag für interne Leser entspricht, zurückgesetzt wird.

9. Das Verfahren nach Anspruch 8, wobei der Block aus Elementen interner Leser Informationen enthält, die von dem Subsystem bei der Steuerung der Planung des Auftrags für interne Leser verwendet werden.

10. Das Verfahren nach einem der vorangegangenen Ansprüche 1 bis 9, wobei die richtige Reihenfolge entsprechend der Priorität des Funktionssteuertabelleneintrags gewählt wird.

11. Ein Computersystem mit einem Betriebssystem, das mit einem Subsystem (12) kommuniziert, das einen Auftrag zur Ausführung durch das Betriebssystem vorbereitet, einem Unterstützungsprogramm (DSP, 18), das eine von dem Auftrag benötigte Arbeitseinheit verarbeitet, einer Kette (24) von Funktionssteuertabellen (FCTs), in der ein Eintrag in der Kette dem Unterstützungsprogramm entspricht, einem Planungselement (32 bis 38) in dem Auftrag, das auf der Funktionssteuertabellenkette durch das Unterstützungsprogramm vertreten ist, das der Arbeitseinheit entspricht, die durch die Verarbeitung des Auftrags ausgeführt werden muß, und einer Datenmenge mit einem Eingabestrom, der von dem Auftrag erzeugt wurde, wobei das Subsystem folgende Teile umfaßt:

Mittel (90, 92, 94, 96, 24, IATISIR, IATISCD), um je nach dem Zunehmen oder Abnehmen der Arbeitsbelastung des Systems automatisch Aufträge für interne Leser zu erzeugen und zu löschen, die Datenmengen direkt zu dem Subsystem übertragen, wenn eine der Datenmengen direkt zu einem Datenmengensteuerblock (17) kopiert wird, der mit einem der Aufträge für interne Leser verbunden ist.