When the application active facility (dc_mcf_execap()) is in use, an MCF process separate from the message exchange functions (such as dc_mcf_receive() and dc_mcf_send()) is used. The MCF process used for message exchanging is called an MCF communication process, whereas an MCF process used by the function dc_mcf_execap() is called an application startup process. Application startup processes do not depend on the communication protocol.

Only MHPs and SPPs can be started with the function dc_mcf_execap(). MHPs can be started by calling the function dc_mcf_execap().

(a) Ordinary starting of application programs (starting MHPs)

Segments sent from the function dc_mcf_execap() can be received with the function dc_mcf_receive() called by an MHP. MHPs can be started only if they exist in the same node as the UAP that called the function dc_mcf_execap(). MHPs at other nodes cannot be started using the function dc_mcf_execap().^#

#

There is no restriction when communicating by using TP1/NET/HNA-NIF, because message exchanging is done with the function dc_mcf_execap().

The MHP or SPP which has been designated for activation will actually start when:

• If the MHP has called the function dc_mcf_execap():
  The MHP transaction is committed (the MHP normally returns or the function dc_mcf_commit() normally returns).
  
• If the SPP has called the function dc_mcf_execap():
  The transaction is committed.
  If the SPP has called the function dc_mcf_execap(), the prerequisite condition is that the SPP is working as a transaction and that the main function of the SPP calls the function dc_mcf_open().
  

An MHP or SPP can be started by either of the following methods:

(a) Immediate start

The application program is started immediately after the UAP process which called the function dc_mcf_execap() is committed.

(b) Timer start

The application program is started at the specified time after the function dc_mcf_execap() is called. Timer starts in either of the following two ways:

• Interval timer start
  The application program is started a specified number of seconds after the function dc_mcf_execap() is called. If the UAP process which called the function dc_mcf_execap() is not committed after the specified number of seconds, the application program will be started when commitment occurs.
  
• Time point timer start
  The application program will be started when the specified time comes after the function dc_mcf_execap() is called.
  If the time the function dc_mcf_execap() called is later than the time specified in the function, the application program is immediately started or will be started at the specified time on the following day, depending on the specification given in the UAP common definition included in the MCF manager definition.
  When the application active facility is used, note the following: if the time schedule is changed from Standard to Daylight Saving or vice versa during the period from activation request issuance to the scheduled UAP start time, the UAP will be activated based on the schedule that was in use when the activation request was issued.
  

After the function dc_mcf_execap(), if an error occurs before the MHP or SPP is started, the following MCF events are generated:

• With immediate start: ERREVT2
• With timer start: ERREVT4

For details on the error events, see 3.10 MCF events.

The figure below shows how to start an application program.

Figure 3-13 How to start application program

(a) MCF communication configuration definition

In addition to an ordinary execution process, an application startup process is required for the node at which the UAP that calls the function dc_mcf_execap() exists. Specify the application startup process in the application start environment definition. With OpenTP1 which uses the application program start function, create the application startup environment definition of the MCF communication configuration definitions.

(b) MCF application definition

The application type specified in the type operand of the application attribute definition (mcfaalcap) in the MCF application definitions determines which type of MHP is to be started.

• When starting a response type (ans) MHP:
  Only an MHP with the response type (ans) specified can send response messages. When an ans type MHP is started from the MHP that received an inquiry message, the response right is transferred. Because of this, the ans type MHP can be started only once. Response messages cannot be sent from the MHP that started the ans type MHP. The ans type MHP cannot also be started from an MHP which has sent a response message.
  An ans type MHP cannot be started from an SPP.
  
• When starting a nonresponse type MHP (noans specified):
  An MHP with the nonresponse type (noans) specified can be started more than once from one transaction.
  
• When starting a continuous-inquiry-response type MHP (cont specified):
  An MHP with the continuous-inquiry-response type (cont) specified can be started only from an MHP handling continuous-inquiry-response processing. In this case, only immediate start is permitted (timer start is not permitted). Only one cont type MHP can be started if the function dc_mcf_execap() is called from an MHP handling continuous-inquiry-response processing. The MHP that started a cont type application cannot call the function dc_mcf_reply() because the continuous response right has been transferred from the MHP. Also, the MHP cannot call the function dc_mcf_contend().
  

When an MHP starts another MHP by using the function dc_mcf_execap(), the started MHP receives the name in the first-received message as the logical terminal name of the message input source. Also, when the function dc_mcf_execap() is called from the MHP, the name in the first-message is passed as the logical terminal name of the message input source.

When an SPP starts an MHP by using the function dc_mcf_execap(), the started MHP receives * as the logical terminal name of the message input source. Also, when the function dc_mcf_execap() is called from the MHP, * is received as the logical terminal name of the message input source.

Figures 3-14 to 3-17 show how application programs are started, and specification of the type operand.

Figure 3-14 Starting MHP from MHP that received send-only message

Figure 3-15 Starting MHP from MHP that received inquiry-response message

Figure 3-16 Starting MHP, which sends send-only message, from MHP that handles inquiry-response message processing

Figure 3-17 Starting MHP from SPP handling transaction processing

Explained below is the handling of timer start upon an OpenTP1 rerun subsequent to a fault which occurs during wait for timer start. After an OpenTP1 rerun, timer start can be inherited only when the disk queue is in use. If a rerun occurs, the function dc_mcf_execap() to be timer-started is handled as follows:

(a) Definition of timer start inheritance

If reruntm=yes is specified for the -o option to the mcftpsvr definition command for the MCF communication configuration definition, the timer start message before the rerun is inherited. If the time specified in the function dc_mcf_execap() has already come, the timer start message is inherited as an immediate start message. Otherwise, the application program will be started at the specified time.

If reruntm=no is specified, timer start is not inherited once a rerun occurs. The timer-started function dc_mcf_execap() must be called from the UAP.

(b) User exit routines for modifying conditions for timer start inheritance

Definition of timer start inheritance user exit routines can be used to modify conditions for timer start inheritance. These user exit routines are called exit routines for determining timer start inheritance. Before a user exit routine for determining timer start inheritance can be used, reruntm=yes must be specified for the -o option to the mcftpsvr definition command for the MCF communication configuration definition.

For details on user exit routines for determining timer start inheritance, see 3.9.2 User exit routine that determines the inheriting timer-start message.