Structure of a dialog program unit

openUTM requires a "strict dialog" for dialog program units, i.e. each message input must be followed by a message output specifying the result or an error message.

Following INIT, the program unit can use MGET to read the dialog message, which can be received from a terminal, a client program or from another program.

This message can be:

• a complete message or

• a message segment

• an empty message if, for example, only a TAC has been specified

• a rollback message from a program unit which has been terminated using PEND RS

• a return code if, for example, the user pressed a function key. In this case, the message must be read with another MGET.

• in the case of distributed processing, status information from, for example, a job receiver which terminated following an error

• in the case of distributed processing using OSI TP, a handshake request (sent by the partner using MPUT HM) or a negative handshake confirmation (sent using MPUT EM)

After this input has been processed, you have either to continue the processing step in another program unit or to use MPUT to answer your partner’s query (end of dialog step). In the case of distributed processing the message can also be addressed to a job-receiving service (no end of dialog step, only end of processing step).

The final UTM call in your program unit must be a PEND, as described in section "Program framework".

If the PEND call terminates the processing step, openUTM outputs the message to the terminal, the client program or another program after PEND processing.

As a general principle, you have to issue an MPUT call before a PEND call which terminates a processing step. Exceptions to this rule will be indicated explicitly.

The diagram below shows the basic structure of a dialog program unit:

Figure: Structure of a dialog program

The transaction code "TAC1" is input by the terminal user. TAC1 was assigned to the program unit at generation time (KDCDEF statement TAC, operand PROGRAM=current program name).