Intertaskkommunikation (ITC)

Makro	Kurzbeschreibung
CLCOM	beendet die Teilnahme an der Intertaskkommunikation
OPCOM	erklärt die Teilnahme an der Intertaskkommunikation und übergibt einen ITC-Namen
RELBF	löscht die erste Nachricht in der ITC-Empfangswarteschlage des ITC-Teilnehmers
REVNT	empfängt eine Nachricht für den ITC-Namen des Teilnehmers
SEVNT	sendet eine Nachricht an einen ITC-Teilnehmer

Verfahren der Intertaskkommunikation ITC

Die Intertaskkommunikation (ITC) ermöglicht den Nachrichtenaustausch zwischen Programmen, die in voneinander verschiedenen Tasks ausgeführt werden. Jeder ITC-Teilnehmer muss sich durch einen Namen gegenüber der ITC ausweisen. ITC-Teilnehmer sind aus der Sicht des Betriebssystems die Tasks, die mit einem ITC-Namen in der Kommunikationstabelle geführt werden; aus der Sicht des Anwenders sind es die (Anwender-)Programme, die in diesen Tasks ausgeführt werden und OPCOM aufgerufen haben. Durch die Teilnahme an der Intertaskkommunikation können alle Tasks im System untereinander Nachrichten austauschen und - wenn nötig - auf deren Eintreffen warten, sofern sie gegenseitig ihre ITC-spezifischen Namen kennen. Jeder ITC-Teilnehmer kann Sender und Empfänger von Nachrichten sein. Ein Teilnehmer (Programm) kann an einen anderen Teilnehmer eine Nachricht senden, aber erfährt nicht automatisch, ob der Empfänger die Nachricht auswertet. Der Empfänger kann zu diesem Zweck seinerseits eine Nachricht zurücksenden.

Ein Teilnehmer kann nicht nur Nachrichten senden, sondern er kann auch Nachrichten anfordern, die andere Teilnehmer an ihn gesendet haben oder senden werden. Liegt die Nachricht zum Zeitpunkt der Anforderung noch nicht vor, dann kann der Programmlauf für eine gewählte Zeitspanne angehalten werden. Sobald die Nachricht eintrifft oder spätestens nach Ablauf der Wartezeit setzt ihn das System fort und übergibt die Nachricht. Der Empfänger kann den Teilnehmer festlegen, dessen Nachricht seine Wartezeit beenden soll; er kann aber auch einen beliebigen Teilnehmer als Sender zulassen.

Die Intertaskkommunikation wird mit folgenden Makros durchgeführt:

OPCOM: ITC-Teilnahme erklären
SEVNT: Nachricht senden
REVNT: Nachricht anfordern
RELBF: Empfangswarteschlange löschen
CLCOM: ITC-Teilnahme beenden

Teilnahme an der ITC erklären und beenden

Soll ein Programm an der Intertaskkommunikation teilnehmen, so muss der Makro OPCOM aufgerufen und ein ITC-Name übergeben werden. Das System prüft diesen Namen und weist ihn ab, wenn er schon an einen anderen ITC-Teilnehmer vergeben ist. Ist der Name eindeutig und ist genügend Systemspeicher (für ITC-Listen) verfügbar, so nimmt das System die Task unter den ITC-Namen in die Teilnehmerliste auf. Ist die Task der erste Teilnehmer an der ITC, so wird mit dem Aufruf OPCOM zusätzlich die Eröffnung des ITC-Verfahrens ausgelöst (das System richtet eine Kommunikationstabelle ein). OPCOM wird abgewiesen, wenn für die Listen und Tabellen nicht genügend Systemspeicher zur Verfügung steht.

Sobald der OPCOM-Aufruf vom System angenommen ist, kann der Teilnehmer an andere ITC-Teilnehmer, deren ITC-Namen er kennt, Nachrichten senden oder sie von ihnen empfangen, sofern sie seinen ITC-Namen kennen.

Mit dem Makro CLCOM beendet der Anwender seine Teilnahme an der Intertaskkommunikation. Gibt er dabei den Operanden NOKEEP an, dann wird seine Teilnahme vollständig beendet, und er kann weder Nachrichten senden noch welche empfangen. Das System löscht alle evtl. noch vorhandenen Nachrichten in der Empfangswarteschlange und streicht seinen ITC-Namen aus der Teilnehmerliste.

Ruft der Anwender den CLCOM mit dem Operanden KEEP auf, dann wird nur seine Teilnahme als Empfänger beendet. Das System lässt keine Nachrichten an ihn zu, aber er kann seine Empfangswarteschlange noch auswerten und auch selbst Nachrichten absenden. Ist die Empfangswarteschlange jedoch leer, wenn der Aufruf CLCOM KEEP gegeben wird, dann verfährt das System wie bei dem Aufruf CLCOM NOKEEP.

Es wird empfohlen, die ITC-Teilnahme mit der Aufruffolge CLCOM KEEP oder CLCOM NOKEEP zu beenden, um einen Nachrichtenverlust zu vermeiden. Nachrichten, die zwischen den Aufrufen REVNT und CLCOM eintreffen, gehen sonst verloren.

Wird das Programm oder die Task beendet, ohne dass CLCOM aufgerufen wurde, so beendet das System die ITC-Teilnahme mit einem systeminternen Aufruf CLCOM NOKEEP. Dabei können Nachrichten verloren gehen. Um das zu vermeiden, kann man in STXIT-Routinen (siehe "STXIT-Verfahren mit Contingency-Verarbeitung") die Empfangswarteschlange noch auswerten. Dort gibt man den Aufruf CLCOM KEEP, prüft die vorliegenden Nachrichten, sendet evtl. eine entsprechende Quittung zurück und schließt mit CLCOM NOKEEP. Damit kommt man der systeminternen Programmbeendigung zuvor (einschließlich CLCOM NOKEEP).

Die Empfangswarteschlange

Für jeden Teilnehmer an der ITC richtet das System im Systemspeicher eine Empfangswarteschlange ein. Alle Nachrichten an einen Teilnehmer werden in der Reihenfolge ihres Eintreffens in die Empfangswarteschlange eingereiht. Ausgewertet und gelöscht werden die Nachrichten in der Warteschlange von dem Teilnehmer.

Fordert ein Teilnehmer eine Nachricht an (REVNT), so übergibt ihm das System diejenige, die als erste Nachricht eingetroffen ist und die auch als erste Nachricht in der Warteschlange steht (FIFO-Prinzip). Wünscht der Teilnehmer eine Nachricht von einem bestimmten Sender, dann bekommt er die erste Nachricht, die dieser Sender geschickt hat. Solange eine Nachricht als erste Nachricht in der Warteschlange steht, übergibt das System immer nur diese. Will der Teilnehmer eine zweite Nachricht anfordern, so muss er die erste Nachricht vorher löschen. Bereits beim Anfordern einer Nachricht (REVNT) kann festgelegt werden, dass das System sie nach der Übergabe aus der Warteschlange löscht. Das kann - je nach Anforderung - die erste Nachricht in der Warteschlange oder die erste Nachricht eines bestimmten Senders sein. Explizit kann die erste Nachricht eines bestimmten Senders nicht gelöscht werden, sondern nur zusammen mit der Anforderung (REVNT). Die erste Nachricht in der Warteschlange kann jedoch explizit mit dem Makro RELBF gelöscht werden. Die ganze Empfangswarteschlange kann der Teilnehmer dadurch löschen, dass er den Makro RELBF in einer Schleife aufruft und über den Returncode prüft, ob die Empfangswarteschlange schon leer ist.

Sobald die Teilnahme an der ITC beendet wird (CLCOM), nimmt das System keine Nachrichten mehr in die Empfangswarteschlange dieses Teilnehmers auf. Gleichzeitig mit dem Beenden der ITC-Teilnahme kann der Teilnehmer veranlassen, dass das System seine Empfangswarteschlange auflöst. Er kann aber auch die bestehenden Nachrichten noch auswerten und danach die Empfangswarteschlange durch einen weiteren Aufruf CLCOM freigeben.

Senden von Nachrichten

Ein Teilnehmer an der ITC kann an jeden anderen ITC-Teilnehmer beliebig oft eine Nachricht schicken (SEVNT), solange dafür genug Systemspeicher verfügbar ist. Er muss dazu nur den ITC-Namen des Empfängers kennen. Das System meldet es einem Teilnehmer jedoch nicht, wenn eine Nachricht für ihn eintrifft. Der Teilnehmer muss sie aus eigener Initiative anfordern. Nachdem er eine Nachricht angefordert und erhalten hat, ist es sinnvoll, dass er eine Nachricht als Quittung zurückschickt. Diese kann der Sender zu einem für ihn geeigneten Zeitpunkt mit REVNT anfordern (z.B. nachdem alle Nachrichten abgeschickt sind).

Der sendende Teilnehmer hält die Nachricht in einem eigenen Programmbereich bereit. Die Nachricht kann bis zu 64 KByte lang sein. Nach Aufruf des Makros SEVNT prüft das System, ob der ITC-Name des Empfängers syntaktisch richtig ist, der Name in der Teilnehmerliste steht und in der Empfangswarteschlange nicht bereits Nachrichten mit einer Gesamtlänge > 128 KByte stehen. Verläuft die Prüfung positiv, dann überträgt das System die Nachricht in die Empfangswarteschlange des Empfängers. Die Task wird nach dem Aufruf SEVNT ohne Warten fortgesetzt und kann weitere Nachrichten an beliebige Empfänger absenden.

Anfordern und Empfangen von Nachrichten

Jeder ITC-Teilnehmer kann mit dem Makro REVNT eine Nachricht anfordern und wenn sie noch nicht da ist - auf sie warten. Dabei kann er festlegen, ob sie von einem bestimmten Absender kommen soll, oder ob er eine Nachricht von einem beliebigen Teilnehmer annimmt. Wenn die Empfangswarteschlange leer ist oder wenn sie keine Nachricht von dem gewünschten Absender enthält, unterbricht das System die Task, bis die Nachricht eintrifft oder längstens bis die Wartezeit abgelaufen ist (siehe Bild 9). Die Dauer der Wartezeit kann im REVNT-Aufruf von einer Sekunde bis 6 Stunden festlegt werden. Sobald die Task fortgesetzt wird, kann mit dem REVNT-Returncode überprüft werden, ob die Nachricht eingetroffen ist.

Die Anforderung einer Nachricht (Makro REVNT) kann mit der Ereignissteuerung gekoppelt werden. Das Eintreffen der Nachricht stellt für die Ereignissteuerung ein ITC-Ereignis dar (siehe folgenden Abschnitt).

Das System überträgt die Nachricht aus der Empfangswarteschlange in einen Programmbereich des Teilnehmers, zusammen mit dem ITC-Namen des Absenders und der Länge. Ist das Empfangsfeld nicht groß genug, um die vollständige Nachricht aufzunehmen, so überträgt das System nur ihren Kopf, der aus Absender, Länge der vollständigen Nachricht und den ersten 4 Byte der Nachricht besteht.

Fordert ein Teilnehmer mit REVNT eine Nachricht an, so kann er festlegen, dass das System sie nach der Übertragung aus der Empfangswarteschlange löschen soll (Operand REL=YES). Er kann die Nachricht auch bestehen lassen (REL=NO), um sie evtl. noch einmal anzufordern. Solange die erste Nachricht in der Warteschlange nicht gelöscht ist, wird immer diese übertragen. Um die folgende Nachricht übertragen zu lassen, muss der Teilnehmer die erste Nachricht löschen (implizit bei REVNT oder explizit mit RELBF).

Empfängt ein Teilnehmer Nachrichten verschiedener Länge, so ist es unter Umständen nicht sinnvoll, ein Empfangsfeld in voller Länge (64K + 7 für Sendername und Nachricht) bereitzuhalten. Es wird nur der Kopf der Nachricht übergeben (Sendername, Satzlängenfeld und 4 Byte Information), wenn REVNT mit der Länge 16 (und REL=NO) aufgerufen wird. Der Teilnehmer kann dann entscheiden, ob er die Nachricht notfalls löscht, oder er kann Speicherplatz anfordern (REQM), um sein Empfangsfeld zu vergrößern. Anschließend kann er die Nachricht wieder anfordern, diesmal in voller Länge.

Bild 9: Intertaskkommunikation ITC: Programm, das eine Nachricht anfordert

Koppelung von ITC und Ereignissteuerung

In diesem Abschnitt wird die Kenntnis der Ereignissteuerung vorausgesetzt. Sie ist auf "Ereignisgesteuerte Verarbeitung (Eventing)" und "Contingency-Prozesse" des vorliegenden Handbuchs beschrieben.

Ereignisklassen:

Das Verfahren der Ereignissteuerung gibt dem Anwender die Möglichkeit, den Ablauf seines Programms unterbrechen zu lassen, bis eines von mehreren verschiedenen Ereignissen eintritt (siehe "Ereignisgesteuerte Verarbeitung (Eventing)"). Die Ereignisse, die die Ereignissteuerung beeinflussen können, sind nach ihrer Herkunft in Klassen eingeteilt (siehe Bild 10). Bisher gibt es folgende Ereignisklassen:

Wahlfreie Ereignisse
UPAM-Ereignisse
ITC-Ereignisse
DCAM-Ereignisse
CJC-Ereignisse

In der Klasse der wahlfreien Ereignisse legt der Anwender fest, wann und warum er der Ereignissteuerung ein Ereignis signalisiert (POSSIG, siehe "Ereignisgesteuerte Verarbeitung (Eventing)"). Ereignisse aus allen anderen Klassen (ITC, UPAM usw.) haben zwar ihre Ursache in dem Programmablauf, aber das System (nicht das Programm) signalisiert sie der Ereignissteuerung (systeminterner POSSIG). Außerdem ist festgelegt, was als Ereignis gilt:
Ein UPAM-Ereignis z.B. tritt ein, wenn eine Ein-/Ausgabeoperation abgeschlossen ist.
Als ITC-Ereignis gilt das Eintreffen einer ITC-Nachricht (oder Ablauf der Wartezeit).

Ein Programm, das von der Ereignissteuerung ein Signal anfordert (SOLSIG), kann auch dasjenige sein, in dem das erwartete Ereignis eintritt. Zum Beispiel wird mit einem PAM-Aufruf eine Ein-/Ausgabeoperation eingeleitet und dann ein Ereignis-Signal angefordert (SOLSIG). Die Ereignissteuerung unterbricht daraufhin (synchroner Fall) den Programmlauf und setzt ihn fort, sobald ihr ein systeminterner POSSIG anzeigt, dass die Ein-/Ausgabeoperation abgeschlossen ist.

Ein Teilnehmer kann die Signalanforderung nicht auf eine bestimmte Ereignisklasse beschränken. Das Signal, das er auf seine Anforderung erhält, kann sich auf jedes Ereignis beziehen, das im Geltungsbereich der Ereignissteuerung eintreten kann. Die Ereignissteuerung informiert den Teilnehmer durch den Post Code (siehe "Ereignisgesteuerte Verarbeitung (Eventing)") über die Klasse und die näheren Umstände des Ereignisses.

Der Programmablauf kann also von verschiedenen Ereignissen abhängig gemacht werden. Das ist sinnvoll, wenn mehrere Ereignisse erwartet werden, man aber nicht weiß, welches zuerst eintreten wird (z.B. ITC-Nachricht oder Lesen eines PAM-Blockes beendet).

Bild 10: Ereignisklassen

ITC-Nachricht als Ereignis der ITC-Klasse

Die Verbindung von ITC und Ereignissteuerung bedeutet, dass ein (ITC-)Ereignis auftritt, wenn eine ITC-Nachricht eintrifft oder wenn die Wartezeit abgelaufen ist. Die Koppelung entsteht dadurch, dass im Aufruf REVNT die Kurzkennungsadresse einer Ereigniskennung angegeben wird. Der Programmablauf wird dann durch den REVNT-Aufruf nicht unterbrochen. Der Sender der Nachricht braucht der Ereignissteuerung nicht anzugehören.

Die Koppelung von ITC und Ereignissteuerung gestaltet den Programmablauf flexibler:

• Der Teilnehmer kann das Warten auf eine ITC-Nachricht mit dem Warten auf ein anderes Ereignis kombinieren.

  Beispiel
  Der Teilnehmer gibt einen PAM- (siehe Handbuch „DVS Makros“ [7]) und einen REVNT-Aufruf, beide gekoppelt mit der Ereignissteuerung. Er gibt dann einen SOLSIG-Aufruf und wird unterbrochen. Nach seiner Fortsetzung prüft er den Post Code, ob die Nachricht eingetroffen war oder ob die Ein-/Ausgabeoperation beendet war.

• Der Teilnehmer kann seine Warte-Unterbrechung auf einen späteren Zeitpunkt verschieben: Die Unterbrechung tritt nicht nach dem REVNT-Aufruf, sondern nach dem SOLSIG-Aufruf ein (siehe Bild 11 und Bild 12).

  Beispiel
  Der Teilnehmer fordert mit einem gekoppelten REVNT-Aufruf eine ITC-Nachricht an und setzt seine Verarbeitung fort. Später gibt er einen SOLSIG-Aufruf, um „nachzuschauen“, ob die Nachricht da ist. Ist sie immer noch nicht da, so setzt erst jetzt die Unterbrechung ein.

• Der Teilnehmer braucht gar keine Warte-Unterbrechung in Kauf zu nehmen, wenn er im SOLSIG-Aufruf eine Contingency-Routine angibt (siehe Bild 13). Bei diesem asynchronen Fall der Ereignissteuerung kann der SOLSIG-Aufruf auch vor dem REVNT-Aufruf folgen.

  Beispiel
  In einem Programm ist eine Contingency-Routine definiert, die die ITC-Nachricht auswertet und alle davon abhängigen Aktionen durchführt. Diese Contingency-Routine wird im SOLSIG-Aufruf angegeben. Vor oder nach nach dem SOLSIG-Aufruf wird die Nachricht mit einem REVNT-Aufruf angefordert. Der Programmablauf wird weder durch den REVNT noch durch den SOLSIG unterbrochen (um zu warten), sondern nur durch den Ablauf der Contingency-Routine. Deren Start erfolgt, sobald ein Ereignis eintrifft.

Mit dem SOLSIG-Aufruf kann ein Teilnehmer kein bestimmtes Ereignis anfordern. Die Ereignissteuerung ordnet ihm das erste Ereignis aus ihrem Geltungsbereich zu, das noch nicht durch andere (frühere) SOLSIG-Aufrufe angefordert wurde. Der Teilnehmer muss mit dem Post Code die Ereignisse herausfiltern, die für ihn maßgebend sind.
Der Geltungsbereich kann eine Task, alle Tasks einer Benutzerkennung, alle Tasks einer Benutzergruppe oder alle Tasks im System umfassen. Er wird bei der Eröffnung der Ereigniskennung festgelegt.
Mehrere Ereigniskennungen (mit verschiedenen Geltungsbereichen) können gleichzeitig bestehen, und eine Task kann sich gleichzeitig verschiedenen Ereigniskennungen anschließen (siehe "Ereignisgesteuerte Verarbeitung (Eventing)").

Programmaufbau für gekoppelte Anwendung von ITC und Ereignissteuerung ohne Contingency-Prozess (siehe Bild 11 und Bild 12).

• Sowohl die Teilnahme an der ITC als auch an der Ereignissteuerung müssen erklärt werden (OPCOM und ENAEI). Unter der im ENAEI angegeben Adresse trägt das System die Kurzkennung der Ereignissteuerung ein.
  Ist die Ereignissteuerung schon eröffnet, dann darf sich der Teilnehmer nur anschließen, wenn er dem festgelegten Geltungsbereich angehört. Rufen auch andere Teilnehmer des Geltungsbereiches den Makro SOLSIG auf, dann ist nicht vorauszusehen, welchem Teilnehmer die Ereignissteuerung ein Ereignis zuordnet.

• Eine Nachricht wird mit dem Makro REVNT angefordert. Zusätzlich zu den bekannten Operanden wird mit dem Operanden EIID die Kurzkennungsadresse angegeben, die im ENAEI-Aufruf verwendet worden war.

• Der Programmablauf ist nicht unterbrochen. Das Programm muss den REVNT-Returncode in R15 prüfen, ob der Aufruf akzeptiert ist oder wegen formaler Fehler abgewiesen wurde. Ein abgewiesener REVNT-Aufruf führt zu keinem ITC-Ereignis. Der Returncode für einen gekoppelten REVNT enthält noch keine Angaben über die Nachricht, sondern erst der Post Code.
  Solange ein gekoppelter REVNT-Aufruf nicht abgeschlossen ist (d.h. Nachricht eingetroffen oder Wartezeit abgelaufen), darf kein weiterer REVNT - gekoppelt oder ungekoppelt - aufgerufen werden. Andere Aufrufe, die sich an die Ereignissteuerung koppeln, z.B. ein PAM-Aufruf, sind jedoch erlaubt.

• Das Programm ruft zu einem Zeitpunkt, der für seinen Ablauf sinnvoll ist, den Makro SOLSIG auf und gibt dabei eine Adresse für den Post Code an. Der Programmlauf wird nicht unterbrochen, wenn die Signalanforderung sofort befriedigt wird. Ansonsten wird im synchronen Fall der Programmlauf unterbrochen - längstens bis Ablauf der angegebenen Wartezeit.

• Nach seiner Fortsetzung prüft das Programm zuerst den Returncode des SOLSIG-Aufrufs, ob er keine formalen Fehler anzeigt oder ob die SOLSIG-Wartezeit abgelaufen ist. (Der Ablauf der REVNT-Wartezeit wird im Post Code angegeben.)

• Der Post Code wird geprüft. Das System hat ihn unter der Adresse gespeichert, die im SOLSIG-Aufruf angegeben war (ein Contingency-Prozess erhält ihn in Register R3). Das linksbündige Byte des Post Codes gibt an, zu welcher Klasse das eingetretene Ereignis gehört (ITC-Ereignis: X'08'). Das Programm geht zu dem Verarbeitungsteil über, der für die Ereignisklasse vorgesehen ist.

• Verarbeitung eines ITC-Ereignisses: Das rechtsbündige Byte des Post Codes wird geprüft. Es gibt an, ob die Wartezeit des REVNT abgelaufen war oder ob die Nachricht bzw. nur der Nachrichtenkopf übertragen wurde. Ab jetzt können wieder REVNT-Aufrufe gegeben werden.

  Bei vielen ITC-Anwendungen ist es wahrscheinlich, dass einer Nachricht sofort noch weitere folgen. Dann empfiehlt es sich, die weiteren REVNT-Aufrufe nicht mehr an die Ereignissteuerung zu koppeln. Die nötigen SOLSIG-Aufrufe sind zeitaufwendig, und sie bieten keinen Vorteil, wenn die Nachricht bereits da ist. Stattdessen gibt das Programm solange ungekoppelte REVNT-Aufrufe mit WTIME=0, bis alle anstehenden Nachrichten empfangen sind. Danach ist ein gekoppelter REVNT-Aufruf wieder sinnvoll, um weitere Nachrichten zu erwarten.

• Das Programm beendet die Teilnahme an der ITC und an der Ereignissteuerung mit CLCOM und DISEI (siehe Hinweis).

Hinweis zum Beenden der ereignisgesteuerten ITC

Solange für einen gekoppelten REVNT-Aufruf kein Ereignis signalisiert wurde (d.h. Nachricht da oder Wartezeit abgelaufen), darf der Teilnehmer die zugehörige Ereignissteuerung nicht beenden. Bei asynchroner Ereignissteuerung wird sonst der Contingency-Prozess auf Grund des DISEI-Aufrufs gestartet, im synchronen Fall kann kein Ereignissignal mehr empfangen werden, auch wenn die Nachricht übertragen wurde. Folgende Vorgehensweise wird empfohlen:
Der Teilnehmer muss intern kontrollieren, ob der letzte gekoppelte REVNT abschlossen ist (z.B. mit einem Zähler; bei lokalem Geltungsbereich mit CHKEI). Danach kann er den DISEI-Aufruf geben. Mit dem Aufruf CLCOM KEEP unterbindet er den Empfang weiterer Nachrichten. Diejenigen, die noch in seiner Nachrichtenwarteschlange eingetragen sind, holt er mit ungekoppelten REVNT-Aufrufen ab. Danach kann die Teilnahme an der ITC mit dem Aufruf CLCOM NOKEEP beendet werden.

Hinweis zu Wartezeiten

Sowohl der REVNT-Aufruf als auch der SOLSIG-Aufruf ermöglichen die Angabe einer Wartezeit.
Die REVNT-Wartezeit begrenzt die Lebensdauer der Nachrichtenanforderung. Läuft sie ab, ohne dass eine Nachricht eintraf, so führt das zu einem ITC-Ereignis. Das System gibt intern einen POSSIG-Aufruf an die Ereignissteuerung, die dem Teilnehmer ein ITC-Ereignis signalisiert. Das rechte Byte des Post Codes enthält bei Ablauf der REVNT-Wartezeit den Wert X'10'.
Die SOLSIG-Wartezeit begrenzt die Lebensdauer der Signalanforderung. Läuft sie ab, ohne dass die Ereignissteuerung ein Ereignis signalisiert, so wird das unterbrochene Programm fortgesetzt (synchroner Fall) oder die Contingency-Routine wird gestartet (asynchroner Fall). Der Returncode des SOLSIG-Aufrufs hat bei Ablauf der SOLSIG-Wartezeit den Wert X'20000004'. (Ist die REVNT-Wartezeit abgelaufen, so gilt das als ITC-Ereignis. Der SOLSIG-Returncode ist dann X'00000000').

Bild 11: ITC gekoppelt mit Ereignissteuerung (Synchroner Fall):
Die angeforderte Nachricht trifft nach dem SOLSIG-Aufruf ein

Bild 12: ITC gekoppelt mit Ereigissteuerung (Synchroner Fall):
Die angeforderte Nachricht trifft vor dem SOLSIG-Aufruf ein

Bild 13: ITC gekoppelt mit Ereignissteuerung (Asynchroner Fall):
Ein Contingency-Prozess läuft ab, wenn die Nachricht eintrifft

Beispiel

Programmaufbau für gekoppelte Anwendung von ITC und Ereignissteuerung mit einem Contingency-Prozess (siehe Bild 13)

Programmteil mit ITC-Verarbeitung (Basisprozess):

BEISPIEL START 
         BALR   6,0
         USING  *,6
         :
         :
         ENAEI  EINAME=EVA,EIIDRET=EKENN --------------------------------(1)
         ENACO  CONAME=CONTEVA,COADAD=CONTADR,
                COIDRET=CONTI
         OPCOM  TEILNA
         :
         :
         SOLSIG EIID=EKENN,COID=CONTI,LIFETIM=3600 ----------------------(2)
         C      15, RC00
         BNE    SOLSFEHL
         :
         :
         REVNT  EMPFANG,100,WTIME=600,EIID=EKENN ------------------------(3)
         C      15,RC00
         BNE    REVFEHL
         :
         :
         CLCOM ----------------------------------------------------------(4)
         DISCO  COID=CONTI
         DISEI  EIID=EKENN
         TERM

Contingency-Routine (Contingency-Prozess):

CONTANF  BALR   5,0 -----------------------------------------------------(5)
         USING  *,5
         ST     3,POSTCODE
         :                    Prüfung des Post Codes auf
         :                    verschiedene Ereignisklassen
         CLI    POSTCODE,ITCEREIG
         BE     ITCBEARB
         :                    Bearbeitung von Ereignissen
         :                    anderer Klassen
         :
ITCBEARB :                    Prüfung des Post Codes
         :                    auf Nachrichtenempfang
         :                    Auswertung der Nachricht
         RETCO

Fehlerroutinen:

REVFEHL  (Behandlung der Fehler im REVNT-Aufruf)
         :
         B      ....
         :
SOLSFEHL (Behandlung der Fehler im SOLSIG-Aufruf)
         :
         B      ....
:

Daten:

EKENN    DS     F
CONTADR  DC     A(CONTANF)
CONTI    DS     F
EMPFANG  DS     CL100
RC00     DC     A(0)
POSTCODE DC     A(0)
ITCEREIG EQU    X'08'
         END

(1)	Die Teilnahme an der Ereignissteuerung wird erklärt. Name der Ereigniskennung ist EVA. Die Adresse für die Kurzkennung ist ERKENN. Der Geltungsbereich ist lokal. Eine Contingency-Routine wird definiert. Die Kurzkennung hat die Adresse CONTI. Die Teilnahme an der ITC wird erklärt. ITC-Name ist TEILNA.
(2)	Ein Ereignis-Signal wird mit SOLSIG angefordert. Im Aufruf wird eine Contingency-Routine angegeben. Diese wird gestartet, wenn eine Nachricht eintrifft oder spätestens, wenn die Wartezeit abgelaufen ist. Der SOLSIG-Aufruf kann auch nach dem REVNT-Aufruf erfolgen. Der Basisprozess läuft weiter (sofern die Nachricht nicht schon vorlag und der Contingency-Prozess ihn bereits unterbrochen hat). Der SOLSIG-Returncode wird geprüft. Wenn er ungleich Null ist, hat das System den Aufruf nicht akzeptiert. Die Routine SOLSFEHL prüft die Ursache.
(3)	Eine ITC-Nachricht wird angefordert. Die Angabe EIID=EKENN koppelt diese Anforderung an die Ereignissteuerung EVA. Der Programmablauf wird nicht unterbrochen. Vor oder nach diesem REVNT-Aufruf sind Aufrufe für andere Ereignisklassen möglich (z.B. PAM). Ist der Returncode in R15 ungleich Null, so wurde der Aufruf nicht akzeptiert. Die Routine REVFEHL untersucht die Ursache.
(4)	Der Teilnehmer will die gekoppelte ITC-Verarbeitung beenden. Mit CLCOM beendet er die ITC-Teilnahme, mit DISCO löscht er die Contingency-Definition und mit DISEI beendet er die Ereignissteuerung EVA (zur Vermeidung von Nachrichtenverlust siehe Hinweis vor dem Beispiel).

(5)

Die Contingency-Routine speichert den Post Code ab, der in Register R3 übergeben wird, und wertet dessen linksbündiges Byte aus. Dieses Byte gibt an, zu welcher Klasse das Ereignis gehört, das den Start der Contingency-Routine ausgelöst hat. Im Verarbeitungsteil für die entsprechende Ereignisklasse wird in der Contingency-Routine das rechtsbündige Byte des Post Codes ausgewertet. Es enthält den klassenspezifischen Returncode. Bei ITC-Ereignissen sind es Angaben, ob die Wartezeit abgelaufen ist oder die Nachricht übertragen werden konnte (siehe REVNT). Bei abgelaufener Wartezeit kann z.B. noch einmal ein gekoppelter REVNT aufgerufen werden (Rücksprung zum ersten REVNT-Aufruf ist nicht möglich!). Der Makro RETCO beendet die Contingency-Routine.