DE3852257T2

DE3852257T2 - Anwenderprogramm-Schnittstelle für Vollbild-Eingabe/Ausgabe.

Info

Publication number: DE3852257T2
Application number: DE3852257T
Authority: DE
Inventors: Christine Teresa Casey; Stephen Elliott Record
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-09-25
Filing date: 1988-09-15
Publication date: 1995-05-24
Anticipated expiration: 2008-09-16
Also published as: EP0308805A3; US4855936A; EP0308805B1; EP0308805A2; DE3852257D1; JPH0195354A

Description

Die vorliegende Erfindung betrifft im allgemeinen Eingabe/Ausgabe-Operationen (I/O-Operationen, Input/Output- Operationen) in Informationsbehandlungssystemen und im besonderen Vollbild-Eingabe/Ausgabe-Operationen eines Anzeigegerätes in einem Informationsbehandlungssystem wie z.B. einem Rechnersystem, auf dem ein oder mehrere Anwenderprogramme (Software) in Verbindung mit einem Betriebssystem (Software) laufen.
Im typischen Fall umfaßt ein Informationsbehandlungssystem wie z.B. ein Rechnersystem eine Zentraleinheit (CPU, Central Processing Unit), die von einem Betriebssystem (Software) gesteuert wird, und verfügt über ein oder mehrere Anwenderprogramme (Software), die I/O-Operationen mit Hilfe eines Anzeigegerätes durchführen, wie z.B. eines Terminals mit angeschlossener Tastatur, über das ein Benutzer des Rechnersystems Informationen (Daten) in das Rechnersystem eingeben und Informationen (Daten) aus dem Rechnersystem bekommen kann. Das Betriebssystem umfaßt normalerweise ein Steuerungsprogramm (CP, Control Programm), das die I/O- Operationen des Anzeigegerätes steuern kann, indem es veranlaßt, daß dem Anzeigegerät nach Bedarf während des normalen Betriebs des Rechnersystems Steuerungssignale zugeleitet werden. Auch können das Anwenderprogramm bzw. die Anwenderprogramme die I/O-Operationen des Anzeigegerätes steuern, da ihr Programmcode entsprechende Anweisungen enthält, die veranlassen, daß dem Anzeigegerät CP- Steuerungssignale derselben Art zugeleitet werden. Dies setzt jedoch voraus, daß die Programmierer von Anwenderprogrammen mit CP-Programmierungsverfahren und Anweisungen auf relativ niedriger Ebene vertraut sein müssen, und verursacht Kompatibilitätsprobleme, wenn ein Anwenderprogramm von einem Rechnersystem auf ein anderes Rechnersystem mit einem anderen Betriebssystem übertragen werden soll. Hauptsächlich aus diesen Gründen nutzen Anwenderprogramme die Vollbild-I/O- Fähigkeiten von Anzeigegeräten nicht voll aus oder beschränken ihre I/O-Operation von Anzeigegeräten oft auf die zeilenorientierte Eingabe und Ausgabe.
Bevor etwa die International Business Machine (IBM) Corporation die vorliegende Erfindung als Bestandteil des Conversational Monitor System (CMS) bei dem IBM Program- Product-Betriebssystem namens Virtual Machine/System Product (VM/SP) (IBM Program Product Nummer 5664-167) einführte, war die Unterstützung für Anzeigegeräte auf die zeilenorientierte Eingabe und Ausgabe beschränkt. Das CMS nutzte seine virtuelle Konsole (d.i. eine Konsole, die von CP auf einem Terminal simuliert wird) noch nicht einmal selbst im Vollbild aus, außer im System Product Editor (XEDIT), der zwar auch zum CMS gehört, eigentlich aber ein Anwenderprogramm ist, das aus Gründen der Geschwindigkeit im CMS-Kern angesiedelt ist. Jedes andere CMS-Anwenderprogramm, das die Nutzung des Anzeigebildschirms in voller Größe erforderte, mußte sich, wie XEDIT, der Unterstützung der Vollbildkonsole bedienen, die das VM/SP-Steuerungsprogramm (CP) bot, eingebettet in eine Anweisung Diagnose X'58', eine CP-Anweisung auf niedriger Ebene an eine virtuelle Konsole, die in einer IBM- Publikation mit dem Titel "VM/SP System Facilities for Programming, Release 5" (SC24-5288-0) näher beschrieben ist, die in ihrer Gesamtheit durch Verweis in die vorliegende Patentschrift aufgenommen ist. Die von der Anweisung Diagnose X'58' präsentierte Schnittstelle entspricht derjenigen der Anweisung Start I/O (SIO) von System/370, einer Assembler- Programmiersprachenanweisung von System/370, die in einer IBM-Publikation mit dem Titel "IBM System/370 Principles of Operation" (GA22-7000) näher beschrieben ist, die in ihrer Gesamtheit durch Verweis in die vorliegende Patentschrift aufgenommen ist. Jedes Rechnerprogramm, das die Anweisung Diagnose X'58' ausgibt, muß Kanalprogramme aufbauen, die die auszuführenden I/O-Programme definieren, I/O-Unterbrechungen behandeln, die aufgrund der Ausführung der Kanalprogramme oder aufgrund der Betätigung der Tastatur durch den Benutzer entstehen, und alle Fehler beseitigen, die sich ergeben können. Dies richtig zu tun erfordert eine behutsame und komplizierte Programmierung, und wenn die Programmierung nicht mit Sorgfalt erfolgt, kann es zu fehlerhaftem Programmcode in CMS-Anwenderprogrammen kommen, die eine Vollbild-Eingabe/Ausgabe an ein Anzeigegerät durchführen.
Zwar hat das CMS seit langem eine Anwendungsschnittstelle für die Behandlung von I/O-Unterbrechungen (ein Makro namens HNDINT), doch es ist etwas schwierig und nicht besonders praktisch für Vollbildprogramme, bei der Verwaltung der virtuellen Konsole HNDINT zu verwenden, weil die virtuelle Konsole gemeinsam mit der CMS-eigenen zeilenorientierten Unterstützung verwendet werden muß. Da von dem Ausgeber von HNDINT erwartet wird, daß er die gesamte Verantwortung für das verwaltete Gerät übernimmt, muß ein Programm, das HNDINT für die virtuelle Konsole verwendet, die gesamte zeilenorientierte Konsolenunterstützung des CMS duplizieren sowie eigene Vollbildoperationen implementieren, was mit viel Aufwand verbunden sein kann. Daher sind Vollbild-CMS- Programme bislang gezwungen, die definierte CMS-Schnittstelle zur Verwaltung virtueller Geräte zu untergraben. Dies geschieht in der Regel durch Verändern der Anweisungsadresse in dem PSW (Programmstatuswort) I/O neu, so daß der Eingang einer I/O-Unterbrechung die Steuerung veranlaßt, in das Anwenderprogramm und nicht in den CMS-Kern zu übertragen. Anschließend geht sie auf die Anwendung über, um alle Unterbrechungen, die sie nicht selbst behandeln kann, (z.B. für andere Geräte als die Konsole) an den normalen I/O- Unterbrechnungsbehandler des CMS weiterzuleiten. Diese zusätzliche Komplexität kann zu zusätzlichem falschem Anwenderprogrammcode führen, besonders wenn ein Vollbildprogramm ein anderes aufrufen kann, sofern der Programmierer beim Schreiben des Anwenderprogrammcodes keine sehr große Sorgfalt walten läßt.
Selbst ein Rechnerprogramm, das die Konsolen-I/O auf niedriger Ebene (wie oben beschrieben) korrekt durchführt, ist mit zusätzlichen Komplikationen konfrontiert, wenn es auf virtuellen Maschinen in System/370 und System/370-Extended Architecture (XA) oder auf virtuellen Konsolen und dedizierten Anzeigegeräten laufen muß. Um die größeren Adreßräume zu nutzen, die in System/370-XA zur Verfügung stehen, müssen Rechnerprogramme 31-Bit-Speicheradressen behandeln können. Allerdings können die Kanalprogramme, die Diagnose X'58' verwendet, keinen Speicher über 16 Megabyte adressieren, ohne indirekte Datenadreßlisten (IDALs, Indirect Data Address Lists) zu verwenden. Außerdem sind die I/O- Anweisungen, die zusätzlich zu Diagnose X'58' verwendet werden müssen, in System/370 und System/370-XA völlig verschieden, so daß ein Programm, das in beiden Umgebungen lauffähig sein soll, jeweils separate Ausführungspfade enthalten muß. Ebenso ist das PSW-Format von System/370-XA anders als das, welches traditionell vom CMS im System/370- Modus verwendet wird, was beim Stehlen des PSW I/O neu zu zusätzlicher Komplexität führt, wenn beide Modi unterstützt werden müssen. Darüber hinaus ist die Schnittstelle Diagnose X'58' nur für die virtuelle Konsole gültig. Die I/O zu einem dedizierten Anzeigegerät muß mit der Anweisung Start Subchannel (SSCH) von System/370 oder System/370-XA durchgeführt werden, und es müssen etwas andere Kanalprogramme aufgebaut werden.
Wie sich aus dem Obengesagten ergibt, besteht eine Notwendigkeit, Lösungen für die oben erörterten Probleme mit der Vollbild-I/O anzubieten. So besteht z.B. eine Notwendigkeit, Anwenderprogramme davon zu befreien, Kanalprogramme aufzubauen, I/O-Unterbrechungen zu behandeln oder sich um die Einzelheiten der Fehlerbehebung zu kümmern. Außerdem ist es in einer Betriebssystemumgebung wie etwa in einer VM/SP-Umgebung wünschenswert, die Notwendigkeit zu beseitigen, die I/O-Unterbrechungsbehandlung des CMS durch Stehlen des PSW I/O neu zu untergraben. Außerdem besteht eine Notwendigkeit zur Definition einer Schnittstelle, die von der virtuellen Maschinenarchitektur und der virtuellen Geräteimplementierung unabhängig ist und auf System/370- und System/370-XA-Maschinen sowie auf virtuellen Konsolen oder dedizierten Anzeigen gleichermaßen funktioniert. Ferner besteht eine Notwendigkeit, zusätzliche Funktionen zur Koordinierung der Nutzung eines Anzeigebildschirms durch mehrere Anwenderprogramme sowie zur Koordinierung der Vollbild-I/O innerhalb eiens Betriebssystems bereitzustellen.
Daher ist es ein Ziel der vorliegenden Erfindung, ein Verfahren bereitzustellen, durch das ein Anwendungsprogrammierer ein Anwenderprogramm schreiben kann, ohne sich um die Details einer Vollbild-I/O-Operation auf niedriger Ebene kümmern zu müssen.
Ein anderes Ziel der vorliegenden Erfindung ist es, ein Verfahren zur Koordination der Vollbild-I/O-Nutzung eines Anzeigegerätes durch mehrere Anwenderprogramme in einem Informationsbehandlungssystem bereitzustellen.
Ein weiteres Ziel der vorliegenden Erfindung ist es, ein Verfahren bereitzustellen, durch das ein Anwenderprogramm in bezug auf Vollbild-I/O-Operationen architekturunabhängig sein kann.
Diese und andere Ziele der vorliegenden Erfindung werden durch die in Anspruch 1 genannten Merkmale erreicht.
Andere Ziele und Vorteile der vorliegenden Erfindung ergeben sich aus den Unteransprüchen und der nachstehenden Beschreibung in Verbindung mit den begleitenden Zeichnungen, die allein der Veranschaulichung dienen sollen und nicht als Einschränkung der vorliegenden Erfindung gedacht sind. Dabei gilt:
Fig. 1 ist ein Blockdiagramm, das die Anwenderprogramm- Schnittstelle gemäß der vorliegenden Erfindung darstellt, wie sie in der Gesamtstruktur der I/O-Behandlungsroutinen des Conversational Monitor System (CMS) des IBM Virtual Machine/System Product (VM/SP) enthalten ist.
Figs. 2 und 3 zeigen ein Flußdiagramm der Funktion der Anwenderprogramm-Schnittstelle gemäß der vorliegenden Erfindung und ihrer Interaktionen mit einem Anwenderprogramm.
Fig. 4 ist ein Diagramm von zwei unterschiedlichen Formaten für ein Kanalbefehlswort (CCW, Channel Command Word) der System/370 Architecture oder der System/370 Extended Architecture sowie von Formaten eines Kanalstatuswortes (CSW, Channel Status Word) des System/370-Modus und eines Subkanalstatuswortes (SCSW, Subchannel Status Word) des System/370-XA-Modus. Dieses Diagramm wird zu Referenzzwecken hinsichtlich der nachstehenden detaillierten Beschreibung des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung vorgelegt.
In Figur 1 ist ein Blockdiagramm dargestellt, das die Anwenderprogramm-Schnittstelle (API, Application Program Interface) gemäß der vorliegenden Erfindung illustriert, wie sie in der IBM "CMS Console I/O Facility" (im folgenden Konsole 6 genannt) enthalten ist, die Teil des aktuellen IBM- Betriebssystems VM/SP ist und sich bei VM/SP Release 5 oder höher in die Gesamtstruktur der I/O-Behandlungsroutinen des Conversational Monitor System (CMS) des IBM Virtual Machine/System Product (VM/SP) einfügen soll. Die IBM "CMS Console I/O Facility" ist in einer IBM-Publikation mit dem Titel "Virtual Machine/System Product CMS Console Facility, Release 4" (SC24-5333-0) beschrieben, die in ihrer Gesamtheit durch Verweis in die vorliegende Patentschrift aufgenommen ist.
Die Blöcke 1 und 2 in Figur 1 stellen das CMS-System in einer Nicht-Vollbild-Umgebung, manchmal auch als Zeilenmodus- Umgebung bezeichnet, dar, die keine API gemäß der vorliegenden Erfindung umfaßt. Die Befehle auf dieser Ebene werden bei einer Maschine im System/370-Modus von einer Anweisung Start I/O (SIO) oder bei einer Maschine im System/370-XA-Modus von einer Anweisung Start Subchannel (SSCH) im Zeilenmodus (3215) behandelt, und das CMS muß die Maschinenarchitektur berücksichtigen, um die gesamte eigene I/O von und zu einem Anzeigegerät 7 zu behandeln.
Der System Product Editor (XEDIT) 3 ist ein Anwenderprogramm, das im CMS-Kern angesiedelt ist und die von der Konsole 6 geleistete I/O-Verarbeitung nutzen kann. Die HELP- Systemroutinen und Produktivitätshilfen wie die Programme "RDRLIST" und "FILELIST" im CMS stellen mit Hilfe von XEDIT 3 auf diese Weise auch Daten in Vollbild-Anzeige dar. Wie oben im Abschnitt "Hintergrund der Erfindung" beschrieben führte XEDIT früher alle eigenen Eingabe/Ausgabe-Operationen selbst durch und behandelte die architekturabhängige Verarbeitung, die mit diesen Operationen zusammenhängt. Von VM/SP Release 5 an erfolgt der Aufbau eines 3270-Datenflusses in CMS- Sitzungsdiensten (CMS Session Services) 4, die für bestimmte Anforderungen Aufrufe der Konsole 6 einrichtet. Der Datenfluß besteht aus Anordnungen (Anweisungen, die Steuerungsinformationen liefern) und Daten, die auf ein Anzeigegerät vom Typ 3270 geschrieben werden sollen, gestützt auf Größe, Attribute und andere Eigenschaften des Gerätes.
Ebenso mußten vor der Einführung der Konsole 6 andere Vollbild-Anwendungen (Anwenderprogramme) 5 selbst ihre I/O- Anweisungen auf niedriger Ebene ausführen, das Kanalprogramm aufbauen sowie Unterbrechungen und alle Fehler behandeln, die sie von dem Anzeigegerät 7 erhielten.
Anwendungen können dieses Verfahren nach wie vor verwenden, müssen dabei jedoch berücksichtigen, ob das Gerät eine virtuelle Konsole oder ein dediziertes Gerät ist und ob die Architektur der Maschine System/370 oder System/370-XA ist. Wenn jedoch die Anwenderprogramme 5 die API der Konsole 6 auf höherer Ebene benutzen, können sie leicht von System/370 zu System/370-XA wechseln und die Konsole 6 die Verarbeitung von Eingabe/Ausgabe-Operationen behandeln lassen.
Zu Figur 1 ist weiterhin anzumerken, daß die Konsole eine Makroschnittstelle und ein oder mehrere Module umfaßt, durch die ein Anwenderprogramm die folgenden Funktionen anfordern kann, die weiter unten im Zusammenhang mit den Figuren 2 und 3 beschrieben werden:
OPEN - Richtet einen Anwendungs-"Pfad" zu einem vom Anwenderprogramm angegebenen Anzeigegerät wie z.B. dem Anzeigegerät 7 ein. Der Pfadname unterscheidet eine Anwendung eindeutig von einer anderen. Die Konsole 6 unterstützt die Durchführung der I/O zu dedizierten 3270-Geräten, einschließlich vermittelter Geräte und 3270-Graphikdrucker, sowie zu der virtuellen Konsole.
CLOSE - Löscht den angegebenen Pfadeintrag.
READ/WRITE - Liest und schreibt Puffer mit 3270-Datenflüssen, die von dem Anwenderprogramm aufgebaut werden. Die Kanalbefehlswörter (CCWs, Channel Command Words) werden aufgebaut, für die virtuelle Konsole wird eine Anweisung Diagnose X'58' ausgegeben, und für dedizierte Geräte werden SIO oder SSCH ausgegeben.
EXCP - Führt I/O-Operationen unter Verwendung von CCWs durch, die von dem Anwenderprogramm geliefert werden.
WAIT - Wartet auf eine I/O-Unterbrechung auf dem entsprechenden Anzeigegerät eines Pfads.
QUERY - Gibt Informationen über das Anzeigegerät zurück, wenn ein Benutzer QUERY DEVICE angibt, oder Informationen über den Pfad und das zugehörige Gerät, wenn QUERY PATH angegeben wird.
Die Figuren 2 und 3 zeigen die Logik der in Figur 1 dargestellten Konsole 6. In Betrieb gibt ein Anwenderprogramm 10 eine Anforderung einer bestimmten Funktion an das Makro der Konsole 6 (Konsolenmakro) aus, das Anweisungen erzeugt, die eine Parameterliste (Pliste) 20 aufbauen, die für die angeforderte Funktion benötigt wird. Eingeschlossen in den erzeugten Anweisungen ist ein Supervisor-Aufruf (SVC, Supervisor Call), der die Steuerung an ein Modul DMSCCSVC übergibt, das die Anforderung verarbeitet (Block 30). Dieser Prozeß erfolgt jedes Mal, wenn das Anwenderprogramm 10 einen Makroaufruf an die Konsole 6 ausgibt. Das Szenario, das jetzt beschrieben wird, ist ein Beispiel dafür, welche Schritte ein Anwenderprogramm 10 unter Umständen ergreifen muß, um mit Hilfe der Konsole 6 effektiv mit dem Anzeigegerät 7 zu kommunizieren. Jedes Anwenderprogramm kann einen etwas anderen Ansatz wählen, manche komplexer als andere, doch zu Demonstrationszwecken wird die folgende Beschreibung die Informationen liefern, die zum Verständnis der Verarbeitung notwendig sind, die zu den zugrundeliegenden Funktionen gehört.
Beginnend bei Block 40 muß das Anwenderprogramm 10 sich zunächst gegenüber der Konsole 6 durch die Ausgabe einer OPEN-Anforderung selbst definieren. Dadurch wird ein Kommunikationspfad zu dem zugehörigen Anzeigegerät 7 eingerichtet. Sofern der angegebene Pfadname bereits existiert, wird im Diagrammblock 50 ein Rückgabecode ausgegeben, und die Information über diesen Pfad und das Anzeigegerät wird in einen Puffer zurückgegeben, wenn dieser von dem Anwenderprogramm 10 bereitgestellt wird; andernfalls, wenn der Pfadname nicht existiert, versucht die Verarbeitung weiter, einen Pfad zu öffnen. Dies ist die einzige Funktion der Konsole 6, die fortfährt, wenn ein Pfad nicht gefunden wird.
Wie bereits ausgeführt ist die Konsole 6 eine einzige Schnittstelle zu der virtuellen Konsole wie auch zu dedizierten 3270-Geräten. Wenn in der Parameterliste (Pliste) keine Gerätenummer angegeben ist, wird angenommen, daß es um die virtuelle Konsole geht. Die Konsole 6 gibt eine Anweisung Diagnose X'24' aus, um die virtuellen und reellen Geräteeigenschaften der Gerätenummer in der Pliste zu erhalten. Sofern das Gerät definiert ist und zu einer Vollbild-I/O in der Lage ist und nicht etwa ein schreibmaschinenartiges Terminal (TTY) ist, gibt die Konsole 6 auch eine Anweisung Diagnose X'8C' aus, um zusätzliche Geräteeigenschaften zu erhalten, wie etwa Informationen darüber, ob das Gerät Farbe, erweiterte Hervorhebungen oder programmierbare Symbolsätze (PPS) unterstützt. Diagnoseanweisungen sind in einer IBM-Publikation mit dem Titel "VM/SP System Facilities for Programming, Release 5" (SC24-5288-0) näher beschrieben, die in ihrer Gesamtheit durch Verweis in die vorliegende Patentschrift aufgenommen ist. Sobald die Konsole feststellt, daß das Gerät für die OPEN-Funktion gültig ist, speichert es die Informationen über Pfad und Gerät in Steuerblöcken, die in einer verknüpften Liste gehalten werden, damit sie für nachfolgende I/O- Operationen wiederverwendet werden können. Zu jedem geöffneten Pfad gehört ein Geräteeintrag, und für jedes gegebene Gerät können mehrere Pfade offen sein. Aus diesen Pfad- und Gerätesteuerblöcken werden bestimmte Informationen herausgezogen und in einem Puffer gespeichert, der von dem Anwenderprogramm 10 bereitgestellt wird. Das Anwenderprogramm 10 kann die zurückgegebenen Informationen dann mit einem Zuordnungsmakro (CQYSECT) interpretieren, das von der Konsole 6 bereitgestellt wird.
Aus den Informationen zu den Eigenschaften des Anzeigegerätes 3270 kann das Anwenderprogramm 10 im Anschluß dann einen gültigen 3270-Datenfluß für dieses Gerät aufbauen, wie im Diagrammblock 60 gezeigt. Ein Datenfluß steuert die Verarbeitung und Formatierung der Daten mit Befehlen, Anordnungen (Anweisungen, die Steuerungsinformationen liefern), Steuerzeichen, Attributen oder strukturierten Feldern. Bei einer Schreibanforderung der Konsole 6 (Block 70) muß die Anwendung einen Puffer bereitstellen, der den Datenfluß enthält.
In der Subroutine, mit der die I/O-Verarbeitung beginnt, prüft DMSCCSVC die von der Parameterliste übergebenen Parameter und stellt sicher, daß alle erforderlichen Parameter angegeben sind und keine sich widersprechenden Optionen angegeben sind (Block 80). Sobald festgestellt wird, daß eine gültige I/O-Anforderung vorliegt, fährt die Verarbeitung fort, die nötigen Informationen für die I/O- Operation aufzubauen.
Die Funktion Write (Schreiben) der Konsole 6 ermöglicht es Anwendungen, Daten als Vollbild auf ihre Anzeigegeräte zu schreiben. Durch Verfolgung des Pfades, der die letzte I/O- Operation ausgeführt hat, kann die Konsole 6 die Nutzung des Bildschirms zwischen verschiedenen Anwendungen koordinieren.
Damit das Anwenderprogramm 10 in den Vollbild-Modus gehen kann, muß das Anwenderprogramm 10 zuerst den Befehl Erase/Write (EW, Löschen/Schreiben) oder Erase/Write Alternate (EWA, Löschen/Schreiben alternativ) geben, damit der Inhalt des Bildschirms vollständig gelöscht wird, und dann in seinen Puffer schreiben. Dies gilt ebenfalls, wenn die Konsole 6 dem Anwenderprogramm durch einen Rückgabecode mitteilt, daß die Steuerung des Bildschirms bei einem anderen Anwenderprogramm liegt, und der Befehl EW/EWA muß dann gegeben werden, um den Bildschirm neu zu formatieren und die Steuerung dem Anwenderprogramm 10 zu geben. Sobald der Bildschirm dem Anwenderprogramm 10 gehört, genügt für nachfolgende Schreibvorgänge ein gewöhnlicher Write-Befehl (W, Schreiben), der den jeweiligen Bildschirminhalt einfach aktualisiert.
Wenn das Anwenderprogramm die Optionen Erase/Write, Erase/Write Alternate, Write Structured Field oder Write angibt, muß es einen Puffer bereitstellen, der einen vollständigen 3270-Datenfluß enthält, wie oben beschrieben. Die Konsole 6 modifiziert diesen Puffer in keiner Weise und verifiziert auch seinen Inhalt nicht. Daher muß das Anwenderprogramm 10 sicher sein, daß die Makro-Optionen nicht dem widersprechen, was in dem Datenfluß geliefert wird. Der Block 90 zeigt, wie DMSCCSVC die Architektur der virtuellen Maschine prüft, auf der die Anwendung läuft, (370- oder XA- Modus). An diesem Punkt wird ein großer Teil der architekturabhängigen Informationen aufgebaut, und die Konsole 6 muß feststellen, ob die Steuerung an ein anderes Modul DMSCCX zur Behandlung der I/O-Verarbeitung von System/370-XA weitergegeben werden soll (Block 95) oder ob innerhalb von DMSCCSVC damit fortgefahren werden soll, aufgrund der angegebenen Makro-Optionen das entsprechende Kanalbefehlswort (CCW) aufzubauen (Block 110). Für die virtuelle Konsole werden CCWs für eine Anweisung Diagnose X'58' aufgebaut; für dedizierte Geräte werden CCWs für SIO- Anweisungen gemäß System/370 Architecture aufgebaut. Der Block 100 enthält einen sehr ähnlichen Prozeß im XA-Modus, wobei jedoch die CCWs gemäß System/370-Extended Architecture aufgebaut werden müssen. Für dedizierte Geräte werden die CCWs für eine SSCH-Anweisung aufgebaut, bei der ein anderes Format (Format-1) und zusätzliche Informationen eine Rolle spielen, die in einem Operationsanforderungsblock (ORB, Operation Request Block) enthalten sind. Sowohl im 370- als auch im XA-Operationsmodus muß für die I/O zu einer virtuellen Konsole eine Anweisung Diagnose X'58' verwendet werden, doch akzeptiert wird nur ein CCW in Format-0, das nur eine 3-Byte-Datenadresse haben kann. Um eine 31-Bit-Adresse im Kanalprogramm unterbringen zu können, richtet die Konsole 6 eine indirekte Datenadreßliste (IDAL, Indirect Data Address List) ein, die dann den Speicher über 16 Megabyte adressieren kann.
Figur 4 zeigt ein CCW in Format-0, das in der System/370 Architecture oder für Anweisungen Diagnose X'58' in beiden Architekturen, System/370 und System/370-XA, verwendet wird, und ein CCW in Format-1, das in System/370-XA verwendet wird. Der Adreßteil des CCW in Format-0 kann auf Daten oder eine IDAL zeigen. Jeder Vier-Byte-Eintrag oder jedes indirekte Datenadreßwort (IDAW, Indirect Data Address Word) in der IDAL zeigt auf die zu schreibenden oder zu lesenden Daten. IDALs erlauben es Programmen, Puffer im Speicher über 16 Megabyte für ein Kanalprogramm Diagnose X'58' im XA-Modus zu adressieren. In dem CCW gibt es ein Bit, daß dem Steuerungsprogramm mitteilt, ob die CCW-Datenadresse tatsächlich auf einen Datenpuffer oder eine IDAL deutet oder nicht. Figur 4 zeigt auch die Formate eines Kanalstatuswortes (CCW, Channel Status Word) von System/370 und eines Subkanalstatuswortes (SCSW, Subchannel Status Word) von System/370-XA, um den Unterschied zwischen den beiden Architekturen bei der Behandlung der Bausteine von I/O- Operationen aufzuzeigen. Genauere Informationen über das Obengesagte finden sich in der IBM-Publikation mit dem Titel "IBM System/370 Principles of Operation" (GA22-7000) und in der IBM-Publikation mit dem Titel "IBM System/370-Extended Architecture Principles of Operation" (GA22-7085), die in ihrer Gesamtheit durch Verweis in die vorliegende Patentschrift aufgenommen sind.
Die Konsole 6 führt ihre I/O-Operationen synchron durch; die Konsole 6 wartet also auf den Abschluß der I/O-Operation durch Ausgabe von Anweisungen Test I/O (TIO) im 370-Modus oder von Anweisungen Test Subchannel (TSCH) im XA-Modus. Die Prüfung des Kanalstatuswortes (CSW, Channel Status Word) im 370-Modus (Block 115) oder des Subkanalstatuswortes (SCSW, Subchannel Status Word) im XA-Modus (Block 105) und das erneute Versuchen der I/O bei einigen Fehlerbedingungen liegt in der Verantwortlichkeit der Konsole 6. Bei einem unmittelbaren Fehler aus der Ausführung einer I/O-Anweisung versucht die Konsole 6, mehr darüber herauszufinden, warum die Operation gescheitert ist. Dies erfolgt durch Ausgabe einer weiteren Anweisung Diagnose X'24' zur Beschaffung der Geräteeigenschaften, die dem Anwenderprogramm 10 mitteilen können, ob der Fehler aufgetreten ist, weil das Gerät gerade nicht angeschlossen ist, oder ob sich die Eigenschaften verändert haben, weil es seit der letzten I/O für diesen Pfad zu einem Abtrennen und Wiederanschließen an ein anderes Gerät gekommen ist. Das Ergebnis dieser Feststellung wird dem Anwenderprogramm 10 zusammenfassend als Eigenschafts- Rückgabecode mitgeteilt. Wenn weitere Informationen benötigt werden, kann das Anwenderprogramm 10 eine Anforderung Query Path ausgeben, um den CSW/SCSW-Inhalt und alle Prüfdaten zu bekommen, die nach der letzten I/O-Operation eingegangen sind.
Sobald der Bildschirm erfolgreich beschrieben wurde, gibt das Anwenderprogramm 10 eine Wait-Anforderung aus (Block 120). Wenn ein Anwenderprogramm auf eine Unterbrechung zu einem Gerät warten will, das zu seinem Pfad gehört, gibt es eine Wait-Anforderung oder eine Read-Anforderung mit Wait-Option aus. Die Warteroutine verfolgt den Pfad, der wartet, und lädt dann ein freigegebenes Warte-PSW (Block 130). Wenn die Unterbrechung durch den Unterbrechungsbehandler der ersten Ebene (DMSITI) eingeht, kehrt die Steuerung nach der Anweisung Load PSW (LPSW) zu der Warteroutine der Konsole 6 zurück. Dann kehrt die Steuerung entweder zu dem Anwenderprogramm zurück, das eine Warteanforderung ausgegeben hat, oder zu der Routine der Konsole 6, die eine Leseoperation zur Behandlung der Unterbrechung ausgibt. Wenn das Anwenderprogramm eine explizite Warteanforderung ausgegeben hat, muß es die Unterbrechung durch Ausgabe einer Leseanforderung behandeln, wenn die Steuerung zu ihm zurückkehrt.
Um der vorangegangenen Verarbeitung gerecht zu werden, muß DMSITI (Block 140) die Unterbrechungen an das Konsolenmodul DMSCCSVC zurückleiten (Block 160). Die Geräteeinträge der Konsole 6 werden nach einer Geräteadresse durchsucht, die der unterbrechenden Geräteadresse entspricht. Wird sie gefunden und ein Pfad wartet auf diese Unterbrechung, wird das CSW/SCSW zu dem Pfadeintrag verschoben, und die Steuerung wird der Konsole 6 zurückgegeben. Wenn der Geräteeintrag angezeigt hat, daß das Gerät nicht angeschlossen war, gilt dies als Wiederanschluß, und es wird ein Eintragspunkt aufgerufen, der die Geräteinformationen im Geräteeintrag der Konsole 6 aktualisieren soll (Block 150). Dies trägt dazu bei, daß die Geräteinformationen aktuell bleiben.
Wenn kein Pfad auf das unterbrechende Gerät wartet, setzt sich die Verarbeitung mit DMSITI fort, um benutzerdefinierte Tabellen (von HNDINT eingerichtete Routinen) zu durchsuchen, nach STAX-Ausgängen (Ausgängen nur für Abrufunterbrechungen) und nach Ausgängen der Konsole (durch die Open-Funktion definiert) zu forschen. Wenn keiner der genannten bisher durch ein Anwenderprogramm definiert wurde, wird die Steuerung an eine I/O-Routine des CMS übergegeben.
Das Konzept eines Pfadausgangs der Konsole 6 ist primär für dedizierte Geräte bestimmt, doch auch für die virtuelle Konsole können Ausgänge benutzt werden. Wenn mehrere Pfade zu demselben Gerät geöffnet werden, wird die Ausgangsroutine des Pfades aktiviert, der die I/O zuletzt durchgeführt hat. Wenn kein Pfad die I/O durchgeführt hat, bekommt der Ausgang des zuletzt geöffneten Pfades die Steuerung. Wenn der Pfad, der die letzte I/O durchgeführt hat, oder der zuletzt geöffnete Pfad nicht mehr existiert (geschlossen wurde), wird die Verarbeitung fortgesetzt, als wären keine Ausgänge angegeben, und DMSITI übergibt die Steuerung an eine I/O-Routine des CMS.
Wenn das Anwenderprogramm 10 nach einem Wartevorgang die Steuerung zurückbekommt, gibt sie eine Read-Anforderung aus (Block 170). Die Lesefunktion erlaubt es dem Anwenderprogramm 10, den Inhalt des physischen Bildschirms in den Puffer einzulesen, den es bereitstellt. Dabei kann es sich entweder um den gesamten Bildschirm oder aber nur um die modifizierten Felder auf dem Bildschirm handeln. Stattdessen kann das Anwenderprogramm 10 auch wählen, die Lesefunktion der Konsole 6 mit der Warteoption zu verwenden. Letztere teilt der Konsole 6 mit, daß sie zuerst auf die Unterbrechung warten und dann den Lesevorgang durchführen soll, so daß dem Benutzer ein zusätzlicher Aufruf an DMSCCSVC erspart wird.
Lese-CCWs werden genauso aufgebaut wie bei der Schreibfunktion, indem die in der Parameterliste enthaltenen Optionen geprüft (Block 20) und Kanalprogramme entweder für Diagnose X'58' oder I/O-Anweisungen von System/370 aufgebaut werden (Block 180). Wie beim Schreiben wird DMSCCX aufgerufen, um das Lesen für System/370-XA zu behandeln (Block 190). READ und WRITE nutzen gemeinsam dieselben Subroutinen zur Durchführung der I/O und zur Prüfung des Kanalstatuswortes oder des Subkanalstatuswortes.
Block 200 zeigt, daß die Steuerung zu dem Anwenderprogramm 10 zurückgekehrt ist, wo dieses Programm die Informationen verarbeiten muß, die soeben in seinen Puffer eingelesen wurden. Die meisten Anwenderprogramm müssen feststellen, welche Taste auf dem Terminal gedrückt wurde und ob es auf dem Bildschirm modifizierte Felder gibt, die angezeigt werden müssen (d.h. ob der Benutzer etwas eingetippt und die Eingabetaste gedrückt hat). Generell geht das Anwenderprogramm 10 dann zurück und schreibt den Bildschirm mit allen neuen Informationen neu. Die Verarbeitung zwischen den Blöcken 60 und 200 findet in der Regel in einer Art Schleife mit einer Reihe von Schreib-, Warte- und Lesevorgängen statt.
Zusätzlich zu den Lese- und Schreibfunktionen, die die Konsole 6 bietet, gibt es eine Funktion zum Ausführen des Kanalprogramms (EXCP, Execute Channel Program), die von der Konsole bereitgestellt wird und es einem Anwenderprogramm ermöglicht, CCWs oder ein Kanalprogramm selbst bereitzustellen. Die Konsole 6 validiert die CCWs nicht und übersetzt sie nicht in eine für die Implementierung geeignete Form. Die I/O-Operation und die CSW/SCSW-Prüfung wird ebenso behandelt wie bei Lese- und Schreibfunktionen, allerdings mit Hilfe von CCWs, die von dem Anwenderprogramm bereitgestellt werden.
Block 210 zeigt, wie das Anwenderprogramm 10 eine Query- Anforderung ausgibt. Diese Abfragefunktion gibt Informationen über einen bestimmten Pfad und/oder ein Gerät in einen Puffer zurück, der von dem Anwenderprogramm bereitgestellt wurde. Eine Anforderung zur Abfrage eines Gerätes gibt nur die Geräteinformationen zurück (Block 220); zu dem Gerät muß kein Pfad geöffnet sein. Eine Anforderung zur Abfrage eines Pfades gibt Pfadinformationen sowie auch Informationen über das zu ihm gehörende Gerät zurück (Block 230). Eine Abfrageanforderung kann nach einem I/O-Fehler nützlich sein, damit ein Anwenderprogramm das CSW/SCSW oder alle Prüfdaten aus der I/O-Operation weiter untersuchen kann.
Die für eine Abfrageanforderung zurückgegebene Information wird im Speicher existierenden Pfad- und/oder Geräteeinträgen entnommen, sofern es sich nicht um ein Gerät handelt, zu dem die Konsole 6 keinen Pfad geöffnet hat. In diesem Falle werden die Geräteeigenschaften aus den Anweisungen Diagnose X'24' und X'8C' gewonnen und im Puffer des Anwenderprogramms gespeichert.
Es ist eine gute Programmierpraxis, vor dem Verlassen einer Vollbild-Anwendung eine Close-Anforderung auszugeben (Block 240). Block 250 zeigt, daß diese Funktion den von dem nicht mehr benötigten Pfadeintrag belegten Speicher freigibt. Wenn der letzte Pfad zu einem Gerät geschlossen ist, wird auch der Geräteeintrag freigegeben, und wenn das Gerät dediziert war, wird ein Befehl CP RESET gegeben. Dadurch werden alle anhängigen Unterbrechungen von dem Gerät gelöscht, und bei vermittelten Gerät wird die Wählverbindung fallengelassen.
Natürlich richtet sich die vorangegangene Beschreibung auf ein bestimmtes Ausführungsbeispiel der vorliegenden Erfindung, und verschiedene Modifikationen und andere Ausführungsbeispiele der vorliegenden Erfindung liegen für jemand auf der Hand, der in dem Fach kundig ist, zu dem die vorliegende Erfindung gehört. Daher wurde die vorliegende Erfindung zwar in Verbindung mit einem bestimmten Ausführungsbeispiel beschrieben, doch es ist klar, daß verschiedene Modifikationen und andere Ausführungsbeispiele der vorliegenden Erfindung möglich sind, ohne daß vom Umfang der vorliegenden Erfindung, wie sie hier beschrieben ist und in den beigefügten Ansprüchen beansprucht wird, abgewichen wird.

Claims

1. Ein Verfahren zur Bereitstellung von Vollbild- Eingabe/Ausgabe-Operationen in einem Informationsbehandlungssystem mit einer Zentraleinheit, gesteuert von einem Betriebssystem, das einen Datenfluß für das Gerät aufbaut und ein oder mehrere Anwendungsprogramme aufweist, die Eingabe/Ausgabe- Operationen zu einem Anzeigegerät durchführen, und das Parameterlisten aufbaut, wobei das Verfahren von einer Konsole durchgeführt wird, die zwischen dem Betriebssystem und einem oder mehreren Anwenderprogrammen kommuniziert, bestehend aus folgenden Schritten:

Feststellen von Eigenschaften des Anzeigegerätes als Reaktion auf eine Anfrage nach diesen Eigenschaften seitens eines Anwenderprogramms und Weitergeben dieser Eigenschaften an das Anwenderprogramm zur Verwendung bei der Bereitstellung eines Puffers und, wenn eine Ausgabeoperation durchgeführt werden soll,

Durchführen einer Vollbild-Eingabe/Ausgabe-Operation als Reaktion auf eine Anforderung seitens eines Anwenderprogramms mit Hilfe des Puffers und eines jeglichen Datenflusses, der von dem Anwenderprogramm bereitgestellt wird;

Erzeugen von Anweisungen zur Verarbeitung der Anforderung und Koordinieren der Anforderung mit anderen Anforderungen, die von anderen Anwenderprogrammen gestellt werden;

Weiterleiten der erzeugten Anweisungen an das Betriebssystem zur Durchführung der gewünschten Vollbild-Eingabe/Ausgabe-Operation; und

Weiterleiten von Statusinformationen, die sich aus der Eingabe/Ausgabe-Operation ergeben, an das Anwenderprogramm.

2. Das Verfahren zur Bereitstellung von Vollbild- Eingabe/Ausgabe-Operationen gemäß Anspruch 1, weiter bestehend aus folgendem Schritt:

Feststellen der Eigenschaften der Zentraleinheit zur Verwendung bei der Erzeugung von Anweisungen zur Durchführung von Vollbild-Eingabe/Ausgabe-Operationen, die sich für die Zentraleinheit eignen.

3. Das Verfahren zur Bereitstellung von Vollbild- Eingabe/Ausgabe-Operationen gemäß Anspruch 2, wobei der Schritt der Feststellung von Eigenschaften der Zentraleinheit durch Ausgeben einer Anforderung dieser Eigenschaften an das Betriebssystem durchgeführt wird.

4. Das Verfahren zur Bereitstellung von Vollbild- Eingabe/Ausgabe-Operationen gemäß Anspruch 1, weiter bestehend aus folgendem Schritt:

Feststellen von Eigenschaften des Betriebssystems zur Verwendung bei der Erzeugung von Anweisungen zur Durchführung von Vollbild-Eingabe/Ausgabe-Operationen, die sich für das Betriebssystem eignen.

5. Das Verfahren zur Bereitstellung von Vollbild- Eingabe/Ausgabe-Operationen gemäß Anspruch 4, wobei der Schritt der Feststellung von Eigenschaften des Betriebssystems durch Ausgeben einer Anforderung bestimmter Eigenschaften der Zentraleinheit an das Betriebssystem und durch Schlußfolgern von Eigenschaften des Betriebssystems aus den Eigenschaften der Zentraleinheit durchgeführt wird.

6. Das Verfahren zur Bereitstellung von Vollbild- Eingabe/Ausgabe-Operationen gemäß Anspruch 1, wobei der Schritt der Koordinierung der Anforderung mit anderen Anforderungen, die von anderen Anwendungen gestellt werden, durchgeführt wird durch das Zurückhalten von Informationen darüber, welches von dem einen oder den mehreren Anwenderprogrammen zuletzt eine Eingabe/Ausgabe-Operation an das Anzeigegerät durchgeführt hat, und durch Erzeugen von Anweisungen zum Löschen und Neuformatieren des Anzeigegerätes nach Bedarf.