TP Never Dies: The ACMS/DECtp Reunion

About 80 of us showed up for the first (and hopefully not the last) ACMS/DECtp reunion this past weekend in Groton, Mass. Some folks traveled from Baltimore, Virginia, Detroit, Ohio, Seattle, and Houston to get there. We had a great time.
ACMS is the TP monitor Digital developed for the VMS operating system. The project started in 1979 and during its 26 year history the product has seen a lot of highs and lows, quite like that of Digital itself. A great ride, but definitely a bit of a roller-coaster.
Along the way ACMS pioneered many innovations, contributed to the development of several TP standards, and very nearly took over the world. The things I learned during my 15 or so years connected with ACMS are things I still use every day of my professional life. A lot of people at the reunion said the same, or similar. Above all, it was really a great group of people to work with, and it was tremendous seeing so many of them again.
In early 1990 Nippon Telegraph and Telephone selected ACMS and we were swept up into a much larger program called the Multivendor Integration Architecture, the goal of which was no less than standardizing IT software, including TP. And we achieved it back then, too, demonstrating 7 independent implementations at Telecom ’95 in Geneva. At that time NTT had submitted the MIA specs to SPIRIT, and gained the support of major telecom companies around the world.
As part of this effort we redesigned ACMS and produced a standards-based, multiplatform implementation called ACMSxp. But like many legacy replacement products on Unix and Windows (anyone remember CICS 6000?), it never did as well as the original.
Around this time ACMS became also became part of DECtp, which was a big program related to the “Mainframe VAX” (aka the VAX 9000) initiative, since TP is so important to the mainframe market. We even had our own building, with an official ribbon cutting ceremony and everything. Digital started aggressively hiring the best and the brightest TP talent, much like Microsoft did about six or seven years later.
DECtp was one of the turning points in Digital’s history, since while we were trying to compete with IBM at the high end of the market, we were more or less ignoring the PC and the low end of the market.
Along the way ACMS pioneered remote procedure call based transaction processing, the three-tier architecture so widely used in modern application servers today, the interface definition language used in CORBA (and other places), and the idea of abstracting implementation details out of the “container” now found in COM+/.NET and EJB. Yes, all of these things were there when the product was first released in 1984, and yes, sometimes we had a very difficult time selling it (although the customers who understood it really loved it).
It’s amazing what bits and pieces of MIA and ACMSxp are still around.
Through the support of the telecom companies in charge of MIA and then TMF/SPIRIT, the ACMS approach came close to taking over the world, giving CICS a real run for its money. The Structured Transaction Definition Language (STDL) based on ACMS was nothing less than an attempt to provide the equivalent of SQL for the TP world. But (and perhaps predictably since it wasn’t based on their products) IBM and other TP vendors were strongly opposed. The specification was approved by X/Open only because of user pressure for a portable TP language.
With object orientation on the horizon along with CORBA/OTS, COM+, and even EJBs, STDL eventually became an interesting step in the evolution of TP standards.
Today we are seeing a new approach to the problem of software standardization in the form of a text-based solution based on XML, SOAP, and WSDL, and even more flexibility in interpreting an even higher level language. And perhaps the industry is finally mature enough for standardization, including TP. The lessons of ACMS and DECtp continue to serve us well, and the people are all still great people.

Advertisements

2 responses to “TP Never Dies: The ACMS/DECtp Reunion

  1. Congratulations. I always think it’s a shame that today’s “young ‘uns” think TP systems evolved through J2EE and .NET and can (usually) cite the big players such as CICS and Tuxedo, but not “those that came before” (said in my best Deep Thought voice). I remember when I started with transactions back in the mid 80’s that ACMS was the key cutting-edge product. It’s a shame how times change.

  2. Great article, Eric!
    A small tidbit worth mentioning: way back when I recall we ran a benchmark with some 40,000 online users on VAX machines, making use of the fact that the ACMS distributed architecture could be deployed at the drop of a hat (actually, it was an environment variable, but that’s not important), thereby being able to separate the presentation layer from the business layer and the DB layer.
    Might be worth pointing out that V5 of ACMS will be along soon (on Alpha and Integrity (Intel)) and that it is very easy to expose ACMS transactions (Tasks) as JavaBeans or Enterprise JavaBeans using a product called HP BridgeWorks (http://h71000.www7.hp.com/commercial/bridgeworks/bridgeworks_index.html). This product includes support for XA transactions when invoking ACMS Tasks from within an EJB container on OpenVMS such as BEA WebLogic Server.
    If you prefer a Windows COM environment, there’s also the TP Web Connector (http://h71000.www7.hp.com/commercial/tpwebconnector/).
    We have some great references, new ones as well, and we’d be more than happy to speak with anyone wishing to know more about all this “legacy” stuff.