OpenTP1 uses schedule queues, which are created for each service group of an SPP, to schedule service requests to an SPP. When a UAP requests a service from an SPP, OpenTP1 catalogs the service request in the proper schedule queue by using the service group name and service name specified in the client UAP's RPC. Scheduling of service requests is possible even if a service group of the SPP specified by the client UAP is located on another node in the network.

Service requests can be assigned scheduling priorities. Service requests with higher scheduling priorities are taken out from the schedule queue first; service requests with the same scheduling priorities are taken out with the FIFO method.

Figure 3-40 illustrates scheduling of service requests for SPPs.

Figure 3-40 Scheduling of service requests for SPP

The programmer can assign a scheduling priority to a service request issued from a client UAP. The scheduling priority for a service request is declared by writing the dc_rpc_set_service_prio() function immediately before the dc_rpc_call() function for the RPC that a client UAP issues. Based on the scheduling priority declared here, the schedule service at the server UAP schedules the service requests.

In the user service definition for the server UAP (the SPP), you can specify whether or not scheduling is to follow the scheduling priorities of the client UAPs.

In the user service definition, you can specify whether scheduling of service requests for an SPP should be blocked when the SPP abnormally terminates while executing a service. In OpenTP1 this is called shutting down scheduling of service requests to an SPP.

Figure 3-41 illustrates shutting down scheduling of service requests to a service group.

Figure 3-41 Shutdown of scheduling of service requests to a service group

(a) Specifiable target when shutting down scheduling

You can specify whether OpenTP1 is to shut down scheduling of service requests to service groups or to services. When an SPP service abnormally terminates:

• if you have specified shutdown of scheduling for service groups, OpenTP1 immediately shuts down scheduling of all requests to the SPP.
• if you have specified shutdown of scheduling for services, OpenTP1 shuts down scheduling of requests to the affected service only but does not shut down scheduling of requests to other services in the same service group.

(b) Processing when an SPP terminates abnormally

If you have specified shutdown of scheduling for service groups and a UAP process in an SPP abnormally terminates, OpenTP1 shuts down scheduling of requests to all services in that service group. After scheduling of requests to a service group is shut down and a request for a service arrives, an error is returned to the client UAP that issued the request. If a service request is already in the schedule queue when scheduling of service requests to a service group is shut down, an error is also returned to the client UAP that issued the request.

When no scheduling shutdown is specified for when a UAP process in an SPP abnormally terminates, scheduling proceeds without shutdown. However, if there are three or more abnormal terminations within the period specified in the user service definition, then scheduling is shut down for the service group of the SPP.

(c) Using a command to release SPP shutdown

You can use the command scdrles to release the scheduling shutdown for an SPP and restart the SPP.

(d) How scheduling-shutdown status is handled at restart

In the user service definition for each SPP, you can specify whether an SPP is to inherit the SPP scheduling-shutdown status when a complete recovery is performed following a stoppage of the online system. Among those SPPs for which scheduling was shut down when online processing stopped, the SPPs for which inheritance of scheduling-shutdown status was specified are restarted with the same scheduling-shutdown status even after a complete recovery. An error is returned to the source of a request for a service of an SPP for which scheduling has been shut down.

For those SPPs for which no inheritance of scheduling-shutdown status is specified, the SPP is restarted with the status at the release of the shutdown, and the requested service is executed.

(e) Using commands to shut down scheduling

You can use the command scdhold to shut down scheduling and use the command scdrles to release scheduling shutdown, thereby enabling SPPs to be modified online.

The command scdhold can shut down scheduling of service requests to service groups or to services. To replace an SPP online, the OpenTP1 administrator should shut down scheduling to service groups of the SPP, replace the SPP with a new SPP, and then use the scdrles command to release the scheduling shutdown and execute the new SPP.

If you specify the -p option with the server name in the scdhold command (scdhold -s server-name -p), even after scheduling for an SPP has been shut down, service requests for the SPP can still be received. The received requests are stored in the schedule queue. When the SPP is again in a condition to process services, OpenTP1 restarts scheduling for the stored service requests.

Storage of service requests is only possible for shutting down scheduling of service requests to service groups. When scheduling of service requests to services is shut down, you cannot use the scdhold command to store service requests.

Figure 3-42 illustrates service requests stored in the schedule queue when scheduling is shut down.

Figure 3-42 Shutting down scheduling and storing service requests in the schedule queue

In order to improve scheduling efficiency, you can specify an SPP that is to receive services without going through the schedule queue. This kind of UAP (a user server) is called a server that receives requests from a socket. Service requests are passed directly to a server (SPP) that receives requests from a socket; the requests are not passed through a schedule queue.

In cases where the server that receives requests from a socket cannot receive service requests, such as when waiting for a transaction synchronous point, OpenTP1 temporarily stores the service requests. When the server that receives requests from a socket can once again receive service requests, OpenTP1 passes the service requests to the server. When the area used for temporary storage is full, errors are returned to the source of the service requests.

In the user service definition, you can specify whether an SPP is to receive requests from a socket.

Compared to a server (SPP) that receives requests from the queue, the following restrictions apply to a server that receives requests from a socket:

• Operation commands cannot be used to shutdown scheduling.
• The Multiserver facility (described in 3.4.3 Process control and the Multiserver facility) cannot be used. In the user service definition, you can specify one resident process only for the number of usable processes.

You can activate more than one server that receive requests from the socket only by changing the user server name (file name of the user service definition). In this case, specify the same service group name, server name, and executable program name.

When more than one server that receive requests from the socket are activated, service requests can be distributed as with a Multiserver facility.

Note that a server that receives requests from the socket and a server that receives requests from the queue cannot be activated concurrently if their service group names are the same. If a server that receives requests from the queue of the same service group has already been activated, terminate it before activating the server that receives requests from the socket.

For details of the Multiserver facility, see 3.4.3(1) Multiserver facility.

By specifying the scdsvcdef definition command in the user service definition or user service default definition, you can specify the following scheduling controls for a specific service requested via the schedule queue for an SPP. For details about the scdsvcdef definition command, see the manual OpenTP1 System Definition.

• Maximum number of server processes that can be executed concurrently for a specific service
• Maximum number of requests for a specific service that can be placed in the schedule queue
• Maximum size of the message-storing buffer pool for a specific service that can be placed in the schedule queue

(a) Maximum number of server processes that can be executed concurrently for a specific service

If the number of server processes that are processing a particular service reaches the maximum number of concurrent executions specified in the scdsvcdef definition command, requests for those services whose set number of concurrently executable processes has not yet been reached are kept scheduled, regardless of their order of placement in the queue and their scheduling priority.

If the queued service requests are all for services whose maximum number of concurrently executable processes has already been reached, the pending requests wait for completion of the service processing currently being executed. Figure 3-43 illustrates the maximum number of server processes that can be executed concurrently.

Figure 3-43 Maximum number of server processes that can be executed concurrently for a specific service

1. Specify the -c and -p options of the scdsvcdef definition command as follows. This sets the maximum number of server processes that can be executed concurrently for services SV1 and SV2 as 1 in each case.
   

   scdsvcdef -c SV1 -p 1
   scdsvcdef -c SV2 -p 1

2. Service requests in excess of the limit placed on the number of concurrently executable server processes are left in the schedule queue.

(b) Maximum number of requests for a specific service that can be placed in the schedule queue

If the number of service requests for a particular service reaches the maximum number of queued requests specified in the scdsvcdef definition command, subsequent requests for that service are re-directed to another OpenTP1 node instead of the local schedule queue.

If the subsequent requests cannot be rescheduled on the other OpenTP1 node, an error is returned to the client UAP, indicating that the message-storing buffer is full. Figure 3-44 illustrates the maximum number of queued requests for a specific service.

Figure 3-44 Maximum number of requests for a specific service that can be placed in the schedule queue

1. Specify the -c and -n options of the scdsvcdef definition command as follows. This sets the maximum number of requests that can be queued as 2 for SV1 and as 1 for SV2.
   

   scdsvcdef -c SV1 -n 2
   scdsvcdef -c SV2 -n 1

2. Service requests in excess of the limit placed on the number of queued requests cannot be scheduled.

(c) Maximum size of the message-storing buffer pool for a specific service that can be placed in the schedule queue

If the length of the message-storing buffer pool containing service requests for a particular service reaches the maximum length specified in the scdsvcdef definition command, subsequent requests for that service are re-directed to another OpenTP1 node instead of the local schedule queue.

If the subsequent requests cannot be rescheduled on the other OpenTP1 node, an error is returned to the client UAP, indicating that the message-storing buffer is full. Figure 3-45 illustrates the maximum size of the queued message-storing buffer pool for a specific service.

Figure 3-45 Maximum size of the message-storing buffer pool for a specific service that can be placed in the schedule queue

1. Specify the -c and -l options of the scdsvcdef definition command as follows. This sets the maximum size of the queued message-storing buffer pool as 2048 for SV1 and as 1024 for SV2.
   

   scdsvcdef -c SV1 -l 2048
   scdsvcdef -c SV2 -l 1024

2. Service requests in excess of the limit placed on the size of the queued message-storing buffer pool cannot be scheduled.