|
HP OpenVMS Systemsask the wizard |
|
The Question is: I have a program that acts as a service for another program. Both programs run as detached processes. I get requests via a mailbox to read a record from a file. My program has up to 500 files open. I retrieve the data from the appropriate file and return it to the other process. Most of the program is designed to be AST driven. That is, we do asynchronous RMS GETs with AST routines and we use the mailbox data notification AST. I am trying to add support for acting as a middleman between the other processes and a process on another VAX. We have DECnet Phase IV. I use non-transparent task-to-task communications. I have no problem creating a logical link to the process on the other VAX. My problem is that sometimes the response from the other VAX is delayed sometimes for 20 seconds (at other times the response is nearly immediate <1sec). The process on the other VAX seems to receive the request in a timely manner and returns it in less than a second. I cannot use a $QIOW since that would interfere with processing the other ASTs. All the examples I have seen use $QIOWs. The DTS/DTR utilities report the ability to do >100 messages/sec at 16 bytes per message. I have added code to my program to generate test requests and encounter this problem when I do 1 request every 5 seconds or faster. What is the problem with non-transparent task-to-task communications and the $QIO routine? The Answer is : There are many potential causes, ranging from (potential) application bugs to (potential) DECnet bugs to networking problems or congestion. The Wizard would suggest integrating support for debugging within the application, including timestamp information on the transmission and reception of messages at the DECnet routines. (Exchanging information on the protocol version, the remote system name, and the remote system time -- as compared to the local system time -- during the initial network connection negotiations -- can help isolate the current clock skew value. And this can make comparing the traffic logs on two systems rather easier.) The Wizard would also suggest looking for process quota limitations on both ends of the connection, with particular interest in this case on ensuring that the sender's quotas are sufficient for all outstanding I/O activity. The Wizard will assume that DECnet connections are not being started and shut down frequently, that the connections are being maintained for a series of messages. If this information is insufficient or does not lead to a solution, please contact the customer support center.
|