FairCom ISAM for C

Client/Server ctntio Communications Errors (Formerly VDP Errors)

FairCom DB performs rigorous error checking and logging during the course of everyday operation. Because of the depth of error checking that is performed, warnings and error messages are logged in even the most benign situations.

When a communication error such as ARQS_ERR (127, send failure) or ARSP_ERR (128, receive failure) occurs, the FairCom DB logs an entry in the status log file, CTSTATUS.FCS.

Wed Nov 26 14:58:59 2008

- User# 00013 ctntio: read error - O13 bytes=0 pErr=127

|ADMIN|ctreplr 192.168.1.110|: 161

This is not a serious situation unless the client application is also getting errors such as 127, 128, or other general connection failure errors. To ensure the errors are not serious, try to reconcile the ctntio errors in the log with the client events that triggered them. Since these errors do not usually happen frequently and user and node names are provided, it should be easy to determine which event caused this situation.

The context of the ctntio error is that a server thread receives a notification that a message is available, however, when the server performs the read operation, nothing is returned.

This can be caused by (but not limited to):

• Clients or processes aborting without calling CloseISAM() or StopUser(), or end users turning their machines off without properly logging out of the application. A client application crash effectively results in this same condition.
• A faulty network connection or related network hardware failure such as a network adapter, cabling, switch, or router. Check the the server machine, client machines, and all connections between them.
• An overworked network transport layer that is timing out and doing retries.
• Other processes on the network consuming the majority of the CPU time and not permitting the communications layer bound to FairCom DB sufficient time to handle incoming messages.

Faulty network connections or problems in related network hardware can be investigated by your network managers. This may require considerable investigation to discover the culprit, which could be just a single network card in one machine.

By raising the priority of the FairCom Server, you can easily experiment with the problem in CPU consumption. To raise the priority of FairCom DB, go into the Windows task Manager and find ctsrvr. Right click on it and raise the priority to REAL TIME. If this eliminates or significantly reduces the errors you need to look at either reducing the processing load on the machine or increasing its processing power by moving to a faster machine, possibly with multiple processors.

To avoid these errors, ensure FairCom DB's host machine is not burdened beyond its capacity. A more powerful machine or limiting the number and types of applications on the machine can improve performance and limit communication level errors. Also, ensure no specific application is over-using resources on the host machine. If appropriate in the Server's operating environment, increasing the priority of the process can eliminate or reduce ctntio errors. This should be done cautiously as it will affect other applications running on the same machine.

The error messages in the server status log can be turned off, however, unless they are an inconvenience, this is not recommended. The messages serve as a general health check on the state of your network and application logic and may be an early warning of more serious network and/or system problems. Should you wish to disable the messages, The CTSTATUS_MASK VDP_ERROR keyword can be added to the ctsrvr.cfg server configuration file. Restart FairCom DB to enable the configuration changes.

Note: Legacy c-tree I/O errors were previously noted as VDP (Virtual Device Protocol) errors in the past. These have largely been replaced with ctntio errors.

If java.nav (formerly JTDB) connects to the SQL_PORT instead of the SERVER_PORT (or SERVER_NAME), that java.nav client will get error 128.