TRANSACTION MONITORS

In message gg8BZhn0Bwxd0YAdx, Mark Sherman of Transarc writes:

>transactional RPCs and Encina, and we've been concentrating on making
>those good for years.

Mark, are you suggesting that competing products, such as Tuxedo or Top End, do not operate on a transactional basis? I thought that was the whole point of an OLTP monitor. As for the 'making those good for years' comment - from my recollection neither Encina nor Top End have been on the market more than twelve-fifteen months. I believe all three products pass the 'ACID' test.

>to VMS to MVS, and everything in between. The point is that every
 distributed
>system needs naming, security, and so on. Why invent (and administer)
 several
>(one for mail, one for your database, one for your tp system, ...) when
>you can reuse an existing one. Not only do we believe this, but I think
the

Again, I am mystified. I understood Kerberos, for example, was modular enough that it could be implemented by itself, as opposed to having to implement an architecture entirely DCE-dependent. If DCE is not modular, does that not greatly decrease its current worth? - since it is not nearly as functional as the existing 'proprietary' architectures. Surely you are not suggesting lowest-common-denominator functionality simply for its own sake? We shall, for the moment, leave the idea of DCE defining 'open systems' - that would be a message in itself. Further, I understood the major vendors - HP, DEC, IBM, et al - are incorporating pieces of DCE, not all of it, as they see fit.

>industry (as driven by users) is coming to the same conclusion. For
 example,
>Oracle and Sybase also showed DCE-based versions of their systems
>recently at the OSF. One infrastructure is better than N.

A marketing shot, Markl; Oracle is notorious for being promiscuous - they even have a CTOS version - while Sybase is so heavily tied to the DCE vendors for their marketplace that they literally have no choice but to follow this drummer - and if their major platofrms go another direction, they'll switch horses just as quickly.

>and so on. With Encina, we have carefully drawn the boxes so you can
>get at those subsystems if you want. Other products hide these subsystems,

Personally, Mark, once I am satsified that you manage my subsystems properly, I wouldn't want to know about them - error reporting aside. I would _not_want to write the routines I need to manage global transactions to non-XA-compliant resource managers - such as, say, VSAM, or DB2, or non-current versions of Oracle, Sybase, Informix. They should be function or RPC calls with the same syntax as to XA-compliant ones, with the transaction monitor handling the sticky details. Nor do I think a product that touts itself as a global transaction manager should force me to do this.

I don't advocate a startup providing the same broad support that a billion-dollar company would; I do think any product in this niche should note marketplace realities, see where people are migrating _from_, and provide tools to minimize this migration pain. My understanding of Encina's current offerings is that your product does not do this.

Lurkers please note: Transarc at least has the excuse of being a startup. Novell/USL (Tuxedo) and ATT/NCR (Top End) do not, so if you are examining this class of product, you might reasonably expect a braoder support base as well as strategy. So be a little tougher on 'em when you talk to them.

jh

---
. MR/2 1.39x NR . "Death before Disco" - 1975 "Death before DOS" - 1993