How to filter the EMS events based on a keyword in ems events?

Post by Ivak .
Hi,
I am using EMS command as below.
TACL>emsdist co $0,ty p,te [#myterm]
However, I need to specify the keyword in above command. Based on that
keyword, the events should be displayed on screen.
Ex;
TACL>emsdist co $0,ty p,te [#myterm]
\system1.$SYSTEM.SYSTEM 7> emsdist co $0,ty p,te [#myterm]
11-01-18 06:14:08 \system2,1193 TANDEM.EMS.H01 000512
NSBGCT:The
212162071040773452
.
.
.
.
.
.
.
Here, there are so many ems events emitted from different sub systems.
But,I am just concerned about my events which have always prefixed by
specific keyword. Here it is "NSBGCT"
I came across FILTER options. However it needs command file, and it
seems, it filters based on the subsystem name, but keyword.
Looking forward for your valuable suggestions.
Thanks,
Ivak.

Ivak,

it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
But let me say something about filters:
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.

Here is a sample for filtering 512-messages.

For compiling a filter you have to load the definitions:

#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY

This is the filter, the file is called FIL512:

FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;

And now we compile the filter:

emf /in fil512/ofil512

The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.

My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

Keith Dick

2011-01-17 20:04:12 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.

Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.

If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).

If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.

Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.

A filter that would select messages that contain NSBGCT would be:

[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;

Put those lines into an Edit file, for this example call it NSBGCT, then compile it as follows:

#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT

Then you can use the compiled filter in the EMSDIST command:

EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT

If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.

I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.

Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.

There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.

Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.

If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.

I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).

I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.

wbreidbach

2011-01-18 08:36:36 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.
Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.
If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).
If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.
Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT
EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT
If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.
I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.
Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.
There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.
Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.
If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.
I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).
I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

Keith is right, in my filter I did not check for the EMS subsystem.
Maybe some other subsystem can produce a 512 event. So Keith's filter
would do the trick. I myself never used the match function because we
are generating real EMS events with correct eventnumbers from our
applications.
The browser version of Viewpoint is called EMS event viewer and should
be available on port 9991 at least within the service network but you
can configure it for additional networks. This has to be done by the
system manager and is very easy.
Indeed there are products available on the market like MOMI, PROGNOSIS
and some others but you have to pay for them.
Depending on the needs it is possible to send those EMS events as SNMP
traps to a trap handler. This trap handler could be running on any
system. If this is of interest, I could post some more details.
Wolfgang

Pramod Suryawanshi

2020-12-11 15:06:07 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.
Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.
If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).
If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.
Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT
EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT
If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.
I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.
Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.
There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.
Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.
If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.
I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).
I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.

Hi,

I am using below filter to search the events based on specific keyword. But which is giving ems as an output for only one SSID "TANDEM.EMS"
I suspect it is because ZEMS^TKN^TEXT only.

Is there a way to get all events matching with given keyword from all SSIDs and not with any specific SSID this is what I am expecting from my filter.

Filter-
FILTER MYFILTER;
BEGIN
IF MATCH(ZEMS^TKN^TEXT,"*MYWORD*") THEN PASS
ELSE FAIL;
END;

Keith Dick

2020-12-11 16:53:04 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.
Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.
If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).
If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.
Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT
EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT
If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.
I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.
Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.
There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.
Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.
If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.
I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).
I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.

Hi,
I am using below filter to search the events based on specific keyword. But which is giving ems as an output for only one SSID "TANDEM.EMS"
I suspect it is because ZEMS^TKN^TEXT only.
Is there a way to get all events matching with given keyword from all SSIDs and not with any specific SSID this is what I am expecting from my filter.
Filter-
FILTER MYFILTER;
BEGIN
IF MATCH(ZEMS^TKN^TEXT,"*MYWORD*") THEN PASS
ELSE FAIL;
END;

If I am remembering correctly, you are correct that the behaviour you see is because you are using ZEMS^TKN^TEXT as the source of the string you are getting MATCH to compare against. An event only contains that token if the developer of the program that created the event wanted to provide the message text to use when a regular EMS Formatter template for the event is not available.

There is a way to get a filter to generate the text of the message that normally would be displayed for the event, then compare against that. It is the EMSTEXTMATCH function. That is a little harder to use, and generating the full text for each event makes it pretty slow, but it will do the job. If you can cut down the number of events you have it expand to full text by first selecting on the subsystem or subject tokens (or any other way), that would be helpful to improve the performance of the filtering.

Pramod Suryawanshi

2020-12-14 14:14:27 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.
Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.
If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).
If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.
Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT
EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT
If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.
I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.
Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.
There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.
Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.
If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.
I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).
I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.

Hi,
I am using below filter to search the events based on specific keyword. But which is giving ems as an output for only one SSID "TANDEM.EMS"
I suspect it is because ZEMS^TKN^TEXT only.
Is there a way to get all events matching with given keyword from all SSIDs and not with any specific SSID this is what I am expecting from my filter.
Filter-
FILTER MYFILTER;
BEGIN
IF MATCH(ZEMS^TKN^TEXT,"*MYWORD*") THEN PASS
ELSE FAIL;
END;

If I am remembering correctly, you are correct that the behaviour you see is because you are using ZEMS^TKN^TEXT as the source of the string you are getting MATCH to compare against. An event only contains that token if the developer of the program that created the event wanted to provide the message text to use when a regular EMS Formatter template for the event is not available.
There is a way to get a filter to generate the text of the message that normally would be displayed for the event, then compare against that. It is the EMSTEXTMATCH function. That is a little harder to use, and generating the full text for each event makes it pretty slow, but it will do the job. If you can cut down the number of events you have it expand to full text by first selecting on the subsystem or subject tokens (or any other way), that would be helpful to improve the performance of the filtering.

Keith, really thank you for your reply.

I did search on EMSTEXTMATCH but really not got exactly how to use it.
Could you have possible to post the syntax or any filter having EMSTEXTMATCH is used.

Thanking you in advance.

Keith Dick

2020-12-14 16:20:10 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.
Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.
If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).
If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.
Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT
EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT
If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.
I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.
Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.
There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.
Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.
If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.
I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).
I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.

Hi,
I am using below filter to search the events based on specific keyword. But which is giving ems as an output for only one SSID "TANDEM.EMS"
I suspect it is because ZEMS^TKN^TEXT only.
Is there a way to get all events matching with given keyword from all SSIDs and not with any specific SSID this is what I am expecting from my filter.
Filter-
FILTER MYFILTER;
BEGIN
IF MATCH(ZEMS^TKN^TEXT,"*MYWORD*") THEN PASS
ELSE FAIL;
END;

If I am remembering correctly, you are correct that the behaviour you see is because you are using ZEMS^TKN^TEXT as the source of the string you are getting MATCH to compare against. An event only contains that token if the developer of the program that created the event wanted to provide the message text to use when a regular EMS Formatter template for the event is not available.
There is a way to get a filter to generate the text of the message that normally would be displayed for the event, then compare against that. It is the EMSTEXTMATCH function. That is a little harder to use, and generating the full text for each event makes it pretty slow, but it will do the job. If you can cut down the number of events you have it expand to full text by first selecting on the subsystem or subject tokens (or any other way), that would be helpful to improve the performance of the filtering.

Keith, really thank you for your reply.
I did search on EMSTEXTMATCH but really not got exactly how to use it.
Could you have possible to post the syntax or any filter having EMSTEXTMATCH is used.
Thanking you in advance.

I have never used that EMSTEXTMATCH function myself, so I cannot give you any explanation from my personal experience with it. It is a function that I believe was created after I left the project. In my brief check of the EMS Manual a few days ago when I posted my previous comment, it appeared that it was a bit more complicated to use EMSTEXTMATCH than it was to use some of the other functions. I might be able to figure out what the EMS Manual is saying about how to use EMSTEXTMATCH a bit easier than you can, so I will try to find some time later today to see whether I can figure out exactly how it is intended that EMSTEXTMATCH can be used, then post another comment about it.

In the meantime, if you want to get something going quickly, and if you have OSS installed and are familiar with using it, you could try something like going into OSS, and set up a pipeline that uses gtacl to run an EMS printing distributor, pipe the output of the printing distributor to grep, and use the pattern matching of grep to select the lines you want. That might be slow, but probably not much slower than using EMSTEXTMATCH would be. You'd probably want to use the -A and -B options of grep to make it show a few lines before and after the match, because if the EMS formatted message takes multiple lines, using grep without those options would not show you the full message. I think that would not be the ideal approach, but it might be good enough, depending on what you actual need is.

Keith Dick

2020-12-15 15:11:59 UTC

Ivak,
it seems you are just writing your output to $0, so all you get is a
simple text message type 512. Unfortunately that type of message is
rather common and not a good criteria for searching the log.
I have been using and writing filters for many years and I have always
successfully avoided to scan the text itself.
Writing a filter is described in the EMS manual. As far as I remember
you have the chance to scan the text within a filter.
Here is a sample for filtering 512-messages.
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#POP DUMMY
FILTER FIL512;
BEGIN
IF ZEMS^TKN^EVENTNUMBER = 512 THEN PASS
ELSE FAIL;
END;
emf /in fil512/ofil512
The compiled filter ofil512 can now be used with the EMSDIST program
with the FILTER parameter.
As a result, EMSDIST would only list type 512 messages.
My recommendation would be to produce real EMS-messages instead of
those text messages. That is much easier than most people think and
information about that can be taken from another thread just a few
weeks ago.

I believe what Wolfgang wrote is mostly correct. I believe the filter he shows will cause EMSDIST to display event number 512 from any subsystem, not just the EMS 512 events. It might be the case that few other subsystems have events numbered 512, so testing just the event number probably works well most of the time. I will show a filter below that tests both the subsystem and the event number.
Wolfgang is right that EMS really was intended to have the events be tokenized rather than just plain text messages. The ability to handle plain text messages was a backwards compatibility feature, intended to be used less and less over time. But if plain text messages is what you must work with, there are ways to do that.
If selecting just the EMS 512 events for display reduces the amount of output enough that you can easily find the messages that you want to see, then the filter Wolfgang showed you will be enough (possibly modified to select only events from EMS numbered 512).
If there still are too many events displayed, even when limited to only the EMS 512 events, there are at least two things you could do. One would be to send the output from EMSDIST to the spooler, then use the PERUSE FIND command to search the spooler job for the keyword. I assume you know how to use PERUSE to do this, so I will not explain it here. If you want further explanation of how to use PERUSE this way, post again to ask about that.
Another thing you could do is modify the filter to use the MATCH function in the filter to select only the EMS 512 events whose text token contains the keyword. This means that you would have to modify the filter and recompile it each time you need a different keyword. If there are only a few keywords you need to use, you could create and compile a filter for each keyword in advance, then when you run EMSDIST, simply specify the compiled filter that tests for the desired keyword.
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
FILTER NSBGCT;
BEGIN
IF NOT (ZSPI^TKN^SSID = SSID(ZEMS^VAL^SSID) THEN FAIL;
IF NOT (ZEMS^TKN^EVENTNUMBER = 512) THEN FAIL;
IF MATCH(ZEMS^TKN^TEXT,"*NSBGCT*") THEN PASS
ELSE FAIL;
END;
#PUSH DUMMY
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZSPITACL
#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZEMSDEF.ZEMSTACL
#POP DUMMY
EMF/IN NSBGCT/ ONSBGCT
EMSDIST TYPE P,COLLECTOR $0,TEXTOUT [#MYTERM],FILTER ONSBGCT
If there is not just one or a small set of keywords that you want to use to look for events, but want to give an arbitrary keyword each time, you could create a TACL macro based on the above that takes the keyword as its argument. Have the macro create the filter in an Edit file (using the parameter value in the MATCH), compile the filter, and run EMSDIST using it.
I do not have access to a NonStop system, so I cannot test the above to be sure I have everything exactly correct. I am pretty sure it is very close to correct, but there could be some mistakes. If it does not work, and you cannot figure out how to fix it yourself, post again to show what the problem is and we probably can tell you how to fix it.
Your system might have the token definition files on a volume different from $SYSTEM, so you might have to change $SYSTEM in the above to whatever volume is correct for your system.
There are variations possible in the details of how you create a filter, so what I show here is not the only way it could be done. For example, the manual says that EMF can take input from a TACL variable using INV, so you do not absolutely have to put the filter into an Edit file. You could use ATTACHSEG instead of LOAD to make the token definitions available. Etc.
Yet another approach would be to use the SPI interface to EMSDIST from a TACL routine to retrieve the events and do the filtering in your TACL code before displaying the message, but that probably is more work than you want to do, and would be much more code than I would want to try to write without being able to debug it.
If there were a simple way to direct the output of EMSDIST to an OSS pipe, you could pipe it to a grep command to select the lines you want to display, but I cannot immediately think of a simple way to do that since I think EMSDIST does not write to its OUT file. And messages whose display takes more than one line would not show the whole message that way, so it probably is not a very good approach.
I am pretty sure that the Viewpoint program has a way to display messages that match a keyword, but you probably would not want to set up a Viewpoint system just for that purpose. There is a web browser version of Viewpoint that might be easier to set up and use, but I know little more than that it exists (and I do not know whether it has the keyword filtering feature you want).
I know I have heard of other programs that can display events from the EMS log, and I believe some of them include the ability to select events by keyword, but I do not remember what those programs are called, where they come from, etc. I imagine some of them are sold by other companies that provide NonStop management tools. There might be a couple such programs in the ITUG contributed library. There might be a few free ones available other places. Perhaps someone else will post a reply that tells of such programs.

Hi,
I am using below filter to search the events based on specific keyword. But which is giving ems as an output for only one SSID "TANDEM.EMS"
I suspect it is because ZEMS^TKN^TEXT only.
Is there a way to get all events matching with given keyword from all SSIDs and not with any specific SSID this is what I am expecting from my filter.
Filter-
FILTER MYFILTER;
BEGIN
IF MATCH(ZEMS^TKN^TEXT,"*MYWORD*") THEN PASS
ELSE FAIL;
END;

If I am remembering correctly, you are correct that the behaviour you see is because you are using ZEMS^TKN^TEXT as the source of the string you are getting MATCH to compare against. An event only contains that token if the developer of the program that created the event wanted to provide the message text to use when a regular EMS Formatter template for the event is not available.
There is a way to get a filter to generate the text of the message that normally would be displayed for the event, then compare against that. It is the EMSTEXTMATCH function. That is a little harder to use, and generating the full text for each event makes it pretty slow, but it will do the job. If you can cut down the number of events you have it expand to full text by first selecting on the subsystem or subject tokens (or any other way), that would be helpful to improve the performance of the filtering.

Keith, really thank you for your reply.
I did search on EMSTEXTMATCH but really not got exactly how to use it.
Could you have possible to post the syntax or any filter having EMSTEXTMATCH is used.
Thanking you in advance.

I have never used that EMSTEXTMATCH function myself, so I cannot give you any explanation from my personal experience with it. It is a function that I believe was created after I left the project. In my brief check of the EMS Manual a few days ago when I posted my previous comment, it appeared that it was a bit more complicated to use EMSTEXTMATCH than it was to use some of the other functions. I might be able to figure out what the EMS Manual is saying about how to use EMSTEXTMATCH a bit easier than you can, so I will try to find some time later today to see whether I can figure out exactly how it is intended that EMSTEXTMATCH can be used, then post another comment about it.
In the meantime, if you want to get something going quickly, and if you have OSS installed and are familiar with using it, you could try something like going into OSS, and set up a pipeline that uses gtacl to run an EMS printing distributor, pipe the output of the printing distributor to grep, and use the pattern matching of grep to select the lines you want. That might be slow, but probably not much slower than using EMSTEXTMATCH would be. You'd probably want to use the -A and -B options of grep to make it show a few lines before and after the match, because if the EMS formatted message takes multiple lines, using grep without those options would not show you the full message. I think that would not be the ideal approach, but it might be good enough, depending on what you actual need is.

I had too much else to do yesterday, so it wasn't until this morning I had a chance to look further into EMSTEXTMATCH.

The description of EMSTEXTMATCH is not very good, so I am still not sure I understand it completely. If the description is to be believed, at least the second argument to EMSTEXTMATCH must be a filter parameter token. Filter parameter tokens can only be supplied to a filter when the filter is loaded into the distributor by a SPI command. That is, you cannot specify filter parameter tokens on the EMSDIST command line. If that is true, you would have to write a program (which could be written in any of a number of languages) to make use of a filter that uses the EMSTEXTMATCH function. If you want to go to that effort, I might be able to puzzle out and explain to you all that you must do to accomplish that.

I have a feeling that the description of EMSTEXTMATCH is not complete,, and describes only one way EMSTEXTMATCH can be used. In particular, I have a feeling that the second argument is not required to be a filter parameter token, but could be a string constant that contains the pattern that you want EMSTEXTMATCH to compare to the formatted event text. If my feeling is correct, then you would be able to use EMSTEXTMATCH in a filter that did not use filter parameter tokens, and so the filter could be specified on the EMSDIST command line. I certainly could be wrong about that, so you could be wasting your time if you try to use that approach.

I have a feeling that the approach I described yesterday about piping the output of a printing distributor into grep would be a lot simpler to do, and probably would perform about as fast as an approach that uses a filter with EMSTEXTMATCH (maybe even a little faster, if the solution using EMSTEXTMATCH calls EMSTEXT twice per event).

mustlearntandem

2011-01-17 16:43:16 UTC

You might try starting and then writing to a private collector rather
than $0. This is an easy way to filter out everyone else's messages
and you would only see your own.

emsacoll /name $mine,nowait/ logsubvol $data.mylogs

then

emsdist co $mine,ty p,te [#myterm]

MicroTech

2011-01-18 09:44:49 UTC

Post by Ivak .
Looking forward for your valuable suggestions.

Hello Ivak!

Keith and Wolfgang has already explained what you need to do, and how
to do it. This is just another suggestion:

IF changing the way your application emits messages to $0 is an
option, it might be a Good Thing to use EMS. One simple way to emit
EMS event signatures is to use SENDEMSEVENT(), which you can download
from my website (tinyurl.com/SENDEMSEVENT).

Good Luck!

Henry Norman
MicroTech Consulting
sites.google.com/site/microtechnonstop

Ivak .

2011-01-19 15:21:24 UTC