Makro | Kurzbeschreibung |
CONTXT | liest oder schreibt in den Registern des unterbrochenen Contingency-Prozesses oder des Basisprozesses |
DISCO | schließt die Definition einer Routine als Contingency-Prozess |
ENACO | eröffnet eine Routine als Contingency-Prozess und weist ihr einen Contingency-Namen und eine Priorität zu |
LEVCO | ändert die Priorität des aufrufenden Basis- oder Contingency-Prozesses während des Ablaufs |
RETCO | beendet den aufrufenden Contingency-Prozess. Das System setzt den Prozess mit dem Basisprozess oder einem anderen Contingency-Prozess fort |
SUSPEND | setzt den aufrufenden Basis- oder Contingency-Prozess in einen unterbrechbaren Wartezustand |
Einsatz von Contingency-Prozessen
Contingency-Prozesse werden in Zusammenhang mit der ereignisgesteuerten Verarbeitung und auch mit dem STXIT-Verfahren verwendet.
Die Verwendung von Contingency-Prozessen im STXIT-Verfahren stellt einen speziellen Anwendungsfall dar. Daraus sich ergebende Einschränkungen gegenüber der folgenden Beschreibung gehen aus dem Abschnitt „STXIT-Verfahren“, ("STXIT-Verfahren mit Contingency-Verarbeitung") hervor.
Es handelt sich dabei um benutzereigene Abläufe, die vom System als abhängiger Prozess verarbeitet werden.
Folgende Merkmale kennzeichnen einen Contingency-Prozess und unterscheiden ihn von einer Task einerseits und von einer Routine andererseits:
Ein Contingency-Prozess hat keine eigene Auftragsnummer (TSN).
Contingency-Prozesse können ineinander geschachtelt werden.
Ein Contingency-Prozess wird nicht durch SET-LOGON-PARAMETERS vom Benutzer gestartet. Sein Start wird durch das Eintreten eines vom Benutzer bestimmten Ereignisses ausgelöst.
Ein Contingency-Prozess hat eine eigene Verarbeitungsebene (Priorität) und einen eigenen Process Control Block (PCB); damit einen eigenen Registersatz.
Der Benutzer kann durch einen Contingency-Prozess, dessen Start definitionsgemäß von einem Ereignis ausgelöst wird, Maßnahmen durchführen lassen, die auf dieses Ereignis genau abgestimmt sind. Als solches Ereignis könnte zum Beispiel gelten, dass ein anderer Prozess ein bestimmtes Verarbeitungsstadium erreicht hat, wie die Erstellung einer Datei oder der Start eines Programms.
Die Maßnahmen zur Behandlung mehrerer Ereignisse können durch die Vergabe entsprechender Prioritäten präzise koordiniert werden.
Die Register des Contingency-Prozesses enthalten bei seinem Start den Wert Null, und man muss ein Basisregister zuweisen und laden. Bei der Wahl des Basisregisters muss man berücksichtigen, dass die Register R1, R2, R3 und evtl. R4 für Informationsübergabe an den Contingency-Prozess vorgesehen sind.
Contingency-Prozesse können vom Benutzer durch den Aufruf folgender Makros verwendet werden:
ENACO: Eröffnen der Contingency-Definition
DISCO: Schließen der Contingency-Definition
RETCO: Beenden Contingency-Prozess
CONTXT: Zugriff auf Prozessdaten
LEVCO: Priorität ändern
Eröffnen und Schließen der Contingency-Definition
Die Definition eines Contingency-Prozesses wird durch den Aufruf des Makros ENACO vorgenommen. Dabei werden der Name, die Startadresse und die Priorität festgelegt. Der zum Zeitpunkt der Contingency-Definition eingeschaltete Adressierungsmodus (AMODE) wird durch das Betriebssystem auch bei Ablauf der Contingency-Routine eingeschaltet.
Der Makro ENACO kann sowohl in einem Prozess (Basisprozess) als auch in einem Contingency-Prozess aufgerufen werden. Der Basisprozess ist immer der zugehörige unabhängige Prozess, der als erster Prozess (mit SET-LOGON-PARAMETERS) gestartet wurde.
Sobald eine Routine nicht mehr zum Ablauf als Contingency-Prozess verwendet werden soll, kann der Benutzer die Contingency-Definition schließen, indem er den Makroaufruf DISCO mit dem Namen des Contingency-Prozesses gibt. Die Contingency-Definition wird dadurch gelöscht.
Nachfolgende POSSIG- und SOLSIG-Aufrufe, die sich auf eine gelöschte Contingency-Definition beziehen, werden zurückgewiesen. POSSIG- oder SOLSIG-Aufrufe, deren zugehöriger Eintrag zum Zeitpunkt der Löschung noch in den Warteschlangen der Ereigniskennung steht, sind von der Löschung der Contingency-Definition nicht betroffen. Der Contingency-Prozess wird also bei Eintreten der Bedingungen noch aktiviert.
Im Gegensatz zur Ereigniskennung ist der Geltungsbereich eines Contingency-Prozesses immer lokal, seine Verwendung ist also auf die definierende Task beschränkt. Eine Task kann maximal 400 Contingency-Prozesse gleichzeitig verwenden.
Das System stellt dem definierenden Prozess für den Namen eines Contingency-Prozesses unter einer Adresse eine Kurzkennung zur Verfügung. Die Verwendung dieser Kurzkennung beschleunigt die Verarbeitung und ist in den Makroaufrufen POSSIG und SOLSIG vorgeschrieben. Wird eine Contingency-Definition gelöscht und mit demselben Namen von neuem gegeben, so kann die Kurzkennung anders lauten als im vorhergehenden Fall.
Start und Ende des Contingency-Prozessablaufs
Der Benutzer ermöglicht den Start eines Contingency-Prozesses dadurch, dass er dessen Kurzkennung in einem POSSIG- oder SOLSIG-Makroaufruf (siehe "Contingency-Prozesse") als Operand angibt. Dadurch wird der Zusammenhang mit dem auslösenden Ereignis hergestellt.
In folgenden Fällen wird ein Contingency-Prozess aktiviert und - sofern seine Priorität das erlaubt - gestartet:
Asynchroner Fall der ereignisgesteuerten Verarbeitung
Der Contingency-Prozess wurde in dem Makroaufruf SOLSIG zur Anforderung eines Ereignissignals angegeben, und das Signal ist eingetroffen (Bild 17 (Ereignisgesteuerte Verarbeitung (Eventing))) bzw. die Wartezeit ist verstrichen.
Der Contingency-Prozess wird auch gestartet, wenn der Basisprozess die Ereigniskennung vorher löscht (DISEI).Quittung für ein gegebenes Signal
Der Contingency-Prozess wurde in dem Makroaufruf POSSIG zur Signalisierung eines Ereignisses angegeben, und das Signal wurde angefordert (Bild 19) bzw. die Wartezeit ist verstrichen. Der Contingency-Prozess wird auch gestartet, wenn der Basisprozess die Ereigniskennung vorher löscht (DISEI).
Der Start eines Contingency-Prozesses wird vom System unter folgenden Voraussetzungen durchgeführt:
Kein Prozess mit höherer Priorität ist aktiviert oder gestartet.
Kein Prozess mit gleicher Priorität ist vor ihm in der Warteschlange eingereiht.
Der Contingency-Prozess muss zu Beginn ein Basisregister definieren.
Der Contingency-Prozess wird mit dem Zugriffsrecht gestartet, das während des zugehörigen SOLSIG- bzw. POSSIG-Aufrufs gültig war. Die Contingency-Routine wird vom Betriebssystem in demselben Adressierungsmodus gestartet, der zum Zeitpunkt der Contingency-Definition (Makro ENACO oder STXIT) eingeschaltet war. Nach Ablauf des Contingency-Prozesses erhält der unterbrochene Prozess wieder das Zugriffsrecht, das er vor der Unterbrechung hatte.
Bild 19: Ablaufschema eines Contingency-Prozesses: Der Contingency-Prozess wird hier zur Quittierung eingesetzt
Der Ablauf eines Contingency-Prozesses wird dadurch beendet, dass von dem Contingency-Prozess der Makro RETCO aufgerufen wird. Die Steuerung wird dann, abhängig von den Prioritäten, dem Basisprozess oder einem anderen Contingency-Prozess übergeben.
Prozesspriorität bei der Contingency-Verarbeitung
Sind mehrere Contingency-Prozesse definiert, so kann durch Vergabe von Prioritäten bei der Contingency-Definition und durch Prioritätsänderung während des Ablaufs eine Koordinierung bei gleichzeitigem Eintreten von mehreren Ereignissen durchgeführt werden.
Zugelassener Prioritätsbereich:
Basisprozess | Priorität 0-127 | Standardwert: 0 |
Contingency-Prozess | Priorität 1-127 | Standardwert: 1 |
Ein Contingency-Prozess hat standardmäßig eine höhere Priorität als der Basisprozess und unterbricht diesen durch seinen Start. Der Basisprozess kommt erst wieder nach Beendigung des Contingency-Prozesses zum Ablauf. Auch ein Contingency-Prozess kann durch einen weiteren Contingency-Prozess mit höherer Priorität unterbrochen werden (Bild 20). Mehrere Contingency-Prozesse gleicher Priorität werden standardmäßig in eine Warteschlange eingereiht, die nach dem FIFO-Prinzip (first in - first out) abgearbeitet wird.
Sowohl ein Basisprozess als auch ein Contingency-Prozess kann seine eigene Priorität während des Ablaufs durch den Aufruf des Makros LEVCO ändern. Dabei kann zwischen dem FIFO- und dem LIFO-Prinzip gewählt werden. Der Prozess wird mit seiner geänderten Priorität unter Prozesse gleicher Priorität entsprechend eingereiht.
FIFO-Prinzip (first in - first out):
Der Prozess wird nach seiner Aktivierung oder nach Ausführung des Makros LEVCO am Ende der Warteschlange für Prozesse gleicher Priorität eingereiht. Alle vor ihm in der Warteschlange eingereihten Prozesse werden vor ihm gestartet. Setzt ein Prozess seine Priorität während seines Ablaufs herab und lässt das FIFO-Prinzip gelten, dann besteht die Möglichkeit, dass er auch durch Prozesse gleicher Priorität unterbrochen wird. Dies kann verhindert werden, indem im Aufruf des Makros LEVCO das LIFO-Prinzip gewünscht wird.LIFO-Prinzip (last in - first out):
Der Prozess wird nach seiner Aktivierung oder nach Ausführung des Makros LEVCO an der Spitze der Warteschlange für Prozesse gleicher Priorität eingereiht. Vor ihm können also nur Prozesse höherer Priorität zum Ablauf kommen.
Zur Unterbrechbarkeit von Contingency-Prozessen siehe auch Makro CONTXT.
Es liegt in der Hand des Benutzers, die Prioritäten so zu vergeben, dass sich eine sinnvolle Prozess-Schachtelung ergibt. Bei Erhöhung der Basisprozess-Priorität sollte darauf geachtet werden, dass nachfolgend aktivierte Contingency-Prozesse nicht dadurch abgeblockt werden, bis der Basisprozess beendet ist. Wird in einer derartigen Konstellation (der aktive Prozess hat eine höhere Priorität als bereits wartende Contingency-Prozesse in der Warteschlange) der aktive Prozess mit dem SUSPEND-Makro in den Wartezustand versetzt, führt das nicht zum Start der bereits wartenden Contingency-Prozesse.
Einschränkung
Ein Prozess darf seine Priorität nicht derartig herabsetzen, dass sie unter der eines Prozesses liegt, der bereits gestartet (und unterbrochen) war. Dieser zu irgendeinem früheren Zeitpunkt gestartete und unterbrochene Prozess darf erst nach Beendigung des nach ihm gestarteten Contingency-Prozesses wieder zum Ablauf kommen.
Zugriff zum unterbrochenen Prozess
Jeder Contingency-Prozess hat einen eigenen Registersatz.
Ein Contingency-Prozess hat Zugriff zu den Registern des Prozesses, den er unterbrochen hat, oder zu denen des Basisprozesses. Der Makro CONTXT ermöglicht das Lesen oder Verändern der Gleitpunktregister, des Befehlszählers und der allgemeinen Register des unterbrochenen oder des Basisprozesses.
Informationsübergabe an Contingency-Prozesse
Ein Contingency-Prozess kann bei seinem Start maximal drei Arten von Informationen erhalten.
Register R1:
Kann eine Contingency-Mitteilung (4 Byte) enthalten. Sie kann im Aufruf ENACO oder - zu einem späteren Zeitpunkt mit überschreibender Wirkung - in den Aufrufen POSSIG oder SOLSIG angegeben werden (Bild 18 (Ereignisgesteuerte Verarbeitung (Eventing))). Ihre Form und Bedeutung kann vom Anwender beliebig festgelegt werden.
Register R2:
Enthält immer den Ereignis-Informationscode (2 Byte), der angibt, welche Bedingungen zur Aktivierung des Contingency-Prozesses geführt haben. Seine Form und Bedeutung ist vorgegeben (siehe Tabelle 8).
Register R3 (+ R4):
Kann einen Post Code (4 oder 8 Byte) enthalten. Umfasst der Post Code 8 Byte (2 Worte), wird das zweite Wort in Register R4 eingetragen. Der Post Code kann im Makroaufruf POSSIG angegeben werden (Bild 18 (Ereignisgesteuerte Verarbeitung (Eventing))). Seine Form und Bedeutung kann vom Benutzer innerhalb der geltenden Konventionen festgelegt werden (siehe "Ereignisgesteuerte Verarbeitung (Eventing)").
Bild 20: Contingency-Prozesse: Prioritätsbedingter Ablauf
Der Ereignis-Informationscode in Register R2 besteht aus dem Ereignisschalter ES im rechtsbündigen Byte und dem Informationsindikator II im linksbündigen Byte.
II | ES | Erläuterung |
X'00' | X'00' | Das erwartete Ereignis ist eingetreten. Weder Post Code noch Contingency-Mitteilung sind vorhanden. |
X'04' | X'00' | Das erwartete Ereignis ist eingetreten. Contingency-Mitteilung ist vorhanden; Post Code ist nicht vorhanden. |
X'08' | X'00' | Das erwartete Ereignis ist eingetreten. Contingency-Mitteilung ist nicht vorhanden; Post Code (Länge = 4 Byte) wurde in Register R3 eingetragen. |
X'0C' | X'00' | Das erwartete Ereignis ist eingetreten. Contingency-Mitteilung und Post Code (Länge = 4 Byte) sind vorhanden. |
X'28' | X'00' | Das erwartete Ereignis ist eingetreten. Contingency-Mitteilung ist nicht vorhanden. Post Code (Länge = 8 Byte) wurde in die Register R3 + R4 eingetragen. |
X'2C' | X'00' | Das erwartete Ereignis ist eingetreten. Contingency-Mitteilung und Post Code (Länge = 8 Byte) sind vorhanden. |
X'00' | X'04' | Das erwartete Ereignis trat innerhalb der Zeitperiode nicht ein. Weder Contingency-Mitteilung noch Post Code sind vorhanden |
X'04' | X'04' | Das erwartete Ereignis trat innerhalb der Zeitperiode nicht ein. Contingency-Mitteilung ist vorhanden; Post Code ist nicht vorhanden. |
X'08' | X'04' | Das erwartete Ereignis trat innerhalb der Zeitperiode nicht ein. Contingency-Mitteilung ist nicht vorhanden Post Code (Länge = 4 Byte) wurde in Register R3 eingetragen. |
X'0C' | X'04' | Das erwartete Ereignis trat innerhalb der Zeitperiode nicht ein. Contingency-Mitteilung und Post Code (Länge = 4 Byte) sind vorhanden. |
X'10' | X'04' | Die Verwendung der Ereigniskennung wurde beendet (DISEI), bevor das erwartete Ereignis eintrat. Weder Contingency-Mitteilung noch Post Code sind vorhanden. |
X'14' | X'04' | Die Verwendung der Ereigniskennung wurde beendet (DISEI), bevor das erwartete Ereignis eintrat. Contingency-Mitteilung ist vorhanden; Post Code ist nicht vorhanden. |
X'18' | X'04' | Die Verwendung der Ereigniskennung wurde beendet (DISEI), bevor das Ereignis eintrat. Contingency-Mitteilung ist nicht vorhanden; Post Code (Länge = 4 Byte) wurde in Register R3 eingetragen. |
X'1C' | X'04' | Die Verwendung der Ereigniskennung wurde beendet (DISEI), bevor das Ereignis eintrat. Contingency-Mitteilung und Post Code (Länge = 4 Byte) sind vorhanden. |
X'28' | X'04' | Das erwartete Ereignis trat innerhalb der Zeitperiode nicht ein. Contingency-Mitteilung ist nicht vorhanden. Post Code (Länge = 8 Byte) wurde in die Register R3 + R4 eingetragen. |
X'2C' | X'04' | Das erwartete Ereignis trat innerhalb der Zeitperiode nicht ein. Contingency-Mitteilung und Post Code (Länge = 8 Byte) sind vorhanden. |
Tabelle 8: Ereignis-Informationscodes
II | ES | Erläuterung |
X'38' | X'04' | Die Verwendung der Ereigniskennung wurde beendet (DISEI), bevor das Ereignis eintrat. Contingency-Mitteilung ist nicht vorhanden. Post Code (Länge = 8 Byte) wurde in Register R3 + R4 eingetragen. |
X'3C' | X'04' | Die Verwendung der Ereigniskennung wurde beendet (DISEI), bevor das Ereignis eintrat. Contingency-Mitteilung und Post Code (Länge = 8 Byte) sind vorhanden. |
Tabelle 8: Ereignis-Informationscodes
Beispiel: Asynchroner Fall
Teil 1:
Dialogauftrag mit dem Programm PCOSOL1
Das Programm PCOSOL1 definiert zwei Ereigniskennungen (ADAM und EVE) und zwei Contingency-Prozesse (CONTA und CONTE). Das Programm fordert von jeder Ereigniskennung mit dem Makro SOLSIG ein Signal an und gibt jeweils einen Contingency-Prozess an (asynchroner Fall). Im Teil 1 des Beispiels wird kein POSSIG-Aufruf an die Ereigniskennungen gegeben. Der Contingency-Prozess CONTA wird gestartet, weil seine Wartezeit (60 Sekunden) verstrichen ist. CONTE wird gestartet, weil das Programm die Ereigniskennung EVE löscht.
Programm PCOSOL1
PCOSOL1 START
PRINT NOGEN
BALR 5,0
USING *,5
ENAEI EINAME=ADAM,SCOPE=GROUP,EIIDRET=ABBRADAM -----------------(1)
ENAEI EINAME=EVE,SCOPE=GROUP,EIIDRET=ABBREVE
ENACO CONAME=A,COADAD=CONTAAD,COIDRET=ABBRA --------------------(2)
ENACO CONAME=E,COADAD=CONTEAD,COIDRET=ABBRE
GDATE TOD=TIMEBAS1
SOLSIG EIID=ABBRADAM,COID=ABBRA,LIFETIM=60 ---------------------(3)
CL 15,NULL
BNE ERROR
SOLSIG EIID=ABBREVE,COID=ABBRE ---------------------------------(4)
CL 15,NULL
BNE ERROR
WROUT MLDBAS1,ERROR
VPASS 120 ------------------------------------------------------(5)
CONNECT GDATE TOD=TIMEBAS2
CHKEI EIID=ABBRADAM
ST 1,WSADAM
ST 15,WSARC
CHKEI EIID=ABBREVE
ST 1,WSEVE
ST 15,WSERC
WROUT MLDBAS2,ERROR
DISCO COID=ABBRA -----------------------------------------------(6)
DISCO COID=ABBRE
GDATE TOD=TIMEBAS3
DISEI EIID=ABBRADAM --------------------------------------------(7)
DISEI EIID=ABBREVE
WROUT MLDBAS3,ERROR
DTH1 TERM
*
CONTA BALR 6,0 ------------------------------------------------------(8)
USING *,6
GDATE TOD=TIMEA
ST 2,INFOADAM
WROUT MLDCONA,ERROR
CONTXT SAVE=LASTREG,PROCESS=LAST
ST 15,RCCONTXT
RETCO
*
DS 0F
LASTREG DS CL68
INFOADAM DS F
MLDCONA DC Y(ENDCA-MLDCONA)
DS L2
DC X'01'
DC 'TIMEOUT CONTINGENCY A AT '
TIMEA DS CL8
ENDCA EQU *
*
CONTE BALR 7,0 ------------------------------------------------------(9)
USING *,7
GDATE TOD=TIMEE
WROUT MLDCONE,ERROR
ST 2,INFOEVE
RETCO
*
INFOEVE DS F
MLDCONE DC Y(ENDCE-MLDCONE)
DS L2
DC X'01'
DC 'TIMEOUT CONTINGENCY E AT '
TIME DS CL8
ENDCE EQU *
*
ERROR CDUMP2 SCOPE=AREA
TERM
CONTAAD DC A(CONTA)
CONTEAD DC A(CONTE)
NULL DC F'0'
RCCONTXT DS F
*
ABBRADAM DS F
ABBREVE DS F
ABBRA DS F
ABBRE DS F
*
MLDBAS1 DC Y(ENDBAS1-MLDBAS1)
DS L2
DC X'01'
DC 'BOTH SOLSIGS ISSUED AT '
TIMEBAS1 DS CL8
ENDBAS1 EQU *
MLDBAS2 DC Y(ENDBAS2-MLDBAS2)
DC X'000001'
DC 'QUEUES CHECKED AT '
TIMEBAS2 DS CL8
ENDBAS2 EQU *
MLDBAS3 DC Y(ENDBAS3-MLDBAS3)
DC X'000001'
DC 'EVENT ITEMS DISABLED AT '
TIMEBAS3 DS CL8
ENDBAS3 EQU *
*
WSADAM DS F
WSARC DS F
WSEVE DS F
WSERC DS F
ENDE EQU *
END
Basisprozess
(1) | Die Ereigniskennungen ADAM und EVE werden definiert. Die Adressen der Kurzkennungen lauten ABBRADAM und ABBREVE. |
(2) | Die Routine CONTA wird als Contingency-Prozess A definiert. Die Anfangsadresse (CONTA) ist unter der Adresse CONTAAD angegeben, die Adresse der Kurzkennung lautet ABBRA. Entsprechendes gilt für die folgende Definition der Routine CONTE als Contingency-Prozess E. |
(3) | Das Programm fordert mit einem SOLSIG-Aufruf von der Ereigniskennung ADAM ein Signal und gibt den Contingency-Prozess CONTA an. Wenn nach einer Wartezeit von 60 Sekunden das Signal nicht eingetroffen ist, soll die Ereignissteuerung den Contingency-Prozess CONTA starten. Das Programm läuft nach diesem SOLSIG-Aufruf weiter. |
(4) | Mit einem weiteren SOLSIG-Aufruf wird von EVE ein Signal angefordert. Für den Contingency-Prozess CONTE gilt die Standard-Wartezeit von 10 Minuten. |
(5) | Zur Demonstration wartet das Programm mit dem Makro VPASS. Dann wird es von dem Contingency-Prozess CONTA unterbrochen, dessen Wartezeit abgelaufen ist. Nachdem CONTA beendet ist, setzt das Programm mit der Prüfung der Ereigniswarteschlangen von ADAM und EVE fort. |
(6) | Das Programm löscht die Definitionen der Contingency-Prozesse CONTA und CONTE. Der SOLSIG-Aufruf an EVE mit dem Contingency-Prozess CONTE steht zu diesem Zeitpunkt noch in der Ereigniswarteschlange von EVE. CONTE kann noch gestartet werden, aber ein weiterer SOLSIG-Aufruf, in dem CONTE angegeben ist, würde zu diesem Zeitpunkt abgewiesen. |
(7) | Das Programm löscht die Ereigniskennung ADAM und dann EVE. Sobald EVE gelöscht wird, startet die Ereignissteuerung den Contingency-Prozess CONTE. |
Contingency-Prozess CONTA
(8) | Da ein Contingency-Prozess einen eigenen Registersatz hat, muss zu Beginn ein Basisregister definiert und geladen werden. Die Register R1, R2 und R3 sind nicht geeignet, weil sie eventuell von der Ereignissteuerung verwendet werden (siehe „Informationsübergabe an Contingency-Prozesse“). Der Ereignis-Informationscode, der dem Contingency-Prozess in Register R2 übergeben wurde, wird unter der Adresse INFOADAM gespeichert. Die Register des unterbrochenen Prozesses (hier ist es der Basisprozess) werden zur Demonstration mit dem CONTXT-Aufruf in den Bereich LASTREG übertragen. Der Contingency-Prozess beendet sich mit dem Aufruf RETCO. |
Contingency-Prozess CONTE
(9) | Ein Basisregister wird definiert und geladen. Der Ereignis-Informationscode wird unter INFOEVE abgespeichert und der Contingency-Prozess CONTE wird mit RETCO beendet. |
Ablaufprotokoll des Dialogauftrags mit PCOSOL1
/start-assembh % BLS0500 PROGRAM 'ASSEMBH', VERSION '<ver>' OF '<date>' LOADED % ASS6010 <ver> OF BS2000 ASSEMBH READY //compile source=*library-element(macexmp.lib,pcosol1), - // compiler-action=module-generation(module-format=llm), - // module-library=macexmp.lib, - // listing=parameters(output=*library-element(macexmp.lib,pcosol1)), - // test-support=*aid % ASS6011 ASSEMBLY TIME: 1238 MSEC % ASS6018 0 FLAGS, 0 PRIVILEGED FLAGS, 0 MNOTES % ASS6019 HIGHEST ERROR-WEIGHT: NO ERRORS % ASS6006 LISTING GENERATOR TIME: 171 MSEC //end % ASS6012 END OF ASSEMBH /load-executable-program library=macexmp.lib,element-or-symbol=pcosol1, - / test-options=*aid % BLS0523 ELEMENT ’PCOSOL1’, VERSION ’@’ FROM LIBRARY ’:2OSG:$QM212.MACEXMP.LIB’ IN PROCESS % BLS0524 LLM ’PCOSOL1’, VERSION ’ ’ OF ’<date> <time>’ LOADED /%in dth1;%r BOTH SOLSIGS ISSUED AT 16:06:33 ----------------------------------------(10) TIMEOUT CONTINGENCY A AT 16:07:33 --------------------------------------(11) QUEUES CHECKED AT 16:07:33 ---------------------------------------------(12) TIMEOUT CONTINGENCY E AT 16:07:33 --------------------------------------(13) EVENT ITEMS DISABLED AT 16:07:33 STOPPED AT LABEL: DTH1 , SRC_REF: 380, SOURCE: PCOSOL1 , PROC: PCOSOL1 /%d infoadam %x, %@(wsadam) -> %xl8 ------------------------------------(14) *** TID: 00340180 *** TSN: 1PKB ********************************************* CURRENT PC: 00000162 CSECT: PCOSOL1 ************************************* V’00000204’ = INFOADAM + #’00000000’ 00000204 (00000000) 00000004 .... V’00000334’ = PCOSOL1 + #’00000334’ 00000334 (00000334) 000000D0 30000000 ........ /%d infoeve %x, %@(wseve) -> %xl8 --------------------------------------(15) V’0000025C’ = INFOEVE + #’00000000’ 0000025C (00000000) 10000004 .... V’0000033C’ = PCOSOL1 + #’0000033C’ 0000033C (0000033C) 00000001 28000000 ........ /%r
(10) | Das Programm fordert von jeder der beiden Ereigniskennungen ein Signal an. |
(11) | Die Wartezeit für den Contingency-Prozess CONTA ist verstrichen. |
(12) | Der Zustand der POSSIG-Warteschlange und der SOLSIG-Warteschlange jeder Ereigniskennung wird abgefragt. |
(13) | Der Contingency-Prozess CONTE läuft ab, weil die Ereigniskennung EVE von dem Basisprozess gelöscht wird. |
(14) | Ereigniskennung ADAM: Der Ereignis-Informationscode X'04' bedeutet, dass die Wartezeit verstrichen ist, ohne dass das Ereignis eintrat. |
(15) | Ereigniskennung EVE: Der Ereignisinformationscode X'10000004' bedeutet, dass die Ereigniskennung gelöscht wurde, bevor ein Ereignis eintrat. |
Teil 2:
Dialogauftrag mit dem Programm PCOSOL2
ENTER-Auftrag ENTER.POSA mit dem Programm POSA
ENTER-Auftrag ENTER.POSE mit dem Programm POSE
Programm PCOSOL2
Das Programm PCOSOL2 unterscheidet sich von PCOSOL1 nur dadurch, dass es zwei ENTER-Aufträge startet, nachdem es die beiden SOLSIG-Aufrufe an die Ereigniskennungen ADAM und EVA gegeben hat. Von dem Quellprogramm PCOSOL2 wird hier nur der Teil gezeigt, der die Änderung enthält; der Rest ist identisch mit dem Programm PCOSOL1.
PCOSOL2 START
PRINT NOGEN
BALR 5,0
USING *,5
ENAEI EINAME=ADAM,SCOPE=GROUP,EIIDRET=ABBRADAM
ENAEI EINAME=EVE,SCOPE=GROUP,EIIDRET=ABBREVE
ENACO CONAME=A,COADAD=CONTAAD,COIDRET=ABBRA
ENACO CONAME=E,COADAD=CONTEAD,COIDRET=ABBRE
GDATE TOD=TIMEBAS1
SOLSIG EIID=ABBRADAM,COID=ABBRA,LIFETIM=60
CL 15,NULL
BNE ERROR
SOLSIG EIID=ABBREVE,COID=ABBRE
CL 15,NULL
BNE ERROR
WROUT MLDBAS1,ERROR
ENTER 'ENTER.POSE,JOB-CLASS=JCB00050'
ENTER 'ENTER.POSA,JOB-CLASS=JCB00050'
VPASS 90
CONNECT GDATE TOD=TIMEBAS2
...
Programm POSA und ENTER-Datei ENTER.POSA
Der ENTER-Auftrag ENTER.POSA startet das Programm POSA. Das Programm POSA schließt sich der Ereignissteuerung unter der Ereigniskennung ADAM an und gibt einen POSSIG-Aufruf an ADAM. Bevor es die Ereigniskennung löscht, wartet es mit dem Makro VPASS 250 Sekunden, damit der Aufruf nicht aus der Ereigniswarteschlange entfernt wird, bevor das Programm PCOSOL2 den SOLSIG-Aufruf geben konnte.
POSA START
PRINT NOGEN
BALR 5,0
USING *,5
ENAEI EINAME=ADAM,SCOPE=GROUP,EIIDRET=ABBRADAM
GDATE TOD=TIMEA
POSSIG EIID=ABBRADAM
CL 15,=F'0'
BE OK
ERROR EQU *
***** Error handling *****
TERM
*
OK WROUT MLDPOSA,ERROR
VPASS 250
DISEI EIID=ABBRADAM
TERM
ABBRADAM DS F
MLDPOSA DC Y(ENDE-MLDPOSA)
DC X'000001'
DC 'POSSIG FOR ADAM ISSUED AT '
TIMEA DS CL8
ENDE EQU *
END
ENTER-Datei ENTER.POSA
/.POSA SET-LOGON-PARAMETERS /ASSIGN-SYSDTA *SYSCMD /START-ASSEMBH //COMPILE SOURCE=*LIBRARY-ELEMENT(MACEXMP.LIB,POSA), - // COMPILER-ACTION=MODULE-GENERATION(MODULE-FORMAT=LLM), - // MODULE-LIBRARY=MACEXMP.LIB, - // LISTING=PARAMETERS(OUTPUT=*LIBRARY-ELEMENT(MACEXMP.LIB,POSA)) //END /ASSIGN-SYSDTA *PRIMARY /ASSIGN-SYSOUT PROT.POSA /START-EXECUTABLE-PROGRAM LIBRARY=MACEXMP.LIB,ELEMENT-OR-SYMBOL=POSA /EXIT-JOB
Programm POSE und ENTER-Datei ENTER.POSE
Der ENTER-Auftrag ENTER.POSE startet das Programm POSE. Das Programm schließt sich der Ereignissteuerung unter der Ereigniskennung EVE an und gibt einen POSSIG-Auf-ruf an EVE. Aus dem bei POSA genannten Grund wartet es, bevor es den Aufruf DISEI gibt.
POSE START
PRINT NOGEN
BALR 5,0
USING *,5
ENAEI EINAME=EVE,SCOPE=GROUP,EIIDRET=ABBREVE
GDATE TOD=TIMEE
POSSIG EIID=ABBREVE
CL 15,=F'0'
BE OK
ERROR EQU *
***** Error handling *****
TERM
*
OK WROUT MLDPOSE,ERROR
VPASS 150
DISEI EIID=ABBREVE
TERM
ABBREVE DS F
MLDPOSE DC Y(END-MLDPOSE)
DC X'000001'
DC 'POSSIG FOR EVE ISSUED AT '
TIMEE DS CL8
ENDE EQU *
END
ENTER-Datei ENTER.POSE analog zu ENTER.POSA
Ablaufprotokoll des Dialogauftrags PCOSOL2 und der beiden ENTER-Aufträge
/start-assembh % BLS0500 PROGRAM 'ASSEMBH', VERSION '<ver>' OF '<date>' LOADED % ASS6010 <ver> OF BS2000 ASSEMBH READY //compile source=*library-element(macexmp.lib,pcosol2), - // compiler-action=module-generation(module-format=llm), - // module-library=macexmp.lib, - // listing=parameters(output=*library-element(macexmp.lib,pcosol2)), - // test-support=*aid % ASS6011 ASSEMBLY TIME: 1217 MSEC % ASS6018 0 FLAGS, 0 PRIVILEGED FLAGS, 0 MNOTES % ASS6019 HIGHEST ERROR-WEIGHT: NO ERRORS % ASS6006 LISTING GENERATOR TIME: 166 MSEC//END % ASS6012 END OF ASSEMBH /load-executable-program library=macexmp.lib,element-or-symbol=pcosol2, - / test-options=*aid % BLS0523 ELEMENT ’PCOSOL1’, VERSION ’@’ FROM LIBRARY ’:2OSG:$QM212.MACEXMP.LIB’ IN PROCESS % BLS0524 LLM ’PCOSOL1’, VERSION ’ ’ OF ’<date> <time>’ LOADED /%in dth1;%r BOTH SOLSIGS ISSUED AT 17:09:06 -----------------------------------------(1) % JMS0066 JOB ’POSE’ ACCEPTED ON 12-01-20 AT 17:09, TSN = 1PY0 % JMS0066 JOB ’POSA’ ACCEPTED ON 12-01-20 AT 17:09, TSN = 1PY1
Inzwischen geben die Enter-Aufträge POSE und POSA in ihr Ausgabeprotokoll folgende Nachrichten aus:
ENTER.POSE:
POSSIG FOR EVE ISSUED AT 17:09:21 ---------------------------------------(2)
ENTER.POSA:
POSSIG FOR ADAM ISSUED AT 17:09:22 --------------------------------------(3)
Weiter im Ablauf des Dialogauftrags
TIMEOUT CONTINGENCY A AT 17:10:36 ---------------------------------------(4) TIMEOUT CONTINGENCY E AT 17:10:36 QUEUES CHECKED AT 17:10:36 EVENT ITEMS DISABLED AT 17:10:36 STOPPED AT LABEL: DTH1 , SRC_REF: 414, SOURCE: PCOSOL2 , PROC: PCOSOL2 /%d infoadam %x, %@(wsadam) -> %xl8 -------------------------------------(5) *** TID: 00340180 *** TSN: 1PKB ********************************************* CURRENT PC: 000001D2 CSECT: PCOSOL2 ************************************* V’00000274’ = INFOADAM + #’00000000’ 00000274 (00000000) 00000000 .... V’000003A4’ = PCOSOL2 + #’000003A4’ 000003A4 (000003A4) 00000140 30000000 ... ....
/%d infoeve %x, %@(wseve) -> %xl8 V’000002CC’ = INFOEVE + #’00000000’ 000002CC (00000000) 00000000 .... V’000003AC’ = PCOSOL2 + #’000003AC’ 000003AC (000003AC) 00000158 30000000 ........ /%r
(1) | Das Programm PCOSOL2 definiert die beiden Ereigniskennungen ADAM und EVE und richtet an jede einen SOLSIG-Aufruf. Anschließend startet es zuerst den Enter-Auftrag ENTER.POSE und dann den ENTER-Auftrag ENTER.POSA. |
(2) | Der ENTER-Auftrag ENTER.POSE startet das Programm POSE, das die Ereigniskennung EVE definiert und einen POSSIG-Aufruf gibt. |
(3) | Der ENTER-Auftrag ENTER.POSA startet das Programm POSA, das die Ereigniskennung ADAM definiert und einen POSSIG-Aufruf gibt. |
(4) | Die Contingency-Prozesse CONTA und CONTE haben beide die Priorität 1. Welcher Contingency-Prozess zuerst gestartet wird, hängt davon ab, bei welcher Ereigniskennung zuerst ein SOLSIG- und ein POSSIG-Aufruf zusammentreffen. |
(5) | Nach Ablauf der beiden Contingency-Prozesse wird das Programm des Basisprozesses fortgesetzt. Es prüft die Warteschlangen bei der Ereigniskennungen: Sie sind leer. (Die Felder |
Teil 3:
Dialogauftrag mit dem Programm PCOSOL3
ENTER-Aufträge ENTER.POSA und ENTER.POSE wie in Teil 2
Programm PCOSOL3
Das Programm PCOSOL3 unterscheidet sich von PCOSOL1 und PCOSOL2 dadurch, dass es die beiden ENTER-Aufträge zu Beginn startet, bevor es die beiden SOLSIG-Auf-rufe gibt. Von dem Quellprogramm PCOSOL3 wird hier nur der Teil gezeigt, der die Änderung enthält; der Rest ist identisch mit dem Programm PCOSOL1.
PCOSOL3 START
PRINT NOGEN
BALR 4,0
USING *,4
ENTER 'ENTER.POSE,JOB-CLASS=JCB00050'
ENTER 'ENTER.POSA,JOB-CLASS=JCB00050'
ENAEI EINAME=ADAM,SCOPE=GROUP,EIIDRET=ABBRADAM
ENAEI EINAME=EVE,SCOPE=GROUP,EIIDRET=ABBREVE
ENACO CONAME=A,COADAD=CONTAAD,COIDRET=ABBRA
ENACO CONAME=E,COADAD=CONTEAD,COIDRET=ABBRE
VPASS 40
GDATE TOD=TIMEBAS1
SOLSIG EIID=ABBRADAM,COID=ABBRA,LIFETIM=60
CL 15,NULL
BNE ERROR
SOLSIG EIID=ABBREVE,COID=ABBRE
CL 15,NULL
BNE ERROR
WROUT MLDBAS1,ERROR
VPASS 90
CONNECT GDATE TOD=TIMEBAS2
...
ENTER-Auftrag ENTER.POSA mit dem Programm POSA: siehe Teil 2
ENTER-Auftrag ENTER.POSE mit dem Programm POSE: siehe Teil 2
Ablaufprotokoll des Dialogauftrags mit PCOSOL3 und der beiden ENTER-Aufträge
/start-assembh % BLS0500 PROGRAM 'ASSEMBH', VERSION '<ver>' OF '<date>' LOADED % ASS6010 <ver> OF BS2000 ASSEMBH READY //compile source=*library-element(macexmp.lib,pcosol3), - // compiler-action=module-generation(module-format=llm), - // module-library=macexmp.lib, - // listing=parameters(output=*library-element(macexmp.lib,pcosol3)), - // test-support=*aid % ASS6011 ASSEMBLY TIME: 1260 MSEC % ASS6018 0 FLAGS, 0 PRIVILEGED FLAGS, 0 MNOTES % ASS6019 HIGHEST ERROR-WEIGHT: NO ERRORS % ASS6006 LISTING GENERATOR TIME: 168 MSEC //end % ASS6012 END OF ASSEMBH /load-executable-program library=macexmp.lib,element-or-symbol=pcosol3, - / test-options=*aid % BLS0523 ELEMENT ’PCOSOL3’, VERSION ’@’ FROM LIBRARY ’:2OSG:$QM212.MACEXMP.LIB’ IN PROCESS % BLS0524 LLM ’PCOSOL3’, VERSION ’ ’ OF ’<date> <time>’ LOADED /%in dth1;%r % JMS0066 JOB ’POSE’ ACCEPTED ON 12-01-20 AT 17:20, TSN = 1PY7 ---------(1) % JMS0066 JOB ’POSA’ ACCEPTED ON 12-01-20 AT 17:20, TSN = 1PY8
Inzwischen geben die Enter-Aufträge POSE und POSA in ihr Ausgabeprotokoll folgende Nachrichten aus:
ENTER.POSE:
POSSIG FOR EVE ISSUED AT 17:20:19 ---------------------------------------(2)
ENTER.POSA:
POSSIG FOR ADAM ISSUED AT 17:20:20 --------------------------------------(3)
Weiter im Ablauf des Dialogauftrags
TIMEOUT CONTINGENCY A AT 17:20:52 ---------------------------------------(4) TIMEOUT CONTINGENCY E AT 17:20:52 BOTH SOLSIGS ISSUED AT 17:20:52 -----------------------------------------(5) QUEUES CHECKED AT 17:22:22 EVENT ITEMS DISABLED AT 17:22:22 STOPPED AT LABEL: DTH1 , SRC_REF: 417, SOURCE: PCOSOL3 , PROC: PCOSOL3 /%d infoadam %x, %@(wsadam) -> %xl8 *** TID: 00340180 *** TSN: 1PKB ********************************************* CURRENT PC: 000001DA CSECT: PCOSOL3 ************************************* V’0000027C’ = INFOADAM + #’00000000’ 0000027C (00000000) 00000000 .... V’000003AC’ = PCOSOL3 + #’000003AC’
000003AC (000003AC) 00000148 30000000 ........ /%d infoeve %x, %@(wseve) -> %xl8 V’000002D4’ = INFOEVE + #’00000000’ 000002D4 (00000000) 00000000 .... V’000003B4’ = PCOSOL3 + #’000003B4’ 000003B4 (000003B4) 00000160 30000000 ...-.... /%r
(1) | Das Programm PCOSOL3 startet zuerst den ENTER-Auftrag ENTER.POSE und dann den ENTER-Auftrag ENTER.POSA. (Die Ereignissteuerung unter ADAM und EVE eröffnet das Programm erst, nachdem (zur Demonstration) einige Zeit verstrichen ist; die SOLSIG-Aufrufe für ADAM und EVE gibt das Programm noch später.) |
(2) | Das Programm PCOPOSE (gestartet im ENTER-Auftrag ENTER.POSE) definiert die Ereigniskennung EVE und gibt einen POSSIG-Aufruf für EVE. |
(3) | Das Programm PCOPOSA (gestartet im ENTER-Auftrag ENTER.POSA) definiert die Ereigniskennung ADAM und gibt einen POSSIG-Aufruf für ADAM. |
(4) | Sobald das Programm PCOSOL3 (im Dialogauftrag) den SOLSIG-Aufruf für die Ereigniskennung ADAM gegeben hat, wird es durch den Start des Contingency-Prozesses A unterbrochen, da bei ADAM schon ein POSSIG-Aufruf vorliegt. Nach dem Ablauf von A kann das Programm fortsetzen und den SOLSIG-Aufruf für EVE geben. Auch hier liegt schon ein POSSIG-Aufruf vor, und das Programm wird wieder unterbrochen, bis der Contingency-Prozess E abgelaufen ist. |
(5) | Das Programm prüft die Warteschlangen beider Ereigniskennungen: Sie sind leer. (Die Felder |
Für ein weiteres Beispiel siehe Beschreibung des Makros POSSIG ("POSSIG - Ereignis signalisieren").