StoreGazer Event File Definitions & Examples

The ID of the controller the message must occur on. This will typically be CC, since CC is the controller most actively monitored. If this parameter is left out of the rule definition, messages from all controllers that pass through the message pipe will be accepted. There are several wildcards that can be used in this field:

• AA – Check if the message was logged from the acting master.
• AB – Check if the message was logged from the acting alternate master.
• AC – Check if the message was logged from the acting file server.
• AD – Check if the message was logged from the acting alternate file server.

The message field can be used to provide one or more 4690 messages that the rule will monitor. If multiple messages are required, use a comma-delimited list.Each message can be preceded by an ‘X’ to indicate exclusion.The message field supports the ‘*’ and ‘?’ wildcard characters.

Example #1

In this example, we will check if a W100 message (Program Cannot be Loaded) occured. If so, we want to log the message and send an email.

[Rule = 1]
Message = W100
Action ID = 1, 2

As seen above, this is a very simple example. Now we will add another parameter. Consider that we only wish to log a W100 if the application program has been stopped because of a programming error. This is indicated by an event of 10 (from the 4690 Store System Messages Guide).

[Rule = 1]
Message = W100
Event = 10
Action ID = 1, 2

The above two examples have not defined the ‘NodeID’ parameter. Because of this, if a W100 occurs on either the master (CC) or alternate master (DD), the action will occur. If we only want to perform the action if this occurs on the master controller, we need to do the following:

[Rule = 1]
NodeID = CC
Message = W100
Event = 10
Action ID = 1, 2

Example #2

In this example, we want to check if any range of RCMS (Remote Change Management Server) errors occur on the master controller. These messages range from W818 to W822. We also will only want to only be notified if the severity is less than 3, since some of these messages have multiple severity levels. Keep in mind that the lower the severity value, the more severe the error.

[Rule = 2]
NodeID = CC
Message = W818, W819, W820, W821, W822
Severity = 3
Action ID = 1, 2

Example #3

In this example, we will consider the opposite case of example #2. We now want to log all messages on the master controller that have a severity less than three, but are not RCMS messages. For this case, we will use message exclusion.

[Rule = 3]
NodeID = CC
Message = XW818, XW819, XW820, XW821, XW822
Severity = 3
Action ID = 1

Example #4

In this example, we will log all messages in the ‘W4xx’ block (W400-W499).

[Rule = 4]
Message = W4*
Action ID = 1

Note that we also can accomplish this with:

[Rule = 4]
Message = W4??
Action ID = 1

The terminal number field of a system message. It can be used in two different ways

• If the ‘Max Terminal’ parameter is not used within this rule, the terminal in the system message must match this field.
• If this parameter is used along with the ‘Max Terminal’ parameter, it is used as a floor value to determine if the terminal field of the system message is within the limits of the ‘Terminal’ parameter and ‘Max Terminal’ parameter.

Example #1

In this example, we will assume that there is a terminal in the store that has recently been having problems receiving store loop communications. This specific terminal (555) often issues a W007 message before it fails. The following example will allow us to log a message when this occurs:

[Rule = 1]
Message = W007
Terminal = 555
Action ID = 1

Example #2

If there are multiple terminals within a specified range that are issuing W007 messages before they fail, we can use the ‘Max Terminal’ field along with the Terminal field to specify the range. It should be noted that if the Terminal field is removed from the following example, any terminal number less than or equal to 565 will perform the action when a W007 occurs (i.e. the floor of the limit is zero).

[Rule = 2]
Message = W007
Terminal = 555
Max Terminal = 565
Action ID = 1

This parameter can be used in multiple ways

• If the frequency is set to 0, this parameter is used in conjunction with the Start/Stop Time parameters. If no matching system messages occur within the provided Start/Stop times, the action(s) will be executed.

• If the frequency is greater than or equal to 1, it will be used along with the interval parameter. If the system message specified by this rule occurs a defined number of times (frequency) within a defined period of time (interval), the action will be executed.

(Note: If the frequency is set to less than 0, it is treated as if it equals 0. This ensures backwards compatibility.)

Example #1

This example will allow us to log a W650 message if it occurs three or more times in a five-minute period on the master controller.

[Rule = 1]
NodeID = CC
Message = W650
Frequency = 3
Interval = 5
Action ID = 1

Now consider that we want to check for the event above, but only if it occurs on a particular program. If the program EAMCS001 (checkout support, for instance) abnormally ends three times in a five-minute period on the master controller, we want to log it.

[Rule = 1]
NodeID = CC
Message = W650
Ascii Data = EAMCS001
Frequency = 3
Interval = 5
Action ID = 1

Example #2

This example will allow us to log a W650 message the first time it occurs. However, the message will not be logged again for another hour, regardless of the number of times the sytem event may occur.

[Rule = 2]
NodeID = CC
Message = W650
Frequency = 1
Interval = 60
Action ID = 1

Notes:

• In Example #1 above, if the ‘Interval’ parameter was removed, the action will be executed once every three times the event occurs, regardless of the delay in between messages.
• In a typical event rule definition, the action is executed each time the event occurs. In this case the frequency/interval parameters do not need to be defined.

The Start/Stop Time fields can be used to place time restrictions on rules or to set off timed events. The times can span midnight and are formatted for military time with no separators. Depending on the presence of the ‘Frequency’ and ‘Day’ parameters, the Start/Stop Time fields can be used in multiple ways.

• If the ‘Frequency’ parameter is non-existent or if it is greater than 0:
  

  If the specified event occurs between the provided Start and Stop times, the action will be performed. If it occurs outside of these boundaries, it will be ignored.

• If the ‘Frequency’ parameter is set to 0:
  

  If the specified event does not occur between the provided Start and Stop times, the action will automatically be performed as soon as the time expires. 

• If the ‘Day’ parameter is used:
  

  The ‘Day’ parameter can be used in conjunction with either of the above cases to specify a specific day of the week for the event to occur on, or to exclude a day of the week.

Example #1

In this example, we want to perform an action when a W945 (New Controller on LAN) message occurs, but only if it occurs on Monday.

[Rule = 1]
Message = W945
Day = Mon
Action ID = 1

Next, we will add a start and stop time interval to make this rule even more specific. We now only want to perform the action if it occurs on Monday between 5:00am and 3:30pm.

[Rule = 1]
Message = W945
Day = Mon
Start Time = 0500
Stop Time = 1530
Action ID = 1

Finally, we will place one more filter on this rule so that it is ignored on the following dates: {1/1, 7/4, 11/23, 12/25}.

[Rule = 1]
Message = W945
Day = Mon
Start Time = 0500
Stop Time = 1530
Action ID = 1
Date = X01/01, X07/04, X11/23, X12/25

Example #2

In this example, we want to perform an action when a W947 (Controller has left LAN) message occurs, unless it occurs on the weekend between 5:00am and 9:00am. For this we have to use the day exclusion formatting, which is similar to the message exclusion example above(Message Events – Example #3). (Note: Just as in the previous examples, the time fields are not required, but exist to make the rule even more specific.)

[Rule = 2]
Message = W947
Day = XSat, XSun
Start Time = 0500
Stop Time = 0900
Action ID = 1

Example #3

In this example, we will perform an action if a W599 (Normal Controller IPL) does not occur on the master controller on Sunday through Wednesday. For this example we need to set the ‘Frequency’ parameter to ’0′ to specify that the action should be executed if the event does not occur. It should be noted that the Start/Stop Time fields also must be used in this case. Since we want to include the full day of Sunday they are set to midnight and 11:59pm, respectively. These two parameters must be defined when setting ‘Frequency’ to 0.

[Rule = 3]
NodeID = CC
Message = W599
Frequency = 0
Day = Sun, Mon, Tue, Wed
Start Time = 0000
Stop Time = 2359
Action ID = 1

Example #4

Along the lines of the last example, we now want to perform an action if a W599 does not occur between 7:00pm and 5:30am on any day except Sunday. Regardless of whether the message does or does not occur on Sunday, we do not want to do anything.

[Rule = 4]
NodeID = CC
Message = W599
Frequency = 0
Day = XSun
Start Time = 1900
Stop Time = 0530
Action ID = 1

Notice in this example how the time lapses over midnight. If the W599 actually occurs on Monday early in the morning (before 5:30), StoreGazer still considers it Sunday, so it will ignore the message.

Example #5

On every day aside from Sunday, you want to be notified of all Severity ’1′ messages that occur on either controller. However, on Sundays between 12:00am and 9:00am, each controller has a W906 and W907 system message occur, which you want to ignore.

[Rule = 5]
Message = XW906, XW907
Severity = 1
Start Time = 0000
Stop Time = 0900
Day = Sun
Action Id = 1

[Rule = 6]
Severity = 1
Action Id = 1

Notes:

• This case is complicated because of the difficulty in expressing it in syntax that EDJAgent can understand. If the ‘Start/Stop Time’ and ‘Day of week’ checks fail in Rule 5, then Rule 6 is processed. The ordering is important in this situation, and any rules similar to Rule 5 should always be defined before the rule that was previously processing the message (Rule 6 in this case).
• Place all message exclusion rules at the beginning of the event file.

This directive can be issued to indicate that any system message that passes the current rule should be excluded. It is different from the other parameters in that it does not require a value. It can be set to ‘true’, ’1′, etc. This field can be used in multiple ways:

• If no action id is provided, no actions will be performed on this system message.

• If one or more action id’s are provided, only those actions will be prohibited from running.

(Note: Exclusion messages should be defined before all other messages in the event file.)

Example #1

In this example, we want to log all W619 and W620 messages, unless they are caused by our telnet program (ADXHSIUL).

[Rule = 1]
Message = W619, W620
Ascii Data = ADXHSIUL
Exclude = true

[Rule = 2]
Message = W619, W620
Action ID = 1

Example #2

In this next example, we will assume that there are several rules in our event file that perform action number 2. This action sends emails notifying us when problems occur. Consider that we may not want to receive any emails on the weekend. If we use the following exclusion rule, it will prevent any other rules from executing an email action on Saturday or Sunday.

[Rule = 1]
Day = Sat, Sun
Exclude = true
Action ID = 2