A UTM program unit runs in a process between INIT and PEND. Since the process is released at the end of the program unit, a follow-up program unit may run in a different process from the first. This means that the follow-up program unit cannot access the process-specific environment (context), such as resources and program-specific data areas of the first program unit. Usually this is not necessary, since data can either be transferred via an MPUT call issued to the follow-up program or via process-specific storage areas provided by openUTM.
However, openUTM also allows you to retain the process-specific context of a program unit for multiple processing steps. You use a PGWT (program wait) call with the operation modifiers KP, PR, CM and RB. This sets a wait point without terminating the program unit, i.e. the program context is preserved. These variants are used for different purposes.
PGWT KP terminates the processing step and sends the MPUT message. The program unit waits until the next message arrives from the partner. PGWT KP corresponds to the PEND KP call in the previous program unit and the INIT call in the next program unit.
PGWT PR waits for a message to a queue without terminating the processing step. PGWT PR corresponds to a PEND PA/PR call in the previous program unit and an INIT call in the next program unit.
PGWT CM terminates the transaction without terminating the program unit. However, a synchronization point set with PGWT CM is not a restart point. The follow-up transaction can therefore be rolled back with PGWT RB only and not with PEND RS.
The following also applies:
If an MPUT call was executed before the PGWT CM, the MPUT message is sent and the program unit waits until a response is received from the partner. This PGWT CM corresponds to a PEND RE call in the previous program unit and an INIT call in the next program unit.
If no MPUT was executed before the PGWT CM call, the program unit is continued immediately. A PGWT CM without a preceding MPUT call corresponds to a PEND SP call in the previous program unit and an INIT call in the next program unit.
PGWT RB rolls back a transaction.
The functions of two successive program units can therefore be performed by one program unit. The entire functional sequence then runs under one and the same process. The process-specific context is available until the end of the program unit run.
During that period, the program unit occupies a process exclusively. As a result, the UTM application usually requires more resources (processes).
The PGWT call permits the simple integration of program systems which expect a combined SEND/RECEIVE interface into openUTM.
Alongside the PEND PR/PA/SP calls, the PGWT call represents another way of varying the modular processing step structure:
While the PEND PR/PA/SP calls enable you to split one processing step over multiple program units, the PGWT calls make possible multiple processing steps in one program unit.
Since valuable resources are involved with the PWGT calls, these calls should be used only sparingly in an application; it should only be used where the other options of the KDCS interface are inadequate; the frequent use of PGWT calls can have a negative effect on the performance of a UTM application.