continue=yes   specifies that the Listener should continue after finding the first match. This is useful when you specify multiple -l clauses to cause one message to initiate multiple actions. The default is no.

maydial=no   specifies that the action cannot dial the modem. This provides information to the Listener to decide whether to release the modem or not before the action. This option is useful when the action or altaction need exclusive access to the modem used by the Listener. The default is yes.

confirm_delivery=no   specifies that this handler should not confirm delivery. A message requires confirmation if the gateway used to send it has its confirm_delivery property set to yes. Delivery can only be confirmed if the message requires confirmation and if the handler accepts the message. The default is yes.

Normally, you do not need to specify this option. By default the first handler that accepts the message sends delivery confirmation, if required. This option can be used when multiple handlers might accept the same message to give you finer control over which handler should confirm the delivery.

For information about handling delivery confirmation on the server, see confirmation_handler property.

start   spawns a process. When you start a program, the Listener continues listening for more messages.

When you start a program, the Listener doesn't wait for a return code, so it can only tell that the action has failed if it cannot find or start the program.

The following example starts dbmlsync with some command line options, parts of which are obtained from the message using the $content action variable.

"action='start dbmlsync.exe @dbmlsync.txt -n 
  $content -wc dbmlsync_$content -e sch=INFINITE';"

run   runs the program and waits for it to finish. The Listener resumes listening after the process is complete.

When you run a program, the Listener determines that the program has failed if the Listener cannot find or start the program or if it returns a non-zero return code.

The following example runs dbmlsync with some command line options, parts of which are obtained from the message.

"action='run dbmlsync.exe @dbmlsync.txt -n $content';"

post   posts a Windows message to a window class. This is required by dbmlsync when scheduling is on. Post is also used when signaling applications that use Windows messages.

You can identify the Windows message by message contents or by the ID of the Windows message, if one exists.

You can identify the window class by its name or by the title of the window. If you identify the window class by name, you can use the dbmlsync -wc option to specify the window class name. If you identify the window class by its title, only the title of the top level window can be used to identify the window class.

If there are non-alphanumeric characters such as spaces or punctuation marks in your Windows message or window class name, you can put the message or name in single quotes. In that case, to use a single quote in the string, use two single quotes in a row. For example, to post my'message to my'class, use the following syntax:

... -l "action='post my''message to my''class';"

or

... -l "action='post ''my''''message'' to ''my''''class''';"

The following example posts a Windows message registered as dbas_synchronize to a dbmlsync instance registered with the class name dbmlsync_FullSync.

"action='post dbas_synchronize to dmblsync_FullSync';"

See -wc option.

socket   notifies an application by making a TCP/IP connection. This is especially useful for passing dynamic information to a running application. It is also useful for integrating with Java and Visual Basic applications, because Java and VB don't support custom window messaging, and eVB doesn't support command line parameters. You can connect to a local socket by specifying just a port, or you can connect to a remote socket by specifying the host along with the port. Using sendText, you can send a string. You can optionally verify that the response is as expected with recvText. When you use recvText, you can also specify a timeout to avoid hanging if the case of application or network problems.

When you perform a socket action, the Listener determines that the action has failed if it failed to connect, send, or receive expected acknowledgement before timeout.

The following example forwards the string in $sender=$message to a local application that is listening on port 12345, and expects the application to send back "beeperAck" as an acknowledgement within 5 seconds.

-l "action='socket port=12345;
   sendText=$sender=$message;
   recvText=beeperAck;
   timeout=5'"

DBLSN FULL SHUTDOWN   causes the Listener utility to shut down. After shutdown, the Listener stops handling inbound messages and stops synchronizing device tracking information. The remote user must restart the Listener to continue with server-initiated synchronization. This feature is mostly useful during testing.

For example, action='DBLSN FULL SHUTDOWN'