MQ Get
User ManualTable of Contents
Synopsis
General
Configuration
Critical-Message NotificationSystem Command
PrinterEnvironment Variables
Scripts
File FormatsLog File
Deal File
Critical Message FileDaemon Mode
Interactive Mode
Signal HandlingPeriodic Cleanup
Appendix A - Sample mq.conf
MQ Get
User ManualSynopsis
mqget TCID script_ext
General
Please note: this product loads deals into both Front and Back Office systems; therefore, the terms are used interchangeably.
mqget fetches deal records from an IBM MQ queue and calls the Softek Script System to load these deals into a back office system (BOS).
TCID is a four character code that will be used to distinguish this application's audit files from those produced by other applications.
script_ext is appended to scriptnames as an extension and allows scripts for different applications to share a directory.
Configuration
When mqget starts, it reads the file mq.conf which contains information about from where data records are to be fetched and, if the data target is MQ based, what queue name mapping and default MQ server is available. The first line of the mq.conf file contains six white space separated tokens but only the first two are used by mqget. The first token starts with an "@" character and denotes the Queue Manager that hosts the Queue Name (second token) from which deal records will be read. The rest of the tokens must be present but are otherwise ignored by this application and may be set to any values.
The second and subsequent lines in mq.conf are only used if this application is configured to send its Back Office output to an MQ queue. The second line contains one or two tokens. The first token is the name of the default output queue and the optional second token is the name of the Queue Manager that hosts this queue.
The rest of this file (third line to the end) contain mappings used by the namemap transform that are used when configurability is required when Softek Scripts are used to load data into an MQ queue.
Lines, in the file mq.conf, starting with the “hash” character (#) are ignored (they are comments or temporarily disabled configuration lines).
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 <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” 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. The file <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.
Printer
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.
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.
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_LOGDIR The contents of the variable denotes the directory in which the logfiles will be created.
MRG_DLSDIR Denotes the directory where the dealfiles will be created.
MRG_DBTIMEOUT Set to the number of seconds of inactivity before a database handle is deemed to be stale. The next database access will cause the database handle to be refreshed without making an attempt to use the old handle. Only useful if the mqget is configured to use a database.
Scripts
Spectfic events cause mqget to execute scripts. These scripts have a specific basename but have an extension given by the second argument to the call to mqget.
Event Script Basename Program Startup startup. Program Shutdown shutdown. Spot Deal Received mqgetspot.
File Formats
Log File
A logfile named <TCID><MMDD>.log (where <TCID> is the string of four characters given as the first argument to this program 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. A deal identifier is logged whenever a deal is passed to the BOS.
If mqget is left running overnight, a new logfile is automatically created as soon as necessary after midnight.
Deal File
A dealfile named <TCID><MMDD>.dls (where <TCID> is the string of four characters given as the first argument to this program and <MMDD> stands for the digits representing the month and day that the file was created) is appended to as deal records are fetched from the feed queue. The records are plain text and follow a regular format.
If mqget is left running overnight, a new dealfile 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 mqget are in the 30,000 to 39,999 range.
For Example:
mqget [Tue Nov 14 19:03:06 1995] mqget SHUTDOWN #30219
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, mqget 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
- eof mqget 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 mqget. Each day that mqget is executed, 1 new file (a log file) is created in the mqget log directory and another is created in the deals directory. It is suggested that these files are archived and deleted from the drive every few months.
Appendix A - Sample mq.conf # @DDQManager DDIInQueueName DDOutQName PINGString PingACK ACK NACK
@QM.DEALDROP.DEV DEALDROP.HOTSPOT.FEDS none none none none none
# DefaultQName<white_space>OptionalQueueManagerName
DEALDROP.HOTSPOT.FEDS QM.DEALDROP.DEV
# all subsequent lines are QName mappings for "namemap" script transform
dealdrop DEALDROP.HOTSPOT.FEDS
humanreview HUMANREVIEW.IN
Page Last Updated 09/11/04
Warning... this manual is *not* year 3000 compliant.