StoreGazer Action File Definitions & Examples

StoreGazer 4690 Action Types

StoreGazer uses two main files to determine which actions to take when a monitored event is triggered. These two files are ‘edjgazer:evntfile.dat’ and ‘edjgazer:actnfile.dat’. When a message occurs on a 4690 controller, and it matches the filter(s) defined by an event rule in the event file, EDJAgent can execute one or more actions. The action file consists of a number of different actions that can be performed, ranging from logging a message to the StoreGazer Server, to rebooting the controller. The actions will be triggered by EDJAgent when a system message passes through a rule in the event file. Multiple events can point to the same action.

Each action requires two parameters. The first is the ‘Action’ parameter, which is used to distinguish actions from each other, much like the ‘Rule’ parameter in the event file. Each action also must define the ‘Type’ parameter so that EDJAgent knows what type of action to perform. The following actions are available to EDJAgent. Included within each action are several sample action definitions. Most scenarios for each action are described. 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.

Description

This action type sends a log message to the configured StoreGazer Server(s). The logged message contains all of the information provided within the 4690 system message.

Required Parameters

None.

Optional Parameters

Alert Defines the message priority. This parameter influences the color-coded priority icon displayed in the StoreGazer Client. The following values are recognized:

  • Low – Low message priority (yellow icon)
  • Medium – Medium message priority (orange icon)
  • High – High message priority (red icon)
Data If the Data field is used, EDJAgent will overwrite any unique data within the system message with the data provided here. The data will be displayed in the Data column of the StoreGazer Client message monitor. A maximum of 50 characters are recognized within this field.
Data Layout Defines the layout of the unique data provided within the system message. By default, the 18 bytes of unique data is formatted to provide the best display string. However, this default layout may strip non-alphanumeric characters that the user is interested in. For these cases, the user can specify ASCII and Hex layouts via the ‘Data Layout’ parameter. The following values are recognized:

  • ASCII – Display the unique data in ASCII format (last 10 bytes)
  • Hex – Display the application unique data in Hex format (last 20 bytes)
  • Raw – Display the complete unique data in Hex format (all 36 bytes)
  • Printable – Display all unique data, replacing any non-printable characters with a space. (all 18 bytes)
Hidden If this parameter is set to ‘true’, the message will not be displayed within the StoreGazer Client. This may be useful for informational messages that should be in the database for SQL reporting. If this paremeter is set to ‘false’ (or omitted), the message will be displayed in the StoreGazer Client.
Message This parameter can be used to override the Message field displayed in the StoreGazer Client. If this parameter is not provided, the default message (Wxxx, ALRT, etc.) will be used.
Single Server If this parameter is set to ‘true’ and multiple (shadow) servers are defined in the EDJAgent.cfg configuration file, EDJAgent will only perform the action on a single server.

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.

Description

This action type sends an email request to the StoreGazer Server containing information about the system message.

Required Parameters

Template Name Version 2.3.1 or later The name of the email template to use. Email templates are defined within the StoreGazer Client in the “View -> Email Templates” area.
File Name Deprecated in Version 2.3.1 The full path of the email information file that exists on the StoreGazer Server. This file contains the email-specific information such as the subject, recipients, etc.

Optional Parameters

Data If the Data field is used, EDJAgent will overwrite any unique data within the system message with the data provided here. A maximum of 50 characters are recognized within this field.
Data Layout Defines the layout of the unique data provided within the system message. By default, the 18 bytes of unique data is formatted to provide the best display string. However, this default layout may strip non-alphanumeric characters that the user is interested in. For these cases, the user can specify ASCII and Hex layouts via the ‘Data Layout’ parameter. The following values are recognized:

  • ASCII – Display the unique data in ASCII format (last 10 bytes)
  • Hex – Display the application unique data in Hex format (last 20 bytes)
  • Raw – Display the complete unique data in Hex format (all 36 bytes)
  • Printable – Display all unique data, replacing any non-printable characters with a space. (all 18 bytes)
Message This parameter can be used to override the Message field displayed in the email. If this parameter is not provided, the default message (Wxxx, ALRT, etc.) will be used.
Single Server If this parameter is set to ‘true’ and multiple (shadow) servers are defined in the EDJAgent.cfg configuration file, EDJAgent will only perform the action on a single server.

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

Description

This action type sends the system message data to the StoreGazer Server, which will then generate a syslog event and broadcast it to the server-configured location(s).

Required Parameters

None

Optional Parameters

Facility If the Facility is specified in the action, the syslog event will be generated using the provided facility value.  If left unspecified, the default facility value specified in the EDJAGENT.CFG file will be used.  If no facility is specified in either the action or the configuration file, the default facility of 23 (local7) will be used.
Severity If the Facility is specified in the action, the syslog event will be generated using the provided severity value.  If left unspecified, the default value of 0 (Emergency) will be used.

Example #1

In this scenario, StoreGazer will send the original system message to the server with instructions to generate an Informational (priority 6) user-level (facility 1) syslog event for broadcasting.

[Action = 1]
Type = SYSLOG
Facility = 1
Severity = 6

Example #2

In this scenario, StoreGazer will send the original system message to the server with instructions to generate an Informational (priority 6) syslog event for broadcasting, using the facility specified in the EDJAGENT.CFG file (or the default facility of 23, if no default facility was specified).

[Action = 1]
Type = SYSLOG
Severity = 6

 

Description

This action type will send an SNMP v1 Trap request to the configured StoreGazer Server(s). The trap contains all of the information provided within the 4690 system message.

Required Parameters

Category A user-defined category name that is used to determine which servers and communities are used when sending the Trap.

Optional Parameters

Data If the Data field is used, EDJAgent will overwrite any unique data within the system message with the data provided here. A maximum of 50 characters are recognized within this field.
Data Layout Defines the layout of the unique data provided within the system message. By default, the 18 bytes of unique data is formatted to provide the best display string. However, this default layout may strip non-alphanumeric characters that the user is interested in. For these cases, the user can specify ASCII and Hex layouts via the ‘Data Layout’ parameter. The following values are recognized:

  • ASCII – Display the unique data in ASCII format (last 10 bytes)
  • Hex – Display the application unique data in Hex format (last 20 bytes)
  • Raw – Display the complete unique data in Hex format (all 36 bytes)
  • Printable – Display all unique data, replacing any non-printable characters with a space. (all 18 bytes)
Message This parameter can be used to override the Message field displayed in the StoreGazer Client. If this parameter is not provided, the default message (Wxxx, ALRT, etc.) will be used.
Single Server If this parameter is set to ‘true’ and multiple (shadow) servers are defined in the EDJAgent.cfg configuration file, EDJAgent will only perform the action on a single server.

Example #1

The following example will send an SNMPv1 Trap using the Network category.

[Action = 1]
Type = SNMPv1
Category = Network

Description

This action type will send an SNMP v2 Trap request to the configured StoreGazer Server(s). The trap contains all of the information provided within the 4690 system message.

Required Parameters

Category A user-defined category name that is used to determine which servers and communities are used when sending the Trap.

Optional Parameters

Data If the Data field is used, EDJAgent will overwrite any unique data within the system message with the data provided here. A maximum of 50 characters are recognized within this field.
Data Layout Defines the layout of the unique data provided within the system message. By default, the 18 bytes of unique data is formatted to provide the best display string. However, this default layout may strip non-alphanumeric characters that the user is interested in. For these cases, the user can specify ASCII and Hex layouts via the ‘Data Layout’ parameter. The following values are recognized:

  • ASCII – Display the unique data in ASCII format (last 10 bytes)
  • Hex – Display the application unique data in Hex format (last 20 bytes)
  • Raw – Display the complete unique data in Hex format (all 36 bytes)
  • Printable – Display all unique data, replacing any non-printable characters with a space. (all 18 bytes)
Message This parameter can be used to override the Message field displayed in the StoreGazer Client. If this parameter is not provided, the default message (Wxxx, ALRT, etc.) will be used.
Single Server If this parameter is set to ‘true’ and multiple (shadow) servers are defined in the EDJAgent.cfg configuration file, EDJAgent will only perform the action on a single server.

Example #2

The following example will send an SNMPv2 Trap using the Hardware category.

[Action = 1]
Type = SNMPv2
Category = Hardware

Description

This action type will send a Windows Event Log request to the configured StoreGazer Server(s). The request contains all of the information provided within the 4690 system message.

Required Parameters

None.

Optional Parameters

Alert Defines the message priority. The priority is included in the Event description. The following values are recognized:

  • Low – Low message priority (yellow icon)
  • Medium – Medium message priority (orange icon)
  • High – High message priority (red icon)
Data If the Data field is used, EDJAgent will overwrite any unique data within the system message with the data provided here. A maximum of 50 characters are recognized within this field.
Data Layout Defines the layout of the unique data provided within the system message. By default, the 18 bytes of unique data is formatted to provide the best display string. However, this default layout may strip non-alphanumeric characters that the user is interested in. For these cases, the user can specify ASCII and Hex layouts via the ‘Data Layout’ parameter. The following values are recognized:

  • ASCII – Display the unique data in ASCII format (last 10 bytes)
  • Hex – Display the application unique data in Hex format (last 20 bytes)
  • Raw – Display the complete unique data in Hex format (all 36 bytes)
  • Printable – Display all unique data, replacing any non-printable characters with a space. (all 18 bytes)
Message This parameter can be used to override the Message field of the email. If this parameter is not provided, the default message (Wxxx, ALRT, etc.) will be used.
Single Server If this parameter is set to ‘true’ and multiple (shadow) servers are defined in the EDJAgent.cfg configuration file, EDJAgent will only perform the action on a single server.

Example #1

The following example will send a Windows Event.

[Action = 1]
Type = Windows Event

Description

This action type will start a program on a 4690 controller. The program can be started on the controller that the system message occurred on or any other controller that is running StoreGazer.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
Program Name The name of the program to start. This field should consist of the full path followed by the program name (the program’s extension is required). Logical file names are accepted. When running a program in the background, there is a limit of 21 characters (8:8.3).

Optional Parameters

Parameters This field can be used to provide parameters that should be passed to the program. There is one wildcard accepted, ‘%ascii’, that will be replaced with the unique data associated with the system message that triggered the action.
Background If this parameter is set to ‘false’, the program will be started outside of the background screen. This should be used when running batch files. If this paremeter is set to ‘true’ (or omitted), the program will start on the 4690 background screen.
Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.

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

Description

This action type will stop a program running on a 4690 controller. A program can be stopped on the controller that the system message occurred on, or any other controller that is running StoreGazer. If the program is not running, the request will be ignored. If multiple instances of this program are running, the instance with the highest PID (most recently started), will be the program that is stopped.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
Program Name The name of the program to be stopped. This field should only consist of the executable’s name.

Optional Parameters

Parameters This field can be used to provide the parameters that must be present to terminate a process. The ‘*’ and ‘?’ wildcards are supported.
Stop Type The type of logic to use when stopping the process:

  • First – Stop the first available (most recent) instance of the process.
  • All – Stop all instances of the process.

If this parameter is omitted, the Stop Program action will default to the ‘First’ stop type, stopping the most recent instance of the process.

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.

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*

Description

This action type changes the priority of a program currently running on a 4690 controller. This can occur on the controller that the system message occurred on, or any other controller that is running StoreGazer. If the program is not running, the request will be ignored. If multiple instances of this program are running, the instance with the highest PID (most recently started), will be the program that has its priority changed.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
Program Name The name of the program that will have its priority changed. This field should only consist of the executable’s name.
Priority The new priority of the program (Range: 195-204). A lower value leads to a higher CPU priority, with the average being 200. A priority of 200 is almost always recommended.

Optional Parameters

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.

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

Description

This action type will sign off the requested terminal. This can occur on the controller that the system message occurred on or any other controller that is running StoreGazer. If the terminal does not exist, the request will be ignored.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
Parameters The number of the terminal to sign off. There is an option of using a ‘%m‘ in this field. This will reload the terminal on which the event occurred.

Optional Parameters

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.

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

Description

This action type will load the requested terminal(s). This can occur on the controller that the system message occurred on, or any other controller that is running StoreGazer. If the terminal does not exist, the request will be ignored.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
Parameters The number of the terminal to load. There is an option of using a ‘*‘ in this field. This will cause all terminals defined in the terminal status file to be loaded. There is also the option of using a ‘%m‘ in this field. This will reload the terminal on which the event occurred.

Optional Parameters

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.
Load Type The method used to reload the terminal:

  • Reload – Perform a standard terminal storage load
  • STC – Load terminal configuration data

If this parameter is omitted, the Load Terminal action will default to the ‘Reload’ load type.

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

Description

This action type will reload (IPL) a 4690 controller. This can occur on the controller that the system message occurred on, or any other controller that is running StoreGazer.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.

Optional Parameters

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.
Load Type The method used to reload the controller:

  • Reload – Perform a standard reload (IPL) on the requested controller.
  • Dump – Dump the requested controller
  • ReloadAll – Reload all controllers. This load type should typically be issued from the master controller.

If this parameter is omitted, the Load Controller action will default to the ‘Reload’ load type.

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

Description

This action type will perform an FTP request between a 4690 controller and another machine running an FTP server. It is assumed that the FTP server is listening on port 21. This request can be issued from the controller that the system message occurred on, or any other controller that is running StoreGazer. It is possible to have an FTP transfer between two 4690 controllers, as long as an FTP server is running on one. This can be verified in the superserver file.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
RemoteServer This parameter is synonymous with the NodeID parameter described above. This parameter name may be preferred when creating an FTP action that communicates with a StoreGazer Windows Agent running on a self-checkout lane (to avoid confusion caused by referring to a Windows machine as a Node).
IP This is the IP address or hostname of the FTP server.
Source File The source (existing) file to be transferred. This field should contain the full path and filename of the source file, and there is a limit of 50 characters. There are several wildcards that can be used within the file name to designate controller-specific variables. Always ensure that the filename is in the standard “eight-dot-three” format when using these symbols:

  • %s = Store Number (4 Characters)
  • %n = Store Node ID (2 Characters)
  • %t = Terminal Number (3 Characters)
  • %y = Year, ‘yy’ (2 Characters)
  • %Y = Year, (0-9) (1 Character)
  • %m = Month, ‘mm’ (2 Characters)
  • %M = Month (1-C) (1 Character)
  • %d = Day, ‘dd’ (2 Characters)
  • %D = Day (1-V) (1 Character)
  • %h = Hour, ‘hh’ (2 Characters)
  • %u = Minute, ‘mm’ (2 Characters)

The following wildcards can only be used on Supermarket systems to specify T-log file names (A, B, or C):

  • %0 = Current T-log (1 Character)
  • %1 = Previous T-log (1 Character)
  • %2 = T-log from two days ago (1 Character)
Destination File The name of the new file to be created after transferring the source file. This field should contain the full path and filename of the destination file, and there is a limit of 50 characters. The wildcards listed above for the ‘Source File’ can also be used for the destination file. If the destination directory does not exist it will automatically be created.
Option This parameter can take any of the following values:

  • ‘GET’ causes the source file to be retrieved from the remote machine and placed locally in the path set in the ‘Destination File’ field.
  • ‘GETD’ is the same as ‘GET’, with the additional step of deleting the source file(s) on success.
  • ‘PUT’ causes the source file to be sent to the remote machine and placed remotely in the path set in the ‘Destination File’ field.
  • ‘PUTD’ is the same as ‘PUT’, with the additional step of deleting the source file(s) on success.
User ID The user name used when logging in to the FTP server.
Password The password used when logging in to the FTP server.

Optional Parameters

Parameters If this field is used, the user can specify the type of transfer to initiate, ‘Binary’ or ‘Ascii’. If this field is omitted, the default transfer type is used (Binary).
ResolveLocal If this field is set to true, the FTP server hostname (NodeID/RemoteServer) will be mapped to an IP address before EDJAgent sends the FTP request to the destination server. This may be useful if the destination server does not have the ability (through DNS or other means) to resolve the provided hostname. This field is typically only used when FTPing files to/from a Windows Agent.
Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236. (Note: This is not the port of the FTP server, which is assumed to be listening on port 21).

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

Description

This action type will delete a file on a 4690 Controller. The file can be deleted on the controller that the system message occurred on, or any other controller that is running StoreGazer.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
Program Name This is the name of the file to be deleted. It should consist of the full path followed by the file name. Logical file names are accepted.

Optional Parameters

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.

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\*.*

Description

This action type will execute any number of RCP commands on a 4690 Controller. The commands can be run on the controller that the system message occurred on, or any other controller that is running StoreGazer. A complete listing of RCP commands and their usage is available in the ‘IBM 4690 Store System: Communications Programming Reference’ guide (Chapter 4).

There are many times a user would like to perform another action after an RCP command completes. This can be done by adding an additional event to the event file. When the RCP command completes, a system message is created of group type ‘E’ with a number that corresponds to the event number that kicked off the RCP process. For instance if Rule 40 in the event file kicked off the RCP process, an E040 message will be logged upon completion.

Required Parameters

NodeID The Node ID of the controller that should receive the request. This Node ID is mapped to an IP address through one of the following methods:

  • The 4690 hosts file can be used to define static NodeID-to-IP mappings.
  • The DefineNode command can be used within the EDJAgent configuration file.
  • For customers with dynamic IPs (typically assigned by a BOOTP server), the ResolveIPsByFile configuration option can be enabled to parse the 4690 IP files (ADXIPxxZ.BAT and/or ADXBPxxZ.BAT) at run-time to map Node IDs to IP addresses.

There are also several wildcards that can be used in this field:

  • %m – Sends the request to the controller responsible for the original event (or alert).
  • AA – Sends the request to the acting master.
  • AB – Sends the request to the acting alternate master.
  • AC – Sends the request to the acting file server.
  • AD – Sends the request to the acting alternate file server.
File Name The name of the command file to use with RCP. This field should contain the full path followed by the file name. Logical file names are accepted. When an RCP action is executed, this file name will be written to the RCP Selection file (adx_idt1:adxcshcf.dat) and then the RCP process will begin.

Optional Parameters

Port The StoreGazer listening port of the controller that will receive this request. This field is rarely required, as EDJAgent will default to port 1236 – as configured during StoreGazer installation. The INETD superserver should listen on this port for incoming connections. If necessary, the DefinePort command can be used within the EDJAgent configuration file to override the default port of 1236.

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