> I have a subroutine which is being called by an RPC program ,
> this routine
> calls another funtion which requires some open database's. I
> dont want to
> open the two databases everytime I call this function. So
> what I did was
> write another program which opened up the databases and fed
> the open names into a message file.
>
> The message file is then read by the sub routine when it is
> started up , the
> only problem with this is that it does not work. Is this
> because the open
> process is owned by the original program. If so what would be
> the best way of doing this ?

MPE file opens, of which databases are a variant, are
process-specific. I'm not sure what you're putting into your message
file, but it isn't going to be anything meaningful to anyone outside
the process that opened the database: open databases are identified
within a process by a 16-bit integer, which maps to an internal value
within the DBMS support info for that process, and that map is unique
to the process. Another process might have that same database open
with a different value, or have a different database open with the
same value. To allow multiple processes to share the exact same open
of a file, you have to fork() the process. Except that MPE doesn't
support fork()ing a process if it has an open database.

One common way to handle this situation is to open the database in a
background service-type application; it accepts requests from the
multiple clients, interacts with the database, and returns the
results. In this case, your RPC server would interact with the data
service using some local IPC method--message files, shared memory,
sockets, etc. Make sure you carefully evaluate the security
implications of your chosen design; you don't want to give processes
access to things they shouldn't see, and you don't want to leave
things lying around where anyone can peek at them.

You're right that, if the RPC server sees any volume at all, you
*don't* want to open and close two databases for every client request.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *