If the service requests from clients start to be delayed in the service processing stage, they may stay too long in the schedule queue because they cannot be fetched. By specifying a schedule delay limit in the schedule_delay_limit operand in the user service definition, you can monitor how long a service request stays in the schedule queue. If the service requests registered in the schedule queue remain in the schedule queue beyond the schedule delay limit, OpenTP1 outputs message KFCA00838-W for each server affected. In other words, a message is output if the interval from the time of the last queue operation to the status check by the scheduler exceeds the time specified in the schedule_delay_limit operand.

The time of the last queue operation is updated when:

• A service request is fetched from the schedule queue.
• A service request is registered in the schedule queue when there are no service requests remaining in the schedule queue.

If you specify schedule_delay_abort=Y in the user service definition, the servers output message KFCA00839-E along with KFCA00838-W, causing the scheduler daemon to forcibly terminate and OpenTP1 to shut down. When the OpenTP1 system runs in a hot standby configuration, OpenTP1 detects the delayed status of service requests in the schedule queue and executes a system switchover.

The following figure shows an example of monitoring the schedule queue when 15 is specified in the schedule_delay_limit operand and Y is specified in the schedule_delay_abort operand.

Figure 3-2 Example of monitoring the schedule queue (schedule_delay_limit=15, schedule_delay_abort=Y)

Explanation

1. The scheduler checks the status of the queue.
   No service requests are registered in the schedule queue or have been fetched from the schedule queue. Since the service request hold time is not calculated, the schedule delay limit and the service request hold time are not compared. The scheduler continues processing.
   
2. Three service requests are registered.
   The first and second service requests are fetched, and processing of them begins.
   The third service request remains in the queue because the processing systems are busy. At this time, the last queue operation time is second 11.
   
3. The scheduler checks the status of the queue.
   At this time, the last queue operation time is second 11. The service request hold time^#1 is 9 seconds, which does not exceed the schedule delay limit. The scheduler continues processing.
   
4. Processing of the first service request is completed.
   The third service request is fetched by the system that processed the first service request, and processing of the third service request begins^#2. At this time, the last queue operation time is second 27.
   
5. The fourth service request is registered.
   The second and third service requests are being processed, and the processing systems are busy. Therefore, the fourth service request remains in the schedule queue. At this time, the last queue operation time is second 28.
   
6. The fifth service request is registered.
   The second and third service requests are being processed, and the processing systems are busy. Therefore, the fifth service request remains in the schedule queue. At this time, the last queue operation time is second 28.
   
7. The scheduler checks the status of the queue.
   At this time, the last queue operation time is second 28. The service request hold time^#1 is 2 seconds, which does not exceed the schedule delay limit. The scheduler continues processing.
   
8. The scheduler checks the status of the queue.
   At this time, the last queue operation time is second 28. The service request hold time^#1 is 12 seconds, which does not exceed the schedule delay limit. The scheduler continues processing.
   
9. The sixth service request is registered.
   The second and third service requests are being processed, and the processing systems are busy. Therefore, the sixth service request remains in the schedule queue. At this time, the last queue operation time is second 28.
   
10. The scheduler checks the status of the queue.
    At this time, the last queue operation time is second 28. The service request hold time^#1 is 22 seconds, which exceeds the specified schedule delay limit. The OpenTP1 system goes down.
    

#1

The service request hold time is determined by subtracting the last queue operation time from the time at which the scheduler checks the queue.

#2

The third service request actually has been in the schedule queue for 16 seconds (second 27 - second 11). This value exceeds the specified schedule delay limit.

In actuality, however, OpenTP1 determines whether the specified schedule delay limit is exceeded by checking the value calculated by subtracting the last queue operation time from the time at which the scheduler checks the queue status (second 30 - second 28). Therefore, the scheduler continues processing.