OpenTP1 receives messages from another system through a connection. A connection is a logical channel between OpenTP1 and the other system. As described in 3.3.7 Starting user application programs, a message received by OpenTP1 is managed by an MCF communication process.

After determining the required SPP or MHP, MCF writes the received message to the input queue for the service group that will process the message. The input queue manages the inputs as service requests. In a disk queue, the part allocated to a service group is called a MCF message queue file and the name of the corresponding service group is used as the MCF message queue file name.

In the same way as messages for a disk queue, each service group has a separate queue for messages written to a memory queue.

After MCF writes the last segment of a received message to the input queue, MCF records the service request in the schedule queue for the requested MHP. Following the scheduling and starting of an MHP, the MHP uses the segment-receive function dc_mcf_receive() to receive the received message in segments.

Figure 3-35 gives an overview of how a UAP receives messages. In the diagram, note that TP1/NET/xxx indicates the product required for the protocol being used.

Figure 3-35 Overview of how a UAP receives messages

MCF writes send messages to the output queue according to the logical terminal name written in the send function (dc_mcf_send()) parameter. A logical terminal name is a user-specified name assigned to a terminal entity: such as a window of a multi-window workstation, or a printer. OpenTP1 can define either actual terminals or hardware components as logical terminals that have logical terminal names. In the logical terminal definition, you can specify logical terminal names.

When the messages to be sent use a disk queue, a disk queue is allocated to each logical terminal. Each of the distributed queues is called an MCF message queue file and the name of the corresponding logical terminal is used as the MCF message queue file name.

In the same way as messages for a disk queue, each logical terminal has a separate memory queue for messages to be sent.

The MCF communication process created for the protocol sends the message to the other system in segments.

Figure 3-36 gives an overview of how a UAP sends messages. In the diagram, note that TP1/NET/xxx indicates the product required for the protocol being used.

Figure 3-36 Overview of how a UAP sends messages

(a) Sending a send-only message

The dc_mcf_send function can be used in an MHP or SPP to send a send-only message to another system. Specify the logical terminal name as the send destination.

When an MHP or SPP requests that a send-only message be sent, a message sequential number is attached according to the message type, and the message is sent to the logical terminal. When sending the first segment, OpenTP1 passes control to the user exit routine for editing message sequential numbers. This exit routine can edit and set message numbers anywhere in the first segment.

(b) Sending a response to an inquiry

On receipt of an inquiry message from another system by the dc_mcf_receive function, an MHP can send a response message using the dc_mcf_reply function to the logical terminal that made the inquiry.

(c) Sending an inquiry message

An MHP or SPP can send an inquiry message to another system using the dc_mcf_send function.

(d) Sending a synchronous message

An MHP or SPP can send a synchronous message to another system using the dc_mcf_sendsync function or dc_mcf_sendrecv function.

The dc_mcf_sendsync function stops UAP processing until the message has been sent to the other system, thus synchronizing with UAP processing by the other system.

The dc_mcf_sendrecv function stops UAP processing until a response is received to the message it sent to the other system, thus synchronizing with UAP processing by the other system.

If you use the Application Activate facility, you can simplify and unify the sending of messages by writing a single MHP that edits and sends messages from several logical terminals.

If you write an MHP that edits and sends a response message, you can use that MHP to respond to the requesting logical terminal instead of using the MHP that received the inquiry message. If you write an MHP that edits and sends a send-only message, you can use that MHP to send a message by starting the MHP from another MHP or SPP.

In both the above cases, message sending can be unified by issuing the dc_mcf_execap() function from the UAP that requested message sending.

The dc_mcf_execap() function is an asynchronous communication function. MCF starts an MHP that edits and sends messages immediately after the normal termination of the service of the MHP or SPP that issued the dc_mcf_execap() function, or when a specified time has expired (timer start). Therefore, the MHP or SPP that requested the message sending and the MHP that edits and sends messages are executed in different global transactions. The MHP or SPP that requested message sending uses MCF to pass necessary data (such as the name of the target logical terminal) to the MHP that edits and sends messages. In the case of a timer start, you can use the mcfadltap command or the dc_mcf_adltap function to cancel the start request.

Figure 3-37 explains how to unify the sending of messages. In the diagram, note that TP1/NET/xxx indicates the product required for the protocol being used.

Figure 3-37 Message sending unified by the dc_mcf_execap() function

(a) Monitoring of unprocessed messages

MCF monitors the output queue from the start of termination processing till the last message in the output queue is processed. This monitoring prevents the termination processing from taking too much time because of unprocessed messages left in the output queue. The period for monitoring the output queue during OpenTP1 processing is called the lifetime for unprocessed send messages. If messages remain in the output queue after the lifetime expires, OpenTP1 discards them and the MCF event that reports discarding of an unprocessed send message (ERREVTA) occurs. If there is an MHP for this MCF event, MCF starts that MHP. Response messages, however, are not included in the lifetime for unprocessed send messages. If response messages remain when the system terminates, such response messages are unconditionally deleted and ERREVTA does not occur.

MCF also monitors the period from the time OpenTP1 starts termination processing to the time that all the messages in the input queue are processed. This monitoring prevents the termination processing from not ending in situations where an error in the MHP results in the messages in the input queue not being processed. When the system terminates normally, OpenTP1 discards messages that remain due to the shutdown of a service group, and then ERREVT2 occurs. The period for monitoring the input queue during OpenTP1 termination processing is called the lifetime for unprocessed received messages. If messages remain in the input queue after the lifetime expires, OpenTP1 assumes that the MHP has some abnormality and MCF terminates in an abnormal termination mode.

In the MCF communication configuration definition, you can specify the lifetimes for unprocessed send messages and unprocessed received messages.

(b) OpenTP1 termination modes and unprocessed messages

OpenTP1 has five termination modes:

• normal termination
• forced normal termination
• planned termination A
• planned termination B
• forced termination

When OpenTP1 terminates in the normal termination mode or in the forced normal termination mode, OpenTP1 refuses to accept new messages and continues processing until all the messages in the input and output queues are processed. OpenTP1 also monitors the lifetimes of unprocessed received messages and unprocessed send messages.

When OpenTP1 terminates in the planned termination A mode, OpenTP1 refuses to accept new messages and continues processing until all the messages in the input queue have gone. OpenTP1 terminates even if messages remain in the output queue, but the unprocessed messages are processed the next time OpenTP1 starts. Note that when reruntm=no is specified in the -o option of the mcftpsvr command in the MCF communication configuration definition, messages in a memory output queue and messages for timer start requests cannot be restored. In this mode, OpenTP1 monitors the lifetime for unprocessed received messages only.

When OpenTP1 terminates in the planned termination B mode, OpenTP1 completes the currently executing service, then terminates. Since the messages in the input and output queues are left unprocessed, the lifetime of unprocessed messages is not monitored. The messages left in the input and output queues are processed the next time OpenTP1 starts. Note that when reruntm=no is specified in the -o option of the mcftpsvr command in the MCF communication configuration definition, messages in a memory queue and messages for timer start requests cannot be restored.

When OpenTP1 terminates in the forced termination mode, OpenTP1 terminates without waiting for the end of the currently executing service. The lifetime of the unprocessed messages is not monitored. The messages left in the input and output queues are processed the next time OpenTP1 starts. Note that when reruntm=no is specified in the -o option of the mcftpsvr command in the MCF communication configuration definition, messages in a memory queue and messages for timer start requests cannot be restored.

Table 3-6 summarizes how each termination mode processes the messages in the input and output queues.

Table 3-6 Termination modes and processing of messages in input and output queues

Termination mode	Messages in the input queue	Messages in the output queue
Normal termination	OpenTP1 processes all the messages.	OpenTP1 processes all the messages.
Forced normal termination	OpenTP1 processes all the messages.	OpenTP1 processes all the messages.
Planned termination A	OpenTP1 processes all the messages.	OpenTP1 leaves messages in the queue.
Planned termination B	OpenTP1 leaves messages in the queue.	OpenTP1 leaves messages in the queue.