ipmerge user manual

Ipmerge
User Manual
Table of Contents

Synopsis
General
Configuration
Critical-Message Notification

System Command
Printer

Deal Receipt Verification
Environment Variables
File Formats

Log File
Critical Message File

Operator Interaction

Daemon Mode
Interactive Mode
Signal Handling

Periodic Cleanup
Appendix A - Sample ipmerge.ini

Ipmerge
User Manual
Synopsis

ipmerge

General

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.

Configuration

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.

Critical-Message Notification

System Command

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.

Printer

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.

Deal Receipt Verification

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.

Environment Variables

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.

File Formats

Log File

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.

Critical Message File

(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:

<application name>

[<DateTime>]

<a critical message>

#<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

Operator Interaction

Daemon Mode

The program automatically detects if it is to be run non-interactively. If the standard-input is closed during program execution or is redirected to /dev/null at startup, ipmerge stops reading the standard-input and stops delivering output to the standard-output and standard-error channels.

Interactive Mode

When the program is run in interactive mode, the following commands are available, all operating systems except MacOS require a <CR> to be appended for the command to be accepted:

q or Q quit the program gracefully

k or K list on the controlling window a status line concerning each of the ports specified in the ipmerge.ini file. Information is given about any valid sockets associated with these ports and their states (readable (r), writeable (w), or exception (x)).

eof ipmerge enters Daemon Mode (see above).

Signal Handling

On UNIX operating systems, the program catches SIGINT, SIGHUP, and SIGTERM. When one of these signals is detected, the program exits cleanly, closing sockets and writing shutdown information to the logfile. A Critical Message is also generated. On MacOS, only SIGINT is caught, causing clean program termination. Under MSWindows, both SIGINT and SIGTERM receive this treatment.

On UNIX operating systems, SIGPIPE is caught and its passage is noted in the logfile.

Periodic Cleanup

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.

Appendix A - Sample ipmerge.ini
# 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