From: richard_maher@my-deja.com Sent: Tuesday, November 14, 2000 6:26 AM To: Info-VAX@Mvb.Saic.Com Subject: Reinventing the wheel :-( Just Do It Hi, Next contestant - Sybil Fawlty from Torquay, special subject the bleedin' obvious. > 2. let VMS know just what you want to do. http://www.networksorcery.com/enp/rfc/rfc2372.txt (Please see the example API in the appendix) or this one's got pictures http://microsoft.com/winme/MITTs/Transactions/html/default.htm Please read the above if only to understand the concept of a "two-pipe strategy". NB:***It is this that VMS engineering seeks to deny you.*** Phrases like "We'd like to make the interface transparent." are really euphemisms for "Wrap it all up in a one-pipe cloak so that they have to use our software on client _and_ server". Phase one: Bricks and Mortar. All you need to deliver is a tip$pull routine! If this can be achieved with a modified $start_branchw then all the better. I understand that this will restrict us to starting the txn on another TIP compatible node but hey it's a start and will solve the majority of user requirements with minimal effort. Let's face it. It's been spec'd for you, and ACMSxp have already ironed out any creases in the TIP protocol and will be a cornucopia of examples for extracting the TIP URL from MTS. I can't see it taking longer than 3 months (including testing and shipping). If you could include a tip$push () routine at the same time then that would be fantastic. Obviously you'd have to make room for the TIP URL in the DECdtm transaction log file and upgrade LMCP. (After 10 years it's at V1.1 :-) Potentially the biggest change is making DECdtm TCP/IP compatible but it is my understanding that most, if not all, of this work is already done. What will it let us do? 1) You will be able to start an MTS transaction against an Oracle8i (or SQLserver or both) database on W2K. 2) Obtain the transaction URL via DtcGetTransactionManagerEx. 3) Using whatever method *you* like (for example Socket Send() or XML page) send the URL to your VMS node along with the data to be updated. 4) On VMS, Call TIP$PULL(in: URL, out: TID) 5) Normal service is resumed. Pass the DECdtm TID to your Rdb/RMS/DBMS updates. Note: W2K has had a Sea Change back to Asynchronous services!!! This could provide a great opportunity for parallelism in Oracle8i/Rdb I/O. In a nutshell, the updates to all databases are now enshrined with the ACID properties of a true 2PC. Now if you don't get your jollies out of that then you're simply sick of life itself! ------------------------------------------------------------------------ ------------ The story so far:- 1) Keith B Evans (The guy that wrote the book on TIP) works for Compaq (Tandem). I think he'd be someone worth talking to when trying to establish future directions with TIP. Transport Layer Security (TLS) for encryption? 2) ACMSxp already talks TIP and is available *now* and is being used in at least one customer site. Unfortunately in the ACMSxp implementation the the engineers have cloaked the beauty and openess of the two-pipe strategy in a single pipe. But now realize the error of their ways and agree that TIP belongs in DECdtm. If I was implementing TIP on VMS I would certainly call on their experience. 3) Tandem NonStop TM/MP already talks TIP. 4) Windows2000 is available *now* which, in addition to COM+, provides a SDK for obtaining a transaction URL. DtcGetTransactionManagerEx (IDispenserManager, GetDispenserManager, IID_ITipTransaction) Once you've obtained the TIP URL you can send it over the network through your TCP/IP socket, or whatever flavour of second pipe you like, and then call TIP$PULL() or a modified version of $start_branchw. This will return a DECdtm Transaction Identifier / Branch Identifier that can be passed to Rdb, RMS or DBMS. 5) XA functionality is a nice to have but is of little use with Rdb, DBMS or RMS but would obviously be useful for Rdb/VMS<->Oracle/* 2PC. As it is my understanding that resource managers/database vendors would have to modify and certify their code as DECdtm/XA compatible on VMS, I believe that any XA functionality should be prioritised down the list. (I'm thinking of the AX_* routines in sys$help:xa_profile.txt. In particular AX_BIND_DECDTM. I can't see Oracle rushing to incorporate this.) Whereas TIP requires *NO CHANGE* to Rdb/RMS/DBMS to get them talking to the outside world!!! 6) Once Tip$pull and Tip$push are available then DCE/RPC can look at transactional RPC and COM can be upgraded to COM+. NB: It is not DECdtm's responsibility/budget to upgrade COM. They didn't seem to need DECdtm to get authenticated COM. But then again I wish someone else had gotten control of External Authentication. 7) Can someone explain to me my VMS engineering has to reinvent the wheel here? And how a twelve month (being generous) delay can be sold to customers as "Well, we wouldn't want a knee jerk reaction would we?" "What we need is someone who can spin and run interference for us while RTR is getting established." "I've got it! A feasibility study with broad terms of reference like Heterogeneous Computing - Do Transactions Have a Place? If only we can find someone with credibility then we could milk it for about 12 months." "Has anyone seen Rodger?" Regards Richard Maher Sent via Deja.com http://www.deja.com/ Before you buy.