Recent discussions with the development team has revealed that the probes that intereact with logs on the AS400 (fetchmsg, history, logmon) poll the logs on intervals. This means that the hierarchy of profiles within these probes are acting on previous state rather than on current state log entries.
A profile that answers a specific query does not alter the polled information that is passed on to the next profile which may generate an alarm if that query isn't answered.
Also collecting and storing that information is resource intensive and in systems where there is a lot of log activity or where retention is governed by politics rather than practice the polling can break.
Instead something like the 'watch for event' function should be utilized. This would also enable the capturing of more information than the log entries allow generating an opportunity to create reactions on a more granular level (type of server, user name on the job, thread identifier, LIC module name or LIC module timestamp).
Having these variables available will also help in creating email notifications to operators or clients.