quickfix-users — QuickFIX user support

RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Brian E. <azz...@ya...>]

James -

We have two groups of users connecting to our applications. 

The first set are clients who are new to FIX. Their biggest issues tend
to be the session management parts and just getting their minds wrapped
around the whole FIX process. For these users, a couple of additional
field values isn't an issue - development is new and the values have no
intrinsic "meaning" to them anyway. They generally write to the FIX
documents that we provide.

The second set are clients that have pre-existing FIX implementations.
Many clients like to use FIX as a "standard" way to communicate to
several different ISV or FCM systems - a way to mitigate risk and
vendor lock-in. These users will sometimes grumble about yet another
instance of non-standard behavior, but pretty much EVERY ISV/FCM has to
deviate from the standard in some way. The addition of a few new field
values is actually pretty easy compared with different FIX versions
(4.2 and 4.3 being the most popular, but a few 4.0 and 4.4 versions are
out in the wild) and non-standard session management. 

Aside from the additional field values, we've only made a few other
extensions to the protocol: 

1. The addition of tag 789 (NextExpectedMsgSeqNum) on logout messages
(a 4.4 field backported to our 4.3 application). Nearly every customer
loves this addition.

2. Co-opting the SecurityExchange tag (207) to use as an exchange
specifier (e.g., which exchange is this order for?). The only other
choice was to mess around with the Symbol tag, and we thought this
implementation was cleaner.

3. Adding some additional exchange-specific OrdTypes - there are some
pretty funky order types out there and FIX doesn't have values for all
of them.

4. We also drop the ClOrdId on some of the ExecutionReports (due to
limitations within our own legacy app), but this is not unusual
behavior out in the real world.

We do a number of things to mitigate our changes to the specification.
First, we use a very small subset of available FIX fields on orders and
execution reports (typically for us, any order can be submitted using
only 12 tags). Second, we provide additional QuickFIX documentation and
a custom FIX43.XML file to encourage QuickFIX usage - it's vastly
simpler to use than coding all the session management stuff yourself.
(I know - I've written FIX engines into four different exchanges.)
There a couple of things I'd change about QuickFIX [which I've posted
about in the past], but it's vastly superior to anything else out
there.

I think pretty much everyone in the industry uses quotes when they
speak of the FIX "standard". It's a nice starting point, but no one in
the futures industry makes any attempt to stick closely to every
detail. In many cases, it's been impossible (until 4.4, many futures
industry-specific data simply did not have tags). In others, it's
inertia or hubris (the CME is notorious for its "improvements" to the
FIX specification - while simultaneously sticking to the 4.2 release
that doesn't support futures). I think the situation is getting better
now that the exchanges are much more active in the specification - but
even that is a mixed bag, as they continue to push the spec to handle
exchange needs while ignoring the needs of ISVs and FCMs.

Of course, wait until you see the "implicit tagging" specification
that's being worked on - the QuickFIX team will have PLENTY of work in
the future! >;-)

- Brian Erst
Thynk Software, Inc.

--- "James C. Downs" <jc...@co...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Brian,
> This is a great example of how all the differences in business
> requirements
> from implementation to implementation cannot be completely covered by
> a
> standard protocol. This is also a good real world example for those
> who are
> new to FIX struggling with the map between the protocol and business
> needs
> and how that gap is bridged. 
> 
> Would you mind commenting on the general reaction of a new
> counterparty to
> your system when they are presented with custom field values (at the
> application level)? Is it an education process as to the value the
> custom
> values bring to the implementation?
> 
> Thanks,
> Jim
> 
> -----Original Message-----
> From: Brian Erst [mailto:azz...@ya...] 
> Sent: Friday, June 03, 2005 9:39 AM
> To: James C. Downs; azz...@ya...; 'rohan joel pais';
> qui...@li...;
> qui...@li...
> Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> response
> to a client
> 
> James -
> 
> The problem occurs when you have a fairly sophisticated order
> management
> system that acts as more than just a proxy pass-through to an
> exchange.
> Here's an example of an issue that (so far) has best been resolved
> through
> additional OrdStatus values.
> 
> The system I work on has connections to 12 different futures
> exchanges.
> We attempt to deliver a consistent interface for all these exchanges,
> even
> when any particular underlying exchange may not support the superset
> of
> functionality across the many exchanges. For instance, not all of the
> exchange systems support stop orders (even though the use of such
> orders is
> widespread throughout the industry). For those exchanges that do not
> support
> stop orders, we have created a process that simulates stop order
> processing
> within our order management system.
> Essentially, we hold the orders, listen to the price feed and submit
> the
> orders once the trigger price has been touched.
> 
> For these orders, they may NEVER reach the exchange system (price is
> not
> matched). We need a consistent way of telling our users when orders
> have
> been accepted into our system for management, when (if) they have
> been
> diverted to our internal stop processing ssytem, when the orders get
> elected
> into the market and when the order actually reaches the market.
> 
> The simplest way to handle this (by far) was to add a few additional
> OrdStatus/ExecType values. We define "NEW" as being accepted by OUR
> application and add three new values ('l' for locally working stops,
> 'e' for
> stop order election and 'x' for at the exchange).
> 
> In this way, our clients know where an order is at all times. Just as
> importantly, our helpdesk knows where that order is as well. If the
> client
> experiences a communications failure and needs to work their orders,
> they
> should still have some idea as to what their current market risk is
> while
> talking with our helpdesk to manage their open orders.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- "James C. Downs" <jc...@co...> wrote:
> 
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> > 
> > Brian,
> > I'm curious why in your case the OrdStatus = "NEW" was not
> sufficient 
> > to indicate that the order was accepted by the exchange and in the 
> > market? What exchange/venue was most problematic for you in this 
> > regard?
> > 
> > Thanks,
> > Jim
> > 
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On Behalf
> Of 
> > Brian Erst
> > Sent: Friday, June 03, 2005 7:45 AM
> > To: rohan joel pais; qui...@li...;
> > qui...@li...
> > Subject: [Quickfix-developers] Re: [Quickfix-users] how to send 
> > response to a client
> > 
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> > 
> > I have a very similar application and I eventually decided that the
> 
> > "better"
> > way was to add additional ExecType/OrdStatus values and use those
> to 
> > differentiate between "my application has received the order"
> > and "the exchange has received the order".
> > 
> > In my particular case, I use Pending New (OrdStatus='0') to
> indicate 
> > that my app received and databased the order. I created a new 
> > OrdStatus ('x'
> > for at
> > the eXchange) to indicate that the order had been received by the 
> > exchange.
> > 
> > FIX hasn't fully come to terms with third-party order management 
> > systems acting as a bridge between clients and exchanges. Hopefully
> 
> > they will start looking at that (if they haven't already) as most
> of 
> > the ISVs out there are now adding some sort of FIX interface to
> their 
> > order management systems.
> > 
> > - Brian Erst
> > Thynk Software, Inc.
> > 
> > --- rohan joel pais <roh...@re...> wrote:
> > 
> > >   
> > > Hi all,
> > >        I need some help in developing a new project. It is like
> > this
> > > -  My application will act like a passer, which recieves fix
> > messages
> > > from the client and then converts it into another format and
> sends
> > it
> > > to the exchange.
> > > But my problem here is i want to tell the client that i have
> > recieved
> > > his order, without sending him the execution report. so i am
> asking
> > 
> > > whether i can build my own response message and send it to the
> > client.
> > > 
> > > with regards
> > > rohan pais
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your
> own 
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> 
=== message truncated ===

RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Steve B. <st...@te...>]

(Should we move this discussion to either the user or the developer list
rather than both?)

At one place I've worked they used Pending New to acknowledge reception of
the order at the order router. The order was then sent to an exchange
and the exchange sent back a New or Rejected status after it received
the order. That report and subsequent ones were forwarded back to the
client. A few exchanges also sent a Pending New but we didn't send
those back to the client. The customers of that system were satisfied 
with that approach and it required no custom status codes.

I'm a little confused. Is the custom status code being used to 
communicate that the order was /sent/ to the exchange rather than 
as an acknowledgement that the exchange received the order?

Regards,

Steve

> -----Original Message-----
> From: qui...@li... [mailto:quickfix-users-
> ad...@li...] On Behalf Of James C. Downs
> Sent: Friday, June 03, 2005 9:58 AM
> To: azz...@ya...; 'rohan joel pais'; quickfix-
> dev...@li...; qui...@li...
> Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> response to a client
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Brian,
> This is a great example of how all the differences in business
> requirements
> from implementation to implementation cannot be completely covered by a
> standard protocol. This is also a good real world example for those who
> are
> new to FIX struggling with the map between the protocol and business needs
> and how that gap is bridged.
> 
> Would you mind commenting on the general reaction of a new counterparty to
> your system when they are presented with custom field values (at the
> application level)? Is it an education process as to the value the custom
> values bring to the implementation?
> 
> Thanks,
> Jim
> 
> -----Original Message-----
> From: Brian Erst [mailto:azz...@ya...]
> Sent: Friday, June 03, 2005 9:39 AM
> To: James C. Downs; azz...@ya...; 'rohan joel pais';
> qui...@li...;
> qui...@li...
> Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> response
> to a client
> 
> James -
> 
> The problem occurs when you have a fairly sophisticated order management
> system that acts as more than just a proxy pass-through to an exchange.
> Here's an example of an issue that (so far) has best been resolved through
> additional OrdStatus values.
> 
> The system I work on has connections to 12 different futures exchanges.
> We attempt to deliver a consistent interface for all these exchanges, even
> when any particular underlying exchange may not support the superset of
> functionality across the many exchanges. For instance, not all of the
> exchange systems support stop orders (even though the use of such orders
> is
> widespread throughout the industry). For those exchanges that do not
> support
> stop orders, we have created a process that simulates stop order
> processing
> within our order management system.
> Essentially, we hold the orders, listen to the price feed and submit the
> orders once the trigger price has been touched.
> 
> For these orders, they may NEVER reach the exchange system (price is not
> matched). We need a consistent way of telling our users when orders have
> been accepted into our system for management, when (if) they have been
> diverted to our internal stop processing ssytem, when the orders get
> elected
> into the market and when the order actually reaches the market.
> 
> The simplest way to handle this (by far) was to add a few additional
> OrdStatus/ExecType values. We define "NEW" as being accepted by OUR
> application and add three new values ('l' for locally working stops, 'e'
> for
> stop order election and 'x' for at the exchange).
> 
> In this way, our clients know where an order is at all times. Just as
> importantly, our helpdesk knows where that order is as well. If the client
> experiences a communications failure and needs to work their orders, they
> should still have some idea as to what their current market risk is while
> talking with our helpdesk to manage their open orders.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- "James C. Downs" <jc...@co...> wrote:
> 
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Brian,
> > I'm curious why in your case the OrdStatus = "NEW" was not sufficient
> > to indicate that the order was accepted by the exchange and in the
> > market? What exchange/venue was most problematic for you in this
> > regard?
> >
> > Thanks,
> > Jim
> >
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On Behalf Of
> > Brian Erst
> > Sent: Friday, June 03, 2005 7:45 AM
> > To: rohan joel pais; qui...@li...;
> > qui...@li...
> > Subject: [Quickfix-developers] Re: [Quickfix-users] how to send
> > response to a client
> >
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > I have a very similar application and I eventually decided that the
> > "better"
> > way was to add additional ExecType/OrdStatus values and use those to
> > differentiate between "my application has received the order"
> > and "the exchange has received the order".
> >
> > In my particular case, I use Pending New (OrdStatus='0') to indicate
> > that my app received and databased the order. I created a new
> > OrdStatus ('x'
> > for at
> > the eXchange) to indicate that the order had been received by the
> > exchange.
> >
> > FIX hasn't fully come to terms with third-party order management
> > systems acting as a bridge between clients and exchanges. Hopefully
> > they will start looking at that (if they haven't already) as most of
> > the ISVs out there are now adding some sort of FIX interface to their
> > order management systems.
> >
> > - Brian Erst
> > Thynk Software, Inc.
> >
> > --- rohan joel pais <roh...@re...> wrote:
> >
> > >
> > > Hi all,
> > >        I need some help in developing a new project. It is like
> > this
> > > -  My application will act like a passer, which recieves fix
> > messages
> > > from the client and then converts it into another format and sends
> > it
> > > to the exchange.
> > > But my problem here is i want to tell the client that i have
> > recieved
> > > his order, without sending him the execution report. so i am asking
> >
> > > whether i can build my own response message and send it to the
> > client.
> > >
> > > with regards
> > > rohan pais
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[James C. D. <jc...@co...>]

Brian,
This is a great example of how all the differences in business requirements
from implementation to implementation cannot be completely covered by a
standard protocol. This is also a good real world example for those who are
new to FIX struggling with the map between the protocol and business needs
and how that gap is bridged. 

Would you mind commenting on the general reaction of a new counterparty to
your system when they are presented with custom field values (at the
application level)? Is it an education process as to the value the custom
values bring to the implementation?

Thanks,
Jim

-----Original Message-----
From: Brian Erst [mailto:azz...@ya...] 
Sent: Friday, June 03, 2005 9:39 AM
To: James C. Downs; azz...@ya...; 'rohan joel pais';
qui...@li...;
qui...@li...
Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send response
to a client

James -

The problem occurs when you have a fairly sophisticated order management
system that acts as more than just a proxy pass-through to an exchange.
Here's an example of an issue that (so far) has best been resolved through
additional OrdStatus values.

The system I work on has connections to 12 different futures exchanges.
We attempt to deliver a consistent interface for all these exchanges, even
when any particular underlying exchange may not support the superset of
functionality across the many exchanges. For instance, not all of the
exchange systems support stop orders (even though the use of such orders is
widespread throughout the industry). For those exchanges that do not support
stop orders, we have created a process that simulates stop order processing
within our order management system.
Essentially, we hold the orders, listen to the price feed and submit the
orders once the trigger price has been touched.

For these orders, they may NEVER reach the exchange system (price is not
matched). We need a consistent way of telling our users when orders have
been accepted into our system for management, when (if) they have been
diverted to our internal stop processing ssytem, when the orders get elected
into the market and when the order actually reaches the market.

The simplest way to handle this (by far) was to add a few additional
OrdStatus/ExecType values. We define "NEW" as being accepted by OUR
application and add three new values ('l' for locally working stops, 'e' for
stop order election and 'x' for at the exchange).

In this way, our clients know where an order is at all times. Just as
importantly, our helpdesk knows where that order is as well. If the client
experiences a communications failure and needs to work their orders, they
should still have some idea as to what their current market risk is while
talking with our helpdesk to manage their open orders.

- Brian Erst
Thynk Software, Inc.

--- "James C. Downs" <jc...@co...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Brian,
> I'm curious why in your case the OrdStatus = "NEW" was not sufficient 
> to indicate that the order was accepted by the exchange and in the 
> market? What exchange/venue was most problematic for you in this 
> regard?
> 
> Thanks,
> Jim
> 
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of 
> Brian Erst
> Sent: Friday, June 03, 2005 7:45 AM
> To: rohan joel pais; qui...@li...;
> qui...@li...
> Subject: [Quickfix-developers] Re: [Quickfix-users] how to send 
> response to a client
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> I have a very similar application and I eventually decided that the 
> "better"
> way was to add additional ExecType/OrdStatus values and use those to 
> differentiate between "my application has received the order"
> and "the exchange has received the order".
> 
> In my particular case, I use Pending New (OrdStatus='0') to indicate 
> that my app received and databased the order. I created a new 
> OrdStatus ('x'
> for at
> the eXchange) to indicate that the order had been received by the 
> exchange.
> 
> FIX hasn't fully come to terms with third-party order management 
> systems acting as a bridge between clients and exchanges. Hopefully 
> they will start looking at that (if they haven't already) as most of 
> the ISVs out there are now adding some sort of FIX interface to their 
> order management systems.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- rohan joel pais <roh...@re...> wrote:
> 
> >   
> > Hi all,
> >        I need some help in developing a new project. It is like
> this
> > -  My application will act like a passer, which recieves fix
> messages
> > from the client and then converts it into another format and sends
> it
> > to the exchange.
> > But my problem here is i want to tell the client that i have
> recieved
> > his order, without sending him the execution report. so i am asking
> 
> > whether i can build my own response message and send it to the
> client.
> > 
> > with regards
> > rohan pais
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own 
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own 
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

Re: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Brian E. <azz...@ya...>]

Caleb -

That is exactly our issue. We could be even more fine-grained than we
are, but we attempted to minimize the number of extensions we were
making to the protocol. We felt that adding just the three new extended
field values provided enough information for our clients to know the
true state of their order without causing them to have to do a lot of
coding to support our non-standard values.

We could easily have used another 4-5 statuses, but the net value to
our clients was limited.

- Brian Erst
Thynk Software, Inc.

--- Caleb Epstein <cal...@gm...> wrote:

> On 6/3/05, James C. Downs <jc...@co...> wrote:
> 
> > I'm curious why in your case the OrdStatus = "NEW" was not
> sufficient to
> > indicate that the order was accepted by the exchange and in the
> market? What
> > exchange/venue was most problematic for you in this regard?
> 
> I think the answer depends on how fine-grained you want to make the
> information you pass back to clients of a system.  Especially if
> messages take more than one hop before they go out the door. 
> Consider
> for example this system:
> 
> Client app -> FIX router -> ECNs
> 
> If the FIX router were purely a message-passing application, it would
> just rely on the ECNs to generate all of the execution reports and
> wouldn't generate any of its own.  But what if the Client App wants
> to
> distinguish between a message that:
> 
> * It has created, but not yet sent to the router
> * Has been sent to the router (or we think it has)
> * Has been acknowledged by the router as having been received (but
> hasn't been sent to the ECN yet)
> * Has been sent by the router to the ECN (or the router thinks it
> has)
> 
> And so on.  Different systems may want to have some sort of feedback
> for any/all of these events, so I can see a need for finer-grained
> status codes.  As with routing FIX in general though, the more hops
> you have, the more fields or codes you need if you want to capture
> all
> of the this information.  This can turn into a mess pretty fast.
> 
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
> 

RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Brian E. <azz...@ya...>]

James -

The problem occurs when you have a fairly sophisticated order
management system that acts as more than just a proxy pass-through to
an exchange. Here's an example of an issue that (so far) has best been
resolved through additional OrdStatus values.

The system I work on has connections to 12 different futures exchanges.
We attempt to deliver a consistent interface for all these exchanges,
even when any particular underlying exchange may not support the
superset of functionality across the many exchanges. For instance, not
all of the exchange systems support stop orders (even though the use of
such orders is widespread throughout the industry). For those exchanges
that do not support stop orders, we have created a process that
simulates stop order processing within our order management system.
Essentially, we hold the orders, listen to the price feed and submit
the orders once the trigger price has been touched.

For these orders, they may NEVER reach the exchange system (price is
not matched). We need a consistent way of telling our users when orders
have been accepted into our system for management, when (if) they have
been diverted to our internal stop processing ssytem, when the orders
get elected into the market and when the order actually reaches the
market.

The simplest way to handle this (by far) was to add a few additional
OrdStatus/ExecType values. We define "NEW" as being accepted by OUR
application and add three new values ('l' for locally working stops,
'e' for stop order election and 'x' for at the exchange).

In this way, our clients know where an order is at all times. Just as
importantly, our helpdesk knows where that order is as well. If the
client experiences a communications failure and needs to work their
orders, they should still have some idea as to what their current
market risk is while talking with our helpdesk to manage their open
orders.

- Brian Erst
Thynk Software, Inc.

--- "James C. Downs" <jc...@co...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Brian,
> I'm curious why in your case the OrdStatus = "NEW" was not sufficient
> to
> indicate that the order was accepted by the exchange and in the
> market? What
> exchange/venue was most problematic for you in this regard?
> 
> Thanks,
> Jim 
> 
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> Brian
> Erst
> Sent: Friday, June 03, 2005 7:45 AM
> To: rohan joel pais; qui...@li...;
> qui...@li...
> Subject: [Quickfix-developers] Re: [Quickfix-users] how to send
> response to
> a client
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> I have a very similar application and I eventually decided that the
> "better"
> way was to add additional ExecType/OrdStatus values and use those to
> differentiate between "my application has received the order"
> and "the exchange has received the order".
> 
> In my particular case, I use Pending New (OrdStatus='0') to indicate
> that my
> app received and databased the order. I created a new OrdStatus ('x'
> for at
> the eXchange) to indicate that the order had been received by the
> exchange.
> 
> FIX hasn't fully come to terms with third-party order management
> systems
> acting as a bridge between clients and exchanges. Hopefully they will
> start
> looking at that (if they haven't already) as most of the ISVs out
> there are
> now adding some sort of FIX interface to their order management
> systems.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- rohan joel pais <roh...@re...> wrote:
> 
> >   
> > Hi all,
> >        I need some help in developing a new project. It is like
> this
> > -  My application will act like a passer, which recieves fix
> messages 
> > from the client and then converts it into another format and sends
> it 
> > to the exchange.
> > But my problem here is i want to tell the client that i have
> recieved 
> > his order, without sending him the execution report. so i am asking
> 
> > whether i can build my own response message and send it to the
> client.
> > 
> > with regards
> > rohan pais
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

Re: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Caleb E. <cal...@gm...>]

On 6/3/05, James C. Downs <jc...@co...> wrote:

> I'm curious why in your case the OrdStatus =3D "NEW" was not sufficient t=
o
> indicate that the order was accepted by the exchange and in the market? W=
hat
> exchange/venue was most problematic for you in this regard?

I think the answer depends on how fine-grained you want to make the
information you pass back to clients of a system.  Especially if
messages take more than one hop before they go out the door.  Consider
for example this system:

Client app -> FIX router -> ECNs

If the FIX router were purely a message-passing application, it would
just rely on the ECNs to generate all of the execution reports and
wouldn't generate any of its own.  But what if the Client App wants to
distinguish between a message that:

* It has created, but not yet sent to the router
* Has been sent to the router (or we think it has)
* Has been acknowledged by the router as having been received (but
hasn't been sent to the ECN yet)
* Has been sent by the router to the ECN (or the router thinks it has)

And so on.  Different systems may want to have some sort of feedback
for any/all of these events, so I can see a need for finer-grained
status codes.  As with routing FIX in general though, the more hops
you have, the more fields or codes you need if you want to capture all
of the this information.  This can turn into a mess pretty fast.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[James C. D. <jc...@co...>]

Brian,
I'm curious why in your case the OrdStatus = "NEW" was not sufficient to
indicate that the order was accepted by the exchange and in the market? What
exchange/venue was most problematic for you in this regard?

Thanks,
Jim 

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Brian
Erst
Sent: Friday, June 03, 2005 7:45 AM
To: rohan joel pais; qui...@li...;
qui...@li...
Subject: [Quickfix-developers] Re: [Quickfix-users] how to send response to
a client

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

I have a very similar application and I eventually decided that the "better"
way was to add additional ExecType/OrdStatus values and use those to
differentiate between "my application has received the order"
and "the exchange has received the order".

In my particular case, I use Pending New (OrdStatus='0') to indicate that my
app received and databased the order. I created a new OrdStatus ('x' for at
the eXchange) to indicate that the order had been received by the exchange.

FIX hasn't fully come to terms with third-party order management systems
acting as a bridge between clients and exchanges. Hopefully they will start
looking at that (if they haven't already) as most of the ISVs out there are
now adding some sort of FIX interface to their order management systems.

- Brian Erst
Thynk Software, Inc.

--- rohan joel pais <roh...@re...> wrote:

>   
> Hi all,
>        I need some help in developing a new project. It is like this
> -  My application will act like a passer, which recieves fix messages 
> from the client and then converts it into another format and sends it 
> to the exchange.
> But my problem here is i want to tell the client that i have recieved 
> his order, without sending him the execution report. so i am asking 
> whether i can build my own response message and send it to the client.
> 
> with regards
> rohan pais
> 



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-users] how to send response to a client

[Brian E. <azz...@ya...>]

I have a very similar application and I eventually decided that the
"better" way was to add additional ExecType/OrdStatus values and use
those to differentiate between "my application has received the order"
and "the exchange has received the order".

In my particular case, I use Pending New (OrdStatus='0') to indicate
that my app received and databased the order. I created a new OrdStatus
('x' for at the eXchange) to indicate that the order had been received
by the exchange.

FIX hasn't fully come to terms with third-party order management
systems acting as a bridge between clients and exchanges. Hopefully
they will start looking at that (if they haven't already) as most of
the ISVs out there are now adding some sort of FIX interface to their
order management systems.

- Brian Erst
Thynk Software, Inc.

--- rohan joel pais <roh...@re...> wrote:

>   
> Hi all,
>        I need some help in developing a new project. It is like this
> -  My application will act like a passer, which recieves fix messages
> from the client and then converts it into another format and sends it
> to the exchange.
> But my problem here is i want to tell the client that i have recieved
> his order, without sending him the execution report. so i am asking
> whether i can build my own response message and send it to the
> client.
> 
> with regards
> rohan pais
> 

[Quickfix-users] how to send response to a client

[rohan j. p. <roh...@re...>]

 =A0=0AHi all,=0A       I need some help in developing a new project. It is=
 like this -  My application will act like a passer, which recieves fix mes=
sages from the client and then converts it into another format and sends it=
 to the exchange.=0ABut my problem here is i want to tell the client that i=
 have recieved his order, without sending him the execution report. so i am=
 asking whether i can build my own response message and send it to the clie=
nt.=0A=0Awith regards=0Arohan pais=0A

[Quickfix-users] how to manage many clients via singe server

[rohan j. p. <roh...@re...>]

 =A0=0AHi all,=0A       Can  anybody tell me how to manage many number of c=
lients, by a single server.=0AShould i use threading concept here, and if i=
 should ,tell me the implementation details.=0APlease help me regarding thi=
s.=0A                                       with regards=0A                =
                       rohan pais

[Quickfix-users] quickfix bugs and suggestions

[Nick E. <ni...@de...>]

Hi,

During quickfix adoption for one of the projects I've been consulting I've
found the following bugs (or issues):

1. quickfix uses atof() function for parsing doubles which is locale aware.
So on systems having locale with decimal separator other than dot all
doubles will be silently stripped to its whole part only (i.e. 1.32 becomes
1.00 and so on). Even more atof() will convert everything starting with a
digit to double giving you no knowledge if it's actually not a double at all
(i.e. 1.1haba will be converted to 1.1)

locale solution: quickfix must use setlocale() to set it's locale to C or
en_US. a quick workaround on unix platforms is to export either LC_ALL=C or
LC_NUMERIC=C prior to running quickfix application.

parsing solution: use strtod() instead of atof() to parse doubles. it gives
you the pointer to a char at which parsing has stopped. If it's zero --
everything is ok. It will do more strict double conversion which I belive is
essential for trading app :)

2. thread safety. quickfix has implicit thread safety i.e. it perform
internal synchronization on Session.sendToTarget() (it's java syntax). While
it does simplify the things for simpliest cases it also leads to deadlocks
if application tries to do extra synchronization between streams. So it
would be better if quickfix is either does no synchronization at all leaving
everything to developer or does export internal mutexes via getSessionLock()
or something alike.


3. Thread context ClassLoader issue with java port. quickfix starts internal
thread when user calls Acceptor.start(), or Initiator.start(), but it does
not save thread context class loader, so later when you're trying to create
classes accessible from this classloader as a consequnce of MessageCracker
call ClassNotFound Exception will be thrown.

solution: remeber thread context classloader in started thread (yet better
deligate thread creation and running to client application).
workaround: save thread context classloader and restore it manually.

4. Quickfix stops accepting connections on unexpected fields in logon
message. I was lucky enough to send logon message to quickfix server with
username/password fields set w/o adding them to fix-spec first. The reaction
was amazing -- quickfix just stopped listening on its port w/o any error.

solution: well.. what do you expect me to say? :) the server must be robust
that's it. nothing should stop it from working except explicit kill. :)


5. Actuallly is a request for enhancement -- it might be a good idea to
provide set of extensible converters to do backward message conversion i.e.
(fix44.ExecutionReport to fix43.ExecutionReport and so on) otherwise (I
think) everybody's writing such converters by their own.


ps: as for everything else -- just keep moving! quickfix rocks :)

[Quickfix-users] quickfix bugs and sugestions

[Nick E. <ni...@oc...>]

Hi,

During quickfix adoption for one of the projects I've been consulting I've 
found the following bugs (or issues):

1. quickfix uses atof() function for parsing doubles which is locale aware. 
So on systems having locale with decimal separator other than dot all 
doubles will be silently stripped to its whole part only (i.e. 1.32 becomes 
1.00 and so on). Even more atof() will convert everything starting with a 
digit to double giving you no knowledge if it's actually not a double at all 
(i.e. 1.1haba will be converted to 1.1)

locale solution: quickfix must use setlocale() to set it's locale to C or 
en_US. a quick workaround on unix platforms is to export either LC_ALL=C or 
LC_NUMERIC=C prior to running quickfix application.

parsing solution: use strtod() instead of atof() to parse doubles. it gives 
you the pointer to a char at which parsing has stopped. If it's zero --  
everything is ok. It will do more strict double conversion which I belive is 
essential for trading app :)

2. thread safety. quickfix has implicit thread safety i.e. it perform 
internal synchronization on Session.sendToTarget() (it's java syntax). While 
it does simplify the things for simpliest cases it also leads to deadlocks 
if application tries to do extra synchronization between streams. So it 
would be better if quickfix is either does no synchronization at all leaving 
everything to developer or does export internal mutexes via getSessionLock() 
or something alike.


3. Thread context ClassLoader issue with java port. quickfix starts internal 
thread when user calls Acceptor.start(), or Initiator.start(), but it does 
not save thread context class loader, so later when you're trying to create 
classes accessible from this classloader as a consequnce of MessageCracker 
call ClassNotFound Exception will be thrown.

solution: remeber thread context classloader in started thread (yet better 
deligate thread creation and running to client application).
workaround: save thread context classloader and restore it manually.

4. Quickfix stops accepting connections on unexpected fields in logon 
message. I was lucky enough to send logon message to quickfix server with 
username/password fields set w/o adding them to fix-spec first. The reaction 
was amazing -- quickfix just stopped listening on its port w/o any error.

solution: well.. what do you expect me to say? :) the server must be robust 
that's it. nothing should stop it from working except explicit kill. :)


5. Actuallly is a request for enhancement -- it might be a good idea to 
provide set of extensible converters to do backward message conversion i.e. 
(fix44.ExecutionReport to fix43.ExecutionReport and so on) otherwise (I 
think) everybody's writing such converters by their own.


ps: as for everything else -- just keep moving! quickfix rocks :)

Re: [Quickfix-users] Certification / Testing tools

[Joerg T. <Joe...@ma...>]

Hi Guillermo,

> I'm sure this question has been asked before, but I haven't managed to find
> it in the mailing lists archive.
> We're looking to do automated tests on our FIX engine but at the application
> level. That is, testing NewOrderSingles, ExecutionReports, Replaces, usual
> trading messages.

Do you have a more detailed specification, e.g. from an exchange, broker or client you are 
intending to connect to?

> Before we start our development we would like to know if there's any open
> source tool or library that implements this kind of  issues.

> We've heard of OpenFix.net, do you know what kind of tests it provides?

I did not try it myself, so I cannot tell you. Maybe your check the FPL site 
(www.fixprotocol.org) forums for reports.

> Anyway, we would prefer not to depend on an online tool.
> If this projects moves on, I'll be happy to share it with you as I think
> this is something necessary for an Open protocol like FIX.

Yes, this would be great to have such a testing service for QuickFIX. But FIX is very 
customizable at the application level, so the test suite depends on the specific usage. 
E.g. one could collect test cases per exchange.

As a tool for the test suite you could use the ruby script used for QF acceptance tests. 
In the same way, you could manufacture some application level tests. But at the moment 
there is no QuickFIX test suite for application level tests.

I am looking forward to discuss this further in this mail thread.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] Certification / Testing tools

[Guillermo A. A. <gar...@vi...>]

CkhpIGFsbCwKCkknbSBzdXJlIHRoaXMgcXVlc3Rpb24gaGFzIGJlZW4gYXNrZWQgYmVmb3JlLCBi
dXQgSSBoYXZlbid0IG1hbmFnZWQgdG8gZmluZAppdCBpbiB0aGUgbWFpbGluZyBsaXN0cyBhcmNo
aXZlLgpXZSdyZSBsb29raW5nIHRvIGRvIGF1dG9tYXRlZCB0ZXN0cyBvbiBvdXIgRklYIGVuZ2lu
ZSBidXQgYXQgdGhlIGFwcGxpY2F0aW9uCmxldmVsLiBUaGF0IGlzLCB0ZXN0aW5nIE5ld09yZGVy
U2luZ2xlcywgRXhlY3V0aW9uUmVwb3J0cywgUmVwbGFjZXMsIHVzdWFsCnRyYWRpbmcgbWVzc2Fn
ZXMuCkJlZm9yZSB3ZSBzdGFydCBvdXIgZGV2ZWxvcG1lbnQgd2Ugd291bGQgbGlrZSB0byBrbm93
IGlmIHRoZXJlJ3MgYW55IG9wZW4Kc291cmNlIHRvb2wgb3IgbGlicmFyeSB0aGF0IGltcGxlbWVu
dHMgdGhpcyBraW5kIG9mICBpc3N1ZXMuCldlJ3ZlIGhlYXJkIG9mIE9wZW5GaXgubmV0LCBkbyB5
b3Uga25vdyB3aGF0IGtpbmQgb2YgdGVzdHMgaXQgcHJvdmlkZXM/CkFueXdheSwgd2Ugd291bGQg
cHJlZmVyIG5vdCB0byBkZXBlbmQgb24gYW4gb25saW5lIHRvb2wuCklmIHRoaXMgcHJvamVjdHMg
bW92ZXMgb24sIEknbGwgYmUgaGFwcHkgdG8gc2hhcmUgaXQgd2l0aCB5b3UgYXMgSSB0aGluawp0
aGlzIGlzIHNvbWV0aGluZyBuZWNlc3NhcnkgZm9yIGFuIE9wZW4gcHJvdG9jb2wgbGlrZSBGSVgu
CgpDaGVlcnMgZm9yIHlvdXIgd29yayEKCkd1aWxsZS4KCkd1aWxsZXJtbyBBcmJlaXphIEFsYW1l
ZGEKRW1haWw6IGdhcmJlaXphQHZpc3VhbC10cmFkZXIuY29tClRsZiAgOiArMzQ5MTU4OTIxNDAK
ClZpc3VhbCBUcmFkZXIgU3lzdGVtcyBTTC4KUHphIGRlIGxhIExlYWx0YWQgMQoyODAxNCBNYWRy
aWQsIFNwYWluCgoKKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIEFWSVNPIExFR0FMICoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKgoKTGEgaW5mb3JtYWNp824gY29udGVuaWRhIGVu
IGVzdGUgbWVuc2FqZSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgc3UgZGVzdGluYXRhcmlvLiBO
byBkZWJlIGNvcGlhcnNlLCB0cmFuc21pdGlyc2UgYSB0ZXJjZXJvcyBuaSBndWFyZGFyc2UgcG9y
IGVzdG9zIPpsdGltb3MsIHNhbHZvIGF1dG9yaXphY2nzbiBkZWwgcmVtaXRlbnRlLgoKUHVlZGUg
Y29udGVuZXIgaW5mb3JtYWNp824gY29uZmlkZW5jaWFsIG8gbGVnYWxtZW50ZSBwcm90ZWdpZGEg
Y3V5byBy6WdpbWVuIGxlZ2FsIGRlIHV0aWxpemFjafNuIG5vIHNlIHZlIGFmZWN0YWRvIHBvciBl
bCBoZWNobyBkZSBxdWUgaGF5YSBzaWRvIGVudmlhZGEgcG9yIGNvcnJlbyBlbGVjdHLzbmljby4K
ClN1IGVudu1vIHBvciBlcnJvciBhIHVuYSBwZXJzb25hIGRpc3RpbnRhIGRlIHN1IGRlc3RpbmF0
YXJpbyByZWFsIG5vIGltcGxpY2EgcXVlIHNlIGhheWEgbW9kaWZpY2FkbyB0YWwgZGVzdGluYXRh
cmlvIG5pIHN1cG9uZSByZW51bmNpYSBhIHN1IGV2ZW50dWFsIGNhcuFjdGVyIGNvbmZpZGVuY2lh
bCBvIGFsIHLpZ2ltZW4gbGVnYWwgcXVlIHJpamEgc3UgdXRpbGl6YWNp824uCgpDdWFscXVpZXIg
b3BpbmnzbiBleHByZXNhZGEgZW4gZXN0ZSBtZW5zYWplIHZpbmN1bGFy4SBleGNsdXNpdmFtZW50
ZSBhIGxhIHBlcnNvbmEgcXVlIGxvIGhheWEgcmVtaXRpZG8sIGV4Y2VwdG8gY3VhbmRvIGVsIG1l
bnNhamUgZXN0YWJsZXpjYSBsbyBjb250cmFyaW8geSBlbCByZW1pdGVudGUgZXN06SBhdXRvcml6
YWRvIHBhcmEgZXN0YWJsZWNlciBxdWUgZGljaGFzIG9waW5pb25lcyB2aW5jdWxhcuFuIGEgZXN0
YSBlbnRpZGFkLiAKCkVuIGVsIHN1cHVlc3RvIGRlIHF1ZSBlc3RlIGNvcnJlbyBzZSByZWNpYmll
cmEgcG9yIGVycm9yLCByb2dhbW9zIHByb2NlZGFuIGEgYm9ycmFybG8sIHNpbiByZWVudmlhcmxv
IGEgdGVyY2Vyb3MgbmkgY29uc2VydmFybG8gZW4gY3VhbHF1aWVyIHNvcG9ydGUgeSBub3MgaW5m
b3JtZW4gaW5tZWRpYXRhbWVudGUgbGxhbWFuZG8gYWwgdGVs6WZvbm8gMzQgOTEgNTg5MjEyMyBv
IGEgbGEgZGlyZWNjafNuIGRlIGNvcnJlbyBlbGVjdHLzbmljbyByZW1pdGVudGUuIEdyYWNpYXMu
CgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogRElTQ0xBSU1FUiAqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioKClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNz
YWdlIGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgbmFtZWQgcGVyc29uLiBJdCBjYW4g
bm90IGJlIGNvcGllZCwgdHJhbnNtaXR0ZWQgdG8gdGhpcmQgcGFydGllcyBvciBzdG9yZWQgYnkg
dGhlIGxhdHRlciwgZXhjZXB0IGlmIGF1dGhvcmlzZWQgYnkgdGhlIHNlbmRlci4KCkl0IG1heSBj
b250YWluIGNvbmZpZGVudGlhbCBvciBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gd2hv
c2UgbGVnYWwgcmVnaW1lIGlzIG5vdCBhZmZlY3RlZCBieSB0aGUgZmFjdCB0aGF0IHRoaXMgaW5m
b3JtYXRpb24gaGFzIGJlZW4gc2VudCBieSBlLW1haWwuIAoKSXRzIGVycm9uZW91cyB0cmFuc21p
c3Npb24gdG8gYSBwZXJzb24gb3RoZXIgdGhhbiB0aGUgcmVhbCBuYW1lZCBwZXJzb24gbmVpdGhl
ciBpbXBsaWVzIGFueSBtb2RpZmljYXRpb24gb2YgdGhpcyBuYW1lZCBwZXJzb24gbm9yIGEgcmVu
dW5jaWF0aW9uIG9mIHRoZSBldmVudHVhbCBjb25maWRlbnRpYWxpdHkgb3IgbGVnYWwgcmVnaW1l
IGFmZmVjdGluZyB0aGUgdXNlIG9mIGNvbmNlcm5lZCBtZXNzYWdlLgogCkFueSB2aWV3cyBleHBy
ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSBiaW5kaW5nIGV4Y2x1c2l2ZWx5IHVwb24gdGhlIGlu
ZGl2aWR1YWwgc2VuZGVyLCBleGNlcHQgd2hlcmUgdGhlIG1lc3NhZ2Ugc3RhdGVzIG90aGVyd2lz
ZSBhbmQgdGhlIHNlbmRlciBpcyBhdXRob3Jpc2VkIHRvIGJpbmQgdGhpcyBlbnRpdHkuIAoKSWYg
eW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IHdpdGhv
dXQgdHJhbnNtaXR0aW5nIGl0IHRvIGFueSB0aGlyZCBwYXJ0eSBvciBrZWVwaW5nIGl0IGluIGFu
eSBmb3JtIGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkgZWl0aGVyIGJ5IHBob25lICgzNCA5MSA1
ODkyMTIzKSBvciB1c2luZyB0aGUgZS0gbWFpbCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIuIFRoYW5r
IFlvdS4K

Re: [Quickfix-users] can we use an .xml file instead of .cfg file in session settings

[Joerg T. <Joe...@ma...>]

Hi Rohan,

> Can we use a .Xml file instead of .cfg file , while sending an file name as argument to
> sessionsettings class.

The SessionSettings class expects either an input stream or a filename as string:

  	SessionSettings (std::istream &stream) throw ( ConfigError )
  	SessionSettings (const std::string &file) throw ( ConfigError )

If you want to use an XML file, you have to parse it yourself and convert it into the 
QuickFIX configuration format, e.g. as string and use an istream which reads from a string 
as an argument to the SessionSettings class. Since I am not a C++ or C# programmer, I do 
not know the exact code; for Java this would be:

	String configuration = "[DEFAULT]\nConnectionType=initator\n...";
	InputStream configStream = new ByteArrayInputStream( configuration.getBytes() );
	Settings settings = new Settings(configStream);

Then it is up to you to fill the configuration string with data. E.g. we configure 
QuickFIX with Java properties and wrote a convertor from properties to the QF config file 
format.

At the moment, there is no XML format of the config file planned: There is no extra 
benefit of using XML. Instead QuickFIX should be kept as simple as possible. Oren, please 
tell me if you changed your mind.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] can we use an .xml file instead of .cfg file in session settings

[rohan j. p. <roh...@re...>]

 =A0=0AHi all,=0A       Can we use a .Xml file instead of .cfg file , while=
 sending an file name as argument to sessionsettings class. please help me =
if it is possible .=0A                with regards=0A                rohan =
pais

RE: [Quickfix-users] Rejected execution report: tag not required in dictionary but still reported as missing

[Francis G. <fr...@at...>]

Yes I was in a trace statement, silly me.  Now I get the fills, etc.

Thanks!

Francis

-----Original Message-----
From: atr...@am...
[mailto:atr...@am...] On Behalf Of Oren Miller
Sent: Friday, May 13, 2005 12:09
To: Francis Gingras; qui...@li...
Subject: Re: [Quickfix-users] Rejected execution report: tag not required in
dictionary but still reported as missing

Are you pulling field 58 out of the message in your callback without
checking if it has been set?

--oren

----- Original Message -----
From: "Francis Gingras" <fr...@at...>
To: <qui...@li...>
Sent: Friday, May 13, 2005 10:39 AM
Subject: [Quickfix-users] Rejected execution report: tag not required in
dictionary but still reported as missing


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> QF seems to be rejecting an execution report because it doesn't have 
> tag 58, but the FIX42.xml dictionary lists the tag as not required.  
> Any idea why this report is rejected?  I'm sure there's a simple 
> explanation but I can't see it.
>
> This is from a ThreadedSocketInitiator client, and the FIX server is 
> run locally.
>
> FIX42.xml definition:
> <message name="ExecutionReport" msgtype="8" msgcat="app"> <field 
> name="Text" required="N"/>
>
> Sending Order-Single (BUY 2 ES Mar05 at market):
> 8=FIX.4.2
9=187
35=D
34=159
49=FIXUSER
52=20050513-15:17:56.421
56=TES
> T
1=1
 
> 11=13/05/2005.23
21=1
38=2
40=1
47=0
48=ES0120050300000032320035
54=1

> 55=ES
 59=0
60=20050513-15:17:56
167=FUT
204=0
207=SIM
10=024

>
> Receiving Execution Reports:
> 8=FIX.4.2
9=00343
35=8
49=TTEST
56=FIXUSER
50=SIMTRADER
34=3743
52=200
> 50513-
> 15:17:56.437
55=ES
48=ES0120050300000032320035
167=FUT
207=SIM
1=1
440
> =SIM
1 1=13/05/2005.23
37=0H0000022009
17=0H0000022009:1
58=GW:Order 
> sent to
> exchange
198=1005264
204=0
151=2
14=0
54=1
40=1
77=O
59=0
47=0
150=0
2
> 0=0
39 =0
442=1
38=2
6=0
200=200503
60=20050513-15:17:56.437
10=036

>
> This one doesn't have a tag 58, should be no problem:
> 8=FIX.4.2
9=00324
35=8
49=TTEST
56=FIXUSER
50=SIMTRADER
34=3744
52=200
> 50513-
> 15:17:56.437
55=ES
48=ES0120050300000032320035
167=FUT
207=SIM
1=1
440
> =SIM
1
> 1=13/05/2005.23
37=0H0000022009
17=2791
198=1005264
204=0
32=2
151=0
1
> 4=2
54 
> =1
40=1
77=O
59=0
47=0
150=2
20=0
39=2
442=1
38=2
31=112925
6=112925
2
> 00=200
> 503
60=20050513-15:17:56.437
10=027

>
> Sending Reject:
> 8=FIX.4.2
9=108
35=3
34=160
49=FIXUSER
52=20050513-15:17:57.983
56=TES
> T
45=3 744
58=Required tag missing
371=58
372=8
373=1
10=115

>
> Thanks,
>
> Francis
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be 
> the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

Re: [Quickfix-users] Rejected execution report: tag not required in dictionary but still reported as missing

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

Are you pulling field 58 out of the message in your callback without 
checking if it has been set?

--oren

----- Original Message ----- 
From: "Francis Gingras" <fr...@at...>
To: <qui...@li...>
Sent: Friday, May 13, 2005 10:39 AM
Subject: [Quickfix-users] Rejected execution report: tag not required in 
dictionary but still reported as missing


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> QF seems to be rejecting an execution report because it doesn't have tag 
> 58,
> but the FIX42.xml dictionary lists the tag as not required.  Any idea why
> this report is rejected?  I'm sure there's a simple explanation but I 
> can't
> see it.
>
> This is from a ThreadedSocketInitiator client, and the FIX server is run
> locally.
>
> FIX42.xml definition:
> <message name="ExecutionReport" msgtype="8" msgcat="app">
> <field name="Text" required="N"/>
>
> Sending Order-Single (BUY 2 ES Mar05 at market):
> 8=FIX.4.2
9=187
35=D
34=159
49=FIXUSER
52=20050513-15:17:56.421
56=TEST
1=1

> 11=13/05/2005.23
21=1
38=2
40=1
47=0
48=ES0120050300000032320035
54=1
55=ES

> 59=0
60=20050513-15:17:56
167=FUT
204=0
207=SIM
10=024

>
> Receiving Execution Reports:
> 8=FIX.4.2
9=00343
35=8
49=TTEST
56=FIXUSER
50=SIMTRADER
34=3743
52=20050513-
> 15:17:56.437
55=ES
48=ES0120050300000032320035
167=FUT
207=SIM
1=1
440=SIM
1
> 1=13/05/2005.23
37=0H0000022009
17=0H0000022009:1
58=GW:Order sent to
> exchange
198=1005264
204=0
151=2
14=0
54=1
40=1
77=O
59=0
47=0
150=0
20=0
39
> =0
442=1
38=2
6=0
200=200503
60=20050513-15:17:56.437
10=036

>
> This one doesn't have a tag 58, should be no problem:
> 8=FIX.4.2
9=00324
35=8
49=TTEST
56=FIXUSER
50=SIMTRADER
34=3744
52=20050513-
> 15:17:56.437
55=ES
48=ES0120050300000032320035
167=FUT
207=SIM
1=1
440=SIM
1
> 1=13/05/2005.23
37=0H0000022009
17=2791
198=1005264
204=0
32=2
151=0
14=2
54
> =1
40=1
77=O
59=0
47=0
150=2
20=0
39=2
442=1
38=2
31=112925
6=112925
200=200
> 503
60=20050513-15:17:56.437
10=027

>
> Sending Reject:
> 8=FIX.4.2
9=108
35=3
34=160
49=FIXUSER
52=20050513-15:17:57.983
56=TEST
45=3
> 744
58=Required tag missing
371=58
372=8
373=1
10=115

>
> Thanks,
>
> Francis
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

[Quickfix-users] Rejected execution report: tag not required in dictionary but still reported as missing

[Francis G. <fr...@at...>]

QF seems to be rejecting an execution report because it doesn't have tag 58,
but the FIX42.xml dictionary lists the tag as not required.  Any idea why
this report is rejected?  I'm sure there's a simple explanation but I can't
see it.

This is from a ThreadedSocketInitiator client, and the FIX server is run
locally.

 FIX42.xml definition:
<message name="ExecutionReport" msgtype="8" msgcat="app">
<field name="Text" required="N"/>

Sending Order-Single (BUY 2 ES Mar05 at market):
8=FIX.4.2
9=187
35=D
34=159
49=FIXUSER
52=20050513-15:17:56.421
56=TEST
1=1

11=13/05/2005.23
21=1
38=2
40=1
47=0
48=ES0120050300000032320035
54=1
55=ES

59=0
60=20050513-15:17:56
167=FUT
204=0
207=SIM
10=024


Receiving Execution Reports:
8=FIX.4.2
9=00343
35=8
49=TTEST
56=FIXUSER
50=SIMTRADER
34=3743
52=20050513-
15:17:56.437
55=ES
48=ES0120050300000032320035
167=FUT
207=SIM
1=1
440=SIM
1
1=13/05/2005.23
37=0H0000022009
17=0H0000022009:1
58=GW:Order sent to
exchange
198=1005264
204=0
151=2
14=0
54=1
40=1
77=O
59=0
47=0
150=0
20=0
39
=0
442=1
38=2
6=0
200=200503
60=20050513-15:17:56.437
10=036


This one doesn't have a tag 58, should be no problem:
8=FIX.4.2
9=00324
35=8
49=TTEST
56=FIXUSER
50=SIMTRADER
34=3744
52=20050513-
15:17:56.437
55=ES
48=ES0120050300000032320035
167=FUT
207=SIM
1=1
440=SIM
1
1=13/05/2005.23
37=0H0000022009
17=2791
198=1005264
204=0
32=2
151=0
14=2
54
=1
40=1
77=O
59=0
47=0
150=2
20=0
39=2
442=1
38=2
31=112925
6=112925
200=200
503
60=20050513-15:17:56.437
10=027


Sending Reject:
8=FIX.4.2
9=108
35=3
34=160
49=FIXUSER
52=20050513-15:17:57.983
56=TEST
45=3
744
58=Required tag missing
371=58
372=8
373=1
10=115

 
Thanks,

Francis

[Quickfix-users] Session reset

[Brian E. <azz...@ya...>]

We are having a problem with QuickFIX session start/end times.

We currently have the following values set in our QUICKFIX.INI file:

StartDay=Friday
StartTime=16:50:00
EndDay=Friday
EndTime=16:45:00

As I understand the documentation, this should set up a weeklong
session, starting on Friday 16:50 UTC and ending the next Friday at
16:45 UTC.

However, when we tested this, we had our session reset on Friday at
exactly 00:00 local time (Chicago). The "active" session had started on
Monday at 18:47:47 UTC (we brought up our app in "mid-session" and had
let it run continuously since then).

I looked at the Session and SessionTime code (specifically the
checkSessionTime and isSameSession/isSessionTime methods) and I didn't
see anything obviously wrong (tried to run it in my head).

Has anyone seen this type of error before? Any help would be much
appreciated.

- Brian Erst

p.s. We are considering just moving to a Saturday-Saturday session. Is
StartTime/EndTime required, or would it default to 00:00 UTC on
Saturday?

Re: [Quickfix-users] how to stop automatic login

[Dale W. <wil...@oc...>]

Hi, Rohan,
rohan joel pais wrote:

> Hi all,
>       I wanted to know how to stop automatic login when we are calling 
> initiator.start() function.
> Can anybody help me.
>                     with regards
>                     rohan pais
>
This is how we handle it:

void
YourApp::onCreate( const FIX::SessionID & sessionID)
{
  FIX::Dictionary dictionary = getSessionSettings(sessionID);
  std::string connectionType = dictionary.getString(FIX::CONNECTION_TYPE);
  if(connectionType == "acceptor")
  {
    //<SNIP initialize acceptor stuff/>
   }
  }
  else
  {
    // Start initiator sessions in idle state.
    FIX::Session* session = FIX::Session::lookupSession( sessionID );
    session->logout();
    //<SNIP initialize initiator stuff/>
  }
}

Then you can call session->logiin when you're ready.

Dale

-- 
-----------------------------------------------------
  Dale Wilson, Senior Software Engineer      
  Object Computing, Inc. (OCI)
  http://www.ociweb.com/  http://www.theaceorb.com/
----------------------------------------------------

[Quickfix-users] how to stop automatic login

[rohan j. p. <roh...@re...>]

 =A0=0AHi all,=0A       I wanted to know how to stop automatic login when w=
e are calling initiator.start() function.=0ACan anybody help me.=0A        =
            with regards=0A                    rohan pais

Re: [Quickfix-users] ThreadedSocketInitiator - process messages on yet another thread?

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

Yeah, there is no reason not to do processing in the handler when using the 
Threaded model.

--oren

----- Original Message ----- 
From: "Francis Gingras" <fra...@ya...>
To: <qui...@li...>
Sent: Friday, May 06, 2005 7:49 PM
Subject: [Quickfix-users] ThreadedSocketInitiator - process messages on yet 
another thread?


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> When using the ThreadedSocketInitiator, is it recommended to process the
> messages on a different thread?
>
> The docs say the ThreadedSocketInitiator creates two threads so it looks
> safe to do the processing in the message handler, unless I'm missing
> something?
>
> Thanks,
>
> Francis
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

[Quickfix-users] ThreadedSocketInitiator - process messages on yet another thread?

[Francis G. <fra...@ya...>]

Hi,
 
When using the ThreadedSocketInitiator, is it recommended to process the
messages on a different thread?  

The docs say the ThreadedSocketInitiator creates two threads so it looks
safe to do the processing in the message handler, unless I'm missing
something?

Thanks,
 
Francis

[Quickfix-users] Sequence to low problem

[rohan j. p. <roh...@re...>]

 =A0=0AHi all,=0A      i have got a problem with sequence number, when i ru=
n my project for the first time it works correctly, but during the second, =
third run and so on it uses the sequence number used for the last run.=0Awh=
at should i do to solve this problem=0A          regards=0A                =
            rohan pais=20