Maybe I’ll raise a DAR!
I have been looking at Transaction Enabler lately (unix environment) and know that you can control the user funnel and asynchronous daemon at startup by using a bunch of parameters – this is good simply becausae the funnel/daemon infrastructure can be tuned to your installation – memory, load modules, etc…
But what you can’t do (apparently) is stop the asynch daemon and user funnel by sending it some sort of signal – you have to use the unix “kill” command which (in my opinion) is a little scrappy.
Does anyone else feel that this might warrant and enhancement request ?
What you should be able to do is (after starting the UF, for example), be able to use a control tool to send it a signal to close down – either with or without flushing currently in flight transactions.
Maybe I’ll think about it over Christmans and raise a DAR anyway – but I’d be interested to see what others think.
Just a link back to a posting entitled “aefc tcp/ip interface proposal” at http://gentalk.biz/blog/?p=153
I posted this nearly 2 years ago, but didnt follow it up or give it lots of though. Its just re-emerged now !
I agree with Danny – maybe in the new year I’ll look at what I’d like in the TE and put some thoughts around that and see what an “overhaul” could contain – but for now I’ll drag out the documentation over Christmas and see what features it offers – and check out aefcn.
If it turns out that you dont need the Windows TE installed to get it, then maybe that’s a starting point for the overhaul.
(continued) … so maybe a more extensive overhaul is in order).
But for now, I’m just thinking about work-arounds:
Just want to point out that AEFCN on the Gen Developer Workstation also allows you to connect to your unix TE and control it from there in the same way as on your unix box. (But maybe AEFCN is not available as long as you don’t have the Windows TE installed, would need to check that)
Don’t get me wrong, I still support the idea of a DAR. (There are even other painpoints with the TE, like in the area of availability, fail-over scenario’s, etc… so maybe )
I’d forgotten about that – from a unix-based scheduling perspective, that’s OK – since users would probably want to be able to schedule the startup and shutdown of the TE automatically.
From a developer perspective, they may want to have a (possibly Eclipse-based) mechanism to control the TE from the desktop.
Creating such a desktop tool should be easy and integrating it into the Eclipse environment also shouldnt be a problem, however, making the TE respond to signals sent from that tool is more difficult since (as far as I know), the User Funnel and Asynch Daemon don’t have the capabilities at the moment.
In the meantime (while I think about this) I’ll look at the playback script option.
There are certainly grounds to raise a DAR asking for a decent command-based operational management user interface to the TE.
However, you do not have to use “kill” to shut it down. What is available to you for use inside a unix shell script is to use aefc with a playback script. This allows you to have the same control over the TE as you would when managing it online. It is not the nicest solution but it works.