  NETSERVER and Network Partner Exited Errors? 
 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.
 
