Tuxedo, the Transaction Processing Monitor, was a large part of what
ZOIS did. And there’s enough of it still about to cause the odd commission query. These sadly seem to be far away and require more effort than your correspondent is capable of, now he is in his medical-inspired dotage. He’s still up for the odd gig, but please, part-time, and with as little thrashing around strange Airports and Railway Stations in the wee-small hours as possible.
Importantly for anybody contemplating a move from Tuxedo 6.5 to a later Tuxedo was the Threads Issue. This was the major problem with Tuxedo 7.0 that everybody condemned as being ‘crap’. 7.0 was the version where somebody thought it was a good idea to have multi-threaded Servers. It wasn’t. The fix, introduced in Tuxedo 8.0, was to switch-off the largely redundant but expensive thread-dispatcher and leave the oh-so-clever multi-threaded Processing Agents to the now, sadly, defunct Encina.
The magic environment variable setting is:
This is the famous but poorly-documented “make Tuxedo go faster” variable.
For all you ‘stuckists’ out there, moving to a more modern Tuxedo does have a number of advantages. As well as the obvious ones, fixes and support from Oracle as an example, it allows the use of a whole load of more modern features. Most of these are bolt-on jobs, granted, but useful all the same. One thinks of SALT, but there are others. Not least it allows the specification of Transport End-points symbolically, You can remove all the mapped-sockaddr (“0×0002″) addresses and replace them with ‘proper’
//name:port ones. Believe the author, Dear Reader, when he writes that this makes Bulletin Board Configuration files a lot easier to maintain.
Anyhow, if you’re the person who got the Sydney gig, and you’ve been inspired by this post, I hope that you’re charging them a suitably large fee.