Makro | Kurzbeschreibung |
CHKEI | prüft die Warteschlangenbelegung für eine Ereigniskennung |
DELFEI | löscht einen SOLSIG-/POSSIG-Eintrag in der EVENTLST. |
DISEI | beendet die Teilnahme an der Ereignissteuerung. Die angegebene Ereigniskennung |
DPOFEI | erzeugt einen POSSIG-Eintrag in der EVENTLST. |
DSOFEI | erzeugt einen SOLSIG-Eintrag in der EVENTLST. |
ENAEI | ermöglicht die Teilnahme an der Ereignissteuerung. Die Task wird der angegebenen |
POSSIG | sendet ein Signal an die Ereignissteuerung |
RPOFEI | sendet ein Signal (Ereignis) an die Ereignissteuerung. |
RSOFEI | fordert von der Ereignissteuerung das Eintreffen eines Signals an. |
SOLSIG | fordert von der Ereignissteuerung das Eintreffen eines Signals an |
Allgemeines
Die Ereignissteuerung (Eventing) ermöglicht die Koordinierung der Abläufe von zwei oder mehreren (Anwender-)Programmen in voneinander verschiedenen Tasks. Zum Beispiel soll ein Programm B erst dann Datensätze aus einer Datei lesen, wenn das Programm A die Datei aktualisiert hat, oder Programm A soll erst dann einen Datensatz in einen gemeinsam benutzten Speicherbereich schreiben, wenn Programm B den vorhergehenden Satz gelesen hat. Die Koordinierung der Programme erfolgt durch Nutzung (Steuerung) einer gemeinsamen Ereignisvariablen und daraus abgeleiteten Aktionen des Betriebssystems (Task in den Wartezustand setzen, Wartezustand beenden oder Contingency-Prozess starten). Die Ereignisvariable wird über die Ereigniskennung angesprochen. Die Gesamtheit - Ereigniskennung und daraus abgeleitete Aktionen - wird als Ereignissteuerung bezeichnet. Nach außen wird die Ereignissteuerung durch die Ereigniskennung repräsentiert.
Teilnehmer an einer Ereignissteuerung sind aus der Sicht des Betriebssystems die Tasks, die sich einer gemeinsamen Ereignisvariablen (Ereigniskennung) zuordnen; aus der Sicht des Anwenders sind es die (Anwender-)Programme, die in diesen Tasks ausgeführt werden.
Grundfunktionen der Ereignissteuerung (Eventing)
Teilnahme an der Ereignissteuerung erklärenProgramme, deren Abläufe koordiniert werden sollen, müssen die Teilnahme an der Ereignissteuerung erklären und den Namen (und Geltungsbereich) der gemeinsamen Ereignisvariablen (Ereigniskennung) angeben. Die Vereinbarungen über die Teilnahme an der Ereignissteuerung und die Bezeichnung der Ereigniskennung gelten nur für das gerade ausgeführte Programm.Für jede Ereigniskennung werden zwei Warteschlangen (POSSIG-/SOLSIG-Warteschlange) eingerichtet. Einer Task können gleichzeitig maximal 2000 Ereigniskennungen zugeordnet sein.
Signal sendenEin Programm, das den Abschluss einer bestimmten Verarbeitung melden will, sendet ein POSSIG-Signal an die Ereignissteuerung. Das Signal wird in die POSSIG-Warteschlange eingereiht (Einreihungsprinzip = FIFO).
Signal anfordernEin Programm, das Kenntnis über den Abschluss einer bestimmten Verarbeitung in einem anderen Programm benötigt, sendet eine SOLSIG-Anforderung an die Ereignissteuerung. Die Forderung wird in die SOLSIG-Warteschlange eingereiht (Einreihungsprinzip = FIFO/LIFO, je nach Angabe).
Warteschlange abarbeiten (siehe Bild 14)Jeweils das erste POSSIG-Signal in der POSSIG-Warteschlange und die erste SOL-SIG-Anforderung in der SOLSIG-Warteschlange werden einander zugeordnet - unabhängig davon, aus welchen Tasks sie stammen. Kann die SOLSIG-Anforderung nicht befriedigt werden (d.h. die POSSIG-Warteschlange ist leer) sind zwei Abläufe möglich:
synchroner Ablauf (siehe Bild 15 und Bild 16)Die Task mit der SOLSIG-Anforderung wird in den Wartezustand versetzt, bis ein POSSIG-Signal bei der Ereignissteuerung eintrifft oder bis eine spezifizierte Wartezeit abgelaufen ist. (Der Programmlauf wird mit dem POSSIG-Signal synchronisiert).
asynchroner Ablauf (siehe Bild 17)Die Task mit der SOLSIG-Anforderung wird nicht in den Wartezustand versetzt. Kann die SOLSIG-Anforderung im weiteren Programmablauf befriedigt werden oder ist eine für die Befriedigung angegebene Wartezeit abgelaufen, wird eine im Programm spezifizierte Contingency-Routine gestartet.
Kann die SOLSIG-Anforderung unmittelbar befriedigt werden (die POSSIG-Warteschlange ist nicht leer), wird entweder der Programmlauf mit dem den Makro SOLSIG folgenden Befehl fortgesetzt oder eine im SOLSIG-Aufruf spezifizierte Contingency-Routine gestartet.
Jeder Teilnehmer kann den Zustand der Warteschlangen prüfen. Er erhält Auskunft, ob POSSIG-Signale in der POSSIG-Warteschlange und ob SOLSIG-Signale in der SOL-SIG-Warteschlange stehen.
Teilnahme an der Ereignissteuerung beendenDie Teilnahme an der Ereignissteuerung kann zu jedem beliebigen Zeitpunkt beendet werden. Der Teilnehmer wird aus der Liste der teilnehmenden Tasks gelöscht. Noch anstehende SOLSIG-Anforderungen in der SOLSIG-Warteschlange werden gelöscht. Nicht zugeordnete POSSIG-Signale verbleiben in der POSSIG-Warteschlange.Implizit endet die Teilnahme immer mit Programmbeendigung (nicht Taskende!).Die Ereigniskennung und alle internen Verarbeitungslisten werden gelöscht, wenn der letzte (einzige) Teilnehmer die Teilnahme beendet.
Post Code (siehe Bild 18)Die Ereignissteuerung registriert nur das Eintreffen eines POSSIG-Signals. Es wird keine Information über das mit dem Signal verknüpfte Ereignis (Datei geschlossen, Datensatz geschrieben, ...) mitgeteilt. Da immer die ersten Elemente in den beiden Warteschlangen einander zugeordnet werden, ist eine Adressierung des Empfängers oder Senders nicht möglich. Der Sender des POSSIG-Signals hat aber die Möglichkeit, zusammen mit dem Signal eine Kurznachricht (Post Code) an die Ereignissteuerung zu senden. Diese Nachricht wird der Task übergeben, deren SOLSIG-Anforderung durch dieses POSSIG-Signal befriedigt wird. Der Empfänger der Nachricht kann so entscheiden, ob das POSSIG-Signal mit seinem Programmablauf in Verbindung steht oder nicht.
Der Post Code ist 4 oder 8 Byte lang (bei Verwendung der 24-Bit-Schnittstelle nur 4 Byte). Die folgende Tabelle gibt eine Übersicht über wichtige Anwendungen für verschiedene Ereignisklassen:
Anwendung/ | Post Code | Bemerkung |
(POSSIG) | X'aa....aa' | aa....aa: vom Anwender anzugebender String; (4 oder 8 Byte) |
ITC | X'08000000' | REVNT-Ereignis abgeschlossen. |
X'08000004' | Operandenfehler | |
X'0800000C' | Empfangsfeld zu klein | |
X'08000010' | Timeout | |
DCAM | X'0Caa...a' | aa...a: vom Anwender anzugebende Zeichenfolge; (3 oder 7 Byte) |
UPAM | X'1000i..a' | 31-Bit-Adressierungsmodus |
X'10aaaaaa' | 24-Bit-Adressierungsmodus. | |
CJC | X'1400iiii' | Bedingung erfüllt |
X'1404iiii' | Jobvariable gelöscht | |
X'1408iiii' | Katalog exportiert |
Tabelle 7: Anwendungen/Ereignisklassen und deren Post Codes
Der Makro ETCNAM (ohne Operanden) generiert symbolische Namen für die einzelnen Ereignisklassen:
ETCNAM 1 *,MACRO: ETCNAM, VERSION: VER040 1 * 1 * EVENT TYPE CODES WHICH MAY BE 1 * OUTPUT FROM THE SYSTEM TO THE USER 1 * 1 ETCTCS EQU X'04' TCS-EVENT 1 ETCITC EQU X'08' ITC-EVENT 1 ETCDCM EQU X'0C' DCAM-EVENT 1 ETCUPM EQU X'10' UPAM-EVENT 1 ETCCJC EQU X'14' CONDITIONAL JOB CONTROL-EVENT
Bild 14: Ereignisgesteuerte Verarbeitung: Synchroner Fall: Das Ereignis wird vor Ablauf der Wartezeit signalisiert.
Bild 15: Warteschlangen einer Ereigniskennung
Bild 16: Ereignisgesteuerte Verarbeitung: Synchroner Fall: Das Ereignis wird nach Ablauf der Wartezeit signalisiert
Bild 17: Ereignisgesteuerte Verarbeitung: Asynchroner Fall: Das Ereignis wird vor Ablauf der Wartezeit signalisiert
Bild 18: Informationsübergabe (Ereignissteuerung)
Die aufgeführten Grundfunktionen lassen sich mit zwei Gruppen von Makros realisieren. Die Makrogruppe User Eventing ermöglicht die umfassende Ausnutzung der Grundfunktionen. Die Makrogruppe Forward Eventing (FEV) ergänzt User Eventing um eine im Ablauf optimierte Variante. Forward Eventing ist nur für den synchronen Fall anwendbar. Die Makros von User Eventing und Forward Eventing können nebeneinander verwendet werden.
User Eventing
User Eventing wird mit folgenden Makros realisiert:
ENAEI: Teilnahme an der Ereignissteuerung erklärenPOSSIG: POSSIG-Signal senden
SOLSIG: SOLSIG-Anforderung melden
CHKEI: Warteschlange prüfen
DISEI: Teilnahme an der Ereignissteuerung beenden
Die Teilnahme an der Ereignissteuerung wird durch Aufruf des Makros ENAEI erklärt. Im Makroaufruf muss ein Name für die Ereigniskennung und der Geltungsbereich (Teilnehmerkreis an der Ereignissteuerung) angegeben werden. Der Name ist nur im angegebenen Geltungsbereich gültig. Aus den beiden Angaben wird intern eine Kurzbezeichnung für die Ereigniskennung gebildet. Die Kurzbezeichnung wird dem Aufrufer übergeben und kann in weiteren Makroaufrufen zur Ereignissteuerung verwendet werden (beschleunigt die Makroausführung). Jeder Teilnehmer an einer Ereignissteuerung erhält eine eigene Kurzbezeichnung. Beendet ein Anwender die Teilnahme an einer Ereignissteuerung und erklärt sie in demselben Programmlauf etwas später von neuem, wird ihm nicht notwendig dieselbe Kurzbezeichnung übergeben. Der erste Teilnehmer bewirkt das Einrichten der Ereigniskennung und der intern benötigten Verarbeitungslisten; die weiteren Teilnehmer werden der Ereigniskennung zugeordnet.Der Geltungsbereich kann eine Task, alle Tasks einer Benutzerkennung oder alle Tasks im System umfassen (derselbe Name mit einem anderen Geltungsbereich bezeichnet auch eine andere Ereignissteuerung).
Mit dem Makro POSSIG wird ein Signal an die Ereignissteuerung gesendet. Die Task wird durch das Senden des POSSIG-Signals nicht unterbrochen. Im Makroaufruf kann eine Contingency-Routine spezifiziert werden, die dann gestartet wird, wenn das POS-SIG-Signal einer SOLSIG-Anforderung zugeordnet werden konnte oder wenn eine spezifizierte Wartezeit für das Zuordnen des POSSIG-Signals abgelaufen ist (SOLSIG-Warteschlange ist leer). Nach Ablauf der Wartezeit wird das POSSIG-Signal aus der Warteschlange gelöscht.Der Contingency-Routine wird bei ihrem Ablauf in Register R2 ein Ereignis-Informationscode übergeben (siehe "Contingency-Prozesse"). Der Ereignis-Informationscode informiert, ob das erwartete Ereignis (POSSIG-Signal wurde zugeordnet) eingetreten ist oder nicht; er stellt somit eine Art Quittung für das POSSIG-Signal dar.
Im POSSIG-Aufruf kann außerdem eine Contingency-Mitteilung spezifiziert werden, die der Contingency-Routine nach dem Start in Register R1 übergeben wird.
Mehrere aufeinander folgende POSSIG-Aufrufe können verkettet werden. Die Kette kann auch mit dem Makro SOLSIG abschließen.
Mit dem Makro
SOLSIG wird eine SOLSIG-Anforderung an die Ereignissteuerung gesendet. Die Task wird im synchronen Fall solange in den Wartezustand versetzt, bis innerhalb einer angegebenen Wartezeit der SOLSIG-Anforderung ein POSSIG-Signal zugeordnet werden konnte. Es kann auch vereinbart werden, dass die Task nicht auf das Eintreffen des POSSIG-Signals warten soll.Im asynchronen Fall wird die Task nicht in den Wartezustand versetzt. Eine im Makroaufruf spezifizierte Contingency-Routine wird gestartet, wenn
innerhalb einer angegebenen Wartezeit der SOLSIG-Anforderung ein POSSIG-Signal zugeordnet werden konnte, oder
die Wartezeit abgelaufen ist.
Für Fall 1. kann vereinbart werden, dass sofort eine neue SOLSIG-Anforderung gesendet wird.
An die Contingency werden folgende Informationen übergeben:
Register R1 der Contingency enthält die im SOLSIG-Aufruf angegebene Contin-gency-Mitteilung.
Register R2 der Contingency enthält den Ereignisinformationscode.
Register R3 (+ Register R4) enthält den Post Code des POSSIG.
Sowohl im synchronen als auch im asynchronen Fall wird nach Ablauf der Wartezeit die SOLSIG-Anforderung aus der SOLSIG-Warteschlange gelöscht.
Mit dem Makro CHKEI kann die Belegung der Warteschlangen geprüft werden. Dem Teilnehmer wird die Belegung über den Returncode mitgeteilt.
Der Makro DISEI beendet die Teilnahme an der Ereignissteuerung. Noch in den Warteschlangen anstehende SOLSIG-Anforderungen werden gelöscht, ebenso die zugeordneten Forward-Events (siehe unten). Nicht zugeordnete POSSIG-Signale verbleiben in der POSSIG-Warteschlange. Die Ereigniskennung wird gelöscht, wenn der letzte (einzige) Teilnehmer die Teilnahme beendet.
Forward Eventing
Forward Eventing ergänzt User Eventing mit folgenden Makros:
DPOFEI: POSSIG-Eintrag in der EVENTLST erzeugen
DSOFEI: SOLSIG-Eintrag in der EVENTLST erzeugen
RPOFEI: POSSIG-Signal senden
RSOFEI: SOLSIG-Anforderung melden
DELFEI: POSSIG-/SOLSIG-Eintrag in der EVENTLST löschen
Forward Eventing (FEV) ist eine optimierte Form der synchronen Ereignissteuerung. FEV vermeidet für wiederholte POSSIG- bzw. SOLSIG-Aufrufe an eine bestimmte Ereigniskennung die wiederholte Validation der angegebenen Operanden. Stattdessen wird eine Ereignisliste EVENTLST angelegt und z.B. für SOLSIG-Anforderungen ein SOLSIG-Eintrag eingetragen. Im weiteren Programmfortschritt wird bei der (realen) SOLSIG-Anforderung nur noch auf diesen Eintrag Bezug genommen. Der Eintrag kann explizit wieder gelöscht werden. Gleiches gilt auch für das Senden von POSSIG-Signalen.
Pro Teilnehmer können maximal 2047 Einträge in der EVENTLST erzeugt werden.
Die Teilnahme an der Ereignissteuerung muss mit dem Makro ENAEI erklärt und mit DISEI beendet werden. Mit dem Makro CHKEI kann die POSSIG- bzw. die SOLSIG-Warteschlange überprüft werden. Aus der Sicht der Ereignissteuerung besteht kein Unterschied, ob z.B. ein POSSIG-Signal mit POSSIG oder RPOFEI gesendet wird.
Gleiches gilt für das Senden einer SOLSIG-Anforderung. Forward Eventing ist nur für den synchronen Fall anwendbar. Ein Post Code kann angegeben werden.
Der Makro DPOFEI erzeugt einen POSSIG-Eintrag in der EVENTLST. Dem Aufrufer wird eine Referenznummer für den Eintrag zurückgegeben. Analog dem Makro POS-SIG können mehrere aufeinander folgende Aufrufe DPOFEI miteinander verkettet werden. Die Angaben im Makroaufruf werden in den EVENTLST-Eintrag übernommen. Ein Post Code kann angegeben werden. Eine Contingency-Routine (Makro POSSIG) kann nicht spezifiziert werden.
Der Makro DSOFEI erzeugt einen SOLSIG-Eintrag in der EVENTLST. Dem Aufrufer wird eine Referenznummer für den Eintrag zurückgegeben. Die Angaben im Makroaufruf werden in den EVENTLST-Eintrag übernommen. Es kann nur der synchrone Fall spezifiziert werden.
Mit dem Makro RPOFEI wird unter Bezugnahme auf den POSSIG-Eintrag in der EVENTLST ein POSSIG-Signal an die Ereignissteuerung gesendet.
Mit dem Makro RSOFEI wird unter Bezugnahme auf den SOLSIG-Eintrag in der EVENTLST eine SOLSIG-Anforderung an die Ereignissteuerung gemeldet.
Mit dem Makro DELFEI kann ein POSSIG- oder SOLSIG-Eintrag in der EVENTLST wieder gelöscht werden.
Beispiel: Synchroner Fall
Die Programme EV1 und EV2 werden in voneinander verschiedenen Dialogaufträgen (an verschiedenen Datensichtstationen) gestartet. EV2 liest aus einer Datei, die EV1 kopieren will. Das Schließen der Datei signalisiert EV2 an EV1; EV1 kopiert daraufhin die Datei.Beide Programme sollen im 31-Bit-Adressierungsmodus ablaufen; EV1 unterhalb und EV2 oberhalb der 16-MByte-Grenze.
Programm EV1
EV1 START
EV1 AMODE ANY
EV1 RMODE ANY
GPARMOD 31
PRINT NOGEN
BALR 3,0
USING *,3
ENAEI EINAME=EVE,SCOPE=GROUP,EIIDRET=ABRID1 --------------------(1)
GDATE TOD=TIME1
WROUT MESS1,ERROR
SOLSIG EIID=ABRID1,COND=UNCOND,RPOSTAD=PCEMPF,RPOSTL=2, -
LIFETIM=800 ----------------------------------------------(2)
M1 GDATE TOD=TIME2
WROUT MESS2,ERROR ----------------------------------------------(3)
CMD 'COPY-FILE','TEST.FILE.1,TEST.FILE.2'
WROUT TEXT,ERROR
DISEI EIID=ABRID1 ----------------------------------------------(4)
TERM
ERROR TERM DUMP=Y
*** DEFINITIONS ***
ABRID1 DS F
MESS1 DC Y(MESS1END-MESS1)
DS CL2
DC X'01'
DC C'PROGRAM WAITING SINCE '
TIME1 DS CL8
MESS1END EQU *
MESS2 DC Y(MESS2END-MESS2)
DS CL2
DC X'01'
DC C'POSSIG SIGNAL RECEIVED AT '
TIME2 DS CL8
DC C'; POSTCODE = '
PCEMPF DS CL8
MESS2END EQU *
TEXT DC Y(TEXTEND-TEXT)
DS CL2
DC X'01'
DC C'COPY-FILE COMMAND EXECUTED'
TEXTEND EQU *
END
(1) | Die Ereignissteuerung EVE wird eröffnet. |
(2) | EV1 sendet ein SOLSIG-Signal an EVE und stellt ein Empfangsfeld für einen Post Code (2 Worte) zur Verfügung. Anschließend wartet EV1 auf das Eintreffen eines POSSIG-Signals (höchstens 800 Sekunden). |
(3) | Nach Eintreffen des POSSIG-Signals (bzw. nach Ende der Wartezeit) wird EV1 fortgesetzt und gibt eine Meldung aus. EV2 hat die Datei TEST.FILE.1 geschlossen; EV1 kann die Datei kopieren. |
(4) | EV1 beendet die Teilnahme an der Ereignissteuerung EVE. |
Programm EV2
EV2 START
EV2 AMODE ANY
EV2 RMODE ANY
GPARMOD 31
PRINT NOGEN
BALR 3,0
USING *,3
ENAEI EINAME=EVE,SCOPE=GROUP,EIIDRET=ABRID2 --------------------(5)
OPEN TESTFCB,INPUT --------------------------------------------(6)
GET TESTFCB,INAREA
CLOSE CLOSE ALL
GDATE TOD=TIME1
POSSIG EIID=ABRID2,SPOSTAD=PCSEND,SPOSTL=2 ---------------------(7)
WROUT MESS1,ERROR
DISEI EIID=ABRID2 ----------------------------------------------(8)
TERM
ERROR TERM DUMP=Y
*** FILE ***
DS 0F
TESTFCB FCB FCBTYPE=SAM,LINK=FILIN,EXIT=E1
E1 EXLST EOFADDR=CLOSE,COMMON=CLOSE
*** DEFINITIONS ***
ABRID2 DS F
PCSEND DC X'C5E5F26060C5E5F140' FIELD ALIGNED ON WORD BOUNDARY!
MESS1 DC Y(MESS1END-MESS1)
DS CL2
DC X'01'
DC C'POSSIG SIGNAL SENT AT '
TIME1 DS CL8
MESS1END EQU *
INAREA DS CL200
END
(5) | EV2 schließt sich der Ereignissteuerung EVE an. |
(6) | EV2 öffnet die Datei TEST.FILE.1 und liest einen Datensatz ein. Die Datei wird geschlossen. |
(7) | EV2 sendet ein POSSIG-Signal und übergibt einen Post Code (2 Worte). |
(8) | EV2 schließt die Ereignissteuerung EVE. |
Ablaufprotokoll des Dialogauftrags mit dem Programm EV1
/start-assembh % BLS0500 PROGRAM 'ASSEMBH', VERSION '<ver>' OF '<date>' LOADED % ASS6010 <ver> OF BS2000 ASSEMBH READY //compile source=*library-element(macexmp.lib,ev1), - // compiler-action=module-generation(module-format=llm), - // module-library=macexmp.lib, - // listing=parameters(output=*library-element(macexmp.lib,ev1)) % ASS6011 ASSEMBLY TIME: 525 MSEC % ASS6018 0 FLAGS, 0 PRIVILEGED FLAGS, 0 MNOTES % ASS6019 HIGHEST ERROR-WEIGHT: NO ERRORS % ASS6006 LISTING GENERATOR TIME: 86 MSEC //end % ASS6012 END OF ASSEMBH /start-executable-program library=macexmp.lib,element-or-symbol=ev1 -----(1) % BLS0523 ELEMENT 'EV1', VERSION '@' FROM LIBRARY ':2OSG:$QM212.MACEXMP.LIB' IN PROCESS % BLS0524 LLM 'EV1', VERSION ' ' OF '<date> <time>' LOADED PROGRAM WAITING SINCE 13:14:41 ------------------------------------------(2) POSSIG SIGNAL RECEIVED AT 13:20:22; POSTCODE = EV2--EV1 COPY-FILE COMMAND EXECUTED ----------------------------------------------(3)
(1) | EV1 wird geladen und gestartet. |
(2) | EV1 wartet auf das POSSIG-Signal. |
(3) | Das POSSIG-Signal wurde empfangen, EV1 kopiert die Datei. |
Ablaufprotokoll des Dialogauftrags mit dem Programm EV2
/start-assembh % BLS0500 PROGRAM 'ASSEMBH', VERSION '<ver>' OF '<date>' LOADED % ASS6010 <ver> OF BS2000 ASSEMBH READY //compile source=*library-element(macexmp.lib,ev2), - // compiler-action=module-generation(module-format=llm), - // module-library=macexmp.lib, - // listing=parameters(output=*library-element(macexmp.lib,ev2)) % ASS6011 ASSEMBLY TIME: 871 MSEC % ASS6018 0 FLAGS, 0 PRIVILEGED FLAGS, 0 MNOTES % ASS6019 HIGHEST ERROR-WEIGHT: NO ERRORS % ASS6006 LISTING GENERATOR TIME: 86 MSEC //end % ASS6012 END OF ASSEMBH /add-file-link link-name=filin,file-name=test.file.1 /start-executable-program library=macexmp.lib,element-or-symbol=ev2 -----(4) % BLS0523 ELEMENT 'EV2', VERSION '@' FROM LIBRARY ':2OSG:$QM212.MACEXMP.LIB' IN PROCESS % BLS0524 LLM 'EV2', VERSION ' ' OF '<date> <time>' LOADED POSSIG SIGNAL SENT AT 13:20:22 ------------------------------------------(5)
(4) | EV2 wird geladen und gestartet. |
(5) | EV2 sendet das POSSIG-Signal, nachdem es die Datei TEST.FILE.1 geschlossen hat. |
Weitere Beispiele enthalten der Abschnitt „Contingency-Prozesse“ ("Contingency-Prozesse") sowie die Beschreibung der Makros POSSIG ("POSSIG - Ereignis signalisieren") und SOLSIG ("SOLSIG - Signal anfordern").