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

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

Steve -

The rules for "Pending New" have certainly been relaxed since 4.0, but
they persist in leaving in that sentence about Status Requests. Given
that, we went with the new values.

I agree that a bunch of people do use "Pending New" - enough so that
it's probably a de-facto industry standard. It's a little too late to
make the change now, but I'd probably use it on a different project.

I'd still have problems with a couple of other issues (our stop
processing, for one).

FIX is at best a jumping off point. I don't think it'll ever get to the
point that no one needs to tweak it anymore.

- Brian Erst
Thynk Software, Inc.

--- Steve Bate <st...@te...> 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
> 
> Hi Brian,
> 
> Interesting. I see the sentence that says Pending New should only
> be sent for a Status Request message. However, I also see several
> scenarios in the 4.4 specification where Pending New is sent in
> response to orders (e.g. Acknowledgement of a Cross Order, Volume 4,
> pg. 93).
> 
> I don't recall that we ever had a client FIX engine that had a
> problem with the Pending New response to an order.
> 
> Like you said, it's a judgment call involving various tradeoffs.
> I would have guessed that it's more likely that FIX engines would
> be able to process a Pending New response to an order (since popular
> ECNs like Island implement this behavior) than process a nonstandard
> enumerated value for an existing tag. The latter would require engine
> 
> code modifications in some of the home-brew implementations I've
> seen (due to inflexible validation code or hard-coded enumeration
> representations). A user-defined tag would be another option, but 
> it may require the client to make application-level changes and I'd
> still have to select an OrdStatus for the Execution Report anyway.
> 
> Isn't FIX fun? ;-)
> 
> Regards,
> 
> Steve
> 
> > -----Original Message-----
> > From: Brian Erst [mailto:azz...@ya...]
> > Sent: Friday, June 03, 2005 10:50 AM
> > To: Steve Bate; qui...@li...; quickfix-
> > dev...@li...
> > Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> > response to a client
> > 
> > Steve -
> > 
> > I'd be happy to move this to one or the other list. The original
> > question went to both. I'm not currently subscribed to developers,
> so
> > users probably makes more sense.
> > 
> > In regards the use of "Pending New" vs. "New", I think I was a
> little
> > unclear in a previous message. According to the FIX specification,
> > "Pending New" is only to be used in response to a Status Request.
> Many
> > people in the industry have extended its use to mean "at the
> router",
> > but technically it's a violation of the protocol.
> > 
> > We thought it better to add field values (that could be ignored if
> > needed) rather than redefine existing values. Considering
> widespread
> > industry use, we probably would have been safe either way, but we
> > didn't want to cause problems with existing FIX engines. We've
> > generally found it is easier to extend an engine to accept new
> field
> > values than to change how it handles existing ones.
> > 
> > One could make the argument that we should have used "New" to
> indicate
> > acceptance by the exchange and an extended value to indicate
> acceptance
> > by our system. We felt that due to a number of issues (mainly
> having to
> > do with the fact that some orders would never end up at an
> exchange) it
> > made more sense the other way, but that was purely a judgment call.
> I
> > can easily see someone deciding the reverse is better.
> > 
> > - Brian Erst
> > Thynk Software, Inc.
> > 
> > --- Steve Bate <st...@te...> 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
> > >
> > > (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
> 
=== message truncated ===