Conference orarep::nomahs::rdb_60

    Hi Louise,
    
    I don't know what the policy is between DEC and Oracle now that Rdb
    has moved but I know there are many of your own people who can tell
    you exactly how it's done when they get in. (Whether that means you
    can tell your customer? I'm dying to find out!)
    
    If you look back at the archived Rdb notes files you will see that
    I've been screaming about this for ~5 years and very recently in
    various DEC conferences (I really gotta get a life :-)
    
    Anyway I hope it's a really big customer who can bring some pressure
    to bear.
    
    Good Luck. Richard Maher.

    The two processes have separate instances of Rdb.  Rdb does not support
    two processes participating in one transaction - too much context is
    in process memory.  When you pass Rdb a TID, it really only considers
    transactions in progress in *that* process.
    
    Would that it was not so, as it prevents us from fully supporting the
    X/Open XA standard, which requires multiple process participation.

    The difference between what you are trying to do and a simple two-phase
    distributed transaction is that in the latter case a portion of Rdb
    (Dispatch) is involved in starting both parts of the transaction, and
    supplies additional context to glue them together.  It is not really
    the same transaction at a low level - it is two related transactions
    that commit or roll back together.

Hi,

I have placed a working example of exactly what the customer is asking for 
in note 108.* in the VMSNOTES conference. Why am I confident that I know
what the customer wants? It's because I got the same error trying to do
the same thing years ago. (As described in RDB_50 conference note 838.0)

I have read .2 and .3 about ten times and still have no idea what is being
discussed, but the one thing I saw that I could agree with is the part about
being unsupported. (Which just to point out has *nothing* to do with whether
it works or not)

What I, your customer and many others over the years have asked for (either
implicitly or explicitly) is for this magnificent functionality to become
*supported*!

So I maintain the only question is "Will everyone involved just let the 
customer do what he wants?"

I know it is *absolutely none* of my business what you/Oracle tell your
customers but I can't help wondering will it be:

a) We've decided to reverse the earlier decision and support this. 

b) User access to the distribution of transactions to other process is
   unsupported. If you have a requirement please excalate through product
   management. (I guess this is how big customers get PIDs?)

c) The widget on the thingymajig can't possibly work in that configuration
   but we do have the replicator option, parralel query, rtr, dmq, etc. . .
   That's what your really looking for.

Regards Richard maher.

    Richard,
    
    Thanks for letting us know about the example, I'm not sure yet whether
    I'll pass your example on to them, but could you post it in this
    conference, so that those of us on the Oracle network can see it too?
    
    Thanks,
    Louise.

    Hi Louise,
    
    I'm sorry, I didn't realize you couldn't see past the Oracle network.
    I've seen a couple of you people there so I thought you all could. In 
    a nutshell: I could tell you but then I'd have to kill you :-)
    
    But seriously, the example uses information that has been labeled
    "Proprietary and Confidential" to DIGITAL. This may sound strange
    when there is nothing in the example that your people don't already
    know but that's the way it is. 
    
    Anyway it's not the end of the world, as I say I'm sure someone there
    can help you. In the meantime you could look at the rdb$remote sources
    as they show you how to do the same thing. But again having a solution
    doesn't mean the customer can have it.
    
    Regards Richard Maher.

    I see the confusion now.  I thought this customer was trying to get
    *Rdb* distributed transactions to work this way.  That will not work.
    But by making all the DECdtm calls himself he essentially gets two
    independant Rdb transactions (there will be two START TRANSACTION
    SQL statements, or implicit ones) which share a DECdtm TID.  DECdtm
    will then coordinate the commit.
    
    The thing I thought was being attempted, which is what X/Open requires,
    is that a transaction gets started in one process and then commited in
    another process.  Rdb can't do that today.  But what is being attempted
    here is two Rdb transactions, each with its own commit operation. 
    (Though synchronized by DECdtm.)
    
    Yeah, it ought to work.

    It is possible to pass TIDs between processes, Rdb does it with
    remote databases.  Can you supply more details regarding the customers
    application.  The customer will most likely need to call SYS$ADD_BRANCH
    and SYS$START_BRANCH which are not document for some unknown reason.
    
    

~What I, your customer and many others over the years have asked for (either
~implicitly or explicitly) is for this magnificent functionality to become
~*supported*!

Well I think it is supported by Rdb.  It is the VMS folks who need to document
the interface.

~So I maintain the only question is "Will everyone involved just let the 
~customer do what he wants?"

Ask VMS

~I know it is *absolutely none* of my business what you/Oracle tell your
~customers but I can't help wondering will it be:
~
~a) We've decided to reverse the earlier decision and support this. 
~
~b) User access to the distribution of transactions to other process is
~   unsupported. If you have a requirement please excalate through product
~   management. (I guess this is how big customers get PIDs?)
~
~c) The widget on the thingymajig can't possibly work in that configuration
~   but we do have the replicator option, parralel query, rtr, dmq, etc. . .
~   That's what your really looking for.

(b) escalate this through Digital management :-)

Ian

    I'll try to clarify what this customer wants. I haven't seen any code,
    he's just explained this to me over the phone.
    
    He wants two processes. One will start a transaction using
    SYS$START_TXN which returns (among other things) the TID. He then wants
    to pass the TID to the second process using inter process
    communication & use that TID to do the update, then pass the TID back
    for the first process to do the commit:
    
    
    Proc_1				Proc_2
    SYS$START_TXN
    		   -- TID ------------->
    					update 
    		   <------------ TID --
    commit
    
    It's on the update that he gets SYSTEM-F-NOSUCHTID.
    
    Thanks,
    Louise.

    Are these two processes running on the same system?
    

~    Proc_1				Proc_2
~    SYS$START_TXN
~    		   -- TID ------------->
~    					update 
~    		   <------------ TID --
~    commit

What is being used in PROC_2 to use the TID?  I believe this is where you use
SYS$ADD_BRANCH.  You need to also perform an attach in PROC_2

Ian

Hi,

.8> which are not document for some unknown reason.

Last reply I got was "It costs too much to document. Where are the customers?".
Can you believe it? :-( No new software, No new testing, No new release and
it costs too much?

.9> Well I think it is supported by Rdb.

*This is the best news that I've heard for a long time!!!*

.9> It is the VMS folks who need to document the interface.
.9> Ask VMS
.9> (b) escalate this through Digital management :-)

Now that I know Rdb supports this, I have to agree. The problem is that I
have already mailed everybody I thought could have any influence on the
decision and, as compelling as the arguments I put forward may be, they
keep falling on deaf ears. I keep coming up against a wall that says
"Where are the customers?".

Anyway I hope your customer (are they big? is it south England? My contract
finishes in 2 months :-) really pushes DEC for this! Now if only Rdb
engineering put their weight behind the request then this win win situation
will stop being a loss.

Re .10

Hey I was right for once.

Regards Richard Maher.

PS. On the support side of things, I am 99% sure that the process that
    called $start_trans must wait until the other process(es) have completed
    *all* Rdb work before calling $end_trans. (As in my example the sub-
    process must tell the main process (via a mbx) that it has done the 
    update before the txn is committed) is this necessary?

    eg: if procB needs to do 3 updates and the Rdb part of procB gets an
        AST from DECdtm telling it the trans has ended after only 2 updates, 
	can the third update take place in procB in the same txn?

PPS. OK benchmarking is a costly business, but how about an unaudited TPC-C
     benchmark where the order lines are being done by one process and the 
     rest of the stuff done by the other.  Would we be suprised???

    >I keep coming up against a wall that says
    >"Where are the customers?".
    
    	I would think that if there was enough customer requirement for
    such a capability, then this would be no wall at all.

    DECdtm has an interface consisting of 13 system services, of which only
    three (3) are documented.
    
    Comments on the desirability of documenting the other 10 should be
    directed to the DECdtm development team.  Part of which is located
    in Scotland.  (!)
    
    Lets see, "maybe if you documented it so people knew it was there,
    they would think of ways to use it."

    DECdtm calls for each process should be:
    
    Proc 1				Proc 2
    
    SYS$START_TRANS
    SYS$ADD_BRANCH
    		   --- TID ---------->
    					SYS$START_BRANCH
    SYS$END_TRANS
    	-or-
    SYS$ABORT_TRANS
    
    

    ACMS is another product that uses these undocumented services for
    2pc transactions across multiple processes.

    �                      <<< Note 4970.11 by NOVA::DICKSON >>>
    �
    �    Are these two processes running on the same system?
    
    No - does this make any difference if they use SYS$START_BRANCH &
    SYS$ADD_BRANCH?
    
    Louise.
     

    The outcome of this was when the customer spoke to Digital, they
    discouraged him from using the SYS$START_BRANCH & SYS$ADD_BRANCH calls.
    
    They told him they were for internal use only & the format might change
    without notice.
    
    The customer's using a different approach now.
    
    Thanks for all the help though - appreciate it.
    
    Louise.

>    They told him they were for internal use only & the format might change
>    without notice.
    
    Yeah right.  After all these years they are going to change them?  :-)
    Internal use only?  That sure doesn't help encourage people to develop
    SW for DEC platforms.  Oh, I forgot, DEC is a "software company."  ;-)