Zeitanteile bei Ein-/Ausgaben auf Platten

Der Anwender formuliert seine Ein-/Ausgabe-Anforderungen im Anwenderprogramm mit Makroaufrufen (GET, PUT, GETKY, STORE, PAM, ...) auf logischer Ebene.
Bei Verwendung höherer Programmiersprachen werden die READ- bzw. WRITE-Anweisungen durch das jeweilige Laufzeitsystem entsprechend umgesetzt.

Die Makro-Auflösung enthält einen äquivalenten SVC-Aufruf, der aber nicht bei jedem Makroaufruf durchlaufen wird.

Bei sequenziellen Eingabe-Operationen (GET) stellt die Zugriffsmethode (SAM, ISAM) dem Anwender den nächsten logischen Satz aus dem Eingabe-Puffer zur Verfügung, in den der Datenblock physikalisch eingelesen wurde. Nur wenn sich kein Satz mehr im Eingabe-Puffer befindet, wird der SVC-Aufruf durchlaufen.

Bei sequenziellen Ausgabe-Operationen (PUT) erfolgt der SVC-Aufruf durch die Zugriffsmethode (SAM, ISAM) nur, wenn im Ausgabe-Puffer kein Platz mehr ist.

Bevor eine "Update"-Operation PUTX (ISAM) durchgeführt werden kann, muss der entsprechende Satz gelesen worden sein (GET, GETKY). Nur wenn sich beim Update-Vorgang die Satzlänge vergrößert, wird der SVC-Aufruf durchlaufen.

Stellt die aufgerufene DVS-Zugriffsmethode fest, dass eine physikalische Ein-/Ausgabe durchzuführen ist, so wird mit dem SVC-Aufruf $EXCP (Execute Channel Program) oder $XCPW (Execute Channel Program with Wait) die Ein-/Ausgabe angestoßen.
Diese Aufrufe stehen dem Anwender nicht unmittelbar zur Verfügung.

Die zeitlichen Verhältnisse auf der Kanal- bzw. Platten-Seite sind für beide Aufrufe gleich; nur die Reaktion der aufrufenden Programmroutine ist unterschiedlich.

Beim Aufruf $XCPW wird der Programmlauf unterbrochen (Versetzung in den Wartezustand durch die systeminterne PEND-Routine von Q0 nach Q4) und erst nach Beendigung der Ein-/Ausgabe fortgesetzt.

Die Warteschlange Q4 ist nur das "Sammelbecken" für Tasks, die auf Durchführung bzw. Beendigung der Ein-/Ausgabe (und Börsen-Ereignisse) warten. Aus der Länge der Q4 kann i.A. noch kein Rückschluss auf einen evtl. Engpass bei der Ein-/Ausgabe getroffen werden. Wesentlich sind in diesem Zusammenhang die Warteschlangen vor den einzelnen Ein-/Ausgabe-Geräten (Device-Queues; siehe auch Reportgruppe DEVICE von openSM2).

Beim Aufruf $EXCP läuft das Programm asynchron zur Abwicklung der Ein-/Ausgabe weiter (führt andere, von der Ein-/Ausgabe unabhängige Funktionen durch) und gibt zu gegebener Zeit einen expliziten Warte-Aufruf. Der Einfachheit halber wird im Folgenden nur der Aufruf $XCPW weiter dargestellt.

Ist das logische Volume zum Aufrufzeitpunkt des $XCPW belegt (mit der Durchführung von Ein-/Ausgaben für andere Anwender beschäftigt), so tritt eine Wartezeit vor dem Volume auf. Eine höhere Volume-Auslastung bewirkt eine größere Wartezeit (siehe Abschnitt "Software-Bedienzeit").

Bei Einsatz der Funktion PAV stehen pro logischem Volume (Basis-Gerät) mehrere Geräteadressen (Alias-Geräte) zur Verfügung, über die gleichzeitig Ein-/Ausgabe-Aufträge abgewickelt werden können. Die Entstehung größerer Wartezeiten wird dadurch vermieden.

Sobald das Volume frei ist (oder zumindest ein freies Alias-Gerät verfügbar ist), wird vom Betriebssystem der Befehl START SUBCHANNEL (SSCH) zusammen mit dem "Operating-Request Block" (ORB), der in der "Logical Path Mask" eine Beschreibung der möglichen Zugriffspfade enthält, an das DCS übergeben.

Sind sämtliche Zugriffspfade belegt (was bei mehreren Zugriffspfaden sehr selten vorkommt), tritt eine entsprechende Wartezeit auf (Function pending time: siehe Reportgruppe SERVICETIME von openSM2), bevor die Ein-/Ausgabe eingeleitet werden kann. Die Wartezeit auf einen freien Zugriffspfad ist i.d.R. so klein, dass sie vernachlässigt werden kann.

Auf x86-Servern wird die eigentliche Abwicklung der Ein-/Ausgabe (ausgelöst durch den zu SSCH äquivalenten Befehl) durch die I/O-Treiber von X2000 auf einer separaten CPU durchgeführt.

Bild 3: Zeitlicher Ablauf einer Platten-Ein-/Ausgabe Read-Hit/Read-Miss