If you need to have the uDSM in the #1 spot in your dsm ordering, I suggest modifying the catch all regex in the LSX by something unique in your logs. That should fixe the greediness ;)
<!-- Do not remove the "allEventNames" value -->
<pattern id="allEventNames" xmlns=""><![CDATA[
(.*)]]></pattern>
Replace (.*) by something relevant to these logs.
Or if you're unsure, use the recommendation, and put your uDSM in last position.
------------------------------
Anthony Gayadeen
------------------------------
Original Message:
Sent: 03-02-2018 11:27 AM
From: Matthew Carle
Subject: Using Multiple DSMs (LogSources) for the Same IP Address
The Parsing Order should definitely work, though it was somewhat broken many releases ago. We fixed that issue, but I wonder if something else has gone sideways since.In these cases you're seeing where the first DSM gets everything, even events that should go to one of the lower-ordered DSMs, do you recall if the first log source in order was a Universal DSM or a custom log source type? I ask because Universal DSM is "greedy" and will match any event, so log sources of this type should always be last in parsing order. If they are first in order, nothing below them will ever receive events, could it be that's what you're hitting? Similarly, until a recent update (sometime in second half of 2017, not sure the exact date), any custom log source types created in the DSM Editor would be similarly greedy, blocking any log sources after them in parsing order from receiving events. This has been fixed via an update to the IBMCustomDSM rpm, which is the "template" DSM that gets cloned for each custom log source type
------------------------------
Matthew Carle
------------------------------