StoreGazer Event/Action Examples
Example Index
This page contains several sample event rules and action definitions. Most scenarios for each action are discussed, while the sample events cover the majority of the rule definitions available. It should be noted that for each sample event rule defined, an Action ID of '1' is used, and we will assume this is a log action. Some event rules will also make use of Action ID '2', which we can assume to be an email action.
Event Index
Message Events
Terminal Events
Frequency Events
Timed Events
Exclusion Events
Action Index
Logging Messages
Emailing Messages
Sending SNMP Traps
Sending Windows Events
Starting Programs
Stopping Programs
Changing Priority of Programs
Signing Off Terminals
Loading Terminals
Loading Controllers
FTP Files
Deleting Files
Executing RCP Commands
Message Events
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
Terminal Events
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
Frequency Events
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:
Timed Events
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. (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:
Exclusion Events
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
Logging Messages
Example #1
In the first scenario, we will perform a simple log to the StoreGazer Server(s) defined in the configuration file.
[Action = 1] Type = Log
Next, we will slightly modify the log action to include the 'Hidden' directive. This instructs the StoreGazer Client to not display the message in the Message Monitor.
[Action = 1] Type = Log Hidden = true
One other variation may include the 'Alert' indicator. The StoreGazer Client uses different icons in the Message Monitor to reflect the message priority.
[Action = 1] Type = Log Alert = High
Example #2
In this scenario, we will assume the action my have been executed as a result of a time-executed event. If this is the case, we can overwrite the message and data fields displayed in the StoreGazer Client.
[Action = 1] Type = Log Message = AUTO Data = This Action Was Automatically Executed.
If we neglected to define the message parameter above, the default value of 'TIME' would have been used. The maximum length of this field is four bytes. It will be ignored if the action is executed due to a real system event occuring, since that will display the actual system message group and number.
Emailing Messages
Example #1
In this scenario, we will send an email request to the StoreGazer Server(s) defined in the configuration file. This action instructs the StoreGazer Server to use the 'Email4690' template.
[Action = 1] Type = Email Template Name = Email4690
Example #2
In this scenario, we will send an email request to the StoreGazer Server(s) defined in the configuration file. This action instructs the StoreGazer Server to use the 'C:\SGEmails\Email1.txt' email file.
[Action = 1] Type = Email File Name = C:\SGEmails\Email1.txt
Example #3
The following example will send an email request to a single StoreGazer Server. If more than one StoreGazer Servers are in use (e.g. East and West data centers), you may only want to receive one copy of the email. The 'Single Server' parameter instructs the EDJAgent process to only send the request to one of the configured servers. Once a successful response is sent from one controller, the action is no longer executed.
[Action = 1] Type = Email File Name = C:\SGEmails\Email1.txt Single Server = true
Sending SNMP Traps
Example #1
The following example will send an SNMPv1 Trap using the Network category.
[Action = 1] Type = SNMPv1 Category = Network
Example #2
The following example will send an SNMPv2 Trap using the Hardware category.
[Action = 1] Type = SNMPv2 Category = Hardware
Sending Windows Events
Example #1
The following example will send a Windows Event.
[Action = 1] Type = Windows Event
Starting Programs
Example #1
In this example, we will start the program 'test.286' from the 'adx_ipgm' directory. It will be executed on the CC controller. We will also use the optional parameters field to pass a '-d999' parameter to the program.
[Action = 1] Type = Run Program NodeID = CC Program Name = ADX_IPGM:Test.286 Parameters = -d999
Example #2
The above action will always execute the program on the CC controller. It may be the case that we want to start the program on whichever controller the original message occured on. In this case we will set the NodeID parameter to '%m'.
[Action = 2] Type = Run Program NodeID = %m Program Name = ADX_IPGM:Test.286 Parameters = -d999
Example #3
In this example, we will execute a batch file, 'adx_upgm:test.bat'. Since batch files can not run from the background screen, we need to turn the background flag off.
[Action = 3] Type = Run Program NodeID = %m Program Name = ADX_UPGM:Test.bat Background = false
Example #4
The following example will clear the print queue. You may be familiar with running 'print -c' from the command line. This action will load a command prompt and run 'print -c', along with answering 'y'es when prompted for confirmation.
[Action = 4] Type = Run Program NodeID = %m Program Name = adx_spgm:command.286 Parameters = -c echo y | print -c Background = true
Stopping Programs
Example #1
In this example, we will stop the program 'test.286'. It will be stopped on the CC controller.
[Action = 1] Type = Stop Program NodeID = CC Program Name = Test.286
Example #2
The above action will always stop the program on the CC controller. It may be the case that we want to stop the program on whichever controller the original message occured on. In this case we will set the NodeID field to '%m'.
[Action = 2] Type = Stop Program NodeID = %m Program Name = test.286
Example #3
The above actions will only stop a single process. If we require all 'test.286' processes to end, the 'Stop Type' field is available. The following example will terminate all 'test.286' processes.
[Action = 2] Type = Stop Program NodeID = %m Program Name = test.286 Stop Type = All
Example #4
In some cases, we may wish to stop a process based on the parameter list. In the following example, we will stop the ACEAPSHL process if the "ADX_IDT1:ACEAPSHL.DAT" parameter is present. Notice the '*' wildcard that begins and ends the required parameter list. This wildcard will allow other parameters to be defined before and after the data file we are interested in.
[Action = 2] Type = Stop Program NodeID = %m Program Name = ACEAPSHL Parameters = *ADX_IDT1:ACEAPSHL.DAT*
Changing Priority of Programs
Example #1
In this example, we will change the priority of the program 'test.286' to 198. This will be performed on the CC controller.
[Action = 1] Type = Set Priority NodeID = CC Program Name = Test.286 Priority = 198
Example #2
The above action will always change the priority on the CC controller. It may be the case that we want to perform this action on whichever controller the original message occured on. In this case we will set the NodeID parameter to '%m'.
[Action = 2] Type = Set Priority NodeID = %m Program Name = Test.286 Priority = 198
Signing Off Terminals
Example #1
In this example we will signoff terminal 250 from the CC controller.
[Action = 1] Type = Signoff Terminal NodeID = CC Parameters = 250
Example #2
In the above example, the terminal will always be loaded from the CC controller. It may be the case that on certain messages, the CC controller is down and the terminal should be re-loaded from the alternate instead. If this applies, we can use the '%m' parameter in the NodeID field to force the action to occur on whichever controller the original message occured on.
[Action = 2] Type = Signoff Terminal NodeID = %m Parameters = 250
Example #3
In this last example, we will signoff the terminal that the event occurred on (from the system message).
[Action = 3] Type = Signoff Terminal NodeID = %m Parameters = %m
Loading Terminals
Example #1
In this example we will load terminal 555 from the CC controller.
[Action = 1] Type = Load Terminal NodeID = CC Parameters = 555
Example #2
In the above example, the terminal will always be loaded from the CC controller. It may be the case that on certain messages, the CC controller is down and the terminal should be re-loaded from the acting master instead. If this applies, we can use the 'AA' parameter in the NodeID field to force the action to occur on the acting master controller. occured on.
[Action = 2] Type = Load Terminal NodeID = AA Parameters = 555
Example #3
There is also a way to load every terminal defined in the terminal file. If we want to do this we can replace the single terminal in the Parameters field to a '*', as follows:
[Action = 3] Type = Load Terminal NodeID = AA Parameters = *
Example #4
In this last example, we will load terminal configuration data on the terminal that the event occurred on (from the system message).
[Action = 4] Type = Load Terminal NodeID = AA Parameters = %m Load Type = STC
Loading Controllers
Example #1
In this example we will reload (IPL) the CC controller.
[Action = 1] Type = Load Controller NodeID = CC
Example #2
The above action will always reload the CC controller. It may be the case that we want to re-load whichever controller the original message occured on. In this case we will set the NodeID parameter to '%m'.
[Action = 1] Type = Load Controller NodeID = %m
Example #3
In this example we will dump the CC controller.
[Action = 1] Type = Load Controller NodeID = CC Load Type = Dump
Example #4
In this example we will reload all controllers connected to the LAN. We issue this request through the acting master controller.
[Action = 1] Type = Load Controller NodeID = AA Load Type = ReloadAll
FTP Files
Example #1
In this example, we will send the file 'adx_idt1:sendme.dat' from the CC controller to the specified FTP Server. The UserID and Password used in this case are 'anonymous'. The file will be stored on the destination machine as 'c:\4690\CC\sendme.dat'
[Action = 1] Type = FTP File NodeId = CC IP = 1.1.1.1 Source File = c:\adx_idt1\sendme.dat Destination File = c:\4690\CC\sendme.dat Option = Put User ID = anonymous Password = anonymous
Example #2
Let us assume that we will be performing the above action every day from every controller in each store. We do not want to overwrite this file each day, but would prefer to organize all these files in directories defined by their store number and node ID. The following example will still send the same file as in example #1, but the destination file name will consist of the following: 'C:\4690\StoreNumber\NodeID\mmddyy.dat'. We will transfer this file as type Ascii, instead of the default Binary as used above.
We will also set the NodeID to '%m' in this example, which will make the FTP command occur on whichever controller the system message occured on.
[Action = 2] Type = FTP File NodeId = %m IP = 1.1.1.1 Source File = c:\adx_idt1\sendme.dat Destination File = c:\4690\%s\%n\%m%d%y.dat Option = Put User ID = anonymous Password = anonymous Parameters = Ascii
Example #3
In this example, we will receive a file from the DD controller that will be stored as a backup on CC.
[Action = 3] Type = FTP File NodeId = CC IP = DD Source File = c:\adx_idt1\backup\ADXC%m%d.dat Destination File = c:\adx_idt1\ADXCS%n0.dat Option = Get User ID = anonymous Password = anonymous Parameters = Binary
Example #4
In this example, we will send all of the files in our c:\outgoing directory to a controller-specific directory on the FTP server (c:\incoming\StoreNumber+NodeID\). Upon successful transfer, the local source file(s) will be deleted.
[Action = 4] Type = FTP File NodeId = %m IP = 1.1.1.1 Source File = c:\outgoing\*.* Destination File = c:\incoming\%s%n\*.* Option = PutD User ID = anonymous Password = anonymous Parameters = Binary
Example #5
In this example, we will send an FTP request to a StoreGazer Windows Agent. The Windows Agent will be instructed to retrieve all files from the CC controller's outgoing directory. Also, we assume that the Windows Agent is unable to resolve the IP address for CC, so the ResolveLocal parameter is used. This instructs the controller to resolve the IP address before sending the FTP request to the Windows Agent.
[Action = 5] Type = FTP File RemoteServer = WindowsMachineName IP = CC ResolveLocal = true Source File = c:\outgoing\*.* Destination File = c:\incoming\%s%n\*.* Option = Get User ID = anonymous Password = anonymous Parameters = Binary
Deleting Files
Example #1
In this example, we will delete the file 'deleteme.dat' from CC's 'adx_idt1' directory.
[Action = 1] Type = Delete File NodeID = CC Program Name = ADX_IDT1:Deleteme.dat
Example #2
The above action will always delete the file on the CC controller. It may be the case that we want to delete the file on whichever controller the original message occured on. In this case we will set the NodeID parameter to '%m'.
[Action = 2] Type = Delete File NodeID = %m Program Name = ADX_IDT1:Deleteme.dat
Example #3
The following example will delete all files in the 'c:\temp' directory.
[Action = 3] Type = Delete File NodeID = %m Program Name = C:\Temp\*.*
Executing RCP Commands
Example #1
In this example, we will execute the RCP command file 'edjgazer:rcpdump.dat' that will create the IBM problem analysis diskettes (adxcsr?f.dat) as well as a formatted system log file (adx_sdt1:adxcsnrf.dat).
[Action = 1] Type = RCP NodeId = CC File Name = edjgazer:rcpdump.dat
The edjgazer:rcpdump.dat file contains the following RCP commands:
ADXCSN0L Y 8 F B ADXCSN0L N 7 01/01/01 12:00 12/31/10 12:00 * * * 2 ADXCSR0L Y 4