To use the static connection schedule mode, specify static in the rap_connection_assign_type operand or omit the specification.

The static connection schedule mode allows you to schedule a permanent connection between a RAP-processing client and a RAP-processing server (one to one) by allocating a RAP-processing server when a RAP-processing client requests establishment of a connection. This mode is suitable when the number of RAP-processing clients to be used simultaneously is less than the number of RAP-processing servers to be started (the maximum number of RAP-processing servers is 128 due to an OpenTP1 limit).

When you use the static connection schedule mode, the maximum number of permanent connections that a RAP-processing listener can manage is 256. The maximum number of RAP-processing clients that can be executed with simultaneous permanent connections is the number of RAP-processing servers. Remaining permanent connections cannot be established unless currently executing RAP-processing clients release the permanent connections. Therefore, if the number of RAP-processing clients is greater than the number of RAP-processing servers, perform either of the following:

• Establish permanent connections from RAP-processing clients before you request delegated execution of an API and release the permanent connections from RAP-processing clients after you request delegated execution of an API.
• Start multiple RAP-processing listeners and increase the number of RAP-processing servers that RAP-processing clients establish permanent connections with.

To use the dynamic connection schedule mode, specify dynamic in the rap_connection_assign_type operand.

The dynamic connection schedule mode allows you to dynamically allocate an unused RAP-processing server when a request for delegated execution of an API is issued. This mode does not allocate a RAP-processing server when a RAP-processing client requests establishment of a connection. This mode is suitable when the number of RAP-processing clients to be used simultaneously is greater than the number of RAP-processing servers but you do not want to increase the number of resources required for RAP-processing servers.

When you use the dynamic connection schedule mode, the maximum number of permanent connections that a RAP-processing listener can manage is 1024. You can specify the maximum number of clients that simultaneously connect to a RAP-processing listener in the rap_max_client operand in the RAP-processing listener service definition.

In the dynamic connection schedule mode, a RAP-processing server is allocated only when a request for delegated execution of an API is received from a RAP-processing client and the RAP-processing server is released when the delegated execution of an API is terminated. Therefore, you do not need to establish and release a permanent connection each time you request delegated execution of an API like you do in the static connection schedule mode. Since you do not need to start multiple RAP-processing listeners, you do not need to increase the communication ports for letting packages pass through the firewall. However, note that the response performance might degrade in the dynamic connection schedule mode compared to the static connection schedule mode when the load on the RAP-processing listeners becomes too great.