![]() |
Software > OpenVMS Systems > Ask the Wizard ![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: I have written a simple DCL task to task procedure which is used to retrieve data from a database on a remote machine. The local machine is a VAX 4180, running OpenVMS 7.1, Rdb 7.0-5. The remote machine is a VAX 4180 running VMS 5.5-2, Rdb 4.2-1. It was necessary to do it this way as Rdb 7.0-5 will not talk directly to 4.2-1 database using RDBSERVER tasks. The remote task accepts a parameter from the client, writes an SQL script, executes it and returns the data to the client. The problem is that once the task has finished (NET_nnnnn process) another process (SERVER_nnnn) starts up and remains there for a number of minutes before dying off. During this period, the following message is seen if another attempt to connect is made: %DCL-E-OPENIN, error opening VAX"username password"::"task=test_server" as input -RMS-E-ACC, ACP file access failed -SYSTEM-F-LINKEXIT, network partner exited I have tried this to a different remote machine (running OpenVMS 7.1) and it works perfectly. Is there anything I can do to resolve this, short of an upgrade? Thanks. The Answer is : Check the log files created on the system running the client task for an indication of the sequence of events. If you do not wish to permit the reuse of the network server task, either force the task process to exit, or enable the NETSERVER timeout mechanism. (See SYS$SYSTEM:NETSERVER.COM for details.) Alternatively, use an NCP- or NCL-defined object -- other than the task object -- to invoke the server portion of the application, and code the server to exit when completed. Given the initial connection processing with an Oracle Rdb database, the OpenVMS Wizard might well retain a pool of connected server processes, and communicate with these from within the context of a separate DCL (or executable) server invoked in response to the incoming connection, or a multi-threaded server that is continually operating and accepting and processing incoming database connection requests. Using a pool of these pre-connected server processes can avoid the delays that can arise when initially connecting to the Oracle Rdb database.
|