Datenverwaltung, Ein-/Ausgabe

it-Akademie Bayern z/OS und OS/390 Lehrgang 2008

Prof. Dr.-Ing. Wilhelm G. Spruth

Teil 7

Ein-/Ausgabe Verarbeitung

EA 0601 ww6 © copyright W. G. Spruth, 08-2004 wgs 10-02

Program I/O Functions

The organization and processing method are usually described in the program. In addition, some data set information may be specified on the DD statement.

OPEN processing merges information from various sources to build a complete data set description. After OPEN processing the program is logically associated with the data set and the program can access the data records.

The GET/PUT or READ/WRITE macro instructions are used to request the movement of data between the device and main storage.

CLOSE processing breaks the logical connection between the data set and the program. CLOSE processing also does clean-up such as writing end-of-file marks.

I/O Request Initiation

Wenn das Anwendungsprogramm eine I/O Macro Instruction (GET/PUT oder READ/WRITE) ausführt, verzweigt das Anwendungsprogramm über einen SVC Befehl in die innerhalb des Kernels.

Supervisor Status

GET/PUT EXCP STARTI/O SSCH

S 1 2 3 4 C U H B Program Access EXCP IOS A S Method Processor N Y N S 8 7 6 5 E T L E M

Return Dispatcher Process Interrupt Interruption

I/O Services

IOS = Input/Output Supervisor

Access Method I/O Functions

In this example the Queued Sequential Access Method (QSAM) will be invoked by the GET macro.

This access method: 1. Provides I/O buffers within the program's address space. 2. Builds the channel program which describes the I/O operation to the channel subsystem.

As part of the I/O operation, the Access Method:

1. Builds control blocks containing information about the I/O request. 2. Passes control to an I/O driver 3. Issues a WAIT macro to suspend processing of the program's task until the I/O operation is completed.

Gepufferte Ein/Ausgabe

Im Gegensatz zu READ und WRITE benutzen GET und PUT eine gepufferte Ein/Ausgabe. Die Ein/Ausgabe Puffer werden von der Access Method verwaltet.

System

CPU Haupt Speicher System Bus

Kanal Kanal Kanal

256 Kanäle pro System

Control Control Control Unit Unit Unit

S/360 E/A Konfiguration

Bis zu 65 536 Subchannels pro Channel Subsystem. Jedes E/A Gerät ist, unabhängig von seinem physikalischen Anschluss, logisch über einen „Subchannel“ mit dem Channel Subsystem verbunden. Normalerweise 1 E/A Gerät pro Subchannel. es 0210z ww6 wgs 09-99

SADR Speicheradressregister BCR Bytezählregister (Length Count)

DMA (Direct Memory Access)

• Aufgaben der DMA-Steuerung: • Adressieren des Haupts.peichers durch Adreßfortschaltung • Adressieren der Geräteschnittstelle • Steuerung der Buszugriffe für Lesen oder Schreiben • Zählen der übertragenen Bytes • Rückmelden an CPU

Für einen Übertragungsvorgang werden DMA-Steuerung und I/O Controller (adapter card) von der CPU (Channel Subsystem) initialisiert, z.B. Laden der Steuer- und Adressregister.

Channel Program

The machine instructions that direct the control unit and device are called channel command words (CCW). A series of channel commands make up a channel program. This is a mini machine-language for I/O which can • read/ write between memory and devices • do device- specific control functions • test device/ channel status and loop.

Channel command words provide information such as the address of the data area and the number of bytes of data to be transferred.

Some examples of channel command words are SEEK, SETSECTOR, SEARCH, READ and WRITE.

Access Method Interface to I/O Drivers

Wenn die Access Method alle Aufgaben abgearbeitet hat, verzweigt sie zu einer als I/O Driver bezeichneten z/OS Komponente.

Der I/O Driver ist die Schnittstelle zwischen der Access Methode und IOS.

Driver passes Control to IOS

Driver Interface to IOS

The EXCP driver fixes the I/O buffers and the channel program in central storage so that they will be available during the time that the channel subsystem is processing the I/O requests (no paging).

The EXCP driver translates the addresses in the channel program from virtual to real. The channel subsystem (the hardware) uses real addresses since it must transfer data into and out of real storage locations.

IOS Processing

IOS is the interface between the system components (software) and the channel subsystem (hardware).

IOS checks to see if the requested device (typically a DASD) is active with a previous I/O request. If the device is active, IOS holds the current request on a queue for that device. If the device is available, IOS issues a Start Subchannel (SSCH) instruction to the channel subsystem to start the I/O request.

S/360 I/O Verarbeitung

Channel Subsystem Processing

A path consists of the channel path, a control unit, and the device.

There are often multiple channel paths to a single device. The channel subsystem is responsible for selecting the best path for data transfer between the device and main storage. This capability is a powerful performance feature and a major difference between z/OS or an Unix or Windows I/O subsystems.

Start Subschannel SSCH

A single instruction (SSCH, Start SubCHannel) initiates I/O. Operands are : • subchannel number • ORB (Operation Request Block) address. The ORB includes the channel program address.

SAP (Channel Assist Processor) takes over • copies ORB into UCW • places UCW in initiative queue in HSA • finds appropriate channel path • gets channel to execute channel program

When I/O is done • status is stored in UCW. • SAP generates an I/ O interrupt.

Note:

QDIO (I/O for OSA- Express network) bypasses the Channel Subsystem.

SSCH ( ORB, Subchannel)

CCWs

Channel Control Words

CCWs are linked lists of instructions initially pointed to by an operation request block (ORB). The ORB is initially given to the Start Subchannel (SSCH) command along with the subchannel number for the I/O subsystem to process while the CPU continues executing normal code.

CCWs come in two flavors: Format 0 (24 bit for backward compatibility) and Format 1 (31 bit). They are typically used to issue read and write (and many other instructions) and consist of a length field and an absolute address field.

For each I/O typically 1 or 2 interrupts are produced, one for channel end (primary status) when the channel is idle and the second for device end (secondary status). Often both occur concurrently (CEDE interrupt, Channel End Device End).

zSeries Ein/Ausgabe Anschluss

Hauptspeicher

CPU CPU CPU Benutzer Prozesse

Ke r n e l SAP SAP 00 ... 00 HSA

CH. CH. CH. CH. Kanäle

Channel Subsystem

CU CU CU CU CU CU

CU = Control Unit

Plattenspeicher

Das Channel Subsystem wird durch mehrere Prozessoren (als System Assist Prozessoren, SAP, bezeichnet) und entsprechenden Code verwirklicht. Die SAPs greifen parallel zu den CPUs auf den Hauptspeicher zu und entlasten diese von Ein-/Ausgabe Aufgaben.

Die HSA (Hardware System Area) ist ein Teil des Hauptspeichers. Sie liegt außerhalb des Adressenraums, auf den die CPUs zugreifen können. Das Channel Subsystem besteht aus SAP Prozessoren und Code in der HSA. Es bildet das virtuelle E/A Subsystem, mit dem der Betriebssystem Kernel glaubt zu arbeiten, auf die reale E/A Struktur ab.

Es 0370 ww6 wgs 10-04

Channel Subsystem Components

The S/390 channel subsystem contains:

A special processor unit (PU) called an SAP. An SAP is a S/390 compatible Microprocessor, but executes I/O licensed internal code (LIC) only (no z/OS Kernel code and no user code). An SAP alleviates the CPU involvement during the execution of an I/O operation. It schedules an I/O operation, but is not in charge of the movement between central storage (CS) and the channel. Channels, which are special processors able to communicate with I/O control units and manage the movement of data between central storage and these control units. Being more specific, the channels can: 1. Send channel commands from the processor to a Control Unit 2. Transfer data during read and write operations 3. Receive status at the end of operations 4. Receive sense information from control units

An I/O operation starts when a Start Subchannel (SSCH) machine instruction is executed by the Input Output Supervisor (IOS), an OS/390 component, which issues the instruction on behalf of an OS/390 process. It ends when an I/O interrupt is received by the CPU (forcing the execution of IOS code again).

Start Subchannel (SSCH) logic

The Start Subchannel (SSCH) is a privileged instruction. It is issued by the Input Output Supervisor (IOS), a z/OS component, and used to start an I/O operation. SSCH has two operands:

1. Subchannel number, which is an index to the UCW associated with the I/O device 2. Operation Request Block (ORB) address. The ORB contains information about what do to during the I/O operation; among other fields it contains the channel program address.

The SSCH microcode moves the ORB contents into the respective UCW and places the UCW in an specific Hardware System Area (HSA) queue named the initiative queue. After that process completes, the next IOS instruction is executed, allowing the use of the CPU in another task. HSA is a piece of central storage not addressable by z/OS. It is allocated at power-on reset (POR) and contains microcode work areas, and the I/O configuration (UCWs are stored in HSA) used by the channel subsystem.

Haupt- CPU speicher

256 Kanäle

Kanal Kanal Kanal Kanal Kanal

CU CU CU CU CU

256 Devices pro CU CU CU CU CU Kanal

max.

S/360 E/A Konfiguration

0 7 8 15

16 Bit I/O Address

Channel Device Address Address max. 256 Channels und max. 256 Devices pro Channel

Subchannel Number

• Device identification used for communication between CPU and channel subsystem

• 16 Bit, 65 536 possible devices

• Index for the UCW (Unit Control Word) in the UCW table

• Used by microcode interpreting the SSCH (Start Subchannel) machine instruction

• Stored in the UCB at IPL time

• Independent of device number

• Used for communication between I/O Supervisor and Channel Subsystem

UCW Table

UCW

Subchannel Number

The subchannel number is a way for addressing an I/O device. It is a value that is assigned to the subchannel (UCW) representing the device at POR time. It indicates the relative position of the UCW in the UCW table. The specific value depends on the position of the statement I/O DEVICE in the IOCP.

It is used to reference the device during the communication between z/OS and the channel subsystem as well as during the SSCH instruction and the interrupt processing. The subchannel number was designed to speed up the search of a UCW during the SSCH processing. The same device accessed by different logical partitions has one UCW per image. In a G6 the maximum number of UCWs is 80,000.

The subchannel number is expressed in a 16-bit value, whose valid range is 0000-FFFF, allowing for a maximum of 65,536 devices per z/OS image. Stored in the UCB at IPL, it is not declared during HCD initialization.

Channels and Control units

A channel is a processor connected to main memory and one or more control units. Current systems support 256 channels. Identified by an 8- bit channel path id (CHPID)

A control unit (CU) is attached to up to 256 devices, e. g. DASD or tapes. Sometimes a channel is a separate box; sometimes a channel shares a physical box with devices. Each device is identified to humans by a 16 - bit device number, to the Channel Subsystem (CSS) by a 16 Bit subchannel number.

A subchannel number indexes into an array of UCWs stored in the HSA (Hardware Storage Area), memory available only to microcode. An UCW (Unit Control Word) includes • device number • Unit Address,( UA), 8- bit identifier within channel • channel path information

Channel path

Each device can attach to up to 8 different channels for reliability and performance. Devices may connect to more than one CU.

z/OS I/O Overview

Unlike other bus architectures modern zSeries systems do their I/O using mostly fibre optics. Devices such as tapes and disks can be shared between several mainframes. zSeries can support up to 4 x 65536 devices while a high end PC based system might be choking with around 64. Here is some of the common I/O terminology.

Subchannel

This is the logical number most I/O commands use to talk to an I/O device. There can be up to 0x10000 (65536) of these in a channel subsystem. Typically there is a few thousend. Under VM for simplicity they are allocated contiguously. However on the native hardware they are not. Subchannel numbers typically stay consistent between boots provided no new hardware is inserted or removed. E.g. under zLinux they are used as IRQ's. Also under Linux, when issuing an I/O command (CLEAR SUBCHANNEL, HALT SUBCHANNEL, MODIFY SUBCHANNEL, RESUME SUBCHANNEL, START SUBCHANNEL, STORE SUBCHANNEL and TEST SUBCHANNEL) this is the ID of the device being talked to. The most important of these instructions are START SUBCHANNEL (to start I/O), TEST SUBCHANNEL (to check whether the I/O completed successfully), and HALT SUBCHANNEL (to kill I/O). A subchannel can have up to 8 channel paths to a device. This offers redundancy if one channel is not available.

Device Number

This number remains static and Is closely tied to the hardware There are 65536 of these, and are made up of a CHPID (Channel Path ID, the most significant 8 bits) and another LSB 8 bits. They remain static even if more devices are inserted or removed from the hardware, There is a 1 to 1 mapping between Subchannels and Device Numbers, provided devices are not inserted or removed.

SAP Logic

The SAP finds the UCW in the initiative queue and tries to find a channel that succeeds in initial selection (connects to a control unit and starts the I/O operation). Initial selection may be delayed if:

1. All channel paths (serving the device) are busy. 2. The FICON or ESCON director port is busy. 3. The control unit interface is busy. 4. The device is busy, due to shared DASD activity or a previous not completed Write Format operation.

During all of these delays, the request is serviced by SAP without z/OS awareness. When the I/O operation finishes (device-end status is presented) SAP queues the UCW (containing all the I/O operation final status) in the I/O interrupt queue.

SAP uses the I/O configuration information described in the Hardware Configuration Definition (HCD) to determine which channels and control units can reach a target device.

Channel Program Execution

Die Ausführung des Kanalprogramms bewirkt den Transfer von Daten zwischen dem angegebenen Bereich auf dem Plattenspeicher und dem spezifizierten Puffer (Buffer) im Hauptspeicher.

Software und Hardware Interface

Die Software (IOS) und die Hardware (Channel Subsystem) arbeiten eng zusammen, um die E/A Anforderung auszuführen.

Nachdem IOS den SSCH Maschinenbefehl ausgeführt hat, bewirkt das Channel Subsystem den eigentlichen Datentransfer.

I/O Operation Completion

Nach Abschluss des Datentransfers signalisiert das Channel Subsystem diesen Tatbestand an den z/OS Kernel. Dies geschieht mit einer I/O Unterbrechung (CEDE, channel-end, device-end interrupt).

Interrupt processing

S/390 is an I/O interrupt-driven architecture, as opposed to a polling mechanism. The only exception to this rule is the handling of the communication between z/OS and a Coupling Facility, where polling is used. When a CPU I/O interrupt is enabled and the CPU detects the UCW in the interrupt queue, the I/O interrupt is accepted and the I/O PSWs are asynchronously swapped passing the control back to IOS.

An Interrupt Response Block (IRB) is moved to storage describing the final status of the I/O operation. Usually, IOS then posts the z/OS process waiting for the I/O operation.

In certain error situations the I/O interrupt is not generated within an expected time frame, then the z/OS component Missing Interrupt Handler (MIH), a timer-driven routine, alerts IOS about this condition.

I/O Post Processing

As a result of the interrupt, IOS returns control to the I/O driver.

The I/O driver marks the program's task ready-to-execute.

When the program's task is the highest priority unit of work in the system, it will be dispatched. At that time, the access method code will transfer the data from the access method's I/O buffers into the user program's data area and return control to the program.

Program Processing of Data

The data is now available to the user program for processing. The program may issue additional I/O requests which would start the I/O flow process again.

z/OS Channel Subsystem Operation

IOS Input Output Komponente des z/OS Kernels (Supervisor)

SAP S/390 kompatiblen Microprozessor führt Licensed Internal Code aus

SSCH (Start Subchannel) Privilegierte IOS Instruktion

ORB (Operation Request Block) enthält Adresse des ersten CCW und Subchannel Nummer

UCW Unit Control Word es 0358 ww6 wgs 07-02

Ein-/Ausgabe Steuerblöcke

Anwendungs DCB programm DEB Data Extend Block

Access Method IOB Input/Output Block ECB Event Control Block

I/O Driver, z.B. EXCP SRB Syst. Request Block

IOS UCB UCW Unit Control Word IOQ Input/Output Queue ORB Operation Request Block IRB Interrupt Request Block PSA Prefixed Save Area

Channel Subsystem CPID Channel Path Identifier

Devices VTOC Volume Table of Content DSCB Data Set Control Block

Hardware HSA Hardware System Area SAP Syst. Assist Processor SSCP Start Subchannel CCW Channel Command Word

EA 0803 ww6 wgs 10-02

Anordnung von Ein/Ausgabe- Steuerblöcken im Hauptspeicher

Für den Benutzer ist es nicht erforderlich, für jede Art von E/A-Einheit oder jede Art von Dateiorganisation (sequentiell, regional, virtuell, usw) ein eigenes Kanalprogramm zu schreiben. Die Routinen zur Erstellung eines Kanalprogramms werden als Teil des Betriebssystems vorgefertigt zur Verfügung gestellt und als Zugriffsroutinen (Access Methods) bezeichnet. Für die Summe aller Zugriffsroutinen sowie die sie unterstützenden Systemprogramme (EIA-Überwacher), hat sich der Begriff Data Management eingebürgert.

Die Verknüpfung zwischen Anwendungsprogramm, Zugriffsroutinen und EIA-Überwacher erfolgt über eindeutig definierte (Software) Schnittstellen und wird mit Hilfe einer Reihe von Kommunikationsbereichen (Steuerblöcke, Tabellen, Warteschlangen) aufrechterhalten. Einer der Steuerblocktypen ist der Datei-Steuerblock (DSCB); er wird zusammen mit der Datei auf dem Datenträger abgespeichert und enthält Informationen über den Inhalt der Datei. Das Inhaltsverzeichnis (VTOC) des Datenträgers enthält einen DSCB für jede abgespeicherte Datei. Ein zweiter Steuerblocktyp ist der Unit Control Block (UCB). Für jede angeschlossene E/A-Einheit unterhält der E/A-Überwacher einen UCB, der Status und Adresse der E/A-Einheit enthält; er ist Teil des Überwachers. Ein dritter Steuerblocktyp ist der Event Control Block (ECB). Dort wird bei Eintreten einer E/A-Unterbrechung der erfolgreiche Abschluss einer E/A-Operation festgehalten.

Der wichtigste Steuerbereich ist der Data Control Block (DCB). Für jede in Anspruch genommene Datei unterhält das Anwendungsprogramm einen DCB. Kenndaten, diese Datei betreffend, sind dort festgehalten. Zum Kanalprogramm gehörende Steuerinformation wird in einem INPUT-OUTPUT-Block (IOB) festgehalten.

1. Die Anwendung muss sich dem Data Set gegenüber, auf den sie zugreifen möchte, bekannt machen. Dies erfolgt durch das OPEN Macro, welches die Zugriffsberechtigung testet und dann das Data Set in dem Programm bekannt macht. Außerdem legt es fest, dass das Data Set jetzt benutzt wird, und schützt es somit vor Löschen oder Verlagerung. Das Programm kann jetzt Methoden wie GET, PUT, READ und WRITE verwenden, um auf das Data Set zuzugreifen und es gegebenfalls zu verändern. Jede dieser Methoden oder Macros verzweigt auf eine entsprechende Zugriffsmethode.

2. Die Zugriffsmethode hat die Funktion, das Kanalprogramm zu erstellen, um auf die gewünschten Daten zuzugreifen. Außerdem implementiert sie Datenpufferung und Synchronisation, und im Falle eines Fehlers kann sie selbsttätig die I/O Operation wieder aufsetzen. Die Zugriffsmethode hängt dabei von der Dateiorganisation ab, wie im vorherigen Kapitel aufgezeigt wurde.

3. Um das Bewegen von Daten zu veranlassen, verzweigt die Zugriffsmethode auf einen I/O Driver, meistens EXCP. Bisher war das Kanalprogramm mit virtuellen Adressen erstellt worden und muss jetzt in reale Adressen übersetzt werde. Dazu versetzt sich der I/O Driver in den Supervisor State, der es ihm erlaubt, entsprechende Veränderungen auf Systemebene vorzunehmen. Jetzt kann der I/O Driver auch die Seiten im Speicher festlegen, auf die das Kanal-Subsystem später zugreifen kann. Als letzter Schritt wird der I/O Supervisor (IOS) aufgerufen.

4. Der nächste Schritt ist, dass das Kanalprogramm gestartet wird. IOS testet dazu den Unit-Control-Block (UCB), welcher das Logical Volume repräsentiert, auf dem sich die gewünschten Daten befinden. Jedes externe Gerät ist durch einen UCB im System repräsentiert. Falls kein weiterer I/O Request bereits auf Abarbeitung wartet, setzt IOS eine Start-Subchannel (SSCH) Instruktion ab, die die Verarbeitung an das Kanal-Subsystem weiterleitet. Ansonsten wird der I/O Request in eine Warteschlange an den UCB gehängt. Als letzter Schritt geht die Zugriffsmethode in Wartezustande und erlaubt so, dass die CPU andere Prozesse bedient.

5. Einer der System Assist Processors (SAP) bearbeitet jetzt die SSCH Instruktion und wählt einen Kanal aus, mit dem es möglich ist, auf die Platte und die gewünschten Daten zuzugreifen. Der SAP und die Kanäle verwenden jetzt die Kontrollstrukturen des Microcodes, um auf die externen Geräte zuzugreifen. Diese heißen Subchannels, und für jedes Endgerät existiert genau ein Subchannel in einem der Hardware zugeordneten Speicherbereich.

Der Kanal führt jetzt das Kanalprogramm aus und überwacht die Verschiebung der Daten von der Control Unit zum Prozessorspeicher. Dabei können mehrere Kanäle an einer I/O Operation arbeiten. Der erste Kanal initiiert die I/O Operation und leitet die Kanalprogramminstruktionen an die Control Unit weiter. Diese leitet den Datentransfer ein und verbindet sich selbstständig (Reconnect) wieder mit dem Kanal-Subsystem des Systems. Dabei kann ein anderer Kanal ausgewählt werden als derjenige, der die I/O Operation zuerst bearbeitet hat.

6. Wenn ein Kanal die I/O Operation abgeschlossen, hat signalisiert er dies dem SAP. Dieser wiederum generiert einen I/O Interrupt zu dem initiierenden Betriebssystem.

7. IOS bearbeitet den I/O Interrupt und weckt die schlafende Task, die den I/O eingeleitet hatte. Dann wird die Kontrolle wieder an den Dispatcher abgegeben.

8. Wenn es angemessen ist, teilt der Dispatcher der Task eine CPU zu und gibt somit die Kontrolle an die Zugriffsmethode zurück.

9. Die Zugriffsmethode wertet den Zustand der I/O Operation aus und gibt die Kontrolle an die Anwendung zurück.

10. Die Anwendung setzt ihre Bearbeitung fort.

Das Programm formuliert seine Anforderungen mit DCB, OPEN, GET/PUT und CLOSE.

Mit Hilfe der durch OPEN hergestellten Zuordnung des DCB zu einem DEB kann die Access Method den geeigneten CCW-String formulieren.

Die Ausführung wird dem I/O Driver übertragen; ein vielfach verwendeter Driver ist EXCP. Der eigentliche Betriebsystemkern für die Ausführung von I/O, der Input/Output Supervisor (IOS) wird durch den Driver über STARTIO direkt angesprochen.

Nachdem der UCB überprüft worden ist, wird der I/O-Request des User Programms in ein IOQ und anschließend in einen ORB umgesetzt. Eine Hand- voll von SCH-Instruktionen (SSCH, TSCH, HSCH, CSCH) prägt die Schnittstelle zwischen Hardware und Software. CC=0 im Front End leitet die Kontrolle zum WAIT ECB der Access Method zurück.

Das Channel Subsystem übernimmt nach SSCH den I/O-Request und bearbeitet ihn asynchron. Der Rückschluss zur Software erfolgt über einen Interrupt. Über SRB-Schedule und POST erhält das User Programm Nachricht über die I/O-Operation. es 0365 wgs 10-02

Wegen der extrem unterschiedlichen Geschwindigkeit der Prozessoren auf der einen und der I/O Devices auf der anderen Seite ist eine weitgehende Entkoppelung zwischen der Software (User Programm) und der Hardware (Channel Subsystem) in z/OS implementiert worden.

• Das Programm formuliert seine Anforderungen mit DCB, OPEN, GET/PUT und CLOSE.

• Mit Hilfe der durch OPEN hergestellten Zuordnung des DCB zu einem DEB kann die Access Method den geeigneten CCW- String formulieren.

• Die Ausführung wird dem I/O Driver übertragen. Ein vielfach verwendeter Driver ist EXCP. Der eigentliche Betriebsystemkern für die Ausführung von I/O, der Input/Output Supervisor (IOS) wird durch den Driver über STARTIO direkt angesprochen.

• Nachdem der UCB überprüft worden ist, wird der I/O-Request des User Programms in ein IOQ und anschließend in einen ORB umgesetzt. Eine Hand- voll von SCH-Instruktionen (SSCH, TSCH, HSCH, CSCH) prägt die Schnittstelle zwischen Hardware und Software. CC=0 im Front End leitet die Kontrolle zum WAIT ECB der AM zurück.

• Das Channel Subsystem übernimmt nach SSCH den I/O- Request und bearbeitet ihn asynchron. Der Rückschluß zur Software erfolgt über einen Interrupt. Über SRB-Schedule und POST erhält das User Programm Nachricht über die I/O- Operation.

I/O Services

Der Ablauf einer I/O Anforderung in einem z/OS System stellt sich wie folgt dar:

Das Benutzerprogramm fordert einen I/O Service z. B. in Form eines OPEN/CLOSE/GET/PUT/READ/WRITE Aufrufs. Die der Dateiorganisation entsprechende Zugriffsroutine erstellt ein Kanalprogramm und benutzt das EXCP (Execute Channel Program) Makro.

Der I/O driver (for example EXCP Processor) hat prinzipiell die Aufgabe, die von unterschiedlichen Zugriffsmethoden verwendeten Informationen für den I/O Supervisor aufzubereiten (z. B. Kanalprogramme aufbereiten, Datenpuffer fixieren, etc.).

Der I/O Supervisor (IOS) stellt die Verfügbarkeit der Device fest und startet den I/O Service mit Hilfe der Start Subchannel (SSCH) Instruktion.

Das Kanalsubsystem ist jetzt für die Selektion eines Kanalpfades zur entsprechenden Device und die Initiierung und Überwachung des Datentransfers zuständig.

Die Beendigung und der Status der I/O Operation werden dem Benutzer mit Hilfe einer Unterbrechung über IOS, EXCP und Zugriffsmethode mitgeteilt.

I/O Flow Summary

1. The user program issues an OPEN macro to state the intention to do I/O. 2. The user program issues a GET macro to start the I/O request. 3. The access method issues an EXCP macro to pass the request to the EXCP driver after the channel program is built. 4. The EXCP driver issues a STARTIO macro to pass the request to IOS. 5. IOS checks the status of the device and issues a Start Subchannel (SSCH) instruction to pass the request to the channel subsystem. 6. The channel subsystem finds an available path and starts the I/O operation. 7. The access method waits for the I/O to complete. 8. When I/O is complete, the channel subsystem sends an interrupt to IOS. 9. IOS analyzes the interrupt and returns control to the EXCP driver. 10. The driver notifies the access method that the I/O is complete. 11. The access method returns control to the user program.

UCB Queue

SSCH

Path Queue

Device

Physical I/O

Queuing

Queuing: Der z/OS Kernel stellt eine I/O Serviceanforderung in die Warteschlange des angesprochenen Devices (z.B. DASD), wenn diese Device von diesem System schon benutzt wird (UCB busy).

Erst wenn die Einheit logisch verfügbar ist, wird die I/O Operation mit SSCH gestartet.

Das Kanalsubsystem beginnt mit der Auswahl des Kanalpfades und startet die Operation, oder stellt die I/O Serviceanforderung in eine Warteschlange, wenn physische Ressourcen (z. B. Kanalpfad, Device) nicht verfügbar sind

Queuing Points 1. IOS UCB Queue 2. In CSS waiting for channel 3. In Shark control unit

Es 0708 ww6 wgs 10-01

I/O Services (2)

Der Ablauf einer I/O Anforderung in einem z/OS System stellt sich wie folgt dar:

Das Benutzerprogramm fordert einen I/O Service an, z. B. in Form eines GET/PUT/READ/WRITE Aufrufs. Die der Dateiorganisation entsprechende Zugriffsroutine erstellt ein Kanalprogramm und benutzt das EXCP (Execute Channel Program) Makro.

Der I/O driver (for example EXCP Processor) hat prinzipiell die Aufgabe, die von unterschiedlichen Zugriffsmethoden verwendeten Informationen für den I/O Supervisor aufzubereiten (z. B. Kanal- programme aufbereiten, Datenpuffer fixieren, etc.).

Der I/O Supervisor (IOS) stellt die Verfügbarkeit der Device fest und startet den I/O Service mit Hilfe der Start Subchannel (SSCH) Instruktion.

Das Kanalsubsystem ist jetzt für die Selektion eines Kanalpfades zur entsprechenden Device und die Initiierung und Überwachung des Datentransfers zuständig.

Die Beendigung und der Status der I/O Operation werden dem Benutzer mit Hilfe einer Unterbrechung über IOS, EXCP und Zugriffsmethode mitgeteilt.

Verifying an I/O Operation

A Check on how the I/O operation was executed is done by issuing a TEST SUBCHANNEL command at each interrupt.

The Interrupt returns an Interruption response block (IRB). If you receive channel and device end status in the IRB without channel checks etc., the I/O probably executed correctly. If you didn't you probably need to examine the IRB and extended status word etc.

If an error occurs, the control units have a facility known as concurrent sense. If an error occurs, extended sense information will normally be presented in the Extended Status Word in the IRB. If not, you have to issue a subsequent SENSE CCW command after the test subchannel.

TPI (Test pending interrupt) can also be used for polled I/O but in multitasking multiprocessor systems it isn't recommended except for checking special cases (i.e. non-looping checks for pending I/O etc.).

STSCH/MSCH Store Subchannel and Modify Subchannel can be used to examine and modify operating characteristics of a subchannel (e.g. channel paths).

QDIO is a high speed I/O architecture to support devices such as gigabit Ethernet.

I/O Component Overview

When the user program needs I/O to be performed, it issues an access method macro such as GET/PUT or READ/WRITE to initiate the I/O operation.

The access method calls the I/O driver (for example EXCP Macro), which calls the Input/Output Supervisor (IOS) component of z/OS or OS/390 which issues an I/O request to the channel subsystem.