Macro | Brief description |
CONTXT | Reads or writes in the registers of the interrupted contingency process or of the basic |
DISCO | Disables the definition of a routine as a contingency process |
ENACO | Enables a routine as a contingency process and assigns a contingency name and a |
LEVCO | Changes the priority of the calling basic process or contingency process during |
RETCO | Terminates the calling contingency process. The system continues the process with |
SUSPEND | Suspends the calling basic process or contingency process in an interruptible state |
Use of contingency processes
Contingency processes are used in conjunction with eventing and STXIT procedures.
The use of contingency processes in STXIT procedures is a special application and results in certain restrictions with regard to the following description; these are dealt with in “STXIT procedure with contingency processing”, "STXIT procedure with contingency processing".
They consist of user-written routines that are processed by the system as contingency processes.
A contingency process has the following characteristics which distinguish it from a task on the one hand and from a routine on the other:
A contingency process has no task sequence number (TSN) of its own.
Contingency processes can be nested.
A contingency process is not started by the user issuing SET-LOGON-PARAMETERS; it is initiated by the occurrence of a user-defined event.
A contingency process has its own processing level (priority), its own process control block (PCB) and thus its own set of registers.
A contingency process, which by definition is initiated when an event occurs, enables the user to take measures that are specifically related to this event. An example of such an event could be that another process has reached a particular stage during processing, such as the generation of a file or the start of a program.
The measures required to handle several events can be precisely coordinated by the assignment of appropriate priorities.
At its start, the registers of the contingency process contain the value zero, and a base register must be defined and loaded. When selecting the base register, note that registers R1, R2, R3 and possibly R4 are used by the system to transfer information to the contingency process.
Contingency processes can be employed by the user by issuing the following macros:
ENACO: Enable contingency definition
DISCO: Disable contingency definition
RETCO: Return from a contingency process
CONTXT: Access context of a process
LEVCO: Change priority level of a process
Enabling and disabling a contingency definition
A contingency process is defined by means of the ENACO macro, in which name, start address and priority are specified. The addressing mode activated at the time of contingency definition (AMODE) is automatically activated by the operating system at the time the contingency routine is executed.
The ENACO macro can be invoked both in a basic process and in a contingency process. The basic process is always the associated independent process initiated first (with SET-LOGON-PARAMETERS).
As soon as a routine is no longer to be used as a contingency process, the user may disable the contingency definition by means of the DISCO macro, specifying the name of the relevant contingency process. This causes the contingency definition to be deleted.
Any subsequent POSSIG and SOLSIG macros referring to a deleted contingency process are rejected. Any POSSIG or SOLSIG macros whose entries are still in the relevant event item queue when the contingency definition is deleted, are not affected. Consequently, the contingency process will still be activated when the associated event occurs.
Unlike the scope of an event item, the scope of a contingency process is always local; its application is therefore restricted to the defining task. A task can use up to 400 contingency processes simultaneously.
An ID for the name of the contingency process is provided by the system to the defining task at an address. The use of this ID speeds up processing; it is mandatory in the POSSIG and SOLSIG macros. If a contingency process is deleted and subsequently specified again under the same name, the ID may be different from that supplied on the previous occasion.
Start and termination of a contingency process
The user enables the start of a contingency process by specifying its ID as an operand in a POSSIG or SOLSIG macro (see "Contingency processes"). The link with the activating event is thus established.
A contingency process is activated and, subject to its priority, starts its execution under the following conditions:
Asynchronous eventing
A contingency process was specified in the SOLSIG macro to make a solicit signal request and the signal has been received (figure 17 (Eventing)) or the time interval has elapsed.
The contingency process is also started if the basic process has deleted the event item (DISEI).Acknowledgment of a signal
A contingency process was specified in the POSSIG macro to make a post signal request and the signal was solicited (figure 19) or the time interval has elapsed. The contingency process is also started if the basic process has previously deleted the event item (DISEI).
The system starts a contingency process under the following conditions:
No process with a higher priority is activated or started.
No process with equal priority precedes it in the queue.
At its start, the contingency process must first define a base register.
The contingency process is started with the access level valid during the associated SOLSIG or POSSIG call. The contingency routine is started by the operating system with the same addressing mode which was active at the time of contingency definition (ENACO or STXIT). Upon termination of the contingency process, the interrupted task is reassigned the access level it had before the interrupt.
Figure 19: Flow diagram of a contingency process. Here it is used to return an acknowledgment.
The execution of a contingency process is terminated when the process issues the RETCO macro. Depending on priority, control will then be returned to the task (basic process) or to another contingency process.
Contingency process priorities
If several contingency processes have been defined, the use of priority levels, assigned with the contingency definition, and the modification of priority levels during execution provide for coordination facilities when several events occur simultaneously.
Permissible range of priority levels:
Basic process | priority 0-127 | default value: 0 |
Contingency process | priority 1-127 | default value: 1 |
By default, a contingency process has a higher priority level than the basic process. The basic process is interrupted when the contingency process is initiated, and is not continued until the contingency process is terminated. A current contingency process can also be interrupted by another contingency process having a higher priority level (figure 20). If several contingency processes have the same priority level, they are entered in a queue and processed, by default, on the FIFO principle (first in, first out).
Basic processes and contingency processes can change their priority during processing by means of the LEVCO macro. At the same time a choice can be made between the LIFO and FIFO method. A process with a new priority is placed among tasks of the same priority according to the selected queueing method.
FIFO queue processing (first in, first out):
After process activation or after execution of the LEVCO macro, the process is placed at the end of the queue for processes having the same priority level. Any processes preceding it in the queue will be started before it. If a process lowers its priority during processing using the FIFO method, the process may possibly be interrupted by processes having the same priority. This can be prevented by specifying the LIFO method in the LEVCO macro.LIFO queue processing (last in, first out):
After process activation or after execution of the LEVCO macro, the process is placed at the beginning of the queue for processes having the same priority. Thus, only processes with a higher priority level can be executed before this process.
For further details on the interruptibility of contingency processes see the relevant note in the CONTXT macro description.
It is the user's responsibility to assign priorities so as to provide for correct nesting of processes. When the priority level of the basic process is increased special care must be taken to prevent any subsequent contingency processes from being blocked until the basic process terminates. If, in such a situation (the active process has a higher priority than contingency processes already waiting in the queue), the active process is placed in the wait state with the SUSPEND macro, this does not cause the waiting contingency processes to start.
Restrictions
A process is not allowed to lower its priority to a level where it is below the priority level of a process already started (and interrupted). A previously started and interrupted process is only allowed to restart after the interrupting contingency process is terminated.
Access to interrupted processes
Every contingency process has its own set of registers.
A contingency process has access to the registers of the process it has interrupted or to those of the basic process. The CONTXT macro enables the contingency process to read or modify the floating-point registers, the program counter and the general registers of the interrupted contingency process or of the basic process.
Information transfer to contingency processes
A contingency process, when activated, may obtain up to three types of information:
Register R1:
May contain a contingency message (4 bytes). It can be specified in the ENACO macro or - at a later stage, by overwriting - in the POSSIG or SOLSIG macro (figure 18 (Eventing)). Its format and meaning can be defined by the user without any restriction.
Register R2:
Always contains the event information code (2 bytes), which specifies the conditions that caused the contingency process to be initiated. Its form and meaning are predefined (see table 7).
Register R3 (+ R4):
May contain a post code (4 or 8 bytes). If the post code is 8 bytes
(2 words) long, the second word is entered in register R4. The post code can be specified in the POSSIG macro (figure 18 (Eventing)). Its format and meaning can be defined by the user subject to existing conventions (see "Extended addressing with data spaces").
Figure 20: Prioritized execution of contingency processes
The event information code in register R2 consists of the event switch ES in the rightmost byte and the information indicator II in the leftmost byte.
II | ES | Meaning |
X'00' | X'00' | Event has occurred as expected. Neither post code nor contingency message is |
X'04' | X'00' | Event has occurred as expected. Contingency message is available; post code is |
X'08' | X'00' | Event has occurred as expected. Contingency message is not available. Post code |
X'0C' | X'00' | Event has occurred as expected. Both contingency message and post code |
X'28' | X'00' | Event has occurred as expected. Contingency message is not available. Post code |
X'2C' | X'00' | Event has occurred as expected. Both contingency message and post code |
X'00' | X'04' | Event did not occur within the specified period of time. Neither contingency message |
X'04' | X'04' | Event did not occur within the specified period of time. Contingency message is |
X'08' | X'04' | Event did not occur within the specified period of time. Contingency message is not |
X'0C' | X'04' | Event did not occur within the specified period of time. Both contingency message |
X'10' | X'04' | The event item was disabled (DISEI) before the event occurred. Neither contingency |
X'14' | X'04' | The event item was disabled (DISEI) before the event occurred. Contingency |
X'18' | X'04' | The event item was disabled (DISEI) before the event occurred. Contingency |
X'1C' | X'04' | The event item was disabled (DISEI) before the event occurred. Both contingency |
X'28' | X'04' | Event did not occur within the specified period of time. Contingency message is not |
X'2C' | X'04' | Event did not occur within the specified period of time. Both contingency message |
X'38' | X'04' | The event item was disabled (DISEI) before the event occurred. |
Table 7: Event information codes
II | ES | Meaning |
X'3C' | X'04' | The event item was disabled (DISEI) before the event occurred. Both contingency |
Table 7: Event information codes
Example: Asynchronous operation
Part 1:
Interactive job with PCOSOL1 program
The PCOSOL1 program defines two event items (ADAM and EVE) and two contingency processes (CONTA and CONTE). The program solicits a signal from each event item by means of the SOLSIG macro, and specifies a contingency process each time (asynchronous operation). In part 1 of the example, no POSSIG calls are issued to the event items. Contingency process CONTA is started because its waiting time has elapsed (60 seconds). Contingency process CONTE is started because the program deletes event item EVE.
Program 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
Basic process
(1) | Event items ADAM and EVE are defined. The addresses of the IDs are ABBRADAM and ABBREVE. |
(2) | The CONTA routine is defined as contingency process A. The start address (CONTA) is stored at the address CONTAAD; the address of the ID is ABBRA. The same applies to the following definition of the CONTE routine as contingency process E. |
(3) | The program solicits a signal from event item ADAM via a SOLSIG call and specifies contingency process CONTA. If the signal has not arrived within a waiting period of 60 seconds, event item ADAM is to start contingency process CONTA. Program execution is continued after this SOLSIG call. |
(4) | With another SOLSIG call, a signal is solicited from EVE. For contingency process CONTE, the default waiting time (10 minutes) applies. |
(5) | For demonstration purposes, the program is made to wait by issuing the VPASS macro. It is then interrupted by contingency process CONTA, whose waiting period has elapsed. After CONTA has terminated, the program goes on to check the event queues of ADAM and EVE. |
(6) | The program deletes the definitions of contingency processes CONTA and CONTE. At this point, the SOLSIG call to EVE with contingency process CONTE still resides in the event queue of EVE. CONTE can still be started, but another SOLSIG call in which CONTE is specified would be rejected at this point. |
(7) | The program first deletes event item ADAM, and then EVE. As soon as EVE is deleted, the system starts contingency process CONTE. |
Contingency process CONTA
(8) | As a contingency process has its own register set, a base register must be defined and loaded at the start. Registers R1, R2 and R3 are not suitable, since they might be used by the system during eventing (see “Information transfer to contingencyprocesses”). The event information code that was transferred to the contingency process in register 2 is now stored under the address INFOADAM. For demonstration purposes, the registers of the interrupted process (in this case the basic process) are transferred to the LASTREG area by means of the CONTXT macro. The contingency process terminates with the RETCO call. |
Contingency process CONTE
(9) | A base register is defined and loaded. The event information code is stored under INFOEVE, and contingency process CONTE is terminated with RETCO. |
Runtime log of the interactive job with 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) | From each of the two event items the program solicits a signal. |
(11) | The waiting period for contingency process CONTA has elapsed. |
(12) | The status of the POSSIG queue and the SOLSIG queue of each event item is checked. |
(13) | Contingency process CONTE is executed because event item EVE has been disabled by the basic process. |
(14) | Event item ADAM:The event information code X'04' means that the waiting period has elapsed without the event having occurred.The return information X'30' of the CHKEI macro (in the |
(15) | Event item EVE:The event information code X'10000004' means that the event item was disabled before an event occurred. |
The return code X'28' of the CHKEI macro (in the WSERC field) means that the SOLSIG queue is not empty. Field WSEVE: X'01' specifies the number of existing entries, in this case one entry: the SOLSIG entry still exists, because the contingency process CONTE has not yet been started.
Part 2:
Interactive job using the program PCOSOL2
ENTER job ENTER.POSA using the program POSA
ENTER job ENTER.POSE using the program POSE
PCOSOL2 program
The PCOSOL2 program differs from PCOSOL1 only in that it starts two ENTER jobs after issuing the two SOLSIG calls to event items ADAM and EVE. Only that part of the source program PCOSOL2 program which contains the change is listed below; the rest is identical with the PCOSOL1 program.
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
...
POSA program and ENTER file ENTER.POSA
The ENTER job ENTER.POSA starts the POSA program. The POSA program enables event item ADAM and sends a POSSIG call to ADAM. Before deleting the event item, it waits 250 seconds by issuing the VPASS macro in order to prevent the entry from being removed from the event queue before the PCOSOL2 program can call the SOLSIG macro.
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 file 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
POSE program and ENTER file ENTER.POSE
The ENTER job ENTER.POSE starts the POSE program. The program enables event item EVE and issues a POSSIG call to EVE. For the same reason specified for POSA, it waits before issuing the DISEI call.
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 file ENTER.POSE as for ENTER.POSA
Runtime log of the interactive job PCOSOL2 and the two ENTER jobs
/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
In the meantime, the ENTER jobs POSE and POSA output the following messages to their output log:
ENTER.POSE:
ENTER.POSA:
|
|
The interactive job continues as follows
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) | The PCOSOL2 program defines the two event items ADAM and EVE and addresses a SOLSIG call to each of them. Subsequently, it starts ENTER job ENTER.POSE and then ENTER job ENTER.POSA. |
(2) | ENTER job ENTER.POSE starts the program POSE, which enables event item EVE and issues a POSSIG call. |
(3) | ENTER job ENTER.POSA starts the program POSA, which enables event item ADAM and issues a POSSIG call. |
(4) | Contingency processes CONTA and CONTE both have priority 1. The system starts with the contingency process whose corresponding event item is the first to receive a SOLSIG and a POSSIG call. In this case, a SOLSIG call already exists for each event item, and a POSSIG call arrives earlier for the EVE event item than for ADAM. Therefore, contingency process CONTE is started first, followed by contingency process CONTA. |
(5) | On completion of the two contingency processes, the program of the basic process is continued. It checks the queues of both event items: they are empty.(After the CHKEI macro, the fields WSERC and WSARC contain the value X'30000000'.) The event information codes of both contingency processes are zero: the expected event has occurred. |
Part 3:
Interactive job using the PCOSOL3 program
ENTER jobs ENTER.POSA and ENTER.POSE as in part 2
PCOSOL3 program
The PCOSOL3 program differs from PCOSOL1 and PCOSOL2 in that it starts the two ENTER jobs at the beginning, before issuing the two SOLSIG calls. Only that part of the source program PCOSOL3 containing the change is shown here; the rest is identical with the PCOSOL1 program.
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
|
|
ENTER job ENTER.POSA using the POSA program: see part 2
ENTER job ENTER.POSE using the POSE program: see part 2
Runtime log of the interactive job with PCOSOL3 and the two ENTER jobs
/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
In the meantime, the ENTER jobs POSE and POSA output the following messages to their output log:
ENTER.POSE:
|
| |
ENTER.POSA:
|
|
The interactive job continues as follows
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) | The PCOSOL3 program first starts ENTER job ENTER.POSE (TSN 02C1) and then ENTER job ENTER.POSA (TSN 02C2).(Event items ADAM and EVE are, for demonstration purposes, enabled by the program after some time has elapsed; the SOLSIG calls for ADAM and EVE are issued later.) |
(2) | The PCOPOSE program (started in ENTER job ENTER.POSE) defines event item EVE and issues a POSSIG call for EVE. |
(3) | The PCOPOSA program (started in ENTER job ENTER.POSA) defines event item ADAM and issues a POSSIG call for ADAM. |
(4) | As soon as the PCOSOL3 program (in the interactive job) has issued the SOLSIG call for event item ADAM, it is interrupted by the start of contingency process A, since a POSSIG call already exists for ADAM. On completion of A, the program may continue and issue the SOLSIG call for EVE; a POSSIG call also exists here already, and the program is interrupted again until contingency process E is terminated. Only then can it output the message concerning the SOLSIG calls. |
(5) | The program checks the queues of both event items: they are empty. (After the CHKEI macro, the fields WSERC and WSARC contain the value X'30000000'.) The event information codes of both contingency processes are zero: the expected event has occurred. |
For a further example see the POSSIG macro description "POSSIG - Post signal request".