Originally posted by: SystemAdmin
Why is your file watch unable to handle the number of log files coming into your Audit map directory? I've had Audit log processing maps running countless files through, though sometimes you do need to tune your system to get it to work efficiently. Check the resources available to the TX Unix user and to the directory -- also ensure that you have configured the TX system to allow for high volume multi-processing.
Other ways to process audit logs would be to RUN the Audit map from each of your other maps and send the audit log across in memory. This would ensure that the audit log is processed straight away but does have the impact of slowing down (marginally) completion of your main maps.
You could also look into a product called B:Mon developed by CAS AG (though based in Germany I think). It pretty much just feeds off audit logs and has a graphical front end allowing you to view historical process data. It's not too difficult to build the basics of this yourself though.
The alternative to processing
i:136b243524every[/i:136b243524] audit log is to output tracking messages into a database from each map that is run. This allows you to build up a detailed tracking history of every flow through your TX system.
Cheers
T
#DataExchange#IBMSterlingTransformationExtender#IBM-Websphere-Transformation-Extender