ipmerge

Please note: this product loads deals into both front and back office systems; therefore, the terms are used interchangeably.

ipmerge gathers deal data from various TCP-IP connected dealing system interfaces and merges these deals into a single TCP-IP output stream for delivery to a Back Office System (BOS). ipmerge implements identical handshaking at both its inputs and its output and is therefore transparent to the deal sources and to the BOS.

When ipmerge starts, it reads the file ipmerge.ini which contains information about where to look for input and where to deliver output. Each line of the file ipmerge.ini contains a machine/port-number pair as follows:

<machinename>:<portname>

Where <portname> is the number of a port, or the name of a port (found in /etc/services) that, on the machine named <machinename>, should be serving deals in the proper format. Ipmerge is a client to these deal servers. Ipmerge is itself a server for two ports whose details are also given in the ipmerge.ini file. When ipmerge reads a line of the form:

_OUTPUT_:<portname>

or

_CONTROL_:<portname>

ipmerge configures the port whose number is may be derived by looking up <portname> in /etc/services (or whose number is <portname>) to deliver merged deal-output and receive acknowledgments on the port tagged with the token _OUTPUT_. ipmerge executes limited control commands sent to it (e.g., via telnet) on the port tagged with the token _CONTROL_.

Lines, in the file ipmerge.ini, starting with the “hash” character (#) are ignored (they are comments or temporarily disabled configuration lines). Both _OUTPUT_ and _CONTROL_ configuration lines must be present, although they may appear anywhere in ipmerge.ini.

Sites may be configured to have Critical Messages delivered by a “system” command which is driven by the environment variable MRG_ECMD. The shell command specified in this variable is executed with a minimum granularity of 10 minutes and is passed any critical messages issued since the last time the command was executed. Unsent critical messages are stored in the file ipmerge.msg which is passed on the standard-input to the command in the MRG_ECMD environment variable. The execution of this command is noted in the logfile (see later). To prevent unnecessary repetition of identical messages, critical messages stored in ipmerge.msg may be processed with “uniq” for example, as follows:

setenv MRG_ECMD “(uniq -6 | cat > /dev/console)” Each line in the ipmerge.msg file is timestamped and its process-origin is identified. The file ipmerge.msg is deleted each time after the command in MRG_ECMD is executed.

To prevent short-term error conditions from producing “orphaned notifications” a 45 second delay is implemented for new batches of error notifications.

Sites may be connected to a printer to which critical messages are immediately sent. WARNING, on Windows installations, if MSWindows appears to hang, please check that the printer has paper and is on-line.

A header of the form:

<TCID>:<tktnumber>|

is prepended to each record by the deal servers. This header, which uniquely tags each data record with its source and ticket number, is passed on, undisturbed by ipmerge, to the output port. The passage of the header is noted however and the information parsed from the header is used to verify that deal data is in transit. If the header does not conform to a legal form it, and the attached data record, is still passed to the output port. In this case, a critical message is generated.

Any response to a legally formed message that comes from the output port, is passed back to the record originator.

The default behaviour for certain interface functions may be modified by the use of “environment variables”. These variables must be set prior to the interface execution (usually in a “shell” or “batch” file). Command parameters take precendence over equivalent environment variables. The environment variables, used by the interface, all start with “MRG_” and are as follows:

MRG_ECMD The command to be used to process critical (information and error) messages (including all arguments to run the command) is taken from this variable. The command must take its input from the “standard input” stream.

A logfile named mrg<MMDD>.log (where <MMDD> stands for the digits representing the month and day that the file was created) is appended to as log-events occur. All “critical messages” are logged. A deal identifier is logged whenever a deal is passed to the BOS.
If ipmerge is left running overnight, a new logfile is automatically created as soon as necessary after midnight.

(UNIX and NT installations only, see “Critical-Message Notification” above)
The file mrg<ddmm>.msg contains one line for each critical message. Each line comprises four sections:

1. <application name>
2. [<DateTime>]
3. <a critical message>
4. #<a critical message number>. Error numbers for ipmerge are in the 30,000 to 39,999 range, qmerge errors are in the range 40,000 to 49,999.

For Example:
ipmerge [Tue Nov 14 19:03:06 1995] WARNING, no output connected, deal capture suspended #30211

Disk space is consumed according to the number of errors detected by ipmerge. Each day that ipmerge is executed, 1 new file (a log file) is created in the ipmerge execution directory. It is suggested that these files are archived and deleted from the drive every few months.

---

# facetalk0 and facetalk2 must be present in the services table
_OUTPUT_:facetalk0
_CONTROL_:facetalk2
fxny-reuters:1602
fxny-ebs:1702

Page Last Updated 10/13/99