From what I understand, when you SUPPRESS a message in an Xlate, the Xlate still executes all of its code. So it stands to reason that there is less overhead if you kill the message in a tcl script if you know right away that a message is unwanted. There will be some situations where it makes more sense to kill the message in an Xlate.
I would prefer to kill the message as early in the stream as possible. Typically I would kill in the preXlate upoc prior to passing through any xlate code for a targeted downstream system. If the filter is for all of the messages the tps inbound serves as a good point to insert code and kill the message before any further processing. I would also recommend using argument driven tcl code to indicate what field(s), what to test for and what to do with the message(kill, continue, etc.). This makes it relatively easy to insert filters…. That’s my 2
If you can do the Tcl then my recommendation is use Tcl.
If you are Level 1 Certified and not proficient in Tcl, then either find someone else’s Tcl proc that is generic enough for anyone to use or us the Xlate to get your project done. During testing, make sure the impact of using the Xlate method is not excessive for you.
If you have used the Xlate method because you are not ready for the Tcl path, and then become confident with using Tcl, begin using Tcl. It would be nice to retrofit the Xlate filtering but that is not likely to happen as we are all too busy trying to take care of active projects.
I too prefer argument driven Tcl procs. We are using one which has been in existence for 12 years without modification and yet it is used for nearly all of our filtering and is also in use at other institutions.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
.
.