Page Last Updated 1/5/99Deal-Processor
User ManualTable of Contents
Synopsis
General
Critical-Message NotificationSystem CommandEnvironment Variables
File FormatsLog File
Sequence File
Critical Message FileDaemon Mode
Interactive Mode
Signal Handling
Deal-Processor
User ManualSynopsis
rdealproc [tcid [days|mmdd [wdir [script-ext [dummy [port [steer]]]]]]]
edealproc [tcid [days|mmdd [wdir [script-ext [dummy [port [steer]]]]]]]
General
DealProc reads dealing information from a Softek deal store and calls scripts as if those deal had originated from a directly connected Reuters or EBS deal server. DealProc uses a deal store gathered, from a "real" Dealing 2000 or EBS server, by Genesis FX and runs on any hardware and operating system that supports an ANSI C compiler. The deal store is examined in real-time for newly arrived deals.
The parameters for DealProc are as follows:
tcid a sequence of four alpha-numeric characters that uniquely identify this instance of DealProc. This sequence should correspond to the TCID of the interface whose stored deals are being processed.
days|mmdd the number of days to look into the past, in the deal store, for deals. If the requirement is to load a complete .dls file of deals then this argument should contain the full 2-digit month and 2-digit day designator for the .dls file to be loaded (e.g. January 31st would be 0131). If the mmdd form is used, DealProc will exit after the specified .dls file has been completely processed.
wdir the path to the directory containing the corresponding Softek interface’s “.dls” files.
script-ext a different script file is executed for each different deal type read from the deal store. The root name of the executed script file depends on the server and deal type that has just been received, e.g. dofx for Reuters FX deals, doswap for Reuters swap deals, fxebs for EBS FX deals, etc. The script-file filename extension that is used for the current interface session may be changed. For example, an argument of xxx, will cause script files dofx.xxx, doswap.xxx, etc. to be used when Reuters deals are read.
dummy this parameter is unused, it is present for backwards compatibility purposes and may be set to any value.
port designates the TCP-IP base port number to use for status and data. Two numbers (port and port +1) are used. Port number port is used for TCP-IP control and port number port+1 is used for TCP-IP data (deal records). Operating systems that have a "services" file may use a port name which will automatically be mapped to the designated port number.
steer this optional parameter designates a filename (in the optional sequence directory) containing whitespace separated numbers that represent the ticket number to be loaded from the dealstore. Once all the deals referenced in this file have all been processed, DealProc will exit. Please note: The order of ticket numbers in this file is taken literally. No sorting or duplicate-removal is performed. Certain data transformation operations e.g. notfirstmatch may require all deals of a group to be loaded in order to function correctly.
Critical-Message Notification
System Command
Critical Messages are 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 <TCID>.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 <TCID>.msg may be processed with “uniq” (on UNIX) for example, as follows:
setenv MRG_ECMD “(uniq -6 | cat > /dev/console)”
Each line in the <TCID>.msg file is timestamped and its process-origin is identified. <TCID>.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.
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 “DL_” and are as follows:DL_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.
DL_WDIR The equivalent Softek interface “.dls” directory.
DL_LOGDIR The directory where transitory work files will be stored. Both critical messages and conversation details (Reuters only) make a temporary appearance in this directory.
DL_MSGDIR The directory where transitory work files will be stored. Both critical messages and conversation details (Reuters only) make a temporary appearance in this directory.
DL_SEQDIR The directory where transitory work files will be stored. Both critical messages and conversation details (Reuters only) make a temporary appearance in this directory.
DL_DAYS The number of days into the past from which this deal processor will serve deals. As with the days|mmdd program argument, the value of this variable may be used to represent a 4-character mmdd month-day designator that is used to identify a .dls file from which all deals will be processed.
DL_STEER References a file in the sequence directory that contains specific whitespace-separated deal ticket numbers to be processed. After processing these deals, DealProc exits.File Formats
Log File
A logfile named <tcid><mmdd>.log (where <TCID> is the string used as the first parameter to DealProc and <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.
If DealProc is left running overnight, a new logfile is automatically created as soon as necessary after midnight.
Sequence File
The file dl_r<TCID>.seq (Reuters) or dl_qQUOT.seq (EBS) contains the ASCII representation of the ticket number (followed by the normal end-of-line character(s) for the operating system) for the last complete deal reported in the dealfile. Subsequent invocations of DealProc with the same TCID will look for ticket numbers greater than the number stored in this file. For maintenance purposes, this file may be edited by any text editor. NOTE: VMS users should ensure that the resulting (edited) file has version number ;1.
Critical Message File
(UNIX and NT installations only, see “Critical-Message Notification” above)
The file <tcid><mmdd>.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 DealProc are in the 90,000 to 99,999 range..
For Example:
dealproc [Tue Nov 14 19:03:06 1995] Expected end of deal 3002, got start of deal 3003 #90501
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, DealProc 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 and Windows NT require a <CR> to be appended for the command to be accepted:
q or Q quit the program gracefully
eof DealProc 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 DealProc. Each day that DealProc is executed, a new file (a log file) is created in the DealProc execution directory. It is suggested that these files are archived and deleted from the drive every few months.