quickfix-users — QuickFIX user support

[Quickfix-users] Application Terminated.........

[Mohammed J. <jas...@ho...>]

Hi all,i built a small application using quick fix, it behaves as acceptor, in the application during the instantiation of the SocketAcceptor class the program is getting terminated without any error or warning. Since there is no warning or error messages i have no idea whats going on inside, i tried to debug my application and found the line where program is getting terminated......
Below is the line m_application.toAdmin( message,m_sessionID ); Session.cpp contains this line
please help if there is a way to fix this.....
Kind Regards Mohammed Jasind 		 	   		  

Re: [Quickfix-users] quickfix/n error : MsgSeqNum too high, expecting 1 but received 14

[Grant B. <gbi...@co...>]

This is the list for the C++-based QuickFIX.

I
f you are using QF/n, you should join the QF/n-specific list:
http://quickfixn.org/help

T
o your problem
:

U
nless one side of the QF connection is configured to reset sequence numbers
on login, both sides will maintain the sequence number count between
executions.  Most likely you are resetting
the seq of
one side of the connection somehow (by deleting the store maybe?) without
resetting the other.


On Wed, Aug 28, 2013 at 4:45 AM, vishveshraval <vis...@ho...>wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello Sir,
>       I have created a Fix application using 'QuickFIX/n is v1.4.0' from
> this 'http://www.quickfixn.org/download' site.
> When I executed an application,i randomly get error of sequence
> number.Sometimes the application runs fine and sometime I get sequence
> number problem.The log details are as below:
>
> 20130828-07:20:09.859 : Created session
> 20130828-07:20:10.593 : FIX.4.4:Server->Client Socket Reader 16492409
> accepting session FIX.4.4:Server->Client from 192.168.1.109:4155
> 20130828-07:20:10.593 : FIX.4.4:Server->Client Acceptor heartbeat set to 0
> seconds
> 20130828-07:20:10.750 : Received logon
> 20130828-07:20:10.796 : Responding to logon request
> 20130828-07:20:10.796 : MsgSeqNum too high, expecting 1 but received 13
> 20130828-07:20:10.796 : Sent ResendRequest FROM: 1 TO: 0
> 20130828-07:20:10.890 : MsgSeqNum too high, expecting 1 but received 14
> 20130828-07:20:10.890 : Already sent ResendRequest FROM: 1 TO: 0.  Not
> sending another.
> 20130828-07:20:10.921 : Received logout request
> 20130828-07:20:11.187 : Session FIX.4.4:Server->Client disconnecting:
> Socket
> exception (192.168.1.109:4155): An existing connection was forcibly closed
> by the remote host
> 20130828-07:20:11.906 : FIX.4.4:Server->Client Socket Reader 27778196
> accepting session FIX.4.4:Server->Client from 192.168.1.109:4156
> 20130828-07:20:11.906 : FIX.4.4:Server->Client Acceptor heartbeat set to
> 30
> seconds
> 20130828-07:20:11.906 : Received logon
> 20130828-07:20:11.906 : Responding to logon request
> 20130828-07:20:11.906 : MsgSeqNum too high, expecting 1 but received 14
> 20130828-07:20:11.921 : Sent ResendRequest FROM: 1 TO: 0
> 20130828-07:20:11.921 : Got resend request from 13 to 0
> 20130828-07:20:11.937 : Sent SequenceReset TO: 16
> 20130828-07:20:11.953 : ResendRequest for messages FROM: 1 TO: 0 has been
> satisfied.
> 20130828-07:20:11.953 : Received SequenceReset FROM: 1 TO: 2
> 20130828-07:20:11.984 : Received SequenceReset FROM: 3 TO: 4
> 20130828-07:20:11.984 : Received SequenceReset FROM: 5 TO: 10
> 20130828-07:20:12.000 : Received SequenceReset FROM: 11 TO: 12
> 20130828-07:20:12.000 : Received SequenceReset FROM: 13 TO: 16
>
> Please kindly send me suggestions and settings to run this application
> without errors.
>
>
> Thanks and Reguards,
> Vishwesh Raval.
>
>
>
> --
> View this message in context:
> http://quickfix.13857.n7.nabble.com/quickfix-n-error-MsgSeqNum-too-high-expecting-1-but-received-14-tp6560.html
> Sent from the QuickFIX - User mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>



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

[Quickfix-users] quickfix/n error : MsgSeqNum too high, expecting 1 but received 14

[vishveshraval <vis...@ho...>]

Hello Sir,
      I have created a Fix application using 'QuickFIX/n is v1.4.0' from
this 'http://www.quickfixn.org/download' site.
When I executed an application,i randomly get error of sequence
number.Sometimes the application runs fine and sometime I get sequence
number problem.The log details are as below:

20130828-07:20:09.859 : Created session
20130828-07:20:10.593 : FIX.4.4:Server->Client Socket Reader 16492409
accepting session FIX.4.4:Server->Client from 192.168.1.109:4155
20130828-07:20:10.593 : FIX.4.4:Server->Client Acceptor heartbeat set to 0
seconds
20130828-07:20:10.750 : Received logon
20130828-07:20:10.796 : Responding to logon request
20130828-07:20:10.796 : MsgSeqNum too high, expecting 1 but received 13
20130828-07:20:10.796 : Sent ResendRequest FROM: 1 TO: 0
20130828-07:20:10.890 : MsgSeqNum too high, expecting 1 but received 14
20130828-07:20:10.890 : Already sent ResendRequest FROM: 1 TO: 0.  Not
sending another.
20130828-07:20:10.921 : Received logout request
20130828-07:20:11.187 : Session FIX.4.4:Server->Client disconnecting: Socket
exception (192.168.1.109:4155): An existing connection was forcibly closed
by the remote host
20130828-07:20:11.906 : FIX.4.4:Server->Client Socket Reader 27778196
accepting session FIX.4.4:Server->Client from 192.168.1.109:4156
20130828-07:20:11.906 : FIX.4.4:Server->Client Acceptor heartbeat set to 30
seconds
20130828-07:20:11.906 : Received logon
20130828-07:20:11.906 : Responding to logon request
20130828-07:20:11.906 : MsgSeqNum too high, expecting 1 but received 14
20130828-07:20:11.921 : Sent ResendRequest FROM: 1 TO: 0
20130828-07:20:11.921 : Got resend request from 13 to 0
20130828-07:20:11.937 : Sent SequenceReset TO: 16
20130828-07:20:11.953 : ResendRequest for messages FROM: 1 TO: 0 has been
satisfied.
20130828-07:20:11.953 : Received SequenceReset FROM: 1 TO: 2
20130828-07:20:11.984 : Received SequenceReset FROM: 3 TO: 4
20130828-07:20:11.984 : Received SequenceReset FROM: 5 TO: 10
20130828-07:20:12.000 : Received SequenceReset FROM: 11 TO: 12
20130828-07:20:12.000 : Received SequenceReset FROM: 13 TO: 16

Please kindly send me suggestions and settings to run this application
without errors.


Thanks and Reguards,
Vishwesh Raval.



--
View this message in context: http://quickfix.13857.n7.nabble.com/quickfix-n-error-MsgSeqNum-too-high-expecting-1-but-received-14-tp6560.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

[Quickfix-users] fields order within a repeating group

[Rayan R. <ray...@gm...>]

Hi all,
I'm working with the quickfix 1.13.3 in order to create a FIX bridge
(FIX42) using Python.

The aim of this bridge is simply to forward FIX messages from some client
applications towards broker FIX sessions (and vice versa).

Unfortunately I'm experiencing some issues when forwarding FIX messages
that contain repeating groups.

For instance, forwarding a SecurityDefinition (35=d) to clients, the fields
order of some custom repeating groups is not correct.
Actually some tags (for example 18203-ExchangeGateway)  that should be in a
custom group are sent before the group tag delimiter (18203-NoGateways) !


broker SecurityDefinition to bridge :
35=d .... 18206=1  18203=CME
  ....

client SecurityDefinition from bridge :
35=d .... 18203=CME
  18206=1   ....
35=3 ....  
58=Tag not defined for this message type 
  371=18203 ....

where :
          <group name="NoGateways" required="N">
              <field name="ExchangeGateway" required="N" />
          </group>

Of course clients/bridge/brokers use the same FIX dictionary.
Please note that messages received by the bridge are simply re-send to the
corresponding client FIX sessions. No one is altering the content nor the
fields order sequence ...

So why does this order change ?

How can I force the bridge's QF to serialize FIX messages for clients with
the same fields order that brokers are sending to the bridge ?

Thanks a lot,
Rayan

[Quickfix-users] ordermatch modification crashes

[Neeraj R. <rn...@ya...>]

Hi,

I modified example application ordermatch to send an ack after a delay in a separate thread.
I made similar thread for filling it.
It runs for a while and then core dumps (Linux).
The stack trace shows there is an incoming order being processed while my thread is trying to send an ack.
I tried changing to Synchronised app ( though I have only one session), but that is not helping either.

I would like to hear from the group Is this acceptable usage ?
Is there a better way to do this?

thanks
Neeraj

[Quickfix-users] LINK : fatal error LNK1104: cannot open file 'atls.lib'

[Mohammed J. <jas...@ho...>]

Hi all,i downloaded the latest quickfix binary to use it with my application, i am using Microsoft Visual c++ to build my application, but when i build my application it shows the following error message....
LINK : fatal error LNK1104: cannot open file 'atls.lib'

i researched on the Web about this and tried a lot but nothing worked......
Please share if there is any solution for this problem.......
Jasind 		 	   		  

[Quickfix-users] QuickFIX source code hosting has been moved to github

[<or...@qu...>]

As promised, the QuickFIX repository has been moved over to github.  The
subversion repository on sourceforge is now locked and will no longer
receive updates.  The new repository is located at
https://github.com/quickfix/quickfix

Among other things, this should make code submissions much easier.

Re: [Quickfix-users] Visual 2012

[aupadras <ani...@ya...>]

Hi Mike,

Finally, QF is up and running on VS2012 64 bit machine (windows 7), all
issues were resolved. The problem was due to
"Microsoft.Cpp.UpgradeFromVC71.props" file is blank. Also, Re-installation
of Quick FIX solved the issue.

Thanks,
- aupadras.



--
View this message in context: http://quickfix.13857.n7.nabble.com/Visual-2012-tp6511p6533.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] unitTest++ failure

[Conor m. <con...@ho...>]

Hey Guys;

It seems the order of the resent message is different for FIX::FIELD::ContraTrader and FIX::FIELD::ContraBroker

Failing test....

From: con...@ho...
To: qui...@li...
Date: Wed, 17 Jul 2013 08:28:33 +0000
Subject: [Quickfix-users] unitTest++ failure

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html
 

Hi;

I am trying to bring quickfix UnitTest++ into our project for the first time and was wondering could I get some help with the following failures I am seeing.

I am running quickfix/test/runut.sh" -p -f after I have configured compiled and linked unitTest++ with my quickfix library.



  

C++/test/SessionTestCase.cpp:1068: error: Failure in 
nextResendRequestRepeatingGroup: Expected 
8=FIX.4.29=25235=834=243=Y49=TW52=20130715-

12:19:05.29856=ISLD122=20130715-12:19:05.2986=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=139 but was
 
8=FIX.4.29=25235=834=243=Y49=TW52=20130715-12:19:05.29856=ISLD122=20130715-

12:19:05.2986=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-

12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=139

C++/test/SessionTestCase.cpp:1087: error: Failure in 
nextResendRequestT1142RepeatingGroup: Expected 
8=FIXT.1.19=25935=834=243=Y49=TW52=20130715-

12:19:05.63256=ISLD122=20130715-12:19:05.6311128=46=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=015 but was
 
8=FIXT.1.19=25935=834=243=Y49=TW52=20130715-12:19:05.63256=ISLD122=20130715-

12:19:05.6311128=46=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-

12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=015

C++/test/SessionTestCase.cpp:1106: error: Failure in 
nextResendRequestT1150RepeatingGroup: Expected 
8=FIXT.1.19=23335=834=243=Y49=TW52=20130715-

12:19:05.96856=ISLD122=20130715-12:19:05.96814=017=ID37=ID39=054=1150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=240 but was
 
8=FIXT.1.19=23335=834=243=Y49=TW52=20130715-12:19:05.96856=ISLD122=20130715-

12:19:05.96814=017=ID37=ID39=054=1150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=240

FAILURE: 3 out of 178 tests failed (3 failures).

Test time: 10.85 seconds.

  



Many thanks in advance
Conor



Hi;

I am trying to bring quickfix UnitTest++ into our project for the first time and was wondering could I get some help with the following failures I am seeing.

I am running quickfix/test/runut.sh" -p -f after I have configured compiled and linked unitTest++ with my quickfix library.

<ut>

  <output>

C++/test/SessionTestCase.cpp:1068: error: Failure in 
nextResendRequestRepeatingGroup: Expected 
8=FIX.4.29=25235=834=243=Y49=TW52=20130715-

12:19:05.29856=ISLD122=20130715-12:19:05.2986=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=139 but was
 
8=FIX.4.29=25235=834=243=Y49=TW52=20130715-12:19:05.29856=ISLD122=20130715-

12:19:05.2986=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-

12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=139

C++/test/SessionTestCase.cpp:1087: error: Failure in 
nextResendRequestT1142RepeatingGroup: Expected 
8=FIXT.1.19=25935=834=243=Y49=TW52=20130715-

12:19:05.63256=ISLD122=20130715-12:19:05.6311128=46=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=015 but was
 
8=FIXT.1.19=25935=834=243=Y49=TW52=20130715-12:19:05.63256=ISLD122=20130715-

12:19:05.6311128=46=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-

12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=015

C++/test/SessionTestCase.cpp:1106: error: Failure in 
nextResendRequestT1150RepeatingGroup: Expected 
8=FIXT.1.19=23335=834=243=Y49=TW52=20130715-

12:19:05.96856=ISLD122=20130715-12:19:05.96814=017=ID37=ID39=054=1150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=240 but was
 
8=FIXT.1.19=23335=834=243=Y49=TW52=20130715-12:19:05.96856=ISLD122=20130715-

12:19:05.96814=017=ID37=ID39=054=1150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=240

FAILURE: 3 out of 178 tests failed (3 failures).

Test time: 10.85 seconds.

  </output>

</ut>

Many thanks in advance
Conor
 		 	   		  

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users 		 	   		  

[Quickfix-users] unitTest++ failure

[Conor m. <con...@ho...>]

Hi;

I am trying to bring quickfix UnitTest++ into our project for the first time and was wondering could I get some help with the following failures I am seeing.

I am running quickfix/test/runut.sh" -p -f after I have configured compiled and linked unitTest++ with my quickfix library.

<ut>

  <output>

C++/test/SessionTestCase.cpp:1068: error: Failure in 
nextResendRequestRepeatingGroup: Expected 
8=FIX.4.29=25235=834=243=Y49=TW52=20130715-

12:19:05.29856=ISLD122=20130715-12:19:05.2986=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=139 but was
 
8=FIX.4.29=25235=834=243=Y49=TW52=20130715-12:19:05.29856=ISLD122=20130715-

12:19:05.2986=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-

12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=139

C++/test/SessionTestCase.cpp:1087: error: Failure in 
nextResendRequestT1142RepeatingGroup: Expected 
8=FIXT.1.19=25935=834=243=Y49=TW52=20130715-

12:19:05.63256=ISLD122=20130715-12:19:05.6311128=46=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=015 but was
 
8=FIXT.1.19=25935=834=243=Y49=TW52=20130715-12:19:05.63256=ISLD122=20130715-

12:19:05.6311128=46=014=017=ID20=037=ID39=054=155=SYMBOL150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-

12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=015

C++/test/SessionTestCase.cpp:1106: error: Failure in 
nextResendRequestT1150RepeatingGroup: Expected 
8=FIXT.1.19=23335=834=243=Y49=TW52=20130715-

12:19:05.96856=ISLD122=20130715-12:19:05.96814=017=ID37=ID39=054=1150=0151=100382=2375=BROKER337=TRADER437=100438=20130715-

12:19:05375=BROKER2337=TRADER2437=100438=20130715-12:19:0510=240 but was
 
8=FIXT.1.19=23335=834=243=Y49=TW52=20130715-12:19:05.96856=ISLD122=20130715-

12:19:05.96814=017=ID37=ID39=054=1150=0151=100382=2337=TRADER375=BROKER437=100438=20130715-12:19:05337=TRADER2375=BROKER2437=100438=20130715-12:19:0510=240

FAILURE: 3 out of 178 tests failed (3 failures).

Test time: 10.85 seconds.

  </output>

</ut>

Many thanks in advance
Conor
 		 	   		  

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

Hi Mike,

Thanks for your responses. I accomplished the DC session, i.e., send and
respond to the administrative messages and listening drop copies from
counter party. 

Initially, the problem sounded like DC session should be re-created as
NewOrderSingle without sending the messages. But actually I just need to
worry about the session and heart-beats (administrative stuff), Quick FIX
inherently takes care of receiving the execution report and fills from the
counter-party via fromApp() -
> onMessage(ExecutionReport).


Thanks,
aupadras.



--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6530.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Storing orders

[Mike G. <mg...@co...>]

On Thu, Jul 11, 2013 at 4:42 AM, Petr Janda <ele...@ex...>wrote:

> Does quickfix provide a facility to reload the existing orders, or is
> that entirely dependent upon my implementation (ie. I have to do this by
> storing it in a database of some sort)
>

This is left up to your implementation.  Through FYI, you can in fact
retrieve messages you *sent* from the MessageStore


>
> 2) This may be a dumb question, but I'm trying to picture a scenario.
> What's the point of storing messages (either in file store or in
> Postgres). What advantages do I gain by setting PersistOnLogon and/or
> PersistMessages to Y.
>

Messages that you have sent are stored automatically in a MessageStore by
the QF Session layer in case your counterparty requests a resend request
from you.  This is necessary because FIX protocol guarantees delivery of
messages, in the correct sequence.  You can disable this FIX behavior with
settings like PersistMessages=N and ResetOnLogon=Y.  This is really only
recommended for market data sessions, i.e. where resend requests are not
desirable.

-- 
Mike Gatny
Connamara Systems, LLC

Re: [Quickfix-users] Storing orders

[Petr J. <ele...@ex...>]

Sorry, I meant RefreshOnLogon.

[Quickfix-users] Storing orders

[Petr J. <ele...@ex...>]

Hi,

I'm new to QuickFIX and I'm still trying to wrap my head around it. I've
followed the C++ example on OrderMatcher and it seems to work fine. But
I do have a couple of questions.

1) When the QuickFIX engine(acceptor side) shuts down(either scheduled
or unscheduled shutdown), all the existing orders disappear.

Does quickfix provide a facility to reload the existing orders, or is
that entirely dependent upon my implementation (ie. I have to do this by
storing it in a database of some sort)

2) This may be a dumb question, but I'm trying to picture a scenario.
What's the point of storing messages (either in file store or in
Postgres). What advantages do I gain by setting PersistOnLogon and/or
PersistMessages to Y.

Thank you,
Petr Janda


-- 
Please use PGP to encrypt your email to ensure our privacy is respected.

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[Mike G. <mg...@co...>]

On Wed, Jul 10, 2013 at 1:51 PM, aupadras <ani...@ya...> wrote:

> Now my question is regarding the Drop Copy Session what would be the flow
> look like ?
>
> generate new single order message() --> send to Target (toApp()) -->
> fromApp() ---> onMessage(Execution Report)
>

The flow you have described here is what the flow will look like in the app
that actually sends the order.

In the drop copy app, the perceived flow is just:

fromApp() -> onMessage(Execution Report)



-- 
Mike Gatny
Connamara Systems, LLC

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

Hi,

Yes, they did provided me a drop copy session and AFT session. I am using an
AFT session for staging the order. Now my question is regarding the Drop
Copy Session what would be the flow look like ?

generate new single order message() --> send to Target (toApp()) -->
fromApp() ---> onMessage(Execution Report)

or 

generate new single order message() --> fromApp() ---> onMessage(Execution
Report). 

Question is does fromApp() is called if I skip the toApp() or
(SendToTarget()) ? Please suggest the better flow using QF for Drop Copy
Session (just for listening).

Thanks,
aupadras.




--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6525.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[Mike G. <mg...@co...>]

>
> On Wed, Jul 10, 2013 at 1:03 PM, aupadras <ani...@ya...> wrote:
> My other question..., is how to create a DC (execution reports) without
> staging the order using Quick FIX ? i.e.., how to use Quick FIX for only
> listening purposes (without sending the actual message to Target) ? Is this
> possible, if so how ?


If your counterparty supports sending drop copies in the form of
ExecutionReports, your drop copy client will be essentially the same as
your app that sends NewOrderSingles.  I.e. you will implement the
onMessage() callback for ExecutionReports and process them when they arrive.

But first you need to find out if your counterparty supports drop copy.  If
they do, they will set up a separate Session for this purpose.  You cannot
simply connect another Initiator app to the same FIX Session.

-- 
Mike Gatny
Connamara Systems, LLC

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

Hi Mike,

Ok..,  I didn't loop through the application.run(). The code I was using
simply:
initiator.start();
application.run();
initiator.stop();

and the application.run() has all the elements that you suggested me to
follow using the examples (toApp, fromApp, toAdmin, fromAdmin with message
cracker) and I also ensured that getting and setting 
fields using the type safe ways.


My other question..., is how to create a DC (execution reports) without
staging the order using Quick FIX ? i.e.., how to use Quick FIX for only
listening purposes (without sending the actual message to Target) ? Is this
possible, if so how ?


Thanks,
aupadras.



--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6523.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[Mike G. <mg...@co...>]

On Tue, Jul 9, 2013 at 2:45 AM, aupadras <ani...@ya...> wrote:

>         initiator.start();
>         application.run();
>         initiator.stop();
>

As soon as application.run() returns, initiator.stop() is going to be
called.  Does application.run() loop forever? It probably should if you
want this to work correctly.

Finally, I don't recall of seeing the print statement outputs in onMessage
> or fromAPP block. I do see some action from toAPP (when message is sent to
> target), but never seen from fromAPP or onMessages. Do I need to call
> fromAPP and onMessages(Execution Reports) in my application whereas toAPP
> is
> called by default by QF when message is being sent to target ???
>

Quickfix invokes fromApp, toApp, toAdmin, and fromAdmin.  You should not
call those yourself.  Quickfix does not call the onMessage() callbacks --
those are there for convenience, and if you want to use them you have to
call crack() during fromApp().  If you have not done so, please look at the
example applications that are included with the Quickfix source code.  They
demonstrate the correct way to do most of what you are asking about.  And
if you haven't read the docs on the site yet, they also address this:
http://quickfixengine.org/quickfix/doc/html/application.html
http://quickfixengine.org/quickfix/doc/html/receiving_messages.html

-- 
Mike Gatny
Connamara Systems, LLC

[Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

Hi Mike, 

Please address the following:

I am using following piece of code and worried that initiator.stop() is initiating the log -out. I have StartTime=00:01:00 and EndTime=23:55:00 in the config file. How can my application continuously communicate with my counter-party without logging out i..,e Do I need to delete initiator.stop or is there any safe mechanism to handle this like initiator to be stopped when clock Time == EndTime? Or Am I completely out of whack. 

        initiator.start();   
        application.run(); 
        initiator.stop(); 

Please give me insight, when an initiator should be stopped after a new single order is being placed ? Is initiator stopped automatically when the FIX messages are not exchanged between me and counter-party after I complete the execution of the order that I placed ?


In addition to the above, sometimes I under-go fatal problems like... socket initiator error,resend request issues and msgseqno mis-match (msg seq no is too low or too high) etc.., with my counter-party. In those cases, I am asking my counter-party to reset the seqno. However, once we go live and real time this is not the best option. Please suggest the best ways to design the robust system. 

My Config settings are : 
ResetOnDisconnect=N 
CheckLatency=N 
ResetOnLogon=N 
ResetOnLogout=N 
SendResetSeqNumFlag=N 
RefreshOnLogon=Y 
PersistMessages=Y 
MillisecondsInTimeStamp=Y 
UseDataDictionary=Y 

Also, I am implementing try-catch mechanism in setting and getting the field information defined in data-dictionary. 

Currently, I see sendtoTarget ---> toApp() --- > fromAPP() ---> onMessage() is the flow I am expecting. I assume, as I throw the reject message the flow is stopping after toAPP(). Is this correct ?

Finally, We would like to create a DC session (Only for listening purposes). I am using the trade-client example and I am not sending the message to the target, but I re-created the message that has been staged and trying to listen the fill backs using onMessage(ExecutionReport, SessionID) in application.run(). Is this a proper way to implement (DC session) just for listening ? 


Please Advise. 

Thanks, 
Anil.


________________________________
 From: Mike Gatny [via QuickFIX] <ml-...@n7...>
To: aupadras <ani...@ya...> 
Sent: Sunday, July 7, 2013 10:35 PM
Subject: Re: Incorrect Data Format aka possDupFlag issue
 


QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


On Sun, Jul 7, 2013 at 8:13 PM, aupadras <[hidden email]> wrote:

MsgSeqNum=1
>

Note: this has no effect, and you should never set tag 34 yourself.
 
PossDupFlag=N
>

Note: this also has no effect, and you should never remove PossDupFlag from a message yourself.  The presence of PossDupFlag means that quickfix is re-sending a message you sent previously to honor a resend request made by your counterpary.   If you don't want the message to be resent, throw DoNotSend, but do not ever set/unset this field yourself.
  
Problem: I am able to STAGE the order, however the operations of staging is
>not smooth i.e.., STAGING the order is followed by following issues (even
>though tag 15 is not missing (Currency = 'USD')) the message is getting
>rejected) :
>

Your new order single is not being rejected due to a missing tag 15.  Rather, you are rejecting the execution report you are receiving in response to the new order single because the execution report does not contain tag 15.  You need to set required="N" for tag 15 for execution report messages in your data dictionary, and don't try to get() that field unless you catch FieldNotFound.
 
20130707-20:34:49.164 : Initiated logout request
>20130707-20:34:49.164 : Received logout response
>The problem is due to possDupFlag in toAPP and after this reject message I
>am getting logged out not able to enter into fromAPP logic (to retrieve
>execution report info)
>

It looks like you are the one initiating the logout.

If I delete the possDupFlag from toAPP logic then I am having following
>

Don't do that :)  See above.
 
Please suggest how to fix the message seq issues or reset issues that are
>arising ? Am I using the wrong implementation of possDupFlag in toAPP ? What
>is the best and safest way of implementing the toAPP ? What are the issues
>that are creating the problem ? Can we get rid of the possDupFlag altogather
>?
>

Start by fixing the tag 15 reject, then figure out why you are initiating that logout.  Then make sure you aren't messing with PossDupFlag or MsgSeqNum directly.
-- 
Mike Gatny
Connamara Systems, LLC 
------------------------------------------------------------------------------ 
This SF.net email is sponsored by Windows: 

Build for Windows Store. 

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ 
Quickfix-users mailing list 
[hidden email] 
https://lists.sourceforge.net/lists/listinfo/quickfix-users


________________________________
 
If you reply to this email, your message will be added to the discussion below:http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6519.html 
To unsubscribe from Incorrect Data Format aka possDupFlag issue, click here.
NAML



--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6521.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

Hi,

I contacted my counter-party to match my msg type '8' data dictionary
settings.., so hopefully I will not reject their messages. I assume this
will fix the problem.

I am using following piece of code and worried that initiator.stop() is
initiating the log -out. I have StartTime=00:01:00 and EndTime=23:55:00 in
the config file. How can my application continuously communicate with my
counter-party without logging out i..,e Do I need to delete initiator.stop
or is there any safe mechanism to handle this like initiator to be stopped
when clock Time == EndTime? Or Am I completely out of whack.

        initiator.start();  					
	application.run();						
        initiator.stop();		 
        return 0;	

In addition to the above, sometimes I under-go fatal problems like... socket
initiator error,resend request issues and msgseqno mis-match (msg seq no is
too low or too high) etc.., with my counter-party. In those cases, I am
asking my counter-party to reset the seqno. However, once we go live and
real time this is not the best option. Please suggest the best ways to
design the robust system.

My Config settings are :
ResetOnDisconnect=N
CheckLatency=N
ResetOnLogon=N
ResetOnLogout=N
SendResetSeqNumFlag=N
RefreshOnLogon=Y
PersistMessages=Y
MillisecondsInTimeStamp=Y
UseDataDictionary=Y

Also, I am implementing try-catch mechanism in setting and getting the field
information defined in data-dictionary. 

Finally, I don't recall of seeing the print statement outputs in onMessage
or fromAPP block. I do see some action from toAPP (when message is sent to
target), but never seen from fromAPP or onMessages. Do I need to call
fromAPP and onMessages(Execution Reports) in my application whereas toAPP is
called by default by QF when message is being sent to target ???

Please Advise.

Thanks,
aupadras.



--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518p6520.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Incorrect Data Format aka possDupFlag issue

[Mike G. <mg...@co...>]

On Sun, Jul 7, 2013 at 8:13 PM, aupadras <ani...@ya...> wrote:

> MsgSeqNum=1
>

Note: this has no effect, and you should never set tag 34 yourself.


> PossDupFlag=N
>

Note: this also has no effect, and you should never remove PossDupFlag from
a message yourself.  The presence of PossDupFlag means that quickfix is
re-sending a message you sent previously to honor a resend request made by
your counterpary.   If you don't want the message to be resent, throw
DoNotSend, but do not ever set/unset this field yourself.


> Problem: I am able to STAGE the order, however the operations of staging is
> not smooth i.e.., STAGING the order is followed by following issues (even
> though tag 15 is not missing (Currency = 'USD')) the message is getting
> rejected) :
>

Your new order single is not being rejected due to a missing tag 15.
 Rather, you are rejecting the execution report you are receiving in
response to the new order single because the execution report does not
contain tag 15.  You need to set required="N" for tag 15 for execution
report messages in your data dictionary, and don't try to get() that field
unless you catch FieldNotFound.


> 20130707-20:34:49.164 : Initiated logout request
> 20130707-20:34:49.164 : Received logout response
> The problem is due to possDupFlag in toAPP and after this reject message I
> am getting logged out not able to enter into fromAPP logic (to retrieve
> execution report info)
>

It looks like you are the one initiating the logout.

If I delete the possDupFlag from toAPP logic then I am having following
>

Don't do that :)  See above.


> Please suggest how to fix the message seq issues or reset issues that are
> arising ? Am I using the wrong implementation of possDupFlag in toAPP ?
> What
> is the best and safest way of implementing the toAPP ? What are the issues
> that are creating the problem ? Can we get rid of the possDupFlag
> altogather
> ?
>

Start by fixing the tag 15 reject, then figure out why you are initiating
that logout.  Then make sure you aren't messing with PossDupFlag or
MsgSeqNum directly.

-- 
Mike Gatny
Connamara Systems, LLC

[Quickfix-users] Incorrect Data Format aka possDupFlag issue

[aupadras <ani...@ya...>]

Hi,

I am having following problem.., I sort of figured out where the problem is
and not able to figure of the best solution to it...

My Config Settings:

[DEFAULT]
ConnectionType=initiator
StartTime=00:01:00
EndTime=23:55:00
MsgSeqNum=1
UseLocalTime=Y
ResetOnDisconnect=N
CheckLatency=N
PossDupFlag=N
ResetOnLogon=N
ResetOnLogout=N
SendResetSeqNumFlag=N
RefreshOnLogon=Y
PersistMessages=Y
MillisecondsInTimeStamp=Y
UseDataDictionary=Y
HeartBtInt=30

<field name='PossDupFlag' required='N' />

Problem: I am able to STAGE the order, however the operations of staging is
not smooth i.e.., STAGING the order is followed by following issues (even
though tag 15 is not missing (Currency = 'USD')) the message is getting
rejected) : 

20130707-20:34:45.664 : Created session
20130707-20:34:47.227 : Connecting to 63.75.63.250 on port 1838
20130707-20:34:47.274 : Initiated logon request
20130707-20:34:47.289 : Received logon response
20130707-20:34:47.446 : Message 2 Rejected: Required tag missing:15
20130707-20:34:49.164 : Initiated logout request
20130707-20:34:49.164 : Received logout response
20130707-20:34:49.164 : Disconnecting


20130707-20:34:47.258 :
8=FIX.4.2
9=64
35=A
34=1
49=alpha
52=20130707-20:34:47.243
56=beta
98=0
108=30
10=191

20130707-20:34:47.274 :
8=FIX.4.2
9=60
35=A
49=beta
56=alpha
34=1
52=20130707-20:34:47
98=0
108=30
10=244

20130707-20:34:47.321 :
8=FIX.4.2
9=235
35=D
34=2
49=alpha
52=20130707-20:34:47.274
56=beta
57=STAGE
1=NEUTRAL
11=alphaA51873
15=USD
21=1
38=15
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-20:34:47
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=086

20130707-20:34:47.430 :
8=FIX.4.2
9=262
35=8
49=beta
56=alpha
34=2
50=STAGE
52=20130707-20:34:47
37=d9351954-d1-07sp
11=alphaA51873
17=d9351954-d1-07sp-2
20=0
150=0
39=0
1=NEUTRAL
55=/ESU3
54=1
38=15
40=1
59=0
167=FUT
200=201309
205=30
47=I
32=0
31=0.000000
151=15
14=0
6=0.000000
60=20130707-20:34:47
10=151

20130707-20:34:47.446 :
8=FIX.4.2
9=100
35=3
34=3
49=alpha
52=20130707-20:34:47.446
56=beta
45=2
58=Required
tag missing
371=15
372=8
373=1
10=094

20130707-20:34:49.164 :
8=FIX.4.2
9=52
35=5
34=4
49=alpha
52=20130707-20:34:49.164
56=beta
10=158

20130707-20:34:49.164 :
8=FIX.4.2
9=48
35=5
49=beta
56=alpha
34=3
52=20130707-20:34:48
10=216



The problem is kicking from toAPP:

void Application::toApp( FIX::Message& NewOrderSingle, const FIX::SessionID&
sessionID )
throw( FIX::DoNotSend )
{
   std::cout << "\n" << std::endl << "To App" << "\n" << std::endl;
  try
  {        
	FIX::PossDupFlag possDupFlag;	
	std::cout << std::endl << "Currency" << std::endl <<
NewOrderSingle.getField(FIX::Currency()) << "\n" << std::endl;	
	std::cout << std::endl << "Complete Message to XML" << std::endl <<
NewOrderSingle.toXML() << "\n" << std::endl;
	NewOrderSingle.getHeader().getField( possDupFlag );
    if ( possDupFlag ) throw FIX::DoNotSend();
  }
  catch ( FIX::FieldNotFound& FieldNotFound) {
     std::cout << std::endl << " Field Not Found " << FieldNotFound.what()
<< "\n" << std::endl;
	 std::cout << std::endl << "Field Not Found: " << FieldNotFound.field <<
"\n" << std::endl;	
	 std::cout << std::endl << "Field Not Found Type: " << FieldNotFound.type
<< "\n" <<  std::endl;		
  }

  catch ( FIX::IncorrectTagValue& IncorrectTagValue) {
     std::cout << std::endl << "Incorrect Tag detail: " <<
IncorrectTagValue.what() << "\n" << std::endl;
	 std::cout << std::endl << "Incorrect Tag Value: " <<
IncorrectTagValue.field <<  "\n" << std::endl;	
  }

  catch ( FIX::IncorrectDataFormat& IncorrectDataFormat) {
     std::cout << std::endl << "Incorrect Data Format Field: " <<
IncorrectDataFormat.what() << "\n"  <<  std::endl;
	 std::cout << std::endl << "Incorrect Data Format Type: " <<
IncorrectDataFormat.type << "\n" << std::endl;	
  }
}

The problem is due to possDupFlag in toAPP and after this reject message I
am getting logged out not able to enter into fromAPP logic (to retrieve
execution report info) 

If I delete the possDupFlag from toAPP logic then I am having following
issue.., message sequence resetting or socket initiator error by resetting
possDupFlag to Y (initial setting was "N"):

20130707-23:52:54.518 : Connecting to 63.75.63.250 on port 1838
20130707-23:54:11.411 : Created session
20130707-23:54:17.865 : Connecting to 63.75.63.250 on port 1838
20130707-23:54:17.880 : Initiated logon request
20130707-23:54:17.912 : Received logon response
20130707-23:54:17.912 : MsgSeqNum too high, expecting 30 but received 46
20130707-23:54:38.115 : Sent ResendRequest FROM: 30 TO: 0
20130707-23:54:38.131 : Received ResendRequest FROM: 34 TO: 0
20130707-23:54:48.694 : Resending Message: 34
20130707-23:54:53.491 : Sent SequenceReset TO: 36
20130707-23:54:53.491 : Resending Message: 36
20130707-23:54:55.288 : Sent SequenceReset TO: 39
20130707-23:54:55.288 : Resending Message: 39
20130707-23:54:56.085 : Sent SequenceReset TO: 42
20130707-23:54:56.085 : Resending Message: 42
20130707-23:54:56.100 : Sent SequenceReset TO: 44
20130707-23:54:56.100 : Initiated logout request
20130707-23:54:56.100 : Received ResendRequest FROM: 34 TO: 0
20130707-23:54:56.460 : Resending Message: 34
20130707-23:54:56.819 : Sent SequenceReset TO: 36
20130707-23:54:56.819 : Resending Message: 36
20130707-23:54:57.194 : Sent SequenceReset TO: 39
20130707-23:54:57.194 : Resending Message: 39
20130707-23:54:57.569 : Sent SequenceReset TO: 42
20130707-23:54:57.569 : Resending Message: 42
20130707-23:54:57.585 : Sent SequenceReset TO: 45
20130707-23:54:57.585 : Received SequenceReset FROM: 30 TO: 49
20130707-23:54:57.585 : Received logout response
20130707-23:54:57.585 : Disconnecting



20130707-23:43:41.907 :
8=FIX.4.2
9=65
35=A
34=33
49=alpha
52=20130707-23:43:41.891
56=beta
98=0
108=30
10=251

20130707-23:43:41.907 :
8=FIX.4.2
9=61
35=A
49=beta
56=alpha
34=29
52=20130707-23:43:41
98=0
108=30
10=044

20130707-23:46:20.193 :
8=FIX.4.2
9=236
35=D
34=34
49=alpha
52=20130707-23:43:41.954
56=beta
57=STAGE
1=NEUTRAL
11=alphaA10043
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:43:41
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=124

20130707-23:48:28.900 :
8=FIX.4.2
9=65
35=A
34=35
49=alpha
52=20130707-23:48:28.869
56=beta
98=0
108=30
10=012

20130707-23:48:28.932 :
8=FIX.4.2
9=61
35=A
49=beta
56=alpha
34=34
52=20130707-23:48:28
98=0
108=30
10=050

20130707-23:49:51.028 :
8=FIX.4.2
9=236
35=D
34=36
49=alpha
52=20130707-23:48:28.900
56=beta
57=STAGE
1=NEUTRAL
11=alphaA10033
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:48:28
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=136

20130707-23:49:51.028 :
8=FIX.4.2
9=63
35=2
34=37
49=alpha
52=20130707-23:49:51.028
56=beta
7=30
16=0
10=129

20130707-23:51:22.094 :
8=FIX.4.2
9=65
35=A
34=38
49=alpha
52=20130707-23:51:22.062
56=beta
98=0
108=30
10=244

20130707-23:51:22.109 :
8=FIX.4.2
9=61
35=A
49=beta
56=alpha
34=40
52=20130707-23:51:21
98=0
108=30
10=034

20130707-23:52:53.518 :
8=FIX.4.2
9=236
35=D
34=39
49=alpha
52=20130707-23:51:22.094
56=beta
57=STAGE
1=NEUTRAL
11=alphaA10023
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:51:22
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=118

20130707-23:52:53.518 :
8=FIX.4.2
9=63
35=2
34=40
49=alpha
52=20130707-23:52:53.518
56=beta
7=30
16=0
10=123


20130707-23:54:17.880 :
8=FIX.4.2
9=65
35=A
34=41
49=alpha
52=20130707-23:54:17.865
56=beta
98=0
108=50
10=002

20130707-23:54:17.880 :
8=FIX.4.2
9=61
35=A
49=beta
56=alpha
34=46
52=20130707-23:54:17
98=0
108=50
10=050

20130707-23:54:38.115 :
8=FIX.4.2
9=236
35=D
34=42
49=alpha
52=20130707-23:54:17.912
56=beta
57=STAGE
1=NEUTRAL
11=alphaA10023
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:54:17
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=125

20130707-23:54:38.115 :
8=FIX.4.2
9=63
35=2
34=43
49=alpha
52=20130707-23:54:38.115
56=beta
7=30
16=0
10=124

20130707-23:54:38.131 :
8=FIX.4.2
9=59
35=2
49=beta
56=alpha
34=47
52=20130707-23:54:17
7=34
16=0
10=193

20130707-23:54:48.694 :
8=FIX.4.2
9=267
35=D
34=34
43=Y
49=alpha
52=20130707-23:54:38.131
56=beta
57=STAGE
122=20130707-23:43:41.954
1=NEUTRAL
11=alphaA10043
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:43:41
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=130

20130707-23:54:53.491 :
8=FIX.4.2
9=96
35=4
34=35
43=Y
49=alpha
52=20130707-23:54:53.491
56=beta
122=20130707-23:54:53.491
36=36
123=Y
10=033

20130707-23:54:53.491 :
8=FIX.4.2
9=267
35=D
34=36
43=Y
49=alpha
52=20130707-23:54:48.694
56=beta
57=STAGE
122=20130707-23:48:28.900
1=NEUTRAL
11=alphaA10033
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:48:28
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=157

20130707-23:54:55.288 :
8=FIX.4.2
9=96
35=4
34=37
43=Y
49=alpha
52=20130707-23:54:55.272
56=beta
122=20130707-23:54:55.272
36=39
123=Y
10=036

20130707-23:54:55.288 :
8=FIX.4.2
9=267
35=D
34=39
43=Y
49=alpha
52=20130707-23:54:53.507
56=beta
57=STAGE
122=20130707-23:51:22.094
1=NEUTRAL
11=alphaA10023
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:51:22
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=128

20130707-23:54:56.085 :
8=FIX.4.2
9=96
35=4
34=40
43=Y
49=alpha
52=20130707-23:54:56.085
56=beta
122=20130707-23:54:56.085
36=42
123=Y
10=030

20130707-23:54:56.085 :
8=FIX.4.2
9=267
35=D
34=42
43=Y
49=alpha
52=20130707-23:54:55.288
56=beta
57=STAGE
122=20130707-23:54:17.912
1=NEUTRAL
11=alphaA10023
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:54:17
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=143

20130707-23:54:56.100 :
8=FIX.4.2
9=96
35=4
34=43
43=Y
49=alpha
52=20130707-23:54:56.085
56=beta
122=20130707-23:54:56.085
36=44
123=Y
10=035

20130707-23:54:56.100 :
8=FIX.4.2
9=53
35=5
34=44
49=alpha
52=20130707-23:54:56.100
56=beta
10=204

20130707-23:54:56.100 :
8=FIX.4.2
9=59
35=2
49=beta
56=alpha
34=48
52=20130707-23:54:38
7=34
16=0
10=197

20130707-23:54:56.460 :
8=FIX.4.2
9=267
35=D
34=34
43=Y
49=alpha
52=20130707-23:54:56.100
56=beta
57=STAGE
122=20130707-23:43:41.954
1=NEUTRAL
11=alphaA10043
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:43:41
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=126

20130707-23:54:56.819 :
8=FIX.4.2
9=96
35=4
34=35
43=Y
49=alpha
52=20130707-23:54:56.819
56=beta
122=20130707-23:54:56.819
36=36
123=Y
10=047

20130707-23:54:56.819 :
8=FIX.4.2
9=267
35=D
34=36
43=Y
49=alpha
52=20130707-23:54:56.460
56=beta
57=STAGE
122=20130707-23:48:28.900
1=NEUTRAL
11=alphaA10033
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:48:28
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=147

20130707-23:54:57.194 :
8=FIX.4.2
9=96
35=4
34=37
43=Y
49=alpha
52=20130707-23:54:57.194
56=beta
122=20130707-23:54:57.194
36=39
123=Y
10=046

20130707-23:54:57.194 :
8=FIX.4.2
9=267
35=D
34=39
43=Y
49=alpha
52=20130707-23:54:56.835
56=beta
57=STAGE
122=20130707-23:51:22.094
1=NEUTRAL
11=alphaA10023
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:51:22
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=135

20130707-23:54:57.569 :
8=FIX.4.2
9=96
35=4
34=40
43=Y
49=alpha
52=20130707-23:54:57.569
56=beta
122=20130707-23:54:57.569
36=42
123=Y
10=046

20130707-23:54:57.569 :
8=FIX.4.2
9=267
35=D
34=42
43=Y
49=alpha
52=20130707-23:54:57.210
56=beta
57=STAGE
122=20130707-23:54:17.912
1=NEUTRAL
11=alphaA10023
15=USD
21=1
38=25
40=1
44=1624.5
54=1
55=/ESU3
59=0
60=20130707-23:54:17
76=Neutral
107=E-mini
S&P500
114=Y
167=FUT
200=201309
205=30
207=CME
231=50
10=130

20130707-23:54:57.585 :
8=FIX.4.2
9=96
35=4
34=43
43=Y
49=alpha
52=20130707-23:54:57.585
56=beta
122=20130707-23:54:57.585
36=45
123=Y
10=048

20130707-23:54:57.585 :
8=FIX.4.2
9=66
35=4
49=beta
56=alpha
34=30
43=Y
52=20130707-23:54:38
123=Y
36=49
10=074

20130707-23:54:57.585 :
8=FIX.4.2
9=49
35=5
49=beta
56=alpha
34=49
52=20130707-23:54:56
10=023


Also, in the first case the possDupFlag (m_string and m_data values) are ""
and in the later case both are set to "Y" as seen in the message logs.

Please suggest how to fix the message seq issues or reset issues that are
arising ? Am I using the wrong implementation of possDupFlag in toAPP ? What
is the best and safest way of implementing the toAPP ? What are the issues
that are creating the problem ? Can we get rid of the possDupFlag altogather
?

Thanks,
aupadras.



--
View this message in context: http://quickfix.13857.n7.nabble.com/Incorrect-Data-Format-aka-possDupFlag-issue-tp6518.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Visual 2012

[aupadras <ani...@ya...>]

Ok Thank you.., I will  keep you posted.






--
View this message in context: http://quickfix.13857.n7.nabble.com/Visual-2012-tp6511p6517.html
Sent from the QuickFIX - User mailing list archive at Nabble.com.

Re: [Quickfix-users] Visual 2012

[Mike G. <mg...@co...>]

FYI, I just committed VS2012 support to the svn trunk.  I tested on VS2012
Pro on 64bit Win7 -- try it out and let us know if it works in your
environment.