![[Contents]](FIGURE/CONTENT.GIF)
OpenTP1 Version 7 TP1/Client User's Guide TP1/Client/W, TP1/Client/P
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)
When a CUP requests, a service of the SPP that uses the schedule queue (queue-receiving server), the scheduler daemon of the node that has the requested SPP receives the service request message and stores the message into the schedule queue of the requested SPP. The scheduler daemon is a system daemon that provides schedule services.
When a long service request is sent to the scheduler daemon, the request is divided into parts of a fixed length. The scheduler daemon then assembles the parts into the original request, and stores the assembled message in the schedule queue of the queue-receiving server. In an OpenTP1 system, multiple scheduler daemon processes cannot be executed concurrently. Therefore, while the scheduler daemon is receiving a service request message, the scheduler daemon cannot receive any other service request messages. If a long service request is sent over a slow line, scheduling of other service request messages might be delayed, hindering the streamlining of the scheduling in a large-scale system made up of high-performance machines and networks. To prevent scheduling delays, in addition to the scheduler daemon, you can start multiple daemon processes dedicated to receiving service requests to receive service request messages in parallel. This functionality is called the multi-scheduler facility. Hereafter, the ordinary scheduler daemon is called the master scheduler daemon, and the daemons dedicated to receiving service requests are called multi-scheduler daemons.
For details about system configurations that might require the multi-scheduler facility, see the manual OpenTP1 Version 7 Programming Guide.
The multi-scheduler facility randomly selects one of the active multi-scheduler daemons to send service requests.
A multi-scheduler daemon can be selected at random to execute the following RPCs:
When you specify Y in the DCSCDDIRECT client environment definition to execute an RPC that does not use the name service, the daemon selection method differs depending on whether DCSCDPORT is specified in the client environment definition.
This subsection applies when the multi-scheduler facility is used to execute regular RPCs (RPCs that use the name service). In this case, if the temporary storage area for service information does not contain the desired service information, the system asks the name service for the service information. The system uses the service information to select multi-scheduler daemons at random and sends service requests.
When you use the multi-scheduler facility, the scheduler daemon for sending service requests differs depending on the specification in the client environment definition.
Table 2-2 shows the relationship between the client environment definition and the scheduler daemon.
Table 2-2 Client environment definition and scheduler daemon
| Operand values in the client environment definition | Scheduler daemon for sending service requests | |||
|---|---|---|---|---|
| DCSCDMULTI | DCSCDDIRECT | DCSCDPORT | DCSCDMULTI-COUNT | |
| Y | Y | V | V | Multi-scheduler daemon selected at random#1 |
| -- | Scheduler daemon started with the port number specified in DCSCDPORT | |||
| -- | V | Multi-scheduler daemons randomly selected from the multi-scheduler daemons that are determined based on the port number specified in the -p option defined first in the scdmulti schedule service definition#2 | ||
| -- | ||||
| N | V | V | Multi-scheduler daemon randomly selected based on the service information#2 | |
| -- | ||||
| -- | V | |||
| -- | ||||
| N | Y | V | V | Scheduler daemon started with the port number specified in DCSCDPORT |
| -- | ||||
| -- | V | Master scheduler daemon#2 | ||
| -- | ||||
| N | V | V | Server that receives requests from a socket or master scheduler daemon#2 | |
| -- | ||||
| -- | V | |||
| -- | ||||
All Rights Reserved. Copyright (C) 2006, 2009, Hitachi, Ltd.