EMSDIST in TACL script.

[Prasad]

Hello All,

Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.

I just need to tweak. how do I get the ems logs into the Tacl variable.

[wbreidbach]

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.

Wolfgang

[wbreidbach]

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

[Randall]

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)

There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.

[wbreidbach]

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

[Keith Dick]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement. Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do. It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.

So, to respond to the specific question: If you need only select certain EMS events by the subsystem name and event number, a filter table is the easiest way to do that. Filter tables are described in chapter 6 of the EMS Reference manual. There is more to filter tables than this simple example shows, but to select all Pathway events, this would do:

?PASS
TANDEM PATHWAY *

This is a fixed-column format: the items start in columns 1, 10, and 20. (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.) Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command. Look in chapter 6 for the other things a filter table can do.

If you must select events based on the values of other things in the events, a regular EMS filter is needed. It is a little harder to write than a filter table is, but not terribly hard. Just as an example, I think this filter would do the same as the above filter table:

[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]

FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;

Put the above lines into an Edit file, for this example, let us call it GETPATH. Then the following lines would compile the filter:

#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy

EMF/IN GETPATH/ OGETPATH

Then specify OGETPATH as the FILTER in an EMSDIST command.

EMF is a TACL routine which needs the token definitions loaded in TACL form, which is why the #LOAD commands are needed before running EMF. I believe this example filter did not need the EMS tokens, but they are often used in filters (when checking the event number, for example), so you usually would need them. The ZSPIDEF subvolume might be on a different disc than $SYSTEM -- the command:

FILEINFO $*.ZSPIDEF.ZSPITACL

should find where it is if it is not on $SYSTEM.

The full filter language is described in chapter 5 of the EMS Reference manual. When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there. The examples ought to be enough to let you see how to form statements in a filter. If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.

One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH. If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use. EMSTEXTMATCH is for something different.

The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed. If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.

You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report. EMSDIST, at least when used as a printing distributor, already formats event for printing. If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events. That requires learning the template formatting language, which is described in the DSM Template Services manual.

You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates. The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are. You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format. In some cases, a subsystem's token definitions might depend on another subsystem's token definitions. The first four characters of the name of an undefined reference will lead you to the file that defines that item.

To write a formatting template for an event, you must know what tokens are included in the event. This is documented in a manual for the product. Often it contains the words Management Programming Manual in the title of the manual, but not always. Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult. I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product. If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print. That would be easier than writing the templates entirely on your own.

There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event. You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want. I don't find the template key used for that header formatting template in a quick look at the documentation. If you need that, I'm sure we can find it.

You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST. That will not affect the formatting done by other places in your system.

If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.

Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file. The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process. Writing to a disk file and then reading that file from TACL probably is the simplest way to take. I do not know what types of disk files are acceptable, and the manual seems not to list them. It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable. I imagine it would accept longer records, but whether it uses the full record length, I don't know.

It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them. I cannot say whether that will work. If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command. I don't know what else might be necessary. The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.

Using the consumer distributor approach probably is formally the better approach if you cannot use a report produced by EMSDIST as the final result, but it takes more work. You must learn how to send SPI commands to EMSDIST to retrieve events and write the per-event code using the SPI procedures to extract the items you need from each event. If you already know SPI programming, it would be easy to apply that knowledge to this problem (all SPI programming is pretty much the same), but if you are starting from no SPI programming knowledge, this approach probably is a lot more effort than the others.

Now, if the requirement is not to produce some report in TACL, but could be met by having an easy way to browse the event log, look at Web ViewPoint from HP. I do not know all of what it can do, so I will not try to describe it, but it might provide what you need better than the reports you seem to be planning to produce. It might not be suitable, but until you learn about it, you will not know whether it would be better.

Also, if you have the iTP Webserver installed, its management application (which is accessed via a web browser) includes an event browser. I do not know all of its capabilities, either, but I know you can make filter tables from within the event browser, it can use EMS compiled filters, and it can select events by matching on a text template. Once you have selected the events of interest, I do not know whether you can print them or do anything else besides look at them, but check into its capabilities if you have iTP Webserver.

Randall and Wolfgang mentioned still other ways that might be good, depending on the underlying requirements.

[Prasad]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement.  Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do.  It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM  PATHWAY   *
This is a fixed-column format: the items start in columns 1, 10, and 20.  (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.)  Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command.  Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual.  When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there.  The examples ought to be enough to let you see how to form statements in a filter.  If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH.  If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use.  EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed.  If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report.  EMSDIST, at least when used as a printing distributor, already formats event for printing.  If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events.  That requires learning the template formatting language, which is described in the DSM Template Services manual.  
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates.  The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are.  You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format.  In some cases, a subsystem's token definitions might depend on another subsystem's token definitions.  The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event.  This is documented in a manual for the product.  Often it contains the words Management Programming Manual in the title of the manual, but not always.  Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult.  I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product.  If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print.  That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event.  You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want.  I don't find the template key used for that header formatting template in a quick look at the documentation.  If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST.  That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file.  The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process.  Writing to a disk file and then reading that file from TACL probably is the simplest way to take.  I do not know what types of disk files are acceptable, and the manual seems not to list them.  It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable.  I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them.  I cannot say whether that will work.  If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command.  I don't know what else might be necessary.  The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the consumer distributor approach probably is formally the better approach if you cannot use a report produced by EMSDIST as the final result, but it takes more work.  You must learn how to send SPI commands to EMSDIST to retrieve events and write the per-event
...
read more »- Hide quoted text -
- Show quoted text -

Hi Prasad,

Are you certain that the events from MULTIBAT contain the
zems^tkn^text token? If MULTIBAT has defined its events with
individual tokens and supplied formatting templates for the events, it
generally would not include the zems^tkn^text token in the event
messages. In that case, you would have to look at the definition of
the contents of the event messages as documented by MULTIBAT to
determine how to test for the events that are of interest.

If the MULTIBAT events do use the zems^tkn^text token rather than
individual tokens, when you refer to the zems^tkn^text token in the
filter, you must qualify it by the EMS subsystem ID. To do that, you
must first initialize the variable containing the EMS subsystem ID,
then use it in the reference to the token.
You can tell which of the EMS tokens need to be qualified by looking
at their documentation in the EMS manual. If the description of the
token says it is a shared token, you do not qualify it, but if it is
nonshared, you must qualify it with the EMS subsystem ID. These
definitions are in chapter 14 of the EMS Reference manual (EMS
Definitions). In general, tokens stored in the header of the event
message are shared and need not be qualified and tokens in the body of
the event message are nonshared and must be qualified, but there are a
few exceptions to this general rule.

Under the assumption that the MULTIBAT events do use the zems^tkn^text
token, then I believe your filter should be written this way:


#PUSH dummy

#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL

#POP dummy

[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].
[ZEMS^VAL^VERSION]]


[#DEF mbat^val^ssid SSID
BEGIN
SSID x MULTIBAT.1.0;
END;]

FILTER TEST^FILTER
BEGIN

IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND

MATCH (SSID(zems^val^ssid,zems^tkn^text), "*G110*") then
PASS
ELSE
FAIL;
END;

Note that I removed the #LOAD for the ZPWY token definitions, since
your filter does not use any Pathway tokens. Including that line does
not cause any error, but just takes time and memory that are not
needed.
The EMS documentation says that there should be a semicolon following
the name of the filter in the FILTER statement, but I see that your
filter omits that. Perhaps EMF considers that semicolon to be
optional, but if you continue to have trouble with this filter, try
adding that semicolon to see whether that makes a difference.

I hope that solves the problem, but if it does not solve the problem,
please write again.

- Keith


PRASAD BHALEKAR wrote:

Hi Keith,

The filter looks like below.
#PUSH dummy

#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy

[#DEF mbat^val^ssid SSID
BEGIN
SSID x MULTIBAT.1.0;
END;]

FILTER TEST^FILTER
BEGIN

IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (zems^tkn^text, "*G110*") then
PASS
ELSE
FAIL;
END;

this is how the filter I have coded. But to my surprise this doesnt
give any
matching events.
but if I put a check on the ZEMS^TKN^EVENTNUMBER it works fine.
Also in one of the existing filters we have here.. The match criteria
also
works.
I am afraid why it isnt working with me.

Regards,
Prasad

On Thu, Feb 24, 2011 at 9:37 PM, Keith Dick <***@earthlink.net>
wrote:



Prasad wrote:



On Feb 22, 2:19 am, Keith Dick <***@acm.org> wrote:

wbreidbach wrote:


On 21 Feb., 15:01, Randall <***@nexbridge.com> wrote:

On Feb 21, 5:32 am, wbreidbach <***@bv-

zahlungssysteme.de> wrote:

On 21 Feb., 09:42, wbreidbach <***@bv-

zahlungssysteme.de> wrote:

On 21 Feb., 08:49, Prasad <***@gmail.com> wrote:

Hello All,

Please advice me how do read EMS logs pertaining to a specific filter


criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.




I just need to tweak. how do I get the ems logs into the Tacl


variable.




The easiest way to do that is to create a specific filter for the


EMSDIST program.
If you can specify your criteria a filter can easily be created.




Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a


formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.




(shameless plug)

There are other ways of processing EMS logs not on the NonStop. You


can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text
ausblenden -




- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based


application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.



This is a good point: We are not certain that we know the actual
requirement. Sometimes what happens is that the person posting the
question
has progressed part way on what he thinks is the best approach to
solving
the problem, then posts with a question about something with that
approach
that he does not know how to do. It might be that there is a much
better or
easier approach to satisfying the original request that has been
overlooked.

So, to respond to the specific question: If you need only select
certain
EMS events by the subsystem name and event number, a filter table is
the
easiest way to do that. Filter tables are described in chapter 6 of
the EMS
Reference manual. There is more to filter tables than this simple
example
shows, but to select all Pathway events, this would do:

?PASS
TANDEM PATHWAY *

This is a fixed-column format: the items start in columns 1, 10, and
20.
(There also is a pass value that starts in column 40, but that is not
of
any interest for a printing distributor.) Put those two lines into an
Edit
file and specify it as the FILTER parameter in an EMSDIST command.
Look in
chapter 6 for the other things a filter table can do.

If you must select events based on the values of other things in the
events, a regular EMS filter is needed. It is a little harder to
write than
a filter table is, but not terribly hard. Just as an example, I think
this
filter would do the same as the above filter table:

[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].
[ZPWY^VAL^VERSION]
]

FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;

Put the above lines into an Edit file, for this example, let us call
it
GETPATH. Then the following lines would compile the filter:

#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy

EMF/IN GETPATH/ OGETPATH

Then specify OGETPATH as the FILTER in an EMSDIST command.

EMF is a TACL routine which needs the token definitions loaded in TACL
form, which is why the #LOAD commands are needed before running EMF.
I
believe this example filter did not need the EMS tokens, but they are
often
used in filters (when checking the event number, for example), so you
usually would need them. The ZSPIDEF subvolume might be on a
different disc
than $SYSTEM -- the command:

FILEINFO $*.ZSPIDEF.ZSPITACL

should find where it is if it is not on $SYSTEM.

The full filter language is described in chapter 5 of the EMS
Reference
manual. When starting, you probably can skip the beginning parts of
the
description and go directly to the subheading "Declarations" and read
on
from there. The examples ought to be enough to let you see how to
form
statements in a filter. If you find you need to do something that is
not
clear from the statement descriptions and examples, refer back to the
earlier part of chapter 5 for the more detailed description of that
point.

One point that sometimes gets confused is the difference between
EMSTEXTMATCH and MATCH. If you want to test the contents of a token
that
contains a string to see whether it matches a pattern, MATCH is what
to use.
EMSTEXTMATCH is for something different.

The EMS filter is executed in an interpreter inside EMSDIST, so give
some
attention to minimizing the statements that have to be executed. If
the
filter is short, this does not matter much, but if the filter gets to
be
large and complex, try to arrange it so that it tests the most likely
things
first.

You said you wanted to get the results from EMSDIST into a TACL
variable
and format them for a report. EMSDIST, at least when used as a
printing
distributor, already formats event for printing. If the normal output
from
EMSDIST is not in the form you want, you can supply your own
formatting
templates to use to format the events. That requires learning the
template
formatting language, which is described in the DSM Template Services
manual.

You must create a DDL dictionary from the token definition files
supplied
by HP before being able to compile formatting templates. The DDL
source
files that you need for this are in the same ZSPIDEFS subvolume as the
other
token definition files are. You must include the SPI and EMS token
definitions first, then those from the subsystems whose events you
want to
format. In some cases, a subsystem's token definitions might depend
on
another subsystem's token definitions. The first four characters of
the
name of an undefined reference will lead you to the file that defines
that
item.

To write a formatting template for an event, you must know what tokens
are included in the event. This is documented in a manual for the
product.
Often it contains the words Management Programming Manual in the title
of
the manual, but not always. Once you know the tokens in the event,
writing
the template to say how the event should be formatted is not very
difficult.
I cannot remember whether HP includes the source file for the
formatting
templates among the token definitions and other SPI files shipped with
the
product. If so, you might be able to adapt the templates supplied by
HP for
the subsystems whose events you want to print. That would be easier
than
writing the templates entirely on your own.

There is a way to override the part of the event formatting that
displays
the date, time, subsystem ID, etc. at the beginning of the line for
each
event. You can supply an empty formatting template to eliminate that
header
altogether, or you can supply a formatting template that formats just
what
you want. I don't find the template key used for that header
formatting
template in a quick look at the documentation. If you need that, I'm
sure
we can find it.

You get EMSDIST to use your custom formatting templates by naming the
file containing them in the =_EMS_TEMPLATES DEFINE before running
EMSDIST.
That will not affect the formatting done by other places in your
system.

If having EMSDIST produce the report is not suitable, then you could
either take the formatted messages that EMSDIST produces, process
them, and
produce a report in whatever format you prefer, or you could use
EMSDIST as
a consumer distributor, which returns the event messages in SPI
tokenized
for to your program (which could be a TACL program or one in C or
TAL),
which would then extract information from the events and produce the
report
you need.

Getting the report from EMSDIST into your TACL code is not as simple
as
using OUTV in the EMSDIST command, since EMSDIST does not write its
report
to its OUT file. The TEXTOUT parameter to the EMSDIST command can
specify a
disk file or a process. Writing to a disk file and then reading that
file
from TACL probably is the simplest way to take. I do not know what
types of
disk files are acceptable, and the manual seems not to list them. It
does
say that if the file does not exist, EMSDIST will create an entry-
sequenced
file with 80-character records, so entry-sequenced files must be
acceptable.
I imagine it would accept longer records, but whether it uses the full
record length, I don't know.

It might be possible to specify your own TACL process name or that of
another TACL process as the TEXTOUT file and use #SERVER to read the
formatted lines as EMSDIST writes them. I cannot say whether that
will
work. If you try to send the lines to your own TACL process, you
certainly
would have to use NOWAIT on the EMSDIST command. I don't know what
else
might be necessary. The process would not have to be written in TACL
-- it
could be written in C, COBOL, TAL, or pTAL, or any other language that
can
read from $RECEIVE.

Using the consumer distributor approach probably is formally the
better
approach if you cannot use a report produced by EMSDIST as the final
result,
but it takes more work. You must learn how to send SPI commands to
EMSDIST
to retrieve events and write the per-event
...

read more »- Hide quoted text -

- Show quoted text -




HI Keith,

I need to use the MATCH for ems text but unfortunately its not working
as expected. Any ideas why is it so ?

--Prasad




Hi Prasad,

Without seeing the filter code you are using, it is very hard to guess
at
the problem. It could be that you misunderstand how to use MATCH, or
that
you misunderstand what is the contents of the token whose value you
are
testing with MATCH, or something else.

Could you send me the whole filter, or at least a few lines of it that
contain the MATCH function? Also, could you send me the formatted
message
for an event you expected MATCH to be true but it was not? Maybe that
will
give me a better idea of what the problem is.

If you are unsure of the contents of the tokens in an event, even
after
studying the description of the tokens in the event given in the
Management
Programming Manual for the product that produces the event, you can
use the
DUMP ON option to get EMSDIST to display the individual tokens and
values
from the event. Use the TIME and STOP options on EMSDIST at the same
time
to limit the events selected to just the time of the event whose
contents
you want to see so that it does not produce an extremely large output.
If you have programmed an event-processing program using a consumer
distributor and the filter is passing events that you believe should
not
have been passed, you can use Inspect to display an event message:
specify
TYPE EMS or TYPE EMS-NUM in the DISPLAY command. This is described in
the
Inspect manual. This formatted dump is also available in Visual
Inspect,
but I do not know the details of how to request it. It is not
available in
Native Inspect. It might be available in TACL, but I think not.

I do not remember any debugging options available to help see how a
filter
is being interpreted. I think none were implemented, so we can only
look at
the statements of the filter and the contents of an event to try to
figure
out why the filter is not working as expected.

- Keith



Hi Keith,

I tried according to your suggestions but it didnt work. below is the
dump of one of the multibatch ems event

**** Next Event ****
Header_type: %H1
Checksum: F
Last_error: token_not_found (%HFFF8)
Last_error_tkncode: (%H3,%H4,%HFDE6) Ldev-
Number
Max_field_version: 0
SSID: MULTIBAT.1.0
Used_byte_length: %H1E6
Buffer_byte_length: %H1E6
Console-Print: F
Generating-CPU: %H8
Emphasis: F
Event-Number: (%H3)
Standard-defined-type: not-specified (%H0)
User-defined-type: undefined (%H0)
Event-Hdr-Version: %H2
ZEMS-TKN-FORWARDED: F
Generation-Timestamp: 2011-02-26 00:00:02.858.835
Logged-Timestamp: 2011-02-26 00:00:02.859.038
Node-Name: "\NODENAME"
Node-Number: %H4
Generating-PIN: %H2E6
Process-Descriptor: "\NODENAME.$ABCD:145825521"
ZEMS-TKN-REDUNDANT: F
Suppress-Display: F
Userid: %H3F %HFE

Subject-Mark:*
(%H1,%H18,%H1): "G112.AA.01.* "
Manager: \NODENAME.$ABCD
TANDEM.EMS.0 Text: "G112.AA.01.*, started by
operator"
": [ $A123 , 10, Critical-
N, (063"
",254), \NODENAME.
$SYSTEM.SYSTEM.TAC"
"L ,
000000001316606705 ]., "
"\NODENAME.$A1MC 26/02/11,
00:00 "

" "

" "
" "
TANDEM.EMS.0 Action-Needed: T
TANDEM.EMS.0 Action-ID:- %H1

[ghr]

Have you tried a filter table, as Keith suggested:

?PASS
MULTIBAT 1 *

ie MULTIBAT in column 1, 1 in column 10 and * in column 20. Let's say
you put this in a file called fltmult.
Then, assuming ems collector is $0:
and also assuming #set #informat tacl has been executed previously:
emsdist type p, coll $0, filter fltmult, textout [#myterm], time ...

If you want events written to a file:
fup create multevt, type e, buffered, rec 400, ext (100,100)
emsdist type p, coll $0, filter fltmult, textout multevt, time ...

You could then load the file multevt into a tacl variable if necessary
(filetovar, but I'm not sure if it reads non-edi files). But as
already noted, the first version does format the output.

[Keith Dick]

Post by Prasad

Post by Keith Dick

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement. Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do. It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM PATHWAY *
This is a fixed-column format: the items start in columns 1, 10, and 20. (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.) Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command. Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual. When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there. The examples ought to be enough to let you see how to form statements in a filter. If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH. If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use. EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed. If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report. EMSDIST, at least when used as a printing distributor, already formats event for printing. If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events. That requires learning the template formatting language, which is described in the DSM Template Services manual.
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates. The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are. You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format. In some cases, a subsystem's token definitions might depend on another subsystem's token definitions. The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event. This is documented in a manual for the product. Often it contains the words Management Programming Manual in the title of the manual, but not always. Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult. I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product. If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print. That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event. You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want. I don't find the template key used for that header formatting template in a quick look at the documentation. If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST. That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file. The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process. Writing to a disk file and then reading that file from TACL probably is the simplest way to take. I do not know what types of disk files are acceptable, and the manual seems not to list them. It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable. I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them. I cannot say whether that will work. If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command. I don't know what else might be necessary. The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the consumer distributor approach probably is formally the better approach if you cannot use a report produced by EMSDIST as the final result, but it takes more work. You must learn how to send SPI commands to EMSDIST to retrieve events and write the per-event
...
read more »- Hide quoted text -
- Show quoted text -

Hi Prasad,
Are you certain that the events from MULTIBAT contain the
zems^tkn^text token? If MULTIBAT has defined its events with
individual tokens and supplied formatting templates for the events, it
generally would not include the zems^tkn^text token in the event
messages. In that case, you would have to look at the definition of
the contents of the event messages as documented by MULTIBAT to
determine how to test for the events that are of interest.
If the MULTIBAT events do use the zems^tkn^text token rather than
individual tokens, when you refer to the zems^tkn^text token in the
filter, you must qualify it by the EMS subsystem ID. To do that, you
must first initialize the variable containing the EMS subsystem ID,
then use it in the reference to the token.
You can tell which of the EMS tokens need to be qualified by looking
at their documentation in the EMS manual. If the description of the
token says it is a shared token, you do not qualify it, but if it is
nonshared, you must qualify it with the EMS subsystem ID. These
definitions are in chapter 14 of the EMS Reference manual (EMS
Definitions). In general, tokens stored in the header of the event
message are shared and need not be qualified and tokens in the body of
the event message are nonshared and must be qualified, but there are a
few exceptions to this general rule.
Under the assumption that the MULTIBAT events do use the zems^tkn^text
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#POP dummy
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].
[ZEMS^VAL^VERSION]]
[#DEF mbat^val^ssid SSID
BEGIN
SSID x MULTIBAT.1.0;
END;]
FILTER TEST^FILTER
BEGIN
IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (SSID(zems^val^ssid,zems^tkn^text), "*G110*") then
PASS
ELSE
FAIL;
END;
Note that I removed the #LOAD for the ZPWY token definitions, since
your filter does not use any Pathway tokens. Including that line does
not cause any error, but just takes time and memory that are not
needed.
The EMS documentation says that there should be a semicolon following
the name of the filter in the FILTER statement, but I see that your
filter omits that. Perhaps EMF considers that semicolon to be
optional, but if you continue to have trouble with this filter, try
adding that semicolon to see whether that makes a difference.
I hope that solves the problem, but if it does not solve the problem,
please write again.
- Keith
Hi Keith,
The filter looks like below.
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
[#DEF mbat^val^ssid SSID
BEGIN
SSID x MULTIBAT.1.0;
END;]
FILTER TEST^FILTER
BEGIN
IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (zems^tkn^text, "*G110*") then
PASS
ELSE
FAIL;
END;
this is how the filter I have coded. But to my surprise this doesnt
give any
matching events.
but if I put a check on the ZEMS^TKN^EVENTNUMBER it works fine.
Also in one of the existing filters we have here.. The match criteria
also
works.
I am afraid why it isnt working with me.
Regards,
Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl
variable.
The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang
Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.
(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.
This is a good point: We are not certain that we know the actual
requirement. Sometimes what happens is that the person posting the
question
has progressed part way on what he thinks is the best approach to
solving
the problem, then posts with a question about something with that
approach
that he does not know how to do. It might be that there is a much
better or
easier approach to satisfying the original request that has been
overlooked.
So, to respond to the specific question: If you need only select
certain
EMS events by the subsystem name and event number, a filter table is
the
easiest way to do that. Filter tables are described in chapter 6 of
the EMS
Reference manual. There is more to filter tables than this simple
example
?PASS
TANDEM PATHWAY *
This is a fixed-column format: the items start in columns 1, 10, and
20.
(There also is a pass value that starts in column 40, but that is not
of
any interest for a printing distributor.) Put those two lines into an
Edit
file and specify it as the FILTER parameter in an EMSDIST command.
Look in
chapter 6 for the other things a filter table can do.
If you must select events based on the values of other things in the
events, a regular EMS filter is needed. It is a little harder to
write than
a filter table is, but not terribly hard. Just as an example, I think
this
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].
[ZPWY^VAL^VERSION]
]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
Put the above lines into an Edit file, for this example, let us call
it
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
EMF is a TACL routine which needs the token definitions loaded in TACL
form, which is why the #LOAD commands are needed before running EMF.
I
believe this example filter did not need the EMS tokens, but they are
often
used in filters (when checking the event number, for example), so you
usually would need them. The ZSPIDEF subvolume might be on a
different disc
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS
Reference
manual. When starting, you probably can skip the beginning parts of
the
description and go directly to the subheading "Declarations" and read
on
from there. The examples ought to be enough to let you see how to
form
statements in a filter. If you find you need to do something that is
not
clear from the statement descriptions and examples, refer back to the
earlier part of chapter 5 for the more detailed description of that
point.
One point that sometimes gets confused is the difference between
EMSTEXTMATCH and MATCH. If you want to test the contents of a token
that
contains a string to see whether it matches a pattern, MATCH is what
to use.
EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give
some
attention to minimizing the statements that have to be executed. If
the
filter is short, this does not matter much, but if the filter gets to
be
large and complex, try to arrange it so that it tests the most likely
things
first.
You said you wanted to get the results from EMSDIST into a TACL
variable
and format them for a report. EMSDIST, at least when used as a
printing
distributor, already formats event for printing. If the normal output
from
EMSDIST is not in the form you want, you can supply your own
formatting
templates to use to format the events. That requires learning the
template
formatting language, which is described in the DSM Template Services
manual.
You must create a DDL dictionary from the token definition files
supplied
by HP before being able to compile formatting templates. The DDL
source
files that you need for this are in the same ZSPIDEFS subvolume as the
other
token definition files are. You must include the SPI and EMS token
definitions first, then those from the subsystems whose events you
want to
format. In some cases, a subsystem's token definitions might depend
on
another subsystem's token definitions. The first four characters of
the
name of an undefined reference will lead you to the file that defines
that
item.
To write a formatting template for an event, you must know what tokens
are included in the event. This is documented in a manual for the
product.
Often it contains the words Management Programming Manual in the title
of
the manual, but not always. Once you know the tokens in the event,
writing
the template to say how the event should be formatted is not very
difficult.
I cannot remember whether HP includes the source file for the
formatting
templates among the token definitions and other SPI files shipped with
the
product. If so, you might be able to adapt the templates supplied by
HP for
the subsystems whose events you want to print. That would be easier
than
writing the templates entirely on your own.
There is a way to override the part of the event formatting that
displays
the date, time, subsystem ID, etc. at the beginning of the line for
each
event. You can supply an empty formatting template to eliminate that
header
altogether, or you can supply a formatting template that formats just
what
you want. I don't find the template key used for that header
formatting
template in a quick look at the documentation. If you need that, I'm
sure
we can find it.
You get EMSDIST to use your custom formatting templates by naming the
file containing them in the =_EMS_TEMPLATES DEFINE before running
EMSDIST.
That will not affect the formatting done by other places in your
system.
If having EMSDIST produce the report is not suitable, then you could
either take the formatted messages that EMSDIST produces, process
them, and
produce a report in whatever format you prefer, or you could use
EMSDIST as
a consumer distributor, which returns the event messages in SPI
tokenized
for to your program (which could be a TACL program or one in C or
TAL),
which would then extract information from the events and produce the
report
you need.
Getting the report from EMSDIST into your TACL code is not as simple
as
using OUTV in the EMSDIST command, since EMSDIST does not write its
report
to its OUT file. The TEXTOUT parameter to the EMSDIST command can
specify a
disk file or a process. Writing to a disk file and then reading that
file
from TACL probably is the simplest way to take. I do not know what
types of
disk files are acceptable, and the manual seems not to list them. It
does
say that if the file does not exist, EMSDIST will create an entry-
sequenced
file with 80-character records, so entry-sequenced files must be
acceptable.
I imagine it would accept longer records, but whether it uses the full
record length, I don't know.
It might be possible to specify your own TACL process name or that of
another TACL process as the TEXTOUT file and use #SERVER to read the
formatted lines as EMSDIST writes them. I cannot say whether that
will
work. If you try to send the lines to your own TACL process, you
certainly
would have to use NOWAIT on the EMSDIST command. I don't know what
else
might be necessary. The process would not have to be written in TACL
-- it
could be written in C, COBOL, TAL, or pTAL, or any other language that
can
read from $RECEIVE.
Using the consumer distributor approach probably is formally the
better
approach if you cannot use a report produced by EMSDIST as the final
result,
but it takes more work. You must learn how to send SPI commands to
EMSDIST
to retrieve events and write the per-event
...
read more »- Hide quoted text -
- Show quoted text -
HI Keith,
I need to use the MATCH for ems text but unfortunately its not working
as expected. Any ideas why is it so ?
--Prasad
Hi Prasad,
Without seeing the filter code you are using, it is very hard to guess
at
the problem. It could be that you misunderstand how to use MATCH, or
that
you misunderstand what is the contents of the token whose value you
are
testing with MATCH, or something else.
Could you send me the whole filter, or at least a few lines of it that
contain the MATCH function? Also, could you send me the formatted
message
for an event you expected MATCH to be true but it was not? Maybe that
will
give me a better idea of what the problem is.
If you are unsure of the contents of the tokens in an event, even
after
studying the description of the tokens in the event given in the
Management
Programming Manual for the product that produces the event, you can
use the
DUMP ON option to get EMSDIST to display the individual tokens and
values
from the event. Use the TIME and STOP options on EMSDIST at the same
time
to limit the events selected to just the time of the event whose
contents
you want to see so that it does not produce an extremely large output.
If you have programmed an event-processing program using a consumer
distributor and the filter is passing events that you believe should
not
specify
TYPE EMS or TYPE EMS-NUM in the DISPLAY command. This is described in
the
Inspect manual. This formatted dump is also available in Visual
Inspect,
but I do not know the details of how to request it. It is not
available in
Native Inspect. It might be available in TACL, but I think not.
I do not remember any debugging options available to help see how a
filter
is being interpreted. I think none were implemented, so we can only
look at
the statements of the filter and the contents of an event to try to
figure
out why the filter is not working as expected.
- Keith
Hi Keith,
I tried according to your suggestions but it didnt work. below is the
dump of one of the multibatch ems event
**** Next Event ****
Header_type: %H1
Checksum: F
Last_error: token_not_found (%HFFF8)
Last_error_tkncode: (%H3,%H4,%HFDE6) Ldev-
Number
Max_field_version: 0
SSID: MULTIBAT.1.0
Used_byte_length: %H1E6
Buffer_byte_length: %H1E6
Console-Print: F
Generating-CPU: %H8
Emphasis: F
Event-Number: (%H3)
Standard-defined-type: not-specified (%H0)
User-defined-type: undefined (%H0)
Event-Hdr-Version: %H2
ZEMS-TKN-FORWARDED: F
Generation-Timestamp: 2011-02-26 00:00:02.858.835
Logged-Timestamp: 2011-02-26 00:00:02.859.038
Node-Name: "\NODENAME"
Node-Number: %H4
Generating-PIN: %H2E6
Process-Descriptor: "\NODENAME.$ABCD:145825521"
ZEMS-TKN-REDUNDANT: F
Suppress-Display: F
Userid: %H3F %HFE
Subject-Mark:*
(%H1,%H18,%H1): "G112.AA.01.* "
Manager: \NODENAME.$ABCD
TANDEM.EMS.0 Text: "G112.AA.01.*, started by
operator"
": [ $A123 , 10, Critical-
N, (063"
",254), \NODENAME.
$SYSTEM.SYSTEM.TAC"
"L ,
000000001316606705 ]., "
"\NODENAME.$A1MC 26/02/11,
00:00 "
" "
" "
" "
TANDEM.EMS.0 Action-Needed: T
TANDEM.EMS.0 Action-ID:- %H1

It could be that this event does not pass the filter because the MATCH function in the filter as you showed it earlier used "*G110*" as the template, but this event's text contains G112. That will not match "*G110*", and I do not see anything else in the text token's value that will match "*G110*"

Assuming you made the change in the filter to qualify the zems^tkn^text token with the EMS subsystem ID, then if you make the match template be "*G112*" or maybe "*G11*", I think you would find that it will pass this event. If you already have changed the filter so that the match template should match the G112 that appears in this event, then check to be sure you are initializing the EMS subsystem ID variable correctly. Also make sure that you are using the most recently compiled filter object file as the parameter in your EMSDIST command.

If none of those guesses leads to the solution to the problem, please post the filter program as you now have it and the commands used to set up and compile the filter.

[Prasad]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement.  Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do.  It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM  PATHWAY   *
This is a fixed-column format: the items start in columns 1, 10, and 20.  (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.)  Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command.  Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual.  When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there.  The examples ought to be enough to let you see how to form statements in a filter.  If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH.  If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use.  EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed.  If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report.  EMSDIST, at least when used as a printing distributor, already formats event for printing.  If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events.  That requires learning the template formatting language, which is described in the DSM Template Services manual.  
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates.  The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are.  You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format.  In some cases, a subsystem's token definitions might depend on another subsystem's token definitions.  The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event.  This is documented in a manual for the product.  Often it contains the words Management Programming Manual in the title of the manual, but not always.  Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult.  I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product.  If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print.  That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event.  You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want.  I don't find the template key used for that header formatting template in a quick look at the documentation.  If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST.  That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file.  The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process.  Writing to a disk file and then reading that file from TACL probably is the simplest way to take.  I do not know what types of disk files are acceptable, and the manual seems not to list them.  It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable.  I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them.  I cannot say whether that will work.  If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command.  I don't know what else might be necessary.  The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the

...
read more »- Hide quoted text -
- Show quoted text -

[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]

[#DEF mbat^val^ssid STRUCT
BEGIN SSID x VALUE MULTIBAT.1.0; END;]

FILTER FILT^TEST;
BEGIN
SSID(zems^val^ssid)

IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
PASS
ELSE
FAIL;
END;
END;

I event tried MATCH (SSID(ZEMS^VAL^SSID,ZEMS^TKN^TEXT),"*G110*")) THEN


This is the filter code I am using. I want the events with the text
matching G110. the ems dump I posted earlier was a generic message I
get for a multibatch event we will get a similar message for G110.
This code still isnt working as expected.

[Keith Dick]

Post by Prasad

Post by Keith Dick

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement. Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do. It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM PATHWAY *
This is a fixed-column format: the items start in columns 1, 10, and 20. (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.) Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command. Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual. When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there. The examples ought to be enough to let you see how to form statements in a filter. If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH. If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use. EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed. If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report. EMSDIST, at least when used as a printing distributor, already formats event for printing. If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events. That requires learning the template formatting language, which is described in the DSM Template Services manual.
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates. The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are. You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format. In some cases, a subsystem's token definitions might depend on another subsystem's token definitions. The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event. This is documented in a manual for the product. Often it contains the words Management Programming Manual in the title of the manual, but not always. Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult. I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product. If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print. That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event. You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want. I don't find the template key used for that header formatting template in a quick look at the documentation. If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST. That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file. The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process. Writing to a disk file and then reading that file from TACL probably is the simplest way to take. I do not know what types of disk files are acceptable, and the manual seems not to list them. It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable. I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them. I cannot say whether that will work. If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command. I don't know what else might be necessary. The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the

...
read more »- Hide quoted text -
- Show quoted text -

[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]
[#DEF mbat^val^ssid STRUCT
BEGIN SSID x VALUE MULTIBAT.1.0; END;]
FILTER FILT^TEST;
BEGIN
SSID(zems^val^ssid)
IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
PASS
ELSE
FAIL;
END;
END;
I event tried MATCH (SSID(ZEMS^VAL^SSID,ZEMS^TKN^TEXT),"*G110*")) THEN
This is the filter code I am using. I want the events with the text
matching G110. the ems dump I posted earlier was a generic message I
get for a multibatch event we will get a similar message for G110.
This code still isnt working as expected.

Did you include the line:

[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]

that I showed you in one of the emails I sent when you used the SSID qualification in the MATCH? That is critical. If you do not properly set up the value of ZEMS^VAL^SSID, the SSID qualification will not work.

The unqualfified reference to ZEMS^TKN^TEXT will never work for looking at the text token in a MULTIBAT event. You MUST qualify it by the EMS subsystem ID.

If you did set up the value for ZEMS^VAL^SSID correctly and qualified the reference to ZEMS^TKN^TEXT and the filter still did not pass MULTIBAT events that contain G110 in the text token, then we will have to look elsewhere for what is going wrong. The way you initialize the mbat^val^ssid value in your filter is not the way documented in the manuals. I do not know whether the SSID qualification will work properly when you do it that way. If fixing what I mentioned above does not solve the problem, check to see whether the first test in your filter is correctly passing MULTIBAT events. You can do that by temporarily removing the MATCH entirely to see whether just selecting all MULTIBAT events works. If that does not work, set up the MULTIBAT subsystem ID value the documented way to see whether that makes a difference.

[Prasad]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement.  Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do.  It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM  PATHWAY   *
This is a fixed-column format: the items start in columns 1, 10, and 20.  (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.)  Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command.  Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual.  When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there.  The examples ought to be enough to let you see how to form statements in a filter.  If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH.  If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use.  EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed.  If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report.  EMSDIST, at least when used as a printing distributor, already formats event for printing.  If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events.  That requires learning the template formatting language, which is described in the DSM Template Services manual.  
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates.  The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are.  You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format.  In some cases, a subsystem's token definitions might depend on another subsystem's token definitions.  The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event.  This is documented in a manual for the product.  Often it contains the words Management Programming Manual in the title of the manual, but not always.  Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult.  I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product.  If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print.  That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event.  You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want.  I don't find the template key used for that header formatting template in a quick look at the documentation.  If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST.  That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file.  The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process.  Writing to a disk file and then reading that file from TACL probably is the simplest way to take.  I do not know what types of disk files are acceptable, and the manual seems not to list them.  It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable.  I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them.  I cannot say whether that will work.  If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command.  I don't know what else might be necessary.  The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the

...
read more �- Hide quoted text -
- Show quoted text -

 [#PUSH DUMMY]
 [#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
 [#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
 [#POP DUMMY]
 [#DEF mbat^val^ssid STRUCT
    BEGIN SSID x VALUE MULTIBAT.1.0; END;]
 FILTER FILT^TEST;
 BEGIN
      SSID(zems^val^ssid)
      IF  (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
            MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
          PASS
       ELSE
          FAIL;
      END;
 END;
I event tried MATCH (SSID(ZEMS^VAL^SSID,ZEMS^TKN^TEXT),"*G110*")) THEN
This is the filter code I am using. I want the events with the text
matching G110. the ems dump I posted earlier was a generic message I
get for a multibatch event we will get a similar message for G110.
This code still isnt working as expected.

   [#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
that I showed you in one of the emails I sent when you used the SSID qualification in the MATCH?  That is critical.  If you do not properly set up the value of ZEMS^VAL^SSID, the SSID qualification will not work.
The unqualfified reference to ZEMS^TKN^TEXT will never work for looking at the text token in a MULTIBAT event.  You MUST qualify it by the EMS subsystem ID.  
If you did set up the value for ZEMS^VAL^SSID correctly and qualified the reference to ZEMS^TKN^TEXT and the filter still did not pass MULTIBAT events that contain G110 in the text token, then we will have to look elsewhere for what is going wrong.  The way you initialize the mbat^val^ssid value in your filter is not the way documented in the manuals.  I do not know whether the SSID qualification will work properly when you do it that way.  If fixing what I mentioned above does not solve the problem, check to see whether the first test in your filter is correctly passing MULTIBAT events.  You can do that by temporarily removing the MATCH entirely to see whether just selecting all MULTIBAT events works.  If that does not work, set up the MULTIBAT subsystem ID value the documented way to see whether that makes a difference.

Thanks a ton Keith,
This worked... you are a Star. !!!!

[Keith Dick]

Post by Prasad

Post by Keith Dick

Post by Prasad

Post by Keith Dick

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement. Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do. It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM PATHWAY *
This is a fixed-column format: the items start in columns 1, 10, and 20. (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.) Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command. Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual. When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there. The examples ought to be enough to let you see how to form statements in a filter. If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH. If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use. EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed. If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report. EMSDIST, at least when used as a printing distributor, already formats event for printing. If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events. That requires learning the template formatting language, which is described in the DSM Template Services manual.
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates. The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are. You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format. In some cases, a subsystem's token definitions might depend on another subsystem's token definitions. The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event. This is documented in a manual for the product. Often it contains the words Management Programming Manual in the title of the manual, but not always. Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult. I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product. If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print. That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event. You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want. I don't find the template key used for that header formatting template in a quick look at the documentation. If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST. That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file. The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process. Writing to a disk file and then reading that file from TACL probably is the simplest way to take. I do not know what types of disk files are acceptable, and the manual seems not to list them. It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable. I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them. I cannot say whether that will work. If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command. I don't know what else might be necessary. The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the

...
read more �- Hide quoted text -
- Show quoted text -

[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]
[#DEF mbat^val^ssid STRUCT
BEGIN SSID x VALUE MULTIBAT.1.0; END;]
FILTER FILT^TEST;
BEGIN
SSID(zems^val^ssid)
IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
PASS
ELSE
FAIL;
END;
END;
I event tried MATCH (SSID(ZEMS^VAL^SSID,ZEMS^TKN^TEXT),"*G110*")) THEN
This is the filter code I am using. I want the events with the text
matching G110. the ems dump I posted earlier was a generic message I
get for a multibatch event we will get a similar message for G110.
This code still isnt working as expected.

[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
that I showed you in one of the emails I sent when you used the SSID qualification in the MATCH? That is critical. If you do not properly set up the value of ZEMS^VAL^SSID, the SSID qualification will not work.
The unqualfified reference to ZEMS^TKN^TEXT will never work for looking at the text token in a MULTIBAT event. You MUST qualify it by the EMS subsystem ID.
If you did set up the value for ZEMS^VAL^SSID correctly and qualified the reference to ZEMS^TKN^TEXT and the filter still did not pass MULTIBAT events that contain G110 in the text token, then we will have to look elsewhere for what is going wrong. The way you initialize the mbat^val^ssid value in your filter is not the way documented in the manuals. I do not know whether the SSID qualification will work properly when you do it that way. If fixing what I mentioned above does not solve the problem, check to see whether the first test in your filter is correctly passing MULTIBAT events. You can do that by temporarily removing the MATCH entirely to see whether just selecting all MULTIBAT events works. If that does not work, set up the MULTIBAT subsystem ID value the documented way to see whether that makes a difference.

Thanks a ton Keith,
This worked... you are a Star. !!!!

You are welcome. Was the problem missing initialization of ZEMS^VAL^SSID or the somewhat unusual initialization of mbat^val^ssid?

I believe I do not have access to MULTIBAT documentation. If they describe their events well, check to see whether you can make your MATCH test the value of their subject token. In the one example you showed, it seems that what you want to test for is in the subject token. Since the subject token is a lot shorter than the text token, there would be less overhead if you could do your MATCH with the shorter token. I do not know whether the reduction in overhead would be significant. That depends on how efficiently the MATCH function is implemented, and I have no idea how well it was done.

I can see that the token definitions for MULTIBAT are not properly installed into your system, since the event dump could not find the symbolic name for that subject token. I do not know whether that is because your system manager just did not install them or because MULTIBAT does not supply them. If the latter, then you would not be able to write a filter that referenced that token (unless you made up token definitions of your own that match what MULTIBAT is using).

[wbreidbach]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement.  Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do.  It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM  PATHWAY   *
This is a fixed-column format: the items start in columns 1, 10, and 20.  (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.)  Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command.  Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual.  When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there.  The examples ought to be enough to let you see how to form statements in a filter.  If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH.  If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use.  EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed.  If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report.  EMSDIST, at least when used as a printing distributor, already formats event for printing.  If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events.  That requires learning the template formatting language, which is described in the DSM Template Services manual.  
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates.  The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are.  You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format.  In some cases, a subsystem's token definitions might depend on another subsystem's token definitions.  The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event.  This is documented in a manual for the product.  Often it contains the words Management Programming Manual in the title of the manual, but not always.  Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult.  I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product.  If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print.  That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event.  You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want.  I don't find the template key used for that header formatting template in a quick look at the documentation.  If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST.  That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file.  The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process.  Writing to a disk file and then reading that file from TACL probably is the simplest way to take.  I do not know what types of disk files are acceptable, and the manual seems not to list them.  It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable.  I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT

...
Erfahren Sie mehr »- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

The thread is looking a bit strange, where are the posts?

[Prasad]

Post by Prasad

Post by Prasad

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement.  Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do.  It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM  PATHWAY   *
This is a fixed-column format: the items start in columns 1, 10, and 20.  (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.)  Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command.  Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual.  When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there.  The examples ought to be enough to let you see how to form statements in a filter.  If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH.  If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use.  EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed.  If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report.  EMSDIST, at least when used as a printing distributor, already formats event for printing.  If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events.  That requires learning the template formatting language, which is described in the DSM Template Services manual.  
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates.  The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are.  You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format.  In some cases, a subsystem's token definitions might depend on another subsystem's token definitions.  The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event.  This is documented in a manual for the product.  Often it contains the words Management Programming Manual in the title of the manual, but not always.  Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult.  I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product.  If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print.  That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event.  You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want.  I don't find the template key used for that header formatting template in a quick look at the documentation.  If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST.  That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file.  The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process.  Writing to a disk file and then reading that file from TACL probably is the simplest way to take.  I do not know what types of disk files are acceptable, and the manual seems not to list them.  It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable.  I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them.  I cannot say whether that will work.  If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command.  I don't know what else might be necessary.  The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the

...
read more - Hide quoted text -
- Show quoted text -

[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]
[#DEF mbat^val^ssid STRUCT
   BEGIN SSID x VALUE MULTIBAT.1.0; END;]
FILTER FILT^TEST;
BEGIN
     SSID(zems^val^ssid)
     IF  (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
           MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
         PASS
      ELSE
         FAIL;
     END;
END;
I event tried MATCH (SSID(ZEMS^VAL^SSID,ZEMS^TKN^TEXT),"*G110*")) THEN
This is the filter code I am using. I want the events with the text
matching G110. the ems dump I posted earlier was a generic message I
get for a multibatch event we will get a similar message for G110.
This code still isnt working as expected.

  [#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
that I showed you in one of the emails I sent when you used the SSID qualification in the MATCH?  That is critical.  If you do not properly set up the value of ZEMS^VAL^SSID, the SSID qualification will not work.
The unqualfified reference to ZEMS^TKN^TEXT will never work for looking at the text token in a MULTIBAT event.  You MUST qualify it by the EMS subsystem ID.  
If you did set up the value for ZEMS^VAL^SSID correctly and qualified the reference to ZEMS^TKN^TEXT and the filter still did not pass MULTIBAT events that contain G110 in the text token, then we will have to look elsewhere for what is going wrong.  The way you initialize the mbat^val^ssid value in your filter is not the way documented in the manuals.  I do not know whether the SSID qualification will work properly when you do it that way.  If fixing what I mentioned above does not solve the problem, check to see whether the first test in your filter is correctly passing MULTIBAT events.  You can do that by temporarily removing the MATCH entirely to see whether just selecting all MULTIBAT events works.  If that does not work, set up the MULTIBAT subsystem ID value the documented way to see whether that makes a difference.

Thanks a ton Keith,
This worked... you are a  Star. !!!!

You are welcome.  Was the problem missing initialization of ZEMS^VAL^SSID or the somewhat unusual initialization of mbat^val^ssid?
I believe I do not have access to MULTIBAT documentation.  If they describe their events well, check to see whether you can make your MATCH test the value of their subject token.  In the one example you showed, it seems that what you want to test for is in the subject token.  Since the subject token is a lot shorter than the text token, there would be less overhead if you could do your MATCH with the shorter token.  I do not know whether the reduction in overhead would be significant.  That depends on how efficiently the MATCH function is implemented, and I have no idea how well it was done.
I can see that the token definitions for MULTIBAT are not properly installed into your system, since the event dump could not find the symbolic name for that subject token.  I do not know whether that is because your system manager just did not install them or because MULTIBAT does not supply them.  If the latter, then you would not be able to write a filter that referenced that token (unless you made up token definitions of your own that match what MULTIBAT is using).

I reckon the problem was the initialisation of the ZEMS^VAL^SSID.
now the filter code looks like below. I added the #set ZEMS^VAL^SSID
line and it worked.

[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]

[#DEF mbat^val^ssid STRUCT
BEGIN SSID x VALUE MULTIBAT.1.0; END;]

FILTER FILT^TEST;
BEGIN
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].
[ZEMS^VAL^VERSION]]
SSID(zems^val^ssid)

IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
PASS
ELSE
FAIL;

END;

[Keith Dick]

Post by Prasad

Post by Keith Dick

Post by Prasad

Post by Keith Dick

Post by Prasad

Post by Keith Dick

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement. Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do. It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM PATHWAY *
This is a fixed-column format: the items start in columns 1, 10, and 20. (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.) Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command. Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual. When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there. The examples ought to be enough to let you see how to form statements in a filter. If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH. If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use. EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed. If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report. EMSDIST, at least when used as a printing distributor, already formats event for printing. If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events. That requires learning the template formatting language, which is described in the DSM Template Services manual.
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates. The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are. You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format. In some cases, a subsystem's token definitions might depend on another subsystem's token definitions. The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event. This is documented in a manual for the product. Often it contains the words Management Programming Manual in the title of the manual, but not always. Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult. I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product. If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print. That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event. You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want. I don't find the template key used for that header formatting template in a quick look at the documentation. If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST. That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file. The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process. Writing to a disk file and then reading that file from TACL probably is the simplest way to take. I do not know what types of disk files are acceptable, and the manual seems not to list them. It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable. I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them. I cannot say whether that will work. If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command. I don't know what else might be necessary. The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the

...
read more - Hide quoted text -
- Show quoted text -

[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]
[#DEF mbat^val^ssid STRUCT
BEGIN SSID x VALUE MULTIBAT.1.0; END;]
FILTER FILT^TEST;
BEGIN
SSID(zems^val^ssid)
IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
PASS
ELSE
FAIL;
END;
END;
I event tried MATCH (SSID(ZEMS^VAL^SSID,ZEMS^TKN^TEXT),"*G110*")) THEN
This is the filter code I am using. I want the events with the text
matching G110. the ems dump I posted earlier was a generic message I
get for a multibatch event we will get a similar message for G110.
This code still isnt working as expected.

[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].[ZEMS^VAL^VERSION]]
that I showed you in one of the emails I sent when you used the SSID qualification in the MATCH? That is critical. If you do not properly set up the value of ZEMS^VAL^SSID, the SSID qualification will not work.
The unqualfified reference to ZEMS^TKN^TEXT will never work for looking at the text token in a MULTIBAT event. You MUST qualify it by the EMS subsystem ID.
If you did set up the value for ZEMS^VAL^SSID correctly and qualified the reference to ZEMS^TKN^TEXT and the filter still did not pass MULTIBAT events that contain G110 in the text token, then we will have to look elsewhere for what is going wrong. The way you initialize the mbat^val^ssid value in your filter is not the way documented in the manuals. I do not know whether the SSID qualification will work properly when you do it that way. If fixing what I mentioned above does not solve the problem, check to see whether the first test in your filter is correctly passing MULTIBAT events. You can do that by temporarily removing the MATCH entirely to see whether just selecting all MULTIBAT events works. If that does not work, set up the MULTIBAT subsystem ID value the documented way to see whether that makes a difference.

Thanks a ton Keith,
This worked... you are a Star. !!!!

You are welcome. Was the problem missing initialization of ZEMS^VAL^SSID or the somewhat unusual initialization of mbat^val^ssid?
I believe I do not have access to MULTIBAT documentation. If they describe their events well, check to see whether you can make your MATCH test the value of their subject token. In the one example you showed, it seems that what you want to test for is in the subject token. Since the subject token is a lot shorter than the text token, there would be less overhead if you could do your MATCH with the shorter token. I do not know whether the reduction in overhead would be significant. That depends on how efficiently the MATCH function is implemented, and I have no idea how well it was done.
I can see that the token definitions for MULTIBAT are not properly installed into your system, since the event dump could not find the symbolic name for that subject token. I do not know whether that is because your system manager just did not install them or because MULTIBAT does not supply them. If the latter, then you would not be able to write a filter that referenced that token (unless you made up token definitions of your own that match what MULTIBAT is using).

I reckon the problem was the initialisation of the ZEMS^VAL^SSID.
now the filter code looks like below. I added the #set ZEMS^VAL^SSID
line and it worked.
[#PUSH DUMMY]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZSPITACL]
[#LOAD /KEEP 1, LOADED DUMMY/$SYSTEM.ZSPIDEF.ZEMSTACL]
[#POP DUMMY]
[#DEF mbat^val^ssid STRUCT
BEGIN SSID x VALUE MULTIBAT.1.0; END;]
FILTER FILT^TEST;
BEGIN
[#SET ZEMS^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZEMS].
[ZEMS^VAL^VERSION]]
SSID(zems^val^ssid)
IF (zspi^tkn^ssid = SSID(mbat^val^ssid) AND
MATCH (ZEMS^TKN^TEXT,"*G110*")) THEN
PASS
ELSE
FAIL;
END;

Thanks for explaining what change made the filter start working. We often do not find out which advice solved a problem.

I must apologize for missing the SSID qualifier you included immediately following the BEGIN. I see it was there when you posted the filter source earlier, and I overlooked it when considering your problem and posting my reply.

While this filter does work for you now, the technique of using the SSID following the BEGIN is a bad practice that could cause problems for you in other situations.

What that does is cause every token reference within the BEGIN END pair that is not explicitly qualified using SSID to be implicitly qualified by the SSID given after the BEGIN. This would cause an unexpected result if you, for example, modified this filter to test the value of some token defined by MULTIBAT, since the token would be qualified by the EMS subsystem ID and would not be found in the event message (unless you explicitly qualified that reference with the MULTIBAT SSID).

In this filter, the reference to zspi^tkn^ssid works because certain tokens are what are called shared tokens, and the SSID used to qualify them is ignored. Most header tokens are like that. Tokens defined by individual products are not shared tokens.

The intended use for SSID following a BEGIN is when the default SSID for tokens in the event changes when a token list is entered. A token list that changes default SSID is not very common, I think, so I will not describe its use in detail here.

The best way to write this filter would be to remove the SSID following the BEGIN and change the MATCH to be:

MATCH(SSID(zems^val^ssid,zems^tkn^text),"*G110*")

One other thing about your filter is more a matter of style than of proper functioning. It would be best to put the #SET for initializing ZEMS^VAL^SSID before the FILTER line, with the other TACL statements. All of the embedded TACL statements are executed before compilation of the filter statements begins, so their placement makes no difference to operation of the filter compiler, but for readability, I think putting them all before the start of the filter statements is better.

[Pramod Suryawanshi]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

This is a good point: We are not certain that we know the actual requirement. Sometimes what happens is that the person posting the question has progressed part way on what he thinks is the best approach to solving the problem, then posts with a question about something with that approach that he does not know how to do. It might be that there is a much better or easier approach to satisfying the original request that has been overlooked.
?PASS
TANDEM PATHWAY *
This is a fixed-column format: the items start in columns 1, 10, and 20. (There also is a pass value that starts in column 40, but that is not of any interest for a printing distributor.) Put those two lines into an Edit file and specify it as the FILTER parameter in an EMSDIST command. Look in chapter 6 for the other things a filter table can do.
[#SET ZPWY^VAL^SSID [ZSPI^VAL^TANDEM].[ZSPI^SSN^ZPWY].[ZPWY^VAL^VERSION] ]
FILTER pass_pathway;
BEGIN
IF ZSPI^TKN^SSID = SSID ( ZPWY^VAL^SSID ) THEN PASS;
FAIL;
END;
#PUSH dummy
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZSPITACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZEMSTACL
#LOAD /KEEP 1, LOADED dummy/ $SYSTEM.ZSPIDEF.ZPWYTACL
#POP dummy
EMF/IN GETPATH/ OGETPATH
Then specify OGETPATH as the FILTER in an EMSDIST command.
FILEINFO $*.ZSPIDEF.ZSPITACL
should find where it is if it is not on $SYSTEM.
The full filter language is described in chapter 5 of the EMS Reference manual. When starting, you probably can skip the beginning parts of the description and go directly to the subheading "Declarations" and read on from there. The examples ought to be enough to let you see how to form statements in a filter. If you find you need to do something that is not clear from the statement descriptions and examples, refer back to the earlier part of chapter 5 for the more detailed description of that point.
One point that sometimes gets confused is the difference between EMSTEXTMATCH and MATCH. If you want to test the contents of a token that contains a string to see whether it matches a pattern, MATCH is what to use. EMSTEXTMATCH is for something different.
The EMS filter is executed in an interpreter inside EMSDIST, so give some attention to minimizing the statements that have to be executed. If the filter is short, this does not matter much, but if the filter gets to be large and complex, try to arrange it so that it tests the most likely things first.
You said you wanted to get the results from EMSDIST into a TACL variable and format them for a report. EMSDIST, at least when used as a printing distributor, already formats event for printing. If the normal output from EMSDIST is not in the form you want, you can supply your own formatting templates to use to format the events. That requires learning the template formatting language, which is described in the DSM Template Services manual.
You must create a DDL dictionary from the token definition files supplied by HP before being able to compile formatting templates. The DDL source files that you need for this are in the same ZSPIDEFS subvolume as the other token definition files are. You must include the SPI and EMS token definitions first, then those from the subsystems whose events you want to format. In some cases, a subsystem's token definitions might depend on another subsystem's token definitions. The first four characters of the name of an undefined reference will lead you to the file that defines that item.
To write a formatting template for an event, you must know what tokens are included in the event. This is documented in a manual for the product. Often it contains the words Management Programming Manual in the title of the manual, but not always. Once you know the tokens in the event, writing the template to say how the event should be formatted is not very difficult. I cannot remember whether HP includes the source file for the formatting templates among the token definitions and other SPI files shipped with the product. If so, you might be able to adapt the templates supplied by HP for the subsystems whose events you want to print. That would be easier than writing the templates entirely on your own.
There is a way to override the part of the event formatting that displays the date, time, subsystem ID, etc. at the beginning of the line for each event. You can supply an empty formatting template to eliminate that header altogether, or you can supply a formatting template that formats just what you want. I don't find the template key used for that header formatting template in a quick look at the documentation. If you need that, I'm sure we can find it.
You get EMSDIST to use your custom formatting templates by naming the file containing them in the =_EMS_TEMPLATES DEFINE before running EMSDIST. That will not affect the formatting done by other places in your system.
If having EMSDIST produce the report is not suitable, then you could either take the formatted messages that EMSDIST produces, process them, and produce a report in whatever format you prefer, or you could use EMSDIST as a consumer distributor, which returns the event messages in SPI tokenized for to your program (which could be a TACL program or one in C or TAL), which would then extract information from the events and produce the report you need.
Getting the report from EMSDIST into your TACL code is not as simple as using OUTV in the EMSDIST command, since EMSDIST does not write its report to its OUT file. The TEXTOUT parameter to the EMSDIST command can specify a disk file or a process. Writing to a disk file and then reading that file from TACL probably is the simplest way to take. I do not know what types of disk files are acceptable, and the manual seems not to list them. It does say that if the file does not exist, EMSDIST will create an entry-sequenced file with 80-character records, so entry-sequenced files must be acceptable. I imagine it would accept longer records, but whether it uses the full record length, I don't know.
It might be possible to specify your own TACL process name or that of another TACL process as the TEXTOUT file and use #SERVER to read the formatted lines as EMSDIST writes them. I cannot say whether that will work. If you try to send the lines to your own TACL process, you certainly would have to use NOWAIT on the EMSDIST command. I don't know what else might be necessary. The process would not have to be written in TACL -- it could be written in C, COBOL, TAL, or pTAL, or any other language that can read from $RECEIVE.
Using the consumer distributor approach probably is formally the better approach if you cannot use a report produced by EMSDIST as the final result, but it takes more work. You must learn how to send SPI commands to EMSDIST to retrieve events and write the per-event code using the SPI procedures to extract the items you need from each event. If you already know SPI programming, it would be easy to apply that knowledge to this problem (all SPI programming is pretty much the same), but if you are starting from no SPI programming knowledge, this approach probably is a lot more effort than the others.
Now, if the requirement is not to produce some report in TACL, but could be met by having an easy way to browse the event log, look at Web ViewPoint from HP. I do not know all of what it can do, so I will not try to describe it, but it might provide what you need better than the reports you seem to be planning to produce. It might not be suitable, but until you learn about it, you will not know whether it would be better.
Also, if you have the iTP Webserver installed, its management application (which is accessed via a web browser) includes an event browser. I do not know all of its capabilities, either, but I know you can make filter tables from within the event browser, it can use EMS compiled filters, and it can select events by matching on a text template. Once you have selected the events of interest, I do not know whether you can print them or do anything else besides look at them, but check into its capabilities if you have iTP Webserver.
Randall and Wolfgang mentioned still other ways that might be good, depending on the underlying requirements.

Hi Keith,
I learned emf filter from your reply. Thanks alot.

I would appreciate your help on below question-
Is there a way to get the ems stats (number of particular event in specific timeframe) based on ssid and/or event number.

Example -
SSID : TANDEM.EMS.01, Event Number : 512, Occurred X number of times between timeframe dd-mm hh:min to dd-mm hh:min

[Keith Dick]

Post by Prasad
Hi Keith,
I learned emf filter from your reply. Thanks alot.
I would appreciate your help on below question-
Is there a way to get the ems stats (number of particular event in specific timeframe) based on ssid and/or event number.
Example -
SSID : TANDEM.EMS.01, Event Number : 512, Occurred X number of times between timeframe dd-mm hh:min to dd-mm hh:min

I do not recall any built-in feature of EMS or other NonStop system tools that would give you such a summary of the EMS events. The only way I know to get such a summary would be to write a program that uses a Consumer Distributor to fetch the events between the desired start and end times, fetch the SSID from the event, add 1 to a table entry for that SSID, and at the end, print the summary report from the table.

I suppose you could do about the same thing using a printing distributor: Send the output of the printing distributor to a named process. Read the event text from that program's $RECEIVE, recognize the first line of each event, pull out the SSID, and do the counting as with the other program. It would be a little harder to know when there were no more events to come.

Someone probably has written such a program, but I don't recall ever hearing of one. Maybe someone else who reads your post will know of an existing program that does such a summary report.

[Randall]

Post by Prasad
Hi Keith,
I learned emf filter from your reply. Thanks alot.
I would appreciate your help on below question-
Is there a way to get the ems stats (number of particular event in specific timeframe) based on ssid and/or event number.
Example -
SSID : TANDEM.EMS.01, Event Number : 512, Occurred X number of times between timeframe dd-mm hh:min to dd-mm hh:min

I do not recall any built-in feature of EMS or other NonStop system tools that would give you such a summary of the EMS events. The only way I know to get such a summary would be to write a program that uses a Consumer Distributor to fetch the events between the desired start and end times, fetch the SSID from the event, add 1 to a table entry for that SSID, and at the end, print the summary report from the table.
I suppose you could do about the same thing using a printing distributor: Send the output of the printing distributor to a named process. Read the event text from that program's $RECEIVE, recognize the first line of each event, pull out the SSID, and do the counting as with the other program. It would be a little harder to know when there were no more events to come.
Someone probably has written such a program, but I don't recall ever hearing of one. Maybe someone else who reads your post will know of an existing program that does such a summary report.

I wrote one a while back but it was for a client, so I obviously can't share it even if I had the source, which I don't. The most efficient way to do this is to use the EMS SPI interface. Write a program that fetches events from a distributor - so your program starts a distributor as a server. Don't format the events, just retrieve them. EMSTEXT is expensive to call so don't except for debugging. Once that works, configure the distributor (through SPI) with an EMS Filter that specifies whatever you want. SSID, event number, node, whatever. The timeframe can also be specified to the distributor and you will get an end of data indication when you hit the stop time (unless the stop time is after the current time, then you have to wait until another event shows up for another subsystem). This is described in the EMS Manual and can be done from C, TAL, COBOL. I think the tdmext classes in Java have some provision for doing this also or you can go through JNI if Java is your thing.

[Rob Lesan]

Post by Randall

Post by Prasad
Hi Keith,
I learned emf filter from your reply. Thanks alot.
I would appreciate your help on below question-
Is there a way to get the ems stats (number of particular event in specific timeframe) based on ssid and/or event number.
Example -
SSID : TANDEM.EMS.01, Event Number : 512, Occurred X number of times between timeframe dd-mm hh:min to dd-mm hh:min

I do not recall any built-in feature of EMS or other NonStop system tools that would give you such a summary of the EMS events. The only way I know to get such a summary would be to write a program that uses a Consumer Distributor to fetch the events between the desired start and end times, fetch the SSID from the event, add 1 to a table entry for that SSID, and at the end, print the summary report from the table.
I suppose you could do about the same thing using a printing distributor: Send the output of the printing distributor to a named process. Read the event text from that program's $RECEIVE, recognize the first line of each event, pull out the SSID, and do the counting as with the other program. It would be a little harder to know when there were no more events to come.
Someone probably has written such a program, but I don't recall ever hearing of one. Maybe someone else who reads your post will know of an existing program that does such a summary report.

I wrote one a while back but it was for a client, so I obviously can't share it even if I had the source, which I don't. The most efficient way to do this is to use the EMS SPI interface. Write a program that fetches events from a distributor - so your program starts a distributor as a server. Don't format the events, just retrieve them. EMSTEXT is expensive to call so don't except for debugging. Once that works, configure the distributor (through SPI) with an EMS Filter that specifies whatever you want. SSID, event number, node, whatever. The timeframe can also be specified to the distributor and you will get an end of data indication when you hit the stop time (unless the stop time is after the current time, then you have to wait until another event shows up for another subsystem). This is described in the EMS Manual and can be done from C, TAL, COBOL. I think the tdmext classes in Java have some provision for doing this also or you can go through JNI if Java is your thing.

You can do this trivially if you have XYGATE Merged Audit (XMA) installed on your system. XMA is included with all NonStop systems.

If this is all you need, you can install a separate instance of XMA and have it collect messages from any EMS collectors you are interested in. Once the data is loaded, you can run SQL queries against it and get any data you need.

Reach out to me privately if you need any help getting XMA to work.

[Randall]

Post by wbreidbach

Post by Randall

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

(shameless plug)
There are other ways of processing EMS logs not on the NonStop. You
can pull events in real time out to workstations and process them
there using database tools. If interested, contact me.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -

We are processing the EMSLOG(s) with a home developed database-based
application. In addition we are using SNMP traps with EMSDIST. My
impression was that TACL had to be treated as a must.

There are other ways. You can read EMS events in real time off
platform without TACL, but that requires a software bridge, which we
use.

[ghr]

Post by wbreidbach

Post by wbreidbach

Post by Prasad
Hello All,
Please advice me how do read EMS logs pertaining to a specific filter
criteria in a TACL script.
Below is what I need to accomplish by doing so.
1) Need to browse theough the EMS logs  for specific criteria. lets
assume pathway subsys errors
2) save it ro a variable and the prepare a formatted report.
I just need to tweak. how do I get the ems logs into the Tacl variable.

The easiest way to do that is to create a specific filter for the
EMSDIST program.
If you can specify your criteria a filter can easily be created.
Wolfgang

Just to avoid misunderstandings: EMSDIST with TYPE PRINT provides a
formatted report.
Unfortunately the length of the output line is depending on the
destination device, for a process it would be 132 as default. You can
change that be running the process as a subtype 30 process and answer
the -106 message according to your needs.
The only chance to get the event message "in one piece" would be to
use a CONSUMER type distributor, I did that with a TAL program but
this might be difficult in TACL as you have to use the SPI
procedures.

An entry-sequenced file of record size n can be used to get the output
into a single line, as long as n > max length of the EMS messages. If
that is less than 239 chars then it can be put into an edit file and
uploaded to a Windows, Unix or Mac for manipulation.