T.R | Title | User | Personal Name | Date | Lines |
---|
353.1 | Ideas anyone? | 18669::GREEN | | Wed May 28 1997 21:30 | 1 |
| Anyone got any ideas regarding the base note?
|
353.2 | | MOVIES::POTTER | http://www.vmse.edo.dec.com/~potter/ | Thu May 29 1997 10:16 | 8 |
| Don,
Sorry, I don't have any idea as to what you're getting here. Have you asked
the Rdb folk what that error really means? Without that information, there's
no way I could even hazard a guess...
regards,
//alan
|
353.3 | We are Rdb!! | 18669::GREEN | | Thu May 29 1997 18:44 | 27 |
| Alan,
I work in Oracle Rdb/DBI technical support. DEC contracts to Oracle
for support of the DBI product suite. This is until June 24 of this
year. This is why I still have access to DEC systems even though I was
sold to Oracle in the DBI sale last March.
The person resporting the problem is from Rdb support in Denmark. I
have forwarded your reply.
I have also mentioned to this person that I have seen this error before
but in rare cases. Where I have seen this is with DBI and field test
versions of Rdb. In my instances this is what happened...DBI always
queries to see what the highest version of Rdb/Dispatch is on a system.
It does this for capabilities purposes. I've seen cases where DBI will
make a call to Rdb/Dispatch, and a field test Dispatch doesn't know
about the call. When I mentioned this to my friend he said that he'd
check on this but he was pretty sure that there was only one version of
Rdb involved and that it wasn't field test. I have yet to hear back.
We were just wondering if this symptom/error has ever been reported to
DECdtm or if anyone in DECdtm was familiar with the symptoms described.
Thanks for the note. I'll write back when I hear more from the other
side.
Don
|
353.4 | Some more info | 18669::GREEN | | Thu May 29 1997 19:51 | 21 |
| Alan,
Some more info on this.
The RCI error is indicating that an DSRI (RCI) call was incorrectly
constructed. The most likely cause in an rdb_attach_database call is
that someone has set the instantation number to non-zero for a
remote attach.
One posibility is that for some reason DTM is trying a remote attach
as part of its handling of this distributed multi-database transaction.
Another is that DTM in some way corrupts calls or Transaction IDs.
This is not an attack on DTM. We are investigating if VMS, ACMS or Rdb
are doing this too. But we need to follow up all the paths, especially
if there are any known issues? We have already thoroughly checked the
other 3 so now it is time to ask DTM.
Thanks,
Don
|
353.5 | Oops! :-) | MOVIES::POTTER | http://www.vmse.edo.dec.com/~potter/ | Thu May 29 1997 23:27 | 22 |
| Don,
Thanks for your replies. All I can say is that this is entirely foreign to
me - I have heard nothing similar before. Equally, I should point out that
I no longer work on DECdtm. The maintainer for the product is Carey Donat.
It might be worth dropping a mail to her - STAR::CDONAT to see if she has
heard of anything similar.
It would be invaluable if you could find out whether this error is being
generated as the result of a specific call. For example, I think I'm right
in saying that an attach in Rdb parlance corresponds to the DECdtm system
service SYS$ADD_BRANCH. A specific error code back from that service would
make this problem much easier to solve.
I'm not going to be around for the next week or so, so I would recommend
pursuing this with Carey.
Good luck,
regards,
//alan
|
353.6 | Thanks for the lead | 18669::GREEN | | Fri May 30 1997 15:50 | 3 |
| Thanks Alan.
Don
|