{{Quickfixn}} Invalid body length

Grant Birchmeier gbirchmeier at connamara.com
Tue Jan 22 06:38:56 PST 2013 

I'd say 98% confident.  I'd love to see it confirmed on a production system.

On Tue, Jan 22, 2013 at 3:18 AM, treffeisen ltd.
<director at treffeisen.net> wrote:
> Grant,
>         Got it, field 9 needs to have the correct field length then it is successful.
> So are you confident that this will work now?
>
> Thanks,
>         André
>
> -----Original Message-----
> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
> Sent: 21 January 2013 22:37
> To: director at treffeisen.net
> Cc: Mailing list for QuickFIX/n
> Subject: Re: {{Quickfixn}} Invalid body length
>
> (Oops, resending to correct quickfixn list address.)
>
> On Mon, Jan 21, 2013 at 4:35 PM, Grant Birchmeier
> <gbirchmeier at connamara.com> wrote:
>> I don't entirely understand your question; but I'll try my best.
>>
>> Your test is failing because it's wrong.  The test checks for length
>> 1115, and it fails because it finds 1116.  (So I guess 7/8 is 2
>> bytes.)  Basically, your test is failing because it trying to assert
>> that 2+2=5.  If you fix your test, it will pass.
>>
>> Yes, UTF characters can be multibyte.  In the existing QF/n release,
>> the engine is computing BodyLength and Checksum by counting characters
>> (not bytes).  Basic letters and numbers are single-byte, so with those
>> it's the same if you compute by byte or by char.  UTF can be
>> multibyte, so that's when the errors occur.  (Our original tests only
>> used ASCII, and that's why we missed it.)
>>
>> I'm not clear if my branch is failing for you in production.  Your
>> earlier mails imply that you are focusing on the unit test.
>>
>> In my branch, please see unit test ReadFixMessageWithNonAscii, which
>> demonstrates proper parsing of the two-byte UTF character "é" (e with
>> an accent).
>> https://github.com/gbirchmeier/quickfixn/blob/97/UnitTests/ParserTest.cs
>>
>> I also made an acceptance test that verifies that the AcceptanceTest
>> app can receive and send the "é" character.
>> You can also see an acceptance testuses that same character:
>> https://github.com/gbirchmeier/quickfixn/blob/97/AcceptanceTest/definitions/server/fix44/InternationalCharacters.def
>>
>> -Grant
>>
>>
>>
>>
>> On Mon, Jan 21, 2013 at 4:05 PM, treffeisen ltd.
>> <director at treffeisen.net> wrote:
>>> Grant,
>>>         Hmm, got that mixed up - was late yesterday.
>>> So it is about body length, which is not calculated correct. I still don't get the problem, anything I can do to fix? Could you explain why that goes wrong.
>>> You mentioned in one post that the 7/8 is two bytes not one, that is normal in a UTF charset, right? So why is it first counted as one byte?
>>>
>>> Thanks,
>>>         anmatr
>>>
>>> -----Original Message-----
>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>> Sent: 21 January 2013 00:52
>>> To: director at treffeisen.net
>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>
>>> And I forgot to put it back on-list.  Nice.
>>>
>>> On Sun, Jan 20, 2013 at 6:17 PM, Grant Birchmeier <gbirchmeier at connamara.com> wrote:
>>>> (Somehow we got off-list.  Hope you don't mind me putting this back on
>>>> the list.)
>>>>
>>>> This is about BodyLength, not Checksum.  The Unit Test result you show
>>>> is failing on the bodylength test, not checksum.
>>>>
>>>> BodyLength is easy to count: it's the byte count (*not* character
>>>> count) starting at tag 35 (included) all the way to tag 10 (excluded).
>>>> The SOH separators are included.
>>>>
>>>> CheckSum... I probably should write a small ruby script to calculate
>>>> it, but I haven't.  The algorithm is to sum up the int value of all
>>>> the bytes (except the checksum field, of course) and then modulo 256.
>>>> (e.g. sum % 256).
>>>>
>>>> -Grant
>>>>
>>>>
>>>> On Sun, Jan 20, 2013 at 4:40 PM, treffeisen ltd.
>>>> <director at treffeisen.net> wrote:
>>>>> Grant,
>>>>>         Yes I am aware that the correct checksum has to be calculated first and given in field 10. I haven't done that and don't have an easy way of doing this. Did you manage to get a right test with a correct checksum given?
>>>>>
>>>>> (I first would need to dig out the old java framework where I have a
>>>>> tool to calculate the checksum first. But lack of time today .... if
>>>>> you could help out please?)
>>>>>
>>>>> Thanks,
>>>>>         André
>>>>>
>>>>> -----Original Message-----
>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>> Sent: 20 January 2013 22:28
>>>>> To: director at treffeisen.net
>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>
>>>>> Er, in your recent test you changed 0x0100 to "7/8", but it's the
>>>>> same problem.  (Actually, 7/8 might be 3 bytes.  Not sure.)
>>>>>
>>>>> -Grant
>>>>>
>>>>>
>>>>> On Sun, Jan 20, 2013 at 4:19 PM, Grant Birchmeier <gbirchmeier at connamara.com> wrote:
>>>>>> Did you see my Jan 4th email?  Your test is incorrect.  The \x0100
>>>>>> character is two bytes long.  Therefore, the fixMsg2 is indeed one
>>>>>> byte longer than fixMsg1, and the length field needs to be adjusted
>>>>>> accordingly.  1116 is the correct length.
>>>>>>
>>>>>> -Grant
>>>>>>
>>>>>>
>>>>>> On Sun, Jan 20, 2013 at 3:41 PM, treffeisen ltd.
>>>>>> <director at treffeisen.net> wrote:
>>>>>>> Grant,
>>>>>>>
>>>>>>>       Unfortunately I still get the same error - the checksum
>>>>>>> calculation throws an error. I checked out branch 97 and compared
>>>>>>> it to the earlier version I have and I saw you change to UTF8 encoding, right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> What kind of logs would you like? I just get the usual error:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Errors and Failures:
>>>>>>>
>>>>>>> 1) Test Error : UnitTests.ParserTest.ReadFixMessageNEW
>>>>>>>
>>>>>>>    QuickFix.MessageParseError : Could not parse message: Invalid
>>>>>>> body length. Calculated:1116 expected:1115
>>>>>>>
>>>>>>>    at QuickFix.Parser.ReadFixMessage(String& msg) in
>>>>>>> D:\_Project_AMT\C#\quickfixn-97.1\QuickFIXn\Parser.cs:line 80
>>>>>>>
>>>>>>>    at UnitTests.ParserTest.ReadFixMessageNEW() in
>>>>>>> D:\_Project_AMT\C#\quickfixn-97.1\UnitTests\ParserTest.cs:line 118
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This can also be seen by running the NUnit test (unit_test.bat)
>>>>>>> with the test ReadFixMessageNEW which is provided already. It’s attached again.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’ve never got the actual message sent in a proper format to use
>>>>>>> and test it. Bloomberg support is not helpful on this issue. Here
>>>>>>> is what I have got sent from them:
>>>>>>>
>>>>>>> 12:41:32.956 TX
>>>>>>> 8=FIX.4.4|9=1164|35=AE|49=BLP|56=JCAMVCON|34=1878|57=5454321|115=i.
>>>>>>> VC
>>>>>>> ONSRV|43=Y|122=20121205-16:25:52|52=20121205-17:41:32|60=20121205-16:
>>>>>>> 25:52|570=N|31=99.609375|571=00006499:0117:1a3a:50be9d1f|32=850000|
>>>>>>> 42
>>>>>>> 3=1|573=1|64=20121206|487=2|818=5818467426611495718|460=6|880=3739:
>>>>>>> 20
>>>>>>> 121205:50680:6|854=1|75=20121205|856=7|167=TBOND|48=US912810QX90|22
>>>>>>> 8=
>>>>>>> 1|231=1|22=4|55=[N/A]|235=WORST|236=2.769272|9610=3|9611=BOOK|9613=
>>>>>>> 1|CS
>>>>>>> 80/20|9611=STRATEGY|9613=CORP - US|9611=
>>>>>>> |454=3|455=912810QX9|456=1|455=912810QX|456=A|455=US912810QX90|456=
>>>>>>> |4| 552=1|54=1|37=MANUAL|453=3|448=OLIVER
>>>>>>> RISSO-GILL @ RBS SECURITIES INC : 5784450 @
>>>>>>> 1999|447=D|452=1|802=8|523=RBS|803=1|523=1999|803=4014|523=RBS
>>>>>>> 1999|SECURITIES
>>>>>>> INC|803=4015|523=30030569|803=4016|523=STAMFORD|803=34|523=US|803=3
>>>>>>> INC|8| 523=RBSM|803=4010|523=RBS|803=4013|448=DREW
>>>>>>> CHINTALA @ JAE CREDIT MANAGEMENT LP : 5454321 @
>>>>>>> 755803|447=D|452=11|802=7|523=755803|803=4005|523=JAE CREDIT
>>>>>>> MANAG|803=1|523=755803|803=4014|523=JAE CREDIT MANAGEMENT
>>>>>>> LP|803=4015|523=30082871|803=4016|523=NEW
>>>>>>> YORK|803=34|523=US|803=38|448=SXT|447=D|452=16|15=USD|381=846679.68
>>>>>>> YORK|99
>>>>>>> YORK|999999|159=7177.65|118=853857.34|58=RBS
>>>>>>> SELLS TO JAE @ 99-19+ VS BUYING 1MM INTC 4¼'42 @ +143/CT30o
>>>>>>> |9503=N|10=174|
>>>>>>>
>>>>>>>
>>>>>>> 12:41:32.956 TX
>>>>>>> 8=FIX.4.4|9=1183|35=AE|49=BLP|56=JCAMVCON|34=1879|57=5454321|115=i.
>>>>>>> VC
>>>>>>> ONSRV|43=Y|122=20121205-16:26:05|52=20121205-17:41:32|60=20121205-16:
>>>>>>> 26:05|570=N|31=99.609375|571=000064a3:0117:1a3a:50be9d1f|32=850000|
>>>>>>> 42 3=1|64=20121206|487=2|818=5818467426611495718|1328=No
>>>>>>> reason
>>>>>>> provided.|460=6|880=3739:20121205:50680:6|854=1|75=20121205|856=3|1
>>>>>>> 67
>>>>>>> =TBOND|48=US912810QX90|228=1|231=1|22=4|55=[N/A]|235=WORST|236=2.76
>>>>>>> 92
>>>>>>> 72|9610=3|9611=BOOK|9613=CS 80/20|9611=STRATEGY|9613=CORP -
>>>>>>> 72|US|9611=
>>>>>>> |454=3|455=912810QX9|456=1|455=912810QX|456=A|455=US912810QX90|456=
>>>>>>> |4| 552=1|54=1|37=MANUAL|453=3|448=OLIVER
>>>>>>> RISSO-GILL @ RBS SECURITIES INC : 5784450 @
>>>>>>> 1999|447=D|452=1|802=8|523=RBS|803=1|523=1999|803=4014|523=RBS
>>>>>>> 1999|SECURITIES
>>>>>>> INC|803=4015|523=30030569|803=4016|523=STAMFORD|803=34|523=US|803=3
>>>>>>> INC|8| 523=RBSM|803=4010|523=RBS|803=4013|448=DREW
>>>>>>> CHINTALA @ JAE CREDIT MANAGEMENT LP : 5454321 @
>>>>>>> 755803|447=D|452=11|802=7|523=755803|803=4005|523=JAE CREDIT
>>>>>>> MANAG|803=1|523=755803|803=4014|523=JAE CREDIT MANAGEMENT
>>>>>>> LP|803=4015|523=30082871|803=4016|523=NEW
>>>>>>> YORK|803=34|523=US|803=38|448=SXT|447=D|452=16|15=USD|381=846679.68
>>>>>>> YORK|99
>>>>>>> YORK|999999|159=7177.65|118=853857.34|58=RBS
>>>>>>> SELLS TO JAE @ 99-19+ VS BUYING 1MM INTC 4¼'42 @ +143/CT30o
>>>>>>> |9503=N|10=218|
>>>>>>>
>>>>>>> It is in field 58 where most likely the character for a quarter ¼
>>>>>>> causes the issue.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Attached is a message from the time when we had the old interface
>>>>>>> running with the java quickfix framework. In that message in field
>>>>>>> 58 you can find a character which I think would produce the same problem:
>>>>>>>
>>>>>>> 58=*****VS RABOBK 3⅞ '22 NEW ISSUE****
>>>>>>>
>>>>>>> It is the fraction 7 parts of 8. Maybe you can use this message
>>>>>>> data somehow. I have done the test with this character and got the
>>>>>>> same error with your latest changed branch using the UTF8 encoding.
>>>>>>> So I guess it is the same problem still not fixed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hope that helps. Thanks for your time.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>>
>>>>>>>                 André
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>>> Sent: 04 January 2013 21:37
>>>>>>> To: director at treffeisen.net
>>>>>>>
>>>>>>>
>>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anmater, your test fails because your fixMsg2 is invalid.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The \x0100 character is two bytes long.  Therefore, the fixMsg2 is
>>>>>>> indeed one byte longer than fixMsg1, and the length field needs to
>>>>>>> be adjusted accordingly.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So, with my branch build on your actual connection, do you see the
>>>>>>> same exact "invalid body length" error from your original email?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If yes, could you send a message log that includes that message and
>>>>>>> the reject and a bit of the surrounding context?  (I'm wondering if
>>>>>>> your counterparty might be calculating the length wrong, using
>>>>>>> character count rather than byte count.)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Dec 23, 2012 at 10:54 AM, Grant Birchmeier
>>>>>>> <gbirchmeier at connamara.com> wrote:
>>>>>>>
>>>>>>> Thanks, Anmatr.  I'm going to try to look further into this this
>>>>>>> week (if I can make time around the various holiday stuff I have going on).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 20, 2012 at 8:54 AM, treffeisen ltd.
>>>>>>> <director at treffeisen.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Grant,
>>>>>>>
>>>>>>>                 Thanks, that sound promising.
>>>>>>>
>>>>>>> I have used the branch to do some testing on a message that caused
>>>>>>> the issue. But unfortunately it still shows that error. Attached is
>>>>>>> the ParserTest.cs class with the added test method ReadFixMessageNEW.
>>>>>>> You will see the error as before:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Errors and Failures:
>>>>>>>
>>>>>>> 1) Test Error : UnitTests.ParserTest.ReadFixMessageNEW
>>>>>>>
>>>>>>>    QuickFix.MessageParseError : Could not parse message: Invalid
>>>>>>> body length. Calculated:1116 expected:1115
>>>>>>>
>>>>>>>    at QuickFix.Parser.ReadFixMessage(String& msg) in
>>>>>>> D:\_Project_AMT\C#\quickfixn-97\QuickFIXn\Parser.cs:line 80
>>>>>>>
>>>>>>>    at UnitTests.ParserTest.ReadFixMessageNEW() in
>>>>>>> D:\_Project_AMT\C#\quickfixn-97\UnitTests\ParserTest.cs:line 118
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>                 Anmatr
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>>> Sent: 20 December 2012 00:12
>>>>>>> To: director at treffeisen.net
>>>>>>> Cc: Mailing list for QuickFIX/n
>>>>>>>
>>>>>>>
>>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I actually started integrating a submitted patch last week.  I
>>>>>>> think it's nearly done, actually, but I need to extend our test
>>>>>>> framework too in order to properly test it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If you'd like, though, you can build my branch and see if it is
>>>>>>> working for
>>>>>>> you:
>>>>>>>
>>>>>>> https://github.com/gbirchmeier/quickfixn/tree/97
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Dec 19, 2012 at 5:43 PM, treffeisen ltd.
>>>>>>> <director at treffeisen.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I’ve got to pick this up again as it turns out to be a real problem
>>>>>>> on our client now. Is there any way I could do a hack just for my
>>>>>>> version to get this message handled? It would be good to get the
>>>>>>> noise out as we keep getting errors on our interface.
>>>>>>>
>>>>>>> I have already contacted the sender (Bloomberg) and I can only hope
>>>>>>> that they pick this up on their side. But that will not be fixed soon, if at all.
>>>>>>> We used the java quickfix/J before and that seemed more robust.
>>>>>>>
>>>>>>> Still there is no other option then quickfix/N now so we need to
>>>>>>> continue on that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If you could point me to the direction, I’d highly appreciate.
>>>>>>> Maybe I find a solution which could be accepted in your next
>>>>>>> release? Not a promise, just worth a try I guess.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Again, thanks for your time on this!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anmatr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>>> Sent: 07 December 2012 16:27
>>>>>>>
>>>>>>>
>>>>>>> To: director at treffeisen.net; Mailing list for QuickFIX/n
>>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I don't know an easy way around this at this time.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Don't overlook the fact that the message you're receiving is
>>>>>>> technically illegal, and your counterparty should be notified about
>>>>>>> it.  They are using non-ASCII in a field that should only be ASCII.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That said, QF/n does have an associated bug.  If a message has
>>>>>>> non-ASCII in fields where non-ASCII is allowed, then it's QF/n's
>>>>>>> fault.  Fixing this bug will make QF/n tolerant of your
>>>>>>> counterparty's bad message, but that doesn't make your counterparty ok.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> But I'm nitpicking, I guess.  Really, we need to just fix the bug.
>>>>>>> I think we'll try to do that for the next release, which should be
>>>>>>> within two months at most.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 6, 2012 at 1:41 AM, treffeisen ltd.
>>>>>>> <director at treffeisen.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Grant,
>>>>>>>
>>>>>>>                 Thank you for the quick response on  this.
>>>>>>>
>>>>>>> Is there a way to catch the exception thrown so I can ignore or
>>>>>>> skip the message?
>>>>>>>
>>>>>>> As this is happening in the SocketInitiatorThread I see that there
>>>>>>> is an immediate disconnect when an exception is thrown.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>                 anmatr
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Grant Birchmeier [mailto:gbirchmeier at connamara.com]
>>>>>>> Sent: 05 December 2012 20:43
>>>>>>> To: director at treffeisen.net; Mailing list for QuickFIX/n
>>>>>>> Subject: Re: {{Quickfixn}} Invalid body length
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, this is a known bug.  We're not computing the checksum
>>>>>>> correctly for non ASCII characters.  An issue is open for it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note, though, that the message you've presented is technically
>>>>>>> invalid.  FIX messages are supposed to be all-ASCII, except for
>>>>>>> fields named "Encoded<whatever>".  Field 58 ("Text") is not one of
>>>>>>> those, and thus should not have non-ASCII in it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In practice, counterparties can be stupid, though, and QF/n should
>>>>>>> probably be tolerant of non-ASCII, at least as far as the checksum is concerned.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You should let your sender know that this message is technically illegal.
>>>>>>> Unfortunately I don't see a ready workaround at this time.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Grant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Dec 5, 2012 at 2:20 PM, treffeisen ltd.
>>>>>>> <director at treffeisen.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>>         I think this was it in the list as “Checksum problem”.
>>>>>>>
>>>>>>> 20121205-14:46:29.623 : Session FIX.4.4:SOURCE->TARGET disconnecting:
>>>>>>> QuickFix.MessageParseError: Could not parse message: Invalid body
>>>>>>> length
>>>>>>>
>>>>>>>    at QuickFix.Parser.ReadFixMessage(String& msg)
>>>>>>>
>>>>>>>    at QuickFix.SocketInitiatorThread.ProcessStream()
>>>>>>>
>>>>>>>    at QuickFix.SocketInitiatorThread.Read()
>>>>>>>
>>>>>>> There is an odd character in a comment field and it seems that the
>>>>>>> checksum calculation does not handle that.
>>>>>>>
>>>>>>> 58=xyz SELLS TO JAE @ 99-19+ VS BUYING 1MM INTC 4¼'42 @ +143/CT30
>>>>>>>
>>>>>>> It is in this custom field 58 and might be the character after the
>>>>>>> first sequence INTC 4 (not sure if that is displayed properly on the forum).
>>>>>>>
>>>>>>> We use quckfix/n version 1.3.0
>>>>>>>
>>>>>>> Is this a known problem?
>>>>>>>
>>>>>>> Any help is highly appreciated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>         Anmatr.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Quickfixn mailing list
>>>>>>> Quickfixn at lists.quickfixn.com
>>>>>>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Grant Birchmeier
>>>>>>>
>>>>>>> Connamara Systems, LLC
>>>>>>>
>>>>>>> Made-To-Measure Trading Solutions.
>>>>>>>
>>>>>>> Exactly what you need. No more. No less.
>>>>>>>
>>>>>>> http://connamara.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Quickfixn mailing list
>>>>>>> Quickfixn at lists.quickfixn.com
>>>>>>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Grant Birchmeier
>>>>>>>
>>>>>>> Connamara Systems, LLC
>>>>>>>
>>>>>>> Made-To-Measure Trading Solutions.
>>>>>>>
>>>>>>> Exactly what you need. No more. No less.
>>>>>>>
>>>>>>> http://connamara.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Grant Birchmeier
>>>>>>>
>>>>>>> Connamara Systems, LLC
>>>>>>>
>>>>>>> Made-To-Measure Trading Solutions.
>>>>>>>
>>>>>>> Exactly what you need. No more. No less.
>>>>>>>
>>>>>>> http://connamara.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Grant Birchmeier
>>>>>>>
>>>>>>> Connamara Systems, LLC
>>>>>>>
>>>>>>> Made-To-Measure Trading Solutions.
>>>>>>>
>>>>>>> Exactly what you need. No more. No less.
>>>>>>>
>>>>>>> http://connamara.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Grant Birchmeier
>>>>>>>
>>>>>>> Connamara Systems, LLC
>>>>>>>
>>>>>>> Made-To-Measure Trading Solutions.
>>>>>>>
>>>>>>> Exactly what you need. No more. No less.
>>>>>>>
>>>>>>> http://connamara.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Grant Birchmeier
>>>>>> Connamara Systems, LLC
>>>>>> Made-To-Measure Trading Solutions.
>>>>>> Exactly what you need. No more. No less.
>>>>>> http://connamara.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Grant Birchmeier
>>>>> Connamara Systems, LLC
>>>>> Made-To-Measure Trading Solutions.
>>>>> Exactly what you need. No more. No less.
>>>>> http://connamara.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Grant Birchmeier
>>>> Connamara Systems, LLC
>>>> Made-To-Measure Trading Solutions.
>>>> Exactly what you need. No more. No less.
>>>> http://connamara.com
>>>
>>>
>>>
>>> --
>>> Grant Birchmeier
>>> Connamara Systems, LLC
>>> Made-To-Measure Trading Solutions.
>>> Exactly what you need. No more. No less.
>>> http://connamara.com
>>>
>>
>>
>>
>> --
>> Grant Birchmeier
>> Connamara Systems, LLC
>> Made-To-Measure Trading Solutions.
>> Exactly what you need. No more. No less.
>> http://connamara.com
>
>
>
> --
> Grant Birchmeier
> Connamara Systems, LLC
> Made-To-Measure Trading Solutions.
> Exactly what you need. No more. No less.
> http://connamara.com
>



-- 
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com

More information about the Quickfixn mailing list