We are currently testing the Oracle Transparent Gateway for IMAGE/SQL. We
are running out of test time, so we would appreciate some feedback from the
list from anyone whose "been there, done that" :

1) The ROWID_CACHE_SIZE Parameter.

We found that on one particular manual master, a SELECT ... FOR UPDATE from
Oracles interactive SQL interface (SQL/PLUS) would take forever. We'd give
up waiting and have to "kill" the client PC, "Quit" the server and "Stop"
the listener to get rid of the process and release the dataset locks.
Pretty drastic stuff.

Thru allot of trial and error we finally found that by increasing the
ROWID_CACHE_SIZE from the default 10 to 3000 (it has a max of 32000) solved
the problem and the response time is now acceptable.

The question is how do you determine or estimate this value. Other master
sets don't have this problem and they are similar to the one in question.
i.e. similar # of entries, Superdex keys on both, record sizes not too
different, same TurboIMAGE database. The difference is that the "problem"
master has 9 paths (compared to 1 in other masters) and that the "problem"
master has 60 items (compared to a max of 32 in others).

2) IMAGE/SQL Administration Guide manual (5.0)

On page 5-1 it states that a SELECT in modes 1 thru 4 with an Isolation
Level of RR,CS or RC will result in an Exclusive data set lock. Very very
misleading.

This is true only if  the SELECT statement DOESN'T have a WHERE statement.
If it does, and the isolation level is RR (default for ISQL) then only the
qualifying records are locked. Very Logical.

What caught us out is the fact that the default isolation level for
sessions accessing via the Oracle Open Gateway is CS. The IMAGE/SQL manuals
state that CS is basically unsupported and reverts to RR behavior. It
doesn't. Any SELECT statement will lock the entire set. Very very ugly
should you decide to stick with the default CS and believe the IMAGE/SQL
manuals.

The phrase "Shot themselves in the leg" comes to mind for some reason ....
;))

3) Hung sessions

We have been able to kill a client session shortly after issuing a SQL/PLUS
query (i.e. before the "QUERY EXECUTING" message comes up) and have the
corresponding processes on the HP3000 stay active with locks firmly held.
This is the sort of thing that will inevitably happen on a busy Monday
morning. Does anyone know of a way to avoid this situation ?

Thank you for taking the time to read this longish message and thank you
for any feedback.

Costas Anastassiades,
INTRACOM SA
Athens-Greece