![[Contents]](FIGURE/CONTENT.GIF)
OpenTP1 Version 7 TP1/Client User's Guide TP1/Client/J
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)
When a service request is issued from a CUP to an SPP that uses a schedule queue (queue-receiving server), the scheduler daemon at the node where the target SPP is located receives the service request message and stores it in the corresponding SPP's schedule queue. A scheduler daemon is a system daemon that provides schedule service.
A large service request message is divided into multiple segments of a specific length and is then sent to the scheduler daemon. The scheduler daemon assembles the service request message and stores it in the queue-receiving server's schedule queue. Because there can be only one scheduler daemon process per OpenTP1 system, the scheduler daemon cannot receive another service request message until it completes reception processing on the current segmented service request message. If a large service request message is sent over a low-speed line, scheduling of other service requests may be delayed. As the system size increases and machine and network performance improve, efficient scheduling may become a problem. If this occurs, you can prevent scheduling delays by starting multiple service request reception-dedicated daemon processes separately from the conventional scheduler daemon, and by performing multiple service request message reception processes concurrently. This is called the multi-scheduler facility. Hereafter, the conventional scheduler daemon is called the master scheduler daemon, and the service request reception-dedicated daemon is called the multi-scheduler daemon.
For details about the system configuration that must be evaluated in order to use the multi-scheduler facility, see the manual OpenTP1 Version 7 Programming Guide.
Using the multi-scheduler facility enables random selection of an available multi-scheduler daemon from the multiple active multi-scheduler daemons that have been provided; a service request can then be sent. You can select a multi-scheduler daemon at random and execute the scheduler direct facility or an RPC using the name service.
This subsection describes execution of RPCs using the scheduler direct facility when y is specified in the dcscddirect operand in the TP1/Client/J environment definition.
TP1/Client/J enables you to randomly select a multi-scheduler daemon without having to send a query to the name service of TP1/Server as a gateway. This reduces the amount of communication and the workload of the name service.
To randomly select a multi-scheduler daemon, specify the following port number in the dchost or dcscdport operand in the TP1/Client/J environment definition:
You must also specify in the dcscdmulticount operand in the TP1/Client/J environment definition the number of multi-scheduler daemon processes that can be started by TP1/Server. The port number of the multi-scheduler daemon that is to send the service request is selected randomly from within the following range of values:
Note that the value specified in scdmulti in the schedule service definition must be the same among all gateway TP1/Servers that are specified in the dchost operand in the TP1/Client/J environment definition.
This subsection describes the issuance of RPCs using the name service and multi-scheduler facility. If there is no corresponding service information in the area where the service information is stored temporarily, the service information is queried to the name service. Based on the obtained service information, a multi-scheduler daemon is selected randomly and then a service request is sent.
When the multi-scheduler facility is used, the scheduler daemon that is used to send a service request depends on the specification of the TP1/Client/J environment definition.
The following table shows the relationship between the operand definitions in the TP1/Client/J environment definition and scheduler daemon for the RPCs that use the scheduler direct facility.
Table 2-1 Relationship between operand definitions in the TP1/Client/J environment definition and scheduler daemon (RPCs using the scheduler direct facility)
| Operand specifications in the TP1/Client/J environment definition | Scheduler daemon that sends service request | ||
|---|---|---|---|
| dcscddirect | dcscdmulti | dcscdmulticount | |
| Y | Y | S | Multi-scheduler daemon that was selected randomly# |
| -- | Scheduler daemon that has been started with the port number specified in the dchost or dcscdport operand in the TP1/Client/J environment definition | ||
| N | Invalid | Scheduler daemon that has been started with the port number specified in the dchost or dcscdport operand in the TP1/Client/J environment definition | |
The following table shows the relationship between operand definitions in the TP1/Client/J environment definition and the scheduler daemon for the RPCs that use the name service.
Table 2-2 Relationship between operand definitions in the TP1/Client/J environment definition and scheduler daemon (RPCs using the name service)
| Operand specifications in the TP1/Client/J environment definition | Scheduler daemon that sends service request | ||
|---|---|---|---|
| dcnamuse | dcscdmulti | dcscdmulticount | |
| Y | Y | Invalid | Multi-scheduler daemon selected randomly on the basis of the service information# |
| N | Master scheduler daemon# | ||
All Rights Reserved. Copyright (C) 2006, 2009, Hitachi, Ltd.