1) HPSS filesystem mounted over Ethernet LAN on HP workstation running HP/UX 10.20
2) Objectivity 4.0.2 installed on HP workstation
3) Federation created on the HP, with two databases of size 0.5 MBytes each on local disk.
4) Application runs on HP against database correctly
5) Both databases moved to reside on the NFS-mounted HPSS filesystem, using
oochangedb -db [name] -filepath /hpss/[name].db [bootfile]
6) Application runs on HP against databases with new location correctly
7) On the HPSS machine, both database files forced to second-level storage class in HPSS (i.e. forced to tape in this case).
8) Application runs on HP against database: we observ the following
a) HPSS system mounts tape in order to restore the (two?) database file(s)
b) Objy application waits for a while while this is going on
c) Objy application fails with the following error message:

cithe702 29: date;stars_match;date
Fri Aug  1 13:23:31 PDT 1997
With predicate query
** Error #4515: ooHandle(ooDBObj)::open(): Storage Manager: Error reading page.
size = 8192 page = 0 RPC: Timed out (103204)
Cannot open DB2
Fri Aug  1 13:23:59 PDT 1997

The conclusion seems to be that the Objy RPC request times out for the 2nd.
database.

(...later...)

Further to my mail of 1st. August, we have now re-run the test with
an RPC timeout of 1200 seconds (20 minutes). This evidently gives
HPSS plenty of time to restore the database files (which were forced
offline prior to the test):

cithe702 36: date;stars_match;date
Tue Aug  5 17:28:16 PDT 1997
With predicate query
Checksum -1961861
Time to search for nearest stars 898 secs
Tue Aug  5 17:43:17 PDT 1997

This indicates that the NFS/HPSS interface works for Objy
when an appropriate time out value is set.

Note that the elapsed real-time for the application is 15 minutes (900 seconds),
of which most (898 seconds) is comprised by the application searching all objects
in the two databases.

The RPC timeout is set using a call to ooRpcTimeout, apparently
undocumented in the Objy API