quickfix-developers Mailing List for QuickFIX (Page 290)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chuck H. <zzc...@xc...> - 2003-03-06 14:52:02
|
I'm having trouble getting quickfix 1.3.2 compiled under Solaris 8 with = gcc-3.2.2 Here's the setup I have: From www.sunfreeware.com, I've installed: gcc-3.2.2-sol8-sparc-local in /usr/local I built and installed libxml2-2.4.30 in /usr/local The quickfix instructions say glibc is required for Solaris, but there = isn't a pre-packaged version on sunfreeware, and the glibc source (2.x) = complains that Solaris isn't supported, so I went ahead without it = (probably a bad idea...). ./configure and make seem to run ok, but when I try to install, it seems = to have trouble with install-sh (see below). Any ideas on where I've gone wrong would be greatly appreciated. Thanks - Chuck /make install Making install in src make[1]: Entering directory `/tmp/quickfix/src' Making install in C++ make[2]: Entering directory `/tmp/quickfix/src/C++' Making install in test make[3]: Entering directory `/tmp/quickfix/src/C++/test' make[4]: Entering directory `/tmp/quickfix/src/C++/test' make[4]: Nothing to be done for `install-exec-am'. make[4]: Nothing to be done for `install-data-am'. make[4]: Leaving directory `/tmp/quickfix/src/C++/test' make[3]: Leaving directory `/tmp/quickfix/src/C++/test' make[3]: Entering directory `/tmp/quickfix/src/C++' rm -rf ../../lib/libquickfix.a rm -rf ../../lib/libquickfix.la ln -s ../src/C++/.libs/libquickfix.a ../../lib/libquickfix.a ln -s ../src/C++/.libs/libquickfix.la ../../lib/libquickfix.la ./copy.sh *.h make[4]: Entering directory `/tmp/quickfix/src/C++' /bin/sh ../../mkinstalldirs /usr/local/lib /bin/sh ../../libtool --mode=3Dinstall ../.././install-sh -c = libquickfix.la /usr/ local/lib/libquickfix.la ../.././install-sh -c .libs/libquickfix.lai = /usr/local/lib/libquickfix.la ../../libtool: ../.././install-sh: not found make[4]: *** [install-libLTLIBRARIES] Error 1 make[4]: Leaving directory `/tmp/quickfix/src/C++' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/tmp/quickfix/src/C++' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/tmp/quickfix/src/C++' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/tmp/quickfix/src' make: *** [install-recursive] Error 1 |
|
From: <gar...@su...> - 2003-03-05 06:13:41
|
PFA+VGhhbmtzIHRvIE9yZW4gYW5kIEdlbmUgZm9yIHlvdXIgaW5wdXQgb24gbXkgcHJvYmxlbXMu ICZuYnNwO0Rlc3BpdGUgbWUgdmVyaWZ5aW5nIHRoYXQgdGhlIHZhbGlkYXRpb24gZmlsZSB3YXMg dGhlcmUgYW5kIGV4YWN0bHkgYXMgaXQgd2FzIGluIG15IHdvcmtpbmcgZW52aXJvbm1lbnQsIGl0 IHR1cm5zIG91dCB0aGF0IHRoZSBpbml0LmQgc3RhcnR1cCBzY3JpcHRzIHdlcmUgc3BlY2lmeWlu ZyB0byBzdGFydCBpbiBhIGRpZmZlcmVudCBkaXJlY3RvcnkgdGhhbiBteSBzdGFydHVwIHNjcmlw dHMuICZuYnNwO1RoZXJlZm9yZSwgdGhlIHJlbGF0aXZlIHNwZWNpZmljYXRpb24gb2YgdGhlIHZh bGlkYXRpb24gZmlsZSB3YXMgaW5jb3JyZWN0LiAmbmJzcDtBIHNpbXBsZSBzeW1saW5rIGZpeGVk IGFsbCBvZiBteSBwcm9ibGVtcyBhbmQgaXQncyB3b3JraW5nIGFzIGV4cGVjdGVkLjwvUD48UD5U aGFua3MgYWdhaW4gZm9yIHlvdXIgaGVscC4gJm5ic3A7SSdtIHJlYWxseSBhcHByZWNpYXRpdmUg b2YgdGhpcyBwcm9qZWN0IGFuZCBhbGwgb2YgeW91ciBoZWxwZnVsbmVzcy4gJm5ic3A7V2l0aCBh bnkgbHVjaywgd2Ugc2hvdWxkIGJlIG1vdmluZyBpbnRvIHByb2R1Y3Rpb24gd2l0aCBvdXIgZmly c3QgRklYIGNsaWVudCB0aGlzIHdlZWshPC9QPjxQPiZuYnNwOzwvUD48UD5HYXJ5IE11aTxCUj5Q cmVzY2llbnQgTWFya2V0cywgSW5jIDkxNC05ODktMzExOCAoVyk8QlI+NDQ1IEhhbWlsdG9uIEF2 ZW51ZSA5MTQtNDIyLTM2OTMgKEYpPEJSPldoaXRlIFBsYWlucywgTlkgMTA2MDEgPEJSPjxCUj5Q bGVhc2UgdmlzaXQgdXMgYXQgPEEgSFJFRj1odHRwOi8vd3d3LmNwbWFya2V0LmNvbT5odHRwOi8v d3d3LmNwbWFya2V0LmNvbTwvQT4gPC9QPg== |
|
From: Oren M. <ore...@ya...> - 2003-03-05 02:32:43
|
Have you applied this patch? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/java/Conversions.h.diff?r1=1.3&r2=1.4&only_with_tag=MAIN If not, this may explain the behavior you are seeing. We used to use setString to copy the message before passing it to the java fromApp, which would cause the fields to go out of order because no dictionary was provided. We then switched to properly using the copy operator. I think this is likely the case in your situation. If you hadn't supplied a data dictionary correctly, then it is unlikely your message would make it through to the fromApp since it would fail the message length and the checksum tests. At this point it already passed those tests and is being improperly converted after the fact. I believe Gene submitted this fix some time back. --- gar...@su... wrote: > > > Here is the message as it is stored on the sending > side (where it looks > right) > > 8=FIX.4.29=41435=J34=449=FMRFITST52=20030304-22:06:5456=STNMMTST > 6=99.99166715=USD22=148=CUSIP53=100000054=155=FIXED > 60=20030304-21:14:2770=Allocation: > 071=373=111=NONREF37=155888 > 75=2003030478=179=FCUSM80=1000000154=999916.676604=PartAllocID:1 > 106=GECC118=100124=132=100000017=155888_20031404_16142731=3 > 6640=99.991667381=999916.676609=CP6611=1006613=MONEYMARKET6614=1 > 6629=MATURITY6637=2003060410=038 > > > > Here is the message as it is stored in my incoming > message store (on the > side that it is wrong) > > 8=FIX.4.29=41435=J34=449=FMRFITST52=20030304-22:06:5456=STNMMTST > 6=99.99166711=NONREF15=USD17=155888_20031404_16142722=131=332=1000000 > 37=15588848=CUSIP53=100000054=155=FIXED60=20030304-21:14:27 > 70=Allocation: > 071=373=175=2003030478=179=FCUSM80=1000000106=GECC > 118=100124=1154=999916.67381=999916.676604=PartAllocID:16609=CP > 6611=1006613=MONEYMARKET6614=16629=MATURITY6637=200306046640=99.991667 > 10=038 > > > Here also is my fromApp implementation so you can > see that I am printing > out the xml of the trade before storing it: > > > public void fromApp(org.quickfix.Message message, > SessionID sessionID) > throws FieldNotFound, > UnsupportedMessageType, IncorrectTagValue { > LogUtil.debug ("Message received (" + > sessionID + ") type: " + > message.getClass() + "\n " + message.toXML()); > storeIncomingMessage (message, sessionID); > > crack((org.quickfix.Message) message, > sessionID); > } > > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: > qui...@li..., > > > qui...@li...ur > qui...@li... > > ceforge.net > cc: > > > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > 03/04/03 05:10 PM > > > Please respond to omiller > > > > > > > > > > > > Field order is generally not important, except when > it > comes to repeating groups where it is very > important. > If the fields get out of order somewhere, that would > cause a problem trying to parse the message. > > If you are getting messages from the QF callback, > and > the session is given the correct DataDictionary, > then > the fields should be in the same order on both sides > (assuming you are using QF on both sides, other > engines may vary the order). > > If you can post the string of the stored message > that > may provide a clue. > > --- gar...@su... wrote: > > > > Yes, the data dictionary is exactly the same as > the > > working version. > > > > One of the things I was wondering was whether it > > mattered where the native > > libraries were compiled. Right now I am packaging > > all the native libraries > > (stdc++, quickfix, quickfix_jni, xml2, and > stlport) > > on one machine and am > > including those in my deployment package. Is it a > > coincidence that the > > machine that this works for is the same machine > the > > libraries were compiled > > on? > > > > Also, does the order of the fields as they appear > in > > the message store have > > any indication as to the order that is used when > > parsing and generating the > > message? As I mentioned in a different thread, I > > have an Incoming message > > store where I store every message received by the > > FIX engine. When I look > > at the allocation message in that message store, > it > > does appear that some > > of the fields are not in the same order as in the > > FileStore of the sending > > FIX engine. Could the saving of the message into > > another message store > > somehow corrupt the field order? > > > > > > > > Gary Mui > > Prescient Markets, Inc 914-989-3118 (W) > > 445 Hamilton Avenue 914-422-3693 (F) > > White Plains, NY 10601 > > > > Please visit us at http://www.cpmarket.com > > > > > > > > > > > > Oren Miller > > <ore...@ya...> > > > > > > Sent by: > > To: gar...@su..., > > qui...@li... > > > > qui...@li...ur cc: > > > > > > ceforge.net > > Subject: Re: [Quickfix-developers] > > mixed up pasting - please look here for > > > > details > > > > > > > > > > 03/04/03 04:32 PM > > > > > > Please respond to omiller > > > > > > > > > > > > > > > > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Gene G. <mus...@ya...> - 2003-03-05 02:19:26
|
Like Oren mentioned before, this looks exactly like symptoms for missing or incorrect DataDictionary XML on the receiving side. Creation and sending of group message does not require it, while parsing and receiving does; triple check your config file. Also, there used to be a problem with older FIX versions that did not handle absolute paths to the data dictionary XML properly on Unix, and one always had to use relative notation. We had a patch out a couple of months ago. Perhaps you have an unpatched version and use full path? Gene --- gar...@su... wrote: > > Also, > > I tried running the FIX engine that is generating > these allocation messages > on the same environment and there doesn't seem to be > any trouble in > creating allocation messages with repeating groups. > I can even send out > allocation messages with the right repeating groups > from the same fix > engine that cannot seem to receive and parse them. > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: > qui...@li..., > > > qui...@li...ur > qui...@li... > > ceforge.net > cc: > > > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > 03/04/03 05:10 PM > > > Please respond to omiller > > > > > > > > > > > > Field order is generally not important, except when > it > comes to repeating groups where it is very > important. > If the fields get out of order somewhere, that would > cause a problem trying to parse the message. > > If you are getting messages from the QF callback, > and > the session is given the correct DataDictionary, > then > the fields should be in the same order on both sides > (assuming you are using QF on both sides, other > engines may vary the order). > > If you can post the string of the stored message > that > may provide a clue. > > --- gar...@su... wrote: > > > > Yes, the data dictionary is exactly the same as > the > > working version. > > > > One of the things I was wondering was whether it > > mattered where the native > > libraries were compiled. Right now I am packaging > > all the native libraries > > (stdc++, quickfix, quickfix_jni, xml2, and > stlport) > > on one machine and am > > including those in my deployment package. Is it a > > coincidence that the > > machine that this works for is the same machine > the > > libraries were compiled > > on? > > > > Also, does the order of the fields as they appear > in > > the message store have > > any indication as to the order that is used when > > parsing and generating the > > message? As I mentioned in a different thread, I > > have an Incoming message > > store where I store every message received by the > > FIX engine. When I look > > at the allocation message in that message store, > it > > does appear that some > > of the fields are not in the same order as in the > > FileStore of the sending > > FIX engine. Could the saving of the message into > > another message store > > somehow corrupt the field order? > > > > > > > > Gary Mui > > Prescient Markets, Inc 914-989-3118 (W) > > 445 Hamilton Avenue 914-422-3693 (F) > > White Plains, NY 10601 > > > > Please visit us at http://www.cpmarket.com > > > > > > > > > > > > Oren Miller > > <ore...@ya...> > > > > > > Sent by: > > To: gar...@su..., > > qui...@li... > > > > qui...@li...ur cc: > > > > > > ceforge.net > > Subject: Re: [Quickfix-developers] > > mixed up pasting - please look here for > > > > details > > > > > > > > > > 03/04/03 04:32 PM > > > > > > Please respond to omiller > > > > > > > > > > > > > > > > > > > > > > > > Did you copy your data dictionary over to the new > > machine? The data dictionary of the receiving > > application would need to have the proper groups > > defined. > > > > --- gar...@su... wrote: > > > Oops - please ignore the prior email. I mixed > up > > > the pasting of the > > > messages.... > > > > > > > > > > > > > > > I've run into a serious problem that I haven't > > been > > > able to figure out. > > > > > > In trying to send across allocation messages > > (which > > > contain groups), I am > > > able to successfully do so on my development > > > platform. When I move the > > > receiving FIX engine to another environment > (same > > > class machine, same java > > > version, same OS version-solaris 8), the > receiving > > > side is unable to parse > > > the allocation message correctly which causes > the > > > processing to fail. > > > > > > My outgoing message appears to be right in its > XML > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: <gar...@su...> - 2003-03-04 22:18:28
|
Also, I tried running the FIX engine that is generating these allocation messages on the same environment and there doesn't seem to be any trouble in creating allocation messages with repeating groups. I can even send out allocation messages with the right repeating groups from the same fix engine that cannot seem to receive and parse them. Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: qui...@li..., qui...@li...ur qui...@li... ceforge.net cc: Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 05:10 PM Please respond to omiller Field order is generally not important, except when it comes to repeating groups where it is very important. If the fields get out of order somewhere, that would cause a problem trying to parse the message. If you are getting messages from the QF callback, and the session is given the correct DataDictionary, then the fields should be in the same order on both sides (assuming you are using QF on both sides, other engines may vary the order). If you can post the string of the stored message that may provide a clue. --- gar...@su... wrote: > > Yes, the data dictionary is exactly the same as the > working version. > > One of the things I was wondering was whether it > mattered where the native > libraries were compiled. Right now I am packaging > all the native libraries > (stdc++, quickfix, quickfix_jni, xml2, and stlport) > on one machine and am > including those in my deployment package. Is it a > coincidence that the > machine that this works for is the same machine the > libraries were compiled > on? > > Also, does the order of the fields as they appear in > the message store have > any indication as to the order that is used when > parsing and generating the > message? As I mentioned in a different thread, I > have an Incoming message > store where I store every message received by the > FIX engine. When I look > at the allocation message in that message store, it > does appear that some > of the fields are not in the same order as in the > FileStore of the sending > FIX engine. Could the saving of the message into > another message store > somehow corrupt the field order? > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: gar...@su..., > qui...@li... > > qui...@li...ur cc: > > > ceforge.net > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > > > > 03/04/03 04:32 PM > > > Please respond to omiller > > > > > > > > > > > > Did you copy your data dictionary over to the new > machine? The data dictionary of the receiving > application would need to have the proper groups > defined. > > --- gar...@su... wrote: > > Oops - please ignore the prior email. I mixed up > > the pasting of the > > messages.... > > > > > > > > > > I've run into a serious problem that I haven't > been > > able to figure out. > > > > In trying to send across allocation messages > (which > > contain groups), I am > > able to successfully do so on my development > > platform. When I move the > > receiving FIX engine to another environment (same > > class machine, same java > > version, same OS version-solaris 8), the receiving > > side is unable to parse > > the allocation message correctly which causes the > > processing to fail. > > > > My outgoing message appears to be right in its XML > > form while the incoming > > message does not show the repeating group entries. > > I am also including the > > 'raw' format as printed in the output: > > > > Does anyone have any suggestions as to how to > > proceed resolving this > > problem? This is now holding up our UAT and > > production release schedules. > > > > Thanks for any help, > > Gary > > > > Outgoing > > ========= > > > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > > outgoing> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > > > > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > > > > > > <message> > > <header> > > <field number="8" value="FIX.4.2"/> > > <field number="9" value="372"/> > > <field number="35" value="J"/> > > </header> > > <body> > > <field number="6" value="99.991667"/> > > <field number="15" value="USD"/> > > <field number="22" value="1"/> > > <field number="48" value="CUSIP"/> > > <field number="53" value="1000000"/> > > <field number="54" value="1"/> > > <field number="55" value="FIXED"/> > > <field number="60" value="20030304-20:12:54"/> > > <field number="70" value="Allocation: 0"/> > > <field number="71" value="3"/> > > <field number="73" value="1"/> > > <field number="75" value="20030304"/> > > <field number="78" value="1"/> > > <field number="106" value="GECC"/> > > <field number="118" value="100"/> > > <field number="124" value="1"/> > > <field number="381" value="999916.67"/> > > <field number="6609" value="CP"/> > > <field number="6611" value="100"/> > > <field number="6613" value="MONEYMARKET"/> > > <field number="6614" value="1"/> > > <field number="6629" value="MATURITY"/> > > <field number="6637" value="20031204"/> > > <group> > > <field number="11" value="NONREF"/> > > <field number="37" value="155882"/> > > </group> > > <group> > > <field number="79" value="FCUSM"/> > > <field number="80" value="1000000"/> > > <field number="76" value="GECC"/> > > <field number="154" value="999916.67"/> > > <field number="6604" value="PartAllocID:1"/> > > </group> > > <group> > > <field number="32" value="1000000"/> > > <field number="17" > > value="155882_20031204_151254"/> > > <field number="31" value="3"/> > > <field number="6640" value="99.991667"/> > > </group> > > </body> > > <trailer> > > > > > > > > > > Incoming > > ========== > > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > > incoming> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <gar...@su...> - 2003-03-04 22:17:03
|
Here is the message as it is stored on the sending side (where it looks=
right)
8=3DFIX.4.2=019=3D414=0135=3DJ=0134=3D4=0149=3DFMRFITST=0152=3D20030304=
-22:06:54=0156=3DSTNMMTST=01
6=3D99.991667=0115=3DUSD=0122=3D1=0148=3DCUSIP=0153=3D1000000=0154=3D1=01=
55=3DFIXED=01
60=3D20030304-21:14:27=0170=3DAllocation: 0=0171=3D3=0173=3D1=0111=3DNO=
NREF=0137=3D155888=01
75=3D20030304=0178=3D1=0179=3DFCUSM=0180=3D1000000=01154=3D999916.67=01=
6604=3DPartAllocID:1=01
106=3DGECC=01118=3D100=01124=3D1=0132=3D1000000=0117=3D155888_20031404_=
161427=0131=3D3=01
6640=3D99.991667=01381=3D999916.67=016609=3DCP=016611=3D100=016613=3DMO=
NEYMARKET=016614=3D1=01
6629=3DMATURITY=016637=3D20030604=0110=3D038=01
Here is the message as it is stored in my incoming message store (on th=
e
side that it is wrong)
8=3DFIX.4.2=019=3D414=0135=3DJ=0134=3D4=0149=3DFMRFITST=0152=3D20030304=
-22:06:54=0156=3DSTNMMTST=01
6=3D99.991667=0111=3DNONREF=0115=3DUSD=0117=3D155888_20031404_161427=01=
22=3D1=0131=3D3=0132=3D1000000
=0137=3D155888=0148=3DCUSIP=0153=3D1000000=0154=3D1=0155=3DFIXED=0160=3D=
20030304-21:14:27=01
70=3DAllocation: 0=0171=3D3=0173=3D1=0175=3D20030304=0178=3D1=0179=3DFC=
USM=0180=3D1000000=01106=3DGECC=01
118=3D100=01124=3D1=01154=3D999916.67=01381=3D999916.67=016604=3DPartAl=
locID:1=016609=3DCP=01
6611=3D100=016613=3DMONEYMARKET=016614=3D1=016629=3DMATURITY=016637=3D2=
0030604=016640=3D99.991667
=0110=3D038=01
Here also is my fromApp implementation so you can see that I am printin=
g
out the xml of the trade before storing it:
public void fromApp(org.quickfix.Message message,
SessionID sessionID)
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue=
{
LogUtil.debug ("Message received (" + sessionID + ") type: " +
message.getClass() + "\n " + message.toXML());
storeIncomingMessage (message, sessionID);
crack((org.quickfix.Message) message, sessionID);
}
Gary Mui
Prescient Markets, Inc 914-989-3118 (W)
445 Hamilton Avenue 914-422-3693 (F)
White Plains, NY 10601
Please visit us at http://www.cpmarket.com
=
=
=20
Oren Miller <ore...@ya...> =
=
=20
Sent by: To: =
qui...@li..., =
=20
qui...@li...ur quic=
kfi...@li... =
=20
ceforge.net cc: =
=
=20
Subj=
ect: Re: [Quickfix-developers] mixed up pasting - please look here for =
=20
deta=
ils =
=20
03/04/03 05:10 PM =
=
=20
Please respond to omiller =
=
=20
=
=
=20
=
=
=20
Field order is generally not important, except when it
comes to repeating groups where it is very important.
If the fields get out of order somewhere, that would
cause a problem trying to parse the message.
If you are getting messages from the QF callback, and
the session is given the correct DataDictionary, then
the fields should be in the same order on both sides
(assuming you are using QF on both sides, other
engines may vary the order).
If you can post the string of the stored message that
may provide a clue.
--- gar...@su... wrote:
>
> Yes, the data dictionary is exactly the same as the
> working version.
>
> One of the things I was wondering was whether it
> mattered where the native
> libraries were compiled. Right now I am packaging
> all the native libraries
> (stdc++, quickfix, quickfix_jni, xml2, and stlport)
> on one machine and am
> including those in my deployment package. Is it a
> coincidence that the
> machine that this works for is the same machine the
> libraries were compiled
> on?
>
> Also, does the order of the fields as they appear in
> the message store have
> any indication as to the order that is used when
> parsing and generating the
> message? As I mentioned in a different thread, I
> have an Incoming message
> store where I store every message received by the
> FIX engine. When I look
> at the allocation message in that message store, it
> does appear that some
> of the fields are not in the same order as in the
> FileStore of the sending
> FIX engine. Could the saving of the message into
> another message store
> somehow corrupt the field order?
>
>
>
> Gary Mui
> Prescient Markets, Inc 914-989-3118 (W)
> 445 Hamilton Avenue 914-422-3693 (F)
> White Plains, NY 10601
>
> Please visit us at http://www.cpmarket.com
>
>
>
>
>
> Oren Miller
> <ore...@ya...>
>
>
> Sent by:
> To: gar...@su...,
> qui...@li...
>
> qui...@li...ur cc:
>
>
> ceforge.net
> Subject: Re: [Quickfix-developers]
> mixed up pasting - please look here for
>
> details
>
>
>
>
> 03/04/03 04:32 PM
>
>
> Please respond to omiller
>
>
>
>
>
>
>
>
>
>
>
> Did you copy your data dictionary over to the new
> machine? The data dictionary of the receiving
> application would need to have the proper groups
> defined.
>
> --- gar...@su... wrote:
> > Oops - please ignore the prior email. I mixed up
> > the pasting of the
> > messages....
> >
> >
> >
> >
> > I've run into a serious problem that I haven't
> been
> > able to figure out.
> >
> > In trying to send across allocation messages
> (which
> > contain groups), I am
> > able to successfully do so on my development
> > platform. When I move the
> > receiving FIX engine to another environment (same
> > class machine, same java
> > version, same OS version-solaris 8), the receiving
> > side is unable to parse
> > the allocation message correctly which causes the
> > processing to fail.
> >
> > My outgoing message appears to be right in its XML
> > form while the incoming
> > message does not show the repeating group entries.
> > I am also including the
> > 'raw' format as printed in the output:
> >
> > Does anyone have any suggestions as to how to
> > proceed resolving this
> > problem? This is now holding up our UAT and
> > production release schedules.
> >
> > Thanks for any help,
> > Gary
> >
> > Outgoing
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST,
> > outgoing>
> >
> >
>
(8=3DFIX.4.2^A9=3D424^A35=3DJ^A34=3D474^A49=3DFMRFITST^A52=3D20030304-2=
0:12:56^A56=3DSTNMMTST^A6=3D99.991667^A15=3DUSD^A22=3D1^A48=3DCUSIP^A53=
=3D1000000^A54=3D1^A55=3DFIXED^A60=3D20030304-20:12:54^A70=3DAllocation=
:
>
> >
> >
>
0^A71=3D3^A73=3D1^A11=3DNONREF^A37=3D155882^A75=3D20030304^A78=3D1^A79=3D=
FCUSM^A80=3D1000000^A76=3DGECC^A154=3D999916.67^A6604=3DPartAllocID:1^A=
106=3DGECC^A118=3D100^A124=3D1^A32=3D1000000^A17=3D155882_20031204_1512=
54^A31=3D3^A6640=3D99.991667^A381=3D999916.67^A6609=3DCP^A6611=3D100^A6=
613=3DMONEYMARKET^A6614=3D1^A6629=3DMATURITY^A6637=3D20031204^A10=3D053=
^A)
>
> >
> >
> >
> > <message>
> > <header>
> > <field number=3D"8" value=3D"FIX.4.2"/>
> > <field number=3D"9" value=3D"372"/>
> > <field number=3D"35" value=3D"J"/>
> > </header>
> > <body>
> > <field number=3D"6" value=3D"99.991667"/>
> > <field number=3D"15" value=3D"USD"/>
> > <field number=3D"22" value=3D"1"/>
> > <field number=3D"48" value=3D"CUSIP"/>
> > <field number=3D"53" value=3D"1000000"/>
> > <field number=3D"54" value=3D"1"/>
> > <field number=3D"55" value=3D"FIXED"/>
> > <field number=3D"60" value=3D"20030304-20:12:54"/>
> > <field number=3D"70" value=3D"Allocation: 0"/>
> > <field number=3D"71" value=3D"3"/>
> > <field number=3D"73" value=3D"1"/>
> > <field number=3D"75" value=3D"20030304"/>
> > <field number=3D"78" value=3D"1"/>
> > <field number=3D"106" value=3D"GECC"/>
> > <field number=3D"118" value=3D"100"/>
> > <field number=3D"124" value=3D"1"/>
> > <field number=3D"381" value=3D"999916.67"/>
> > <field number=3D"6609" value=3D"CP"/>
> > <field number=3D"6611" value=3D"100"/>
> > <field number=3D"6613" value=3D"MONEYMARKET"/>
> > <field number=3D"6614" value=3D"1"/>
> > <field number=3D"6629" value=3D"MATURITY"/>
> > <field number=3D"6637" value=3D"20031204"/>
> > <group>
> > <field number=3D"11" value=3D"NONREF"/>
> > <field number=3D"37" value=3D"155882"/>
> > </group>
> > <group>
> > <field number=3D"79" value=3D"FCUSM"/>
> > <field number=3D"80" value=3D"1000000"/>
> > <field number=3D"76" value=3D"GECC"/>
> > <field number=3D"154" value=3D"999916.67"/>
> > <field number=3D"6604" value=3D"PartAllocID:1"/>
> > </group>
> > <group>
> > <field number=3D"32" value=3D"1000000"/>
> > <field number=3D"17"
> > value=3D"155882_20031204_151254"/>
> > <field number=3D"31" value=3D"3"/>
> > <field number=3D"6640" value=3D"99.991667"/>
> > </group>
> > </body>
> > <trailer>
> >
> >
> >
> >
> > Incoming
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST,
> > incoming>
> >
> >
>
(8=3DFIX.4.2^A9=3D424^A35=3DJ^A34=3D474^A49=3DFMRFITST^A52=3D20030304-2=
0:12:56^A56=3DSTNMMTST^A6=3D99.991667^A15=3DUSD^A22=3D1^A48=3DCUSIP^A53=
=3D1000000^A54=3D1^A55=3DFIXED^A60=3D20030304-20:12:54^A70=3DAllocation=
:
>
>
=3D=3D=3D message truncated =3D=3D=3D
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debu=
gger
for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd
disoriented. TotalView can help you find your way. Available on major U=
NIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
=
|
|
From: Oren M. <ore...@ya...> - 2003-03-04 22:10:28
|
Field order is generally not important, except when it comes to repeating groups where it is very important. If the fields get out of order somewhere, that would cause a problem trying to parse the message. If you are getting messages from the QF callback, and the session is given the correct DataDictionary, then the fields should be in the same order on both sides (assuming you are using QF on both sides, other engines may vary the order). If you can post the string of the stored message that may provide a clue. --- gar...@su... wrote: > > Yes, the data dictionary is exactly the same as the > working version. > > One of the things I was wondering was whether it > mattered where the native > libraries were compiled. Right now I am packaging > all the native libraries > (stdc++, quickfix, quickfix_jni, xml2, and stlport) > on one machine and am > including those in my deployment package. Is it a > coincidence that the > machine that this works for is the same machine the > libraries were compiled > on? > > Also, does the order of the fields as they appear in > the message store have > any indication as to the order that is used when > parsing and generating the > message? As I mentioned in a different thread, I > have an Incoming message > store where I store every message received by the > FIX engine. When I look > at the allocation message in that message store, it > does appear that some > of the fields are not in the same order as in the > FileStore of the sending > FIX engine. Could the saving of the message into > another message store > somehow corrupt the field order? > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: gar...@su..., > qui...@li... > > qui...@li...ur cc: > > > ceforge.net > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > > > > 03/04/03 04:32 PM > > > Please respond to omiller > > > > > > > > > > > > Did you copy your data dictionary over to the new > machine? The data dictionary of the receiving > application would need to have the proper groups > defined. > > --- gar...@su... wrote: > > Oops - please ignore the prior email. I mixed up > > the pasting of the > > messages.... > > > > > > > > > > I've run into a serious problem that I haven't > been > > able to figure out. > > > > In trying to send across allocation messages > (which > > contain groups), I am > > able to successfully do so on my development > > platform. When I move the > > receiving FIX engine to another environment (same > > class machine, same java > > version, same OS version-solaris 8), the receiving > > side is unable to parse > > the allocation message correctly which causes the > > processing to fail. > > > > My outgoing message appears to be right in its XML > > form while the incoming > > message does not show the repeating group entries. > > I am also including the > > 'raw' format as printed in the output: > > > > Does anyone have any suggestions as to how to > > proceed resolving this > > problem? This is now holding up our UAT and > > production release schedules. > > > > Thanks for any help, > > Gary > > > > Outgoing > > ========= > > > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > > outgoing> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > > > > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > > > > > > <message> > > <header> > > <field number="8" value="FIX.4.2"/> > > <field number="9" value="372"/> > > <field number="35" value="J"/> > > </header> > > <body> > > <field number="6" value="99.991667"/> > > <field number="15" value="USD"/> > > <field number="22" value="1"/> > > <field number="48" value="CUSIP"/> > > <field number="53" value="1000000"/> > > <field number="54" value="1"/> > > <field number="55" value="FIXED"/> > > <field number="60" value="20030304-20:12:54"/> > > <field number="70" value="Allocation: 0"/> > > <field number="71" value="3"/> > > <field number="73" value="1"/> > > <field number="75" value="20030304"/> > > <field number="78" value="1"/> > > <field number="106" value="GECC"/> > > <field number="118" value="100"/> > > <field number="124" value="1"/> > > <field number="381" value="999916.67"/> > > <field number="6609" value="CP"/> > > <field number="6611" value="100"/> > > <field number="6613" value="MONEYMARKET"/> > > <field number="6614" value="1"/> > > <field number="6629" value="MATURITY"/> > > <field number="6637" value="20031204"/> > > <group> > > <field number="11" value="NONREF"/> > > <field number="37" value="155882"/> > > </group> > > <group> > > <field number="79" value="FCUSM"/> > > <field number="80" value="1000000"/> > > <field number="76" value="GECC"/> > > <field number="154" value="999916.67"/> > > <field number="6604" value="PartAllocID:1"/> > > </group> > > <group> > > <field number="32" value="1000000"/> > > <field number="17" > > value="155882_20031204_151254"/> > > <field number="31" value="3"/> > > <field number="6640" value="99.991667"/> > > </group> > > </body> > > <trailer> > > > > > > > > > > Incoming > > ========== > > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > > incoming> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: <gar...@su...> - 2003-03-04 21:49:15
|
Actually, my xml printout of the trade happens before I store the incoming message so saving it can't be the reason why the message is not getting parsed correctly.... Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com gar...@su... Sent by: To: om...@th... qui...@li...ur cc: qui...@li..., ceforge.net qui...@li... Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 04:40 PM Yes, the data dictionary is exactly the same as the working version. One of the things I was wondering was whether it mattered where the native libraries were compiled. Right now I am packaging all the native libraries (stdc++, quickfix, quickfix_jni, xml2, and stlport) on one machine and am including those in my deployment package. Is it a coincidence that the machine that this works for is the same machine the libraries were compiled on? Also, does the order of the fields as they appear in the message store have any indication as to the order that is used when parsing and generating the message? As I mentioned in a different thread, I have an Incoming message store where I store every message received by the FIX engine. When I look at the allocation message in that message store, it does appear that some of the fields are not in the same order as in the FileStore of the sending FIX engine. Could the saving of the message into another message store somehow corrupt the field order? Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: gar...@su..., qui...@li... qui...@li...ur cc: ceforge.net Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 04:32 PM Please respond to omiller Did you copy your data dictionary over to the new machine? The data dictionary of the receiving application would need to have the proper groups defined. --- gar...@su... wrote: > Oops - please ignore the prior email. I mixed up > the pasting of the > messages.... > > > > > I've run into a serious problem that I haven't been > able to figure out. > > In trying to send across allocation messages (which > contain groups), I am > able to successfully do so on my development > platform. When I move the > receiving FIX engine to another environment (same > class machine, same java > version, same OS version-solaris 8), the receiving > side is unable to parse > the allocation message correctly which causes the > processing to fail. > > My outgoing message appears to be right in its XML > form while the incoming > message does not show the repeating group entries. > I am also including the > 'raw' format as printed in the output: > > Does anyone have any suggestions as to how to > proceed resolving this > problem? This is now holding up our UAT and > production release schedules. > > Thanks for any help, > Gary > > Outgoing > ========= > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > outgoing> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="372"/> > <field number="35" value="J"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="15" value="USD"/> > <field number="22" value="1"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="78" value="1"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="381" value="999916.67"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <group> > <field number="11" value="NONREF"/> > <field number="37" value="155882"/> > </group> > <group> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="76" value="GECC"/> > <field number="154" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > </group> > <group> > <field number="32" value="1000000"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="31" value="3"/> > <field number="6640" value="99.991667"/> > </group> > </body> > <trailer> > > > > > Incoming > ========== > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > incoming> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="424"/> > <field number="35" value="J"/> > <field number="34" value="474"/> > <field number="49" value="FMRFITST"/> > <field number="52" value="20030304-20:12:56"/> > <field number="56" value="STNMMTST"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="11" value="NONREF"/> > <field number="15" value="USD"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="22" value="1"/> > <field number="31" value="3"/> > <field number="32" value="1000000"/> > <field number="37" value="155882"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="76" value="GECC"/> > <field number="78" value="1"/> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="154" value="999916.67"/> > <field number="381" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <field number="6640" value="99.991667"/> > </body> > <trailer> > <field number="10" value="053"/> > </trailer> > </message> > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <gar...@su...> - 2003-03-04 21:41:01
|
Yes, the data dictionary is exactly the same as the working version. One of the things I was wondering was whether it mattered where the native libraries were compiled. Right now I am packaging all the native libraries (stdc++, quickfix, quickfix_jni, xml2, and stlport) on one machine and am including those in my deployment package. Is it a coincidence that the machine that this works for is the same machine the libraries were compiled on? Also, does the order of the fields as they appear in the message store have any indication as to the order that is used when parsing and generating the message? As I mentioned in a different thread, I have an Incoming message store where I store every message received by the FIX engine. When I look at the allocation message in that message store, it does appear that some of the fields are not in the same order as in the FileStore of the sending FIX engine. Could the saving of the message into another message store somehow corrupt the field order? Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: gar...@su..., qui...@li... qui...@li...ur cc: ceforge.net Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 04:32 PM Please respond to omiller Did you copy your data dictionary over to the new machine? The data dictionary of the receiving application would need to have the proper groups defined. --- gar...@su... wrote: > Oops - please ignore the prior email. I mixed up > the pasting of the > messages.... > > > > > I've run into a serious problem that I haven't been > able to figure out. > > In trying to send across allocation messages (which > contain groups), I am > able to successfully do so on my development > platform. When I move the > receiving FIX engine to another environment (same > class machine, same java > version, same OS version-solaris 8), the receiving > side is unable to parse > the allocation message correctly which causes the > processing to fail. > > My outgoing message appears to be right in its XML > form while the incoming > message does not show the repeating group entries. > I am also including the > 'raw' format as printed in the output: > > Does anyone have any suggestions as to how to > proceed resolving this > problem? This is now holding up our UAT and > production release schedules. > > Thanks for any help, > Gary > > Outgoing > ========= > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > outgoing> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="372"/> > <field number="35" value="J"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="15" value="USD"/> > <field number="22" value="1"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="78" value="1"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="381" value="999916.67"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <group> > <field number="11" value="NONREF"/> > <field number="37" value="155882"/> > </group> > <group> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="76" value="GECC"/> > <field number="154" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > </group> > <group> > <field number="32" value="1000000"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="31" value="3"/> > <field number="6640" value="99.991667"/> > </group> > </body> > <trailer> > > > > > Incoming > ========== > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > incoming> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="424"/> > <field number="35" value="J"/> > <field number="34" value="474"/> > <field number="49" value="FMRFITST"/> > <field number="52" value="20030304-20:12:56"/> > <field number="56" value="STNMMTST"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="11" value="NONREF"/> > <field number="15" value="USD"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="22" value="1"/> > <field number="31" value="3"/> > <field number="32" value="1000000"/> > <field number="37" value="155882"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="76" value="GECC"/> > <field number="78" value="1"/> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="154" value="999916.67"/> > <field number="381" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <field number="6640" value="99.991667"/> > </body> > <trailer> > <field number="10" value="053"/> > </trailer> > </message> > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Oren M. <ore...@ya...> - 2003-03-04 21:32:57
|
Did you copy your data dictionary over to the new machine? The data dictionary of the receiving application would need to have the proper groups defined. --- gar...@su... wrote: > Oops - please ignore the prior email. I mixed up > the pasting of the > messages.... > > > > > I've run into a serious problem that I haven't been > able to figure out. > > In trying to send across allocation messages (which > contain groups), I am > able to successfully do so on my development > platform. When I move the > receiving FIX engine to another environment (same > class machine, same java > version, same OS version-solaris 8), the receiving > side is unable to parse > the allocation message correctly which causes the > processing to fail. > > My outgoing message appears to be right in its XML > form while the incoming > message does not show the repeating group entries. > I am also including the > 'raw' format as printed in the output: > > Does anyone have any suggestions as to how to > proceed resolving this > problem? This is now holding up our UAT and > production release schedules. > > Thanks for any help, > Gary > > Outgoing > ========= > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > outgoing> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="372"/> > <field number="35" value="J"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="15" value="USD"/> > <field number="22" value="1"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="78" value="1"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="381" value="999916.67"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <group> > <field number="11" value="NONREF"/> > <field number="37" value="155882"/> > </group> > <group> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="76" value="GECC"/> > <field number="154" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > </group> > <group> > <field number="32" value="1000000"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="31" value="3"/> > <field number="6640" value="99.991667"/> > </group> > </body> > <trailer> > > > > > Incoming > ========== > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > incoming> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="424"/> > <field number="35" value="J"/> > <field number="34" value="474"/> > <field number="49" value="FMRFITST"/> > <field number="52" value="20030304-20:12:56"/> > <field number="56" value="STNMMTST"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="11" value="NONREF"/> > <field number="15" value="USD"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="22" value="1"/> > <field number="31" value="3"/> > <field number="32" value="1000000"/> > <field number="37" value="155882"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="76" value="GECC"/> > <field number="78" value="1"/> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="154" value="999916.67"/> > <field number="381" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <field number="6640" value="99.991667"/> > </body> > <trailer> > <field number="10" value="053"/> > </trailer> > </message> > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: <gar...@su...> - 2003-03-04 20:52:30
|
Oops - please ignore the prior email. I mixed up the pasting of the
messages....
I've run into a serious problem that I haven't been able to figure out.
In trying to send across allocation messages (which contain groups), I am
able to successfully do so on my development platform. When I move the
receiving FIX engine to another environment (same class machine, same java
version, same OS version-solaris 8), the receiving side is unable to parse
the allocation message correctly which causes the processing to fail.
My outgoing message appears to be right in its XML form while the incoming
message does not show the repeating group entries. I am also including the
'raw' format as printed in the output:
Does anyone have any suggestions as to how to proceed resolving this
problem? This is now holding up our UAT and production release schedules.
Thanks for any help,
Gary
Outgoing
=========
<20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, outgoing>
(8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation:
0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A)
<message>
<header>
<field number="8" value="FIX.4.2"/>
<field number="9" value="372"/>
<field number="35" value="J"/>
</header>
<body>
<field number="6" value="99.991667"/>
<field number="15" value="USD"/>
<field number="22" value="1"/>
<field number="48" value="CUSIP"/>
<field number="53" value="1000000"/>
<field number="54" value="1"/>
<field number="55" value="FIXED"/>
<field number="60" value="20030304-20:12:54"/>
<field number="70" value="Allocation: 0"/>
<field number="71" value="3"/>
<field number="73" value="1"/>
<field number="75" value="20030304"/>
<field number="78" value="1"/>
<field number="106" value="GECC"/>
<field number="118" value="100"/>
<field number="124" value="1"/>
<field number="381" value="999916.67"/>
<field number="6609" value="CP"/>
<field number="6611" value="100"/>
<field number="6613" value="MONEYMARKET"/>
<field number="6614" value="1"/>
<field number="6629" value="MATURITY"/>
<field number="6637" value="20031204"/>
<group>
<field number="11" value="NONREF"/>
<field number="37" value="155882"/>
</group>
<group>
<field number="79" value="FCUSM"/>
<field number="80" value="1000000"/>
<field number="76" value="GECC"/>
<field number="154" value="999916.67"/>
<field number="6604" value="PartAllocID:1"/>
</group>
<group>
<field number="32" value="1000000"/>
<field number="17" value="155882_20031204_151254"/>
<field number="31" value="3"/>
<field number="6640" value="99.991667"/>
</group>
</body>
<trailer>
Incoming
==========
<20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, incoming>
(8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation:
0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A)
<message>
<header>
<field number="8" value="FIX.4.2"/>
<field number="9" value="424"/>
<field number="35" value="J"/>
<field number="34" value="474"/>
<field number="49" value="FMRFITST"/>
<field number="52" value="20030304-20:12:56"/>
<field number="56" value="STNMMTST"/>
</header>
<body>
<field number="6" value="99.991667"/>
<field number="11" value="NONREF"/>
<field number="15" value="USD"/>
<field number="17" value="155882_20031204_151254"/>
<field number="22" value="1"/>
<field number="31" value="3"/>
<field number="32" value="1000000"/>
<field number="37" value="155882"/>
<field number="48" value="CUSIP"/>
<field number="53" value="1000000"/>
<field number="54" value="1"/>
<field number="55" value="FIXED"/>
<field number="60" value="20030304-20:12:54"/>
<field number="70" value="Allocation: 0"/>
<field number="71" value="3"/>
<field number="73" value="1"/>
<field number="75" value="20030304"/>
<field number="76" value="GECC"/>
<field number="78" value="1"/>
<field number="79" value="FCUSM"/>
<field number="80" value="1000000"/>
<field number="106" value="GECC"/>
<field number="118" value="100"/>
<field number="124" value="1"/>
<field number="154" value="999916.67"/>
<field number="381" value="999916.67"/>
<field number="6604" value="PartAllocID:1"/>
<field number="6609" value="CP"/>
<field number="6611" value="100"/>
<field number="6613" value="MONEYMARKET"/>
<field number="6614" value="1"/>
<field number="6629" value="MATURITY"/>
<field number="6637" value="20031204"/>
<field number="6640" value="99.991667"/>
</body>
<trailer>
<field number="10" value="053"/>
</trailer>
</message>
Gary Mui
Prescient Markets, Inc 914-989-3118 (W)
445 Hamilton Avenue 914-422-3693 (F)
White Plains, NY 10601
Please visit us at http://www.cpmarket.com
|
|
From: <gar...@su...> - 2003-03-04 20:41:21
|
I've run into a serious problem that I haven't been able to figure out.
In trying to send across allocation messages (which contain groups), I am
able to successfully do so on my development platform. When I move the
receiving FIX engine to another environment (same class machine, same java
version, same OS version-solaris 8), the receiving side is unable to parse
the allocation message correctly which causes the processing to fail.
My outgoing message appears to be right in its XML form while the incoming
message does not show the repeating group entries. I am also including the
'raw' format as printed in the output:
Does anyone have any suggestions as to how to proceed resolving this
problem? This is now holding up our UAT and production release schedules.
Thanks for any help,
Gary
Outgoing
=========
(8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation:
0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A
<message>
<header>
<field number="8" value="FIX.4.2"/>
<field number="9" value="424"/>
<field number="35" value="J"/>
<field number="34" value="474"/>
<field number="49" value="FMRFITST"/>
<field number="52" value="20030304-20:12:56"/>
<field number="56" value="STNMMTST"/>
</header>
<body>
<field number="6" value="99.991667"/>
<field number="11" value="NONREF"/>
<field number="15" value="USD"/>
<field number="17" value="155882_20031204_151254"/>
<field number="22" value="1"/>
<field number="31" value="3"/>
<field number="32" value="1000000"/>
<field number="37" value="155882"/>
<field number="48" value="CUSIP"/>
<field number="53" value="1000000"/>
<field number="54" value="1"/>
<field number="55" value="FIXED"/>
<field number="60" value="20030304-20:12:54"/>
<field number="70" value="Allocation: 0"/>
<field number="71" value="3"/>
<field number="73" value="1"/>
<field number="75" value="20030304"/>
<field number="76" value="GECC"/>
<field number="78" value="1"/>
<field number="79" value="FCUSM"/>
<field number="80" value="1000000"/>
<field number="106" value="GECC"/>
<field number="118" value="100"/>
<field number="124" value="1"/>
<field number="154" value="999916.67"/>
<field number="381" value="999916.67"/>
<field number="6604" value="PartAllocID:1"/>
<field number="6609" value="CP"/>
<field number="6611" value="100"/>
<field number="6613" value="MONEYMARKET"/>
<field number="6614" value="1"/>
<field number="6629" value="MATURITY"/>
<field number="6637" value="20031204"/>
<field number="6640" value="99.991667"/>
</body>
<trailer>
<field number="10" value="053"/>
</trailer>
</message>
Incoming:
==============
<20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, incoming>
(8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation:
0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A)
<message>
<header>
<field number="8" value="FIX.4.2"/>
<field number="9" value="372"/>
<field number="35" value="J"/>
</header>
<body>
<field number="6" value="99.991667"/>
<field number="15" value="USD"/>
<field number="22" value="1"/>
<field number="48" value="CUSIP"/>
<field number="53" value="1000000"/>
<field number="54" value="1"/>
<field number="55" value="FIXED"/>
<field number="60" value="20030304-20:12:54"/>
<field number="70" value="Allocation: 0"/>
<field number="71" value="3"/>
<field number="73" value="1"/>
<field number="75" value="20030304"/>
<field number="78" value="1"/>
<field number="106" value="GECC"/>
<field number="118" value="100"/>
<field number="124" value="1"/>
<field number="381" value="999916.67"/>
<field number="6609" value="CP"/>
<field number="6611" value="100"/>
<field number="6613" value="MONEYMARKET"/>
<field number="6614" value="1"/>
<field number="6629" value="MATURITY"/>
<field number="6637" value="20031204"/>
<group>
<field number="11" value="NONREF"/>
<field number="37" value="155882"/>
</group>
<group>
<field number="79" value="FCUSM"/>
<field number="80" value="1000000"/>
<field number="76" value="GECC"/>
<field number="154" value="999916.67"/>
<field number="6604" value="PartAllocID:1"/>
</group>
<group>
<field number="32" value="1000000"/>
<field number="17" value="155882_20031204_151254"/>
<field number="31" value="3"/>
<field number="6640" value="99.991667"/>
</group>
</body>
<trailer>
<field number="10" value="164"/>
</trailer>
</message>
Gary Mui
Prescient Markets, Inc 914-989-3118 (W)
445 Hamilton Avenue 914-422-3693 (F)
White Plains, NY 10601
Please visit us at http://www.cpmarket.com
|
|
From: Oren M. <ore...@ya...> - 2003-03-04 15:37:07
|
You're right. It has been brought up before. I've been a little hesitant to add it because in general I don't believe that FIX is a great way to store the state of the system, particularly if you want to support interfaces other than FIX. It's also sort of the contract with FIX that once you've accepted a message, you are basically saying "I've processed this message", implying that any necessary state changes have taken place in the application. On the other hand, the pragmatic aspects of rapidly creating FIX applications with this sort of built in state mechanism is not lost on me. It should be used carefully, however, because an old message that you process may not be the same message the counterparty would choose to resend to you. This generally applies more to servers than clients. I'd like to here a little more discourse from people as to why it does or doesn't make sense. If anybody else has an opinion on the topic please make your voice heard now. --- Min Tang <mi...@op...> wrote: > Agree. I think there are many chances for a GUI FIX > trading application to > restore incoming messages. For example, a user > closed then re-open this > application, all recent orders and executions should > be re-loaded. It will > be great helpful if Oren can offer the functionality > to store/recover > incoming message as well (just same as what QuickFix > handles outgoing > messages). For performance consideration, this > shouldn't be mandatory, a > flag in config file can solve the problem. Of course > I can implement this > using outgoing log file, but I do feel this is a > fundamental requirement (I > checked email archive, and at least 3 people > mentioned same thing). > > ----- Original Message ----- > From: "Gene Gorokhovsky" <mus...@ya...> > To: <om...@th...>; "Min Tang" > <mi...@op...>; > <qui...@li...> > Sent: Monday, March 03, 2003 8:27 PM > Subject: Re: [Quickfix-developers] Restore messages > > > > Remember also that you can always ask for the > message > > resend from the session counter-party using FIX. > > > > Gene > > > > --- Oren Miller <ore...@ya...> wrote: > > > > > > You can't. There is no reason to store incoming > > > messages to implement the protocol, so they are > not > > > stored. Doing so would just increase I/O. You > can > > > use the logger interface to store both incoming > and > > > outgoing messages, however you would have to > > > implement something to read them into your > > > application. > > > Min Tang <mi...@op...> wrote:Hello, > We > > > can restore outgoing messages by using FileStore > > > class, but how can I restore incoming messages? > Is > > > there any utility to load XXX.incoming | > > > XXX.outgoing files or I have to write myself? > > > Thanks. > > > > > > > > > --------------------------------- > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, > and > > more > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Oren M. <ore...@ya...> - 2003-03-04 15:13:14
|
Well this sounds a little different then what Ming wants. In order to see a complete record of what happened, using the Logging interface (optional interface passed into initiator and acceptor) is a superior choice. The reason is that the store is optimized for the queries it needs, and isn't really good at keeping records. The store only keeps around messages it needs, writes over messages with the same sequence number (so only the newest version of a message exists), and gets cleared out during sequence resets and end of day. The log will keep a complete record of all message transactions and the event log is particularly helpful in showing you when special occurances like resend requests happen. I agree that integrating the incoming and outgoing log files is the right thing to do. --- "Rattinger, John" <Joh...@sa...> wrote: > I also agree! Yes, saving the incoming messages is > not a requirement for the > protocol, but it is a great convenience. There are > several reasons why this > would be a useful feature. > > The most important IMHO is for debugging. When > errors occur with message > processing - such as missed executions, correction, > busts, ..., the user > usually doesn't see them until a break occurs the > next day. At this point a > resend request from the day before is impossible. > Without a complete message > log, it is very difficult to determine who is at > fault and therefore who > should eat the error. I would actually like to take > the logging a step > further and see one integrated log that combined > both incoming and outgoing > messages. This is the only true way to absolutely > determine the sequence of > events. > > Also, I don't like the idea of depending on the > other side to resend the > messages. Even if that engine has been "certified", > it can still have resend > errors and bugs. I know because I have seen it > happen many times from the > top vendors. For this same reason, I never resend > application messages when > the sell side sends a resend request. I have sent > duplicate messages in > response to a resend request and have had them not > recognized as dupes. > > You only have to be burned once to learn that > lesson. > > Having the incoming log is also useful for analyzing > message flow, > latencies, ... > > I agree with Min that is would be nice to have this > as a configurable > option. > > That's my 2 cents on the subject. > John > > ----------------------------------------------------- > John Rattinger > SAC Capital Management Advisors > joh...@sa... > > -----Original Message----- > From: Min Tang [mailto:mi...@op...] > Sent: Tuesday, March 04, 2003 9:03 AM > To: Gene Gorokhovsky; om...@th...; > qui...@li... > Subject: Re: [Quickfix-developers] Restore messages > > > Agree. I think there are many chances for a GUI FIX > trading application to > restore incoming messages. For example, a user > closed then re-open this > application, all recent orders and executions should > be re-loaded. It will > be great helpful if Oren can offer the functionality > to store/recover > incoming message as well (just same as what QuickFix > handles outgoing > messages). For performance consideration, this > shouldn't be mandatory, a > flag in config file can solve the problem. Of course > I can implement this > using outgoing log file, but I do feel this is a > fundamental requirement (I > checked email archive, and at least 3 people > mentioned same thing). > > ----- Original Message ----- > From: "Gene Gorokhovsky" <mus...@ya...> > To: <om...@th...>; "Min Tang" > <mi...@op...>; > <qui...@li...> > Sent: Monday, March 03, 2003 8:27 PM > Subject: Re: [Quickfix-developers] Restore messages > > > > Remember also that you can always ask for the > message > > resend from the session counter-party using FIX. > > > > Gene > > > > --- Oren Miller <ore...@ya...> wrote: > > > > > > You can't. There is no reason to store incoming > > > messages to implement the protocol, so they are > not > > > stored. Doing so would just increase I/O. You > can > > > use the logger interface to store both incoming > and > > > outgoing messages, however you would have to > > > implement something to read them into your > > > application. > > > Min Tang <mi...@op...> wrote:Hello, > We > > > can restore outgoing messages by using FileStore > > > class, but how can I restore incoming messages? > Is > > > there any utility to load XXX.incoming | > > > XXX.outgoing files or I have to write myself? > > > Thanks. > > > > > > > > > --------------------------------- > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, > and > > more > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > DISCLAIMER: This e-mail message and any attachments > are intended solely for > the use of the individual or entity to which it is > addressed and may contain > information that is confidential or legally > privileged. If you are not the > intended recipient, you are hereby notified that any > dissemination, > distribution, copying or other use of this message > or its attachments is > strictly prohibited. If you have received this > message in error, please > notify the sender immediately and permanently delete > this message and any > attachments. > > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Vamsi K. <Vam...@ib...> - 2003-03-04 15:10:16
|
Hi all
I have the following data for Market Data Request Message
MQReqID = "XXXX1"
SubSriptionType='1'
MarketDepth=0
MDUpdateType=0
NoMDEntryTypes=1
MDEntryType='5'
NoRelatedSym=2
Symbol="XXX"
SymbolSfx="XXXX"
SecurityID="NONE"
IDSource="1"
IDSource="2"
MaturityMonthYear="200303"
PutOrCall=0
StrkePrice=4.34
Symbol="XXX"
SymbolSfx="YYYY"
SecurityID="NONE1"
IDSource="1"
IDSource="2"
MaturityMonthYear="200303"
PutOrCall=0
StrkePrice=4.35
How do I use this class to compose MarketDataRequest Message and spit
out
in String form?
Can Somebody help me with an example?
Krishna
[Krishna, Vamsi]
/class MarketDataRequest : public Message
/{
/public:
/MarketDataRequest() : Message( MsgType() ) {}
/MarketDataRequest( const Message& m ) : Message( m ) {}
/ static FIX::MsgType MsgType() { return FIX::MsgType( "V" ); }
/ //
/ MarketDataRequest(
/ const FIX::MDReqID& aMDReqID,
/ const FIX::SubscriptionRequestType& aSubscriptionRequestType,
/ const FIX::MarketDepth& aMarketDepth,
/ const FIX::NoMDEntryTypes& aNoMDEntryTypes,
/ const FIX::NoRelatedSym& aNoRelatedSym )
/: Message( FIX::MsgType( "V" ) )
/
/ {
/ set( aMDReqID );
/ set( aSubscriptionRequestType );
/ set( aMarketDepth );
/ set( aNoMDEntryTypes );
/ set( aNoRelatedSym );
/ }
/
/ FIELD_SET( *this, FIX::MDReqID );
/ FIELD_SET( *this, FIX::SubscriptionRequestType );
/ FIELD_SET( *this, FIX::MarketDepth );
/ FIELD_SET( *this, FIX::MDUpdateType );
/ FIELD_SET( *this, FIX::AggregatedBook );
/ FIELD_SET( *this, FIX::NoMDEntryTypes );
/
/class NoMDEntryTypes : public FIX::Group
/ {
/ public:
/ NoMDEntryTypes() : FIX::Group( 267, 269, FIX::message_order( 1, 269,
0 )
/) {}
/
/ FIELD_SET( *this, FIX::MDEntryType );
/ };
/ FIELD_SET( *this, FIX::NoRelatedSym );
/
/class NoRelatedSym : public FIX::Group
/ {
/ public:
/ NoRelatedSym() : FIX::Group( 146, 55, FIX::message_order( 20, 55, 65,
48,
/22, 167, 200, 205, 201, 202, 206, 231, 223, 207, 106, 348, 349, 107,
350,
/351, 336, 0 ) ) {}
/
/ FIELD_SET( *this, FIX::Symbol );
/ FIELD_SET( *this, FIX::SymbolSfx );
/ FIELD_SET( *this, FIX::SecurityID );
/ FIELD_SET( *this, FIX::IDSource );
/ FIELD_SET( *this, FIX::SecurityType );
/ FIELD_SET( *this, FIX::MaturityMonthYear );
/ FIELD_SET( *this, FIX::MaturityDay );
/ FIELD_SET( *this, FIX::PutOrCall );
/ FIELD_SET( *this, FIX::StrikePrice );
/ FIELD_SET( *this, FIX::OptAttribute );
/ FIELD_SET( *this, FIX::ContractMultiplier );
/ FIELD_SET( *this, FIX::CouponRate );
/ FIELD_SET( *this, FIX::SecurityExchange );
/ FIELD_SET( *this, FIX::Issuer );
/ FIELD_SET( *this, FIX::EncodedIssuerLen );
/ FIELD_SET( *this, FIX::EncodedIssuer );
/ FIELD_SET( *this, FIX::SecurityDesc );
/ FIELD_SET( *this, FIX::EncodedSecurityDescLen );
/ FIELD_SET( *this, FIX::EncodedSecurityDesc );
/ FIELD_SET( *this, FIX::TradingSessionID );
/ };
/};
|
|
From: <gar...@su...> - 2003-03-04 14:55:45
|
I'm not sure if I'm one of the people that have mentioned the benefit of this feature, but I would certainly use it. Because the functionality isn't there, I've had to implement something to provide this at the application layer. Basically, I configure and create my own FileStore used for incoming messages. The Client API I built (through which our client application talks with the FIX engine) has the means to request messages that the engine may have received since the client's last received messages. This becomes useful when the engine remains up and can potentially receive messages from the counterparty's session, but our trading application gets interrupted. If the engine received the message and couldn't pass it upstream, it at least gets archived in the store which can be requested by my trading application when it reconnects. I certainly think that a better implementation could be probably be implemented as mine is pretty tied to the RMI interface I have built around my FIX engine (based of course on quickfix's libraries). Thanks, Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Min Tang <mi...@op...> Sent by: To: Gene Gorokhovsky <mus...@ya...>, om...@th..., qui...@li...ur qui...@li... ceforge.net cc: Subject: Re: [Quickfix-developers] Restore messages 03/04/03 09:03 AM Agree. I think there are many chances for a GUI FIX trading application to restore incoming messages. For example, a user closed then re-open this application, all recent orders and executions should be re-loaded. It will be great helpful if Oren can offer the functionality to store/recover incoming message as well (just same as what QuickFix handles outgoing messages). For performance consideration, this shouldn't be mandatory, a flag in config file can solve the problem. Of course I can implement this using outgoing log file, but I do feel this is a fundamental requirement (I checked email archive, and at least 3 people mentioned same thing). ----- Original Message ----- From: "Gene Gorokhovsky" <mus...@ya...> To: <om...@th...>; "Min Tang" <mi...@op...>; <qui...@li...> Sent: Monday, March 03, 2003 8:27 PM Subject: Re: [Quickfix-developers] Restore messages > Remember also that you can always ask for the message > resend from the session counter-party using FIX. > > Gene > > --- Oren Miller <ore...@ya...> wrote: > > > > You can't. There is no reason to store incoming > > messages to implement the protocol, so they are not > > stored. Doing so would just increase I/O. You can > > use the logger interface to store both incoming and > > outgoing messages, however you would have to > > implement something to read them into your > > application. > > Min Tang <mi...@op...> wrote:Hello, We > > can restore outgoing messages by using FileStore > > class, but how can I restore incoming messages? Is > > there any utility to load XXX.incoming | > > XXX.outgoing files or I have to write myself? > > Thanks. > > > > > > --------------------------------- > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, and > more > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Vamsi K. <Vam...@ib...> - 2003-03-04 14:54:10
|
Hi
How do I use this class to compose MarketDataRequest Message and spit
out in String form?
Can Somebody help me with an example?
Vamsi
class MarketDataRequest : public Message
{
public:
MarketDataRequest() : Message( MsgType() ) {}
MarketDataRequest( const Message& m ) : Message( m ) {}
static FIX::MsgType MsgType() { return FIX::MsgType( "V" ); }
//
MarketDataRequest(
const FIX::MDReqID& aMDReqID,
const FIX::SubscriptionRequestType& aSubscriptionRequestType,
const FIX::MarketDepth& aMarketDepth,
const FIX::NoMDEntryTypes& aNoMDEntryTypes,
const FIX::NoRelatedSym& aNoRelatedSym )
: Message( FIX::MsgType( "V" ) )
{
set( aMDReqID );
set( aSubscriptionRequestType );
set( aMarketDepth );
set( aNoMDEntryTypes );
set( aNoRelatedSym );
}
FIELD_SET( *this, FIX::MDReqID );
FIELD_SET( *this, FIX::SubscriptionRequestType );
FIELD_SET( *this, FIX::MarketDepth );
FIELD_SET( *this, FIX::MDUpdateType );
FIELD_SET( *this, FIX::AggregatedBook );
FIELD_SET( *this, FIX::NoMDEntryTypes );
class NoMDEntryTypes : public FIX::Group
{
public:
NoMDEntryTypes() : FIX::Group( 267, 269, FIX::message_order( 1, 269, 0
) ) {}
FIELD_SET( *this, FIX::MDEntryType );
};
FIELD_SET( *this, FIX::NoRelatedSym );
class NoRelatedSym : public FIX::Group
{
public:
NoRelatedSym() : FIX::Group( 146, 55, FIX::message_order( 20, 55, 65,
48, 22, 167, 200, 205, 201, 202, 206, 231, 223, 207, 106, 348, 349, 107,
350, 351, 336, 0 ) ) {}
FIELD_SET( *this, FIX::Symbol );
FIELD_SET( *this, FIX::SymbolSfx );
FIELD_SET( *this, FIX::SecurityID );
FIELD_SET( *this, FIX::IDSource );
FIELD_SET( *this, FIX::SecurityType );
FIELD_SET( *this, FIX::MaturityMonthYear );
FIELD_SET( *this, FIX::MaturityDay );
FIELD_SET( *this, FIX::PutOrCall );
FIELD_SET( *this, FIX::StrikePrice );
FIELD_SET( *this, FIX::OptAttribute );
FIELD_SET( *this, FIX::ContractMultiplier );
FIELD_SET( *this, FIX::CouponRate );
FIELD_SET( *this, FIX::SecurityExchange );
FIELD_SET( *this, FIX::Issuer );
FIELD_SET( *this, FIX::EncodedIssuerLen );
FIELD_SET( *this, FIX::EncodedIssuer );
FIELD_SET( *this, FIX::SecurityDesc );
FIELD_SET( *this, FIX::EncodedSecurityDescLen );
FIELD_SET( *this, FIX::EncodedSecurityDesc );
FIELD_SET( *this, FIX::TradingSessionID );
};
};
|
|
From: Rattinger, J. <Joh...@sa...> - 2003-03-04 14:45:14
|
I also agree! Yes, saving the incoming messages is not a requirement for the protocol, but it is a great convenience. There are several reasons why this would be a useful feature. The most important IMHO is for debugging. When errors occur with message processing - such as missed executions, correction, busts, ..., the user usually doesn't see them until a break occurs the next day. At this point a resend request from the day before is impossible. Without a complete message log, it is very difficult to determine who is at fault and therefore who should eat the error. I would actually like to take the logging a step further and see one integrated log that combined both incoming and outgoing messages. This is the only true way to absolutely determine the sequence of events. Also, I don't like the idea of depending on the other side to resend the messages. Even if that engine has been "certified", it can still have resend errors and bugs. I know because I have seen it happen many times from the top vendors. For this same reason, I never resend application messages when the sell side sends a resend request. I have sent duplicate messages in response to a resend request and have had them not recognized as dupes. You only have to be burned once to learn that lesson. Having the incoming log is also useful for analyzing message flow, latencies, ... I agree with Min that is would be nice to have this as a configurable option. That's my 2 cents on the subject. John ----------------------------------------------------- John Rattinger SAC Capital Management Advisors joh...@sa... -----Original Message----- From: Min Tang [mailto:mi...@op...] Sent: Tuesday, March 04, 2003 9:03 AM To: Gene Gorokhovsky; om...@th...; qui...@li... Subject: Re: [Quickfix-developers] Restore messages Agree. I think there are many chances for a GUI FIX trading application to restore incoming messages. For example, a user closed then re-open this application, all recent orders and executions should be re-loaded. It will be great helpful if Oren can offer the functionality to store/recover incoming message as well (just same as what QuickFix handles outgoing messages). For performance consideration, this shouldn't be mandatory, a flag in config file can solve the problem. Of course I can implement this using outgoing log file, but I do feel this is a fundamental requirement (I checked email archive, and at least 3 people mentioned same thing). ----- Original Message ----- From: "Gene Gorokhovsky" <mus...@ya...> To: <om...@th...>; "Min Tang" <mi...@op...>; <qui...@li...> Sent: Monday, March 03, 2003 8:27 PM Subject: Re: [Quickfix-developers] Restore messages > Remember also that you can always ask for the message > resend from the session counter-party using FIX. > > Gene > > --- Oren Miller <ore...@ya...> wrote: > > > > You can't. There is no reason to store incoming > > messages to implement the protocol, so they are not > > stored. Doing so would just increase I/O. You can > > use the logger interface to store both incoming and > > outgoing messages, however you would have to > > implement something to read them into your > > application. > > Min Tang <mi...@op...> wrote:Hello, We > > can restore outgoing messages by using FileStore > > class, but how can I restore incoming messages? Is > > there any utility to load XXX.incoming | > > XXX.outgoing files or I have to write myself? > > Thanks. > > > > > > --------------------------------- > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, and > more > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers DISCLAIMER: This e-mail message and any attachments are intended solely for the use of the individual or entity to which it is addressed and may contain information that is confidential or legally privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and permanently delete this message and any attachments. |
|
From: Min T. <mi...@op...> - 2003-03-04 14:06:21
|
Agree. I think there are many chances for a GUI FIX trading application to restore incoming messages. For example, a user closed then re-open this application, all recent orders and executions should be re-loaded. It will be great helpful if Oren can offer the functionality to store/recover incoming message as well (just same as what QuickFix handles outgoing messages). For performance consideration, this shouldn't be mandatory, a flag in config file can solve the problem. Of course I can implement this using outgoing log file, but I do feel this is a fundamental requirement (I checked email archive, and at least 3 people mentioned same thing). ----- Original Message ----- From: "Gene Gorokhovsky" <mus...@ya...> To: <om...@th...>; "Min Tang" <mi...@op...>; <qui...@li...> Sent: Monday, March 03, 2003 8:27 PM Subject: Re: [Quickfix-developers] Restore messages > Remember also that you can always ask for the message > resend from the session counter-party using FIX. > > Gene > > --- Oren Miller <ore...@ya...> wrote: > > > > You can't. There is no reason to store incoming > > messages to implement the protocol, so they are not > > stored. Doing so would just increase I/O. You can > > use the logger interface to store both incoming and > > outgoing messages, however you would have to > > implement something to read them into your > > application. > > Min Tang <mi...@op...> wrote:Hello, We > > can restore outgoing messages by using FileStore > > class, but how can I restore incoming messages? Is > > there any utility to load XXX.incoming | > > XXX.outgoing files or I have to write myself? > > Thanks. > > > > > > --------------------------------- > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, and > more > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > |
|
From: Gene G. <mus...@ya...> - 2003-03-04 01:28:47
|
Remember also that you can always ask for the message resend from the session counter-party using FIX. Gene --- Oren Miller <ore...@ya...> wrote: > > You can't. There is no reason to store incoming > messages to implement the protocol, so they are not > stored. Doing so would just increase I/O. You can > use the logger interface to store both incoming and > outgoing messages, however you would have to > implement something to read them into your > application. > Min Tang <mi...@op...> wrote:Hello, We > can restore outgoing messages by using FileStore > class, but how can I restore incoming messages? Is > there any utility to load XXX.incoming | > XXX.outgoing files or I have to write myself? > Thanks. > > > --------------------------------- > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and more __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Oren M. <ore...@ya...> - 2003-03-03 19:20:44
|
You can't. There is no reason to store incoming messages to implement the protocol, so they are not stored. Doing so would just increase I/O. You can use the logger interface to store both incoming and outgoing messages, however you would have to implement something to read them into your application. Min Tang <mi...@op...> wrote:Hello, We can restore outgoing messages by using FileStore class, but how can I restore incoming messages? Is there any utility to load XXX.incoming | XXX.outgoing files or I have to write myself? Thanks. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more |
|
From: Oren M. <ore...@ya...> - 2003-03-03 19:17:43
|
Access the mailing lists from our web site or from sourceforge. http://quickfix.thoughtworks.com/mailinglists.html As for MySQL, you need to follow the instructions in the installation page for building with MySQL: http://quickfix.thoughtworks.com/documentation/install.html Min Tang <mi...@op...> wrote:I tried to read all archive mails to avoid asking duplicated questions, but seems the link doesn't work. http://www.geocrawler.com/redir-sf.php3?list=quickfix-developers I can use FileStoreFactory but failed to use MySQLStoreFactory. The code is the same: Application application = new ExecApplication(); Settings settings = new Settings(new FileInputStream(args[0])); MessageStoreFactory messageStoreFactory = //new FileStoreFactory(settings); new MySQLStoreFactory(settings); LogFactory logFactory = new ScreenLogFactory(true, true, true); MessageFactory messageFactory = new DefaultMessageFactory(); acceptor = new SocketAcceptor (application, messageStoreFactory, settings, logFactory, messageFactory); acceptor.start(); The error message is (I have updated all quickfix files and re-built the jni dll file): Exception in thread "main" java.lang.UnsatisfiedLinkError: create at org.quickfix.MySQLStoreFactory.create(Native Method) at org.quickfix.MySQLStoreFactory.<init>(MySQLStoreFactory.java:59) at com.ftms.fix.executor.Executor.main(Executor.java:23) Config file: [DEFAULT] SocketAcceptPort=2088 ConnectionType=acceptor SenderCompID=ML [SESSION] BeginString=FIX.4.2 TargetCompID=TA StartTime=00:00:01 EndTime=23:59:59 ReconnectInterval=30 ValidateFieldsOutOfOrder=N DataDictionary=c:\itms\property\FIX42.xml ##FileStorePath=c:\itms\log MySQLStoreDatabase=quickfix MySQLStoreUser=system MySQLStorePassword=ray MySQLStoreHost=tradviser-3 MySQLStorePort=3306 --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more |
|
From: Oren M. <ore...@ya...> - 2003-03-03 19:15:14
|
Well previous versions are only put in the deprecated directory if the name has changed. This is no longer the case by the way and all fields are not in the same directory. As for deprecated enumerations, deleting them ISN'T the solution. As I said earlier, we don't yet HAVE a solution. So please wait until we do before being unhappy with it :) I think it is unlikely that we will create a copy of 450 files in a different package simply because one or two are not backwards compatible. Removing enumerations is a very rare occurance (I believe this is a first) which can be handled on a case by case system. If it ever becomes more frequent, a more general solution will be called for. Commenting out isn't necessary because we do want those enumerations to be present. I've checked in a new generator that will place them in their for versions that no longer have them. This brings back the OPTION and FUTURE enumerations. Min Tang <mi...@op...> wrote:I know the new changes are for FIX4.3 spec, but I am not sure putting those fields of previous versions in deprecated directory is a proper way. Many institutions are still using old version such as FIX4.0. For those users this Java QuickFix simply does compile. I think one way to make them all work is creating a new package calle "fix40to42" and move all classes under deprecated to this new directory. Same idea can also apply to enumerations. If you do want to deprecate those enumerations such as OPTION and FUTURE in SecurityType.java, I believe commenting them out is better than deleting them. At lease I can easily tell you did this intentionally and they were all deprecated. ----- Original Message ----- From: To: Cc: ; Sent: Friday, February 28, 2003 8:24 PM Subject: Re: [Quickfix-developers] Field missing in latest SecurityType.java > > Yes and yes. > > Deprecated fields are ones whose names have changed. For instance > LastShares became LastQty. Although LastShares is in the deprecated > subdirectory, it is in the same package of LastQty, so you don't need to do > anything special to pull them in. Its just a way to show that its use has > been dropped in newer versions of the spec. > > Having these allows you to use LastShares when dealing with older versions > of the spec, and use LastQty when dealing with newer versions (in fact you > must do it this way or the compiler will complain). > > Concerning FUT and OPT, this is in accordance with FIX 4.3: > > It is recommended that CFICode be used instead of SecurityType for > non-Fixed Income instruments. > > Futures and Options should be specified using the CFICode[461] field > instead of SecurityType[167] (Refer to Volume 7 ? Recommendations and > Guidelines for Futures and Options Markets.") > > I haven't yet determined how to handle deprecated enumerations. > Suggestions would be welcome from anybody. For now, If you need to use > them, you can manually add them or just pass in "OPT" and "FUT". > > > --oren > > > |---------+-----------------------------------------------> > | | Min Tang | > | | Sent by: | > | | qui...@li...ur| > | | ceforge.net | > | | | > | | | > | | 02/28/2003 07:00 PM | > | | | > |---------+-----------------------------------------------> > >--------------------------------------------------------------------------- -------------------| > | | > | To: qui...@li... | > | cc: | > | Subject: [Quickfix-developers] Field missing in latest SecurityType.java | > >--------------------------------------------------------------------------- -------------------| > > > > > I cannot find Option and Future in latest SecurityType.java. Some classes > under deprecated directory are still using by classes in other directory. > Are these intentional updates? > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more |
|
From: Min T. <mi...@op...> - 2003-03-03 19:05:06
|
Hello, We can restore outgoing messages by using FileStore class, but how can I restore incoming messages? Is there any utility to load XXX.incoming | XXX.outgoing files or I have to write myself? Thanks. |
|
From: Min T. <mi...@op...> - 2003-03-01 15:44:22
|
I tried to read all archive mails to avoid asking duplicated questions, but seems the link doesn't work. http://www.geocrawler.com/redir-sf.php3?list=quickfix-developers I can use FileStoreFactory but failed to use MySQLStoreFactory. The code is the same: Application application = new ExecApplication(); Settings settings = new Settings(new FileInputStream(args[0])); MessageStoreFactory messageStoreFactory = //new FileStoreFactory(settings); new MySQLStoreFactory(settings); LogFactory logFactory = new ScreenLogFactory(true, true, true); MessageFactory messageFactory = new DefaultMessageFactory(); acceptor = new SocketAcceptor (application, messageStoreFactory, settings, logFactory, messageFactory); acceptor.start(); The error message is (I have updated all quickfix files and re-built the jni dll file): Exception in thread "main" java.lang.UnsatisfiedLinkError: create at org.quickfix.MySQLStoreFactory.create(Native Method) at org.quickfix.MySQLStoreFactory.<init>(MySQLStoreFactory.java:59) at com.ftms.fix.executor.Executor.main(Executor.java:23) Config file: [DEFAULT] SocketAcceptPort=2088 ConnectionType=acceptor SenderCompID=ML [SESSION] BeginString=FIX.4.2 TargetCompID=TA StartTime=00:00:01 EndTime=23:59:59 ReconnectInterval=30 ValidateFieldsOutOfOrder=N DataDictionary=c:\itms\property\FIX42.xml ##FileStorePath=c:\itms\log MySQLStoreDatabase=quickfix MySQLStoreUser=system MySQLStorePassword=ray MySQLStoreHost=tradviser-3 MySQLStorePort=3306 |
98 messages has been excluded from this view by a project administrator.
