Enables "Start on Read" logic to improve performance of applications that perform a large number of START operations all followed by READ sequential operations, such as READ NEXT or READ PREVIOUS.
Accepted Values
Value |
Effect |
Synonyms |
---|---|---|
yes |
FairCom RTG does not execute the START operations until the subsequent READ sequential operation (READ NEXT or READ PREVIOUS). |
y, true, on, 1 |
no |
Disables this logic. |
n, false, off, 0 |
Example
To enable start on READ logic:
<startonread>yes</startonread>
Notes
The <startonread> configuration option improves performance of COBOL applications that perform a large number of START operations all followed by READ sequential operations, such as READ NEXT or READ PREVIOUS.
When <startonread> is enabled, FairCom RTG does not execute the START operations immediately. Instead, it waits for the subsequent READ sequential operation (READ NEXT or READ PREVIOUS). The effect is that START operations return immediately but never fail even if the specified key is not valid. It is the subsequent READ sequential operation that executes the START operation and eventually returns the error. For this reason, we do not recommend using this option unless the user understands the risks.
If the FairCom RTG server does not support <startonread>, the FairCom RTG client fails and logs error message "server does not support <startonread> configuration."
SYMPTOM: Performance of START + READ NEXT / PREVIOUS is worse when <prefetch> is enabled and gets worse increasing the number of prefetched records with <prefetch records> configuration attribute.
PROBLEM: The RTG prefetch logic gets triggered by the second consecutive READ NEXT or READ PREVIOUS operation as a consequence, a loop of START operations followed by READ NEXT operations will never trigger the prefetch logic. However the logic that sends the request to the RTG server to read the next record, prepares the RPC network buffer to receive the prefetched records when just the <prefetch> configuration option is enabled. The result is that an useless memory allocation is performed during a READ NEXT operation that does not prefetch records. This unused amount of memory can be significant for large <prefetch records> attribute settings. We noticed that large memory allocations are sometime costly in terms of performance depending of the platform.
SOLUTION: Change the logic that calculates the RPC network output buffer to include the prefetch buffer size (CT_FILE->fetsiz) only if a prefetch request is actually sent to the server.