quickfix-users — QuickFIX user support

Re: [Quickfix-users] How to control sequence reset time

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

Use the StartDay and EndDay configuration settings to use week long  
sessions.

http://www.quickfixengine.org/quickfix/doc/html/configuration.html

--oren

On Jul 14, 2005, at 1:27 PM, Sumit Kumar 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,
>
> I am using quickfix 1.10.2.
>
> My fix application interacts with a provider that
> resets it's sequence number once a week. While at my
> end the sequence number resets itself to 1 : 1 at
> 00:00:00 (UTC) everyday.
>
> I tried to control it by changing the StartTime and
> EndTime (which by default were 00:00:00) in the
> QuickFix Settings file but doesn't seem to work. What
> is the right way to control sequence reset schedule?
>
> Thanks
>
> Sumit Kumar
>
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

[Quickfix-users] How to control sequence reset time

[Sumit K. <sk_...@ya...>]

Hi,

I am using quickfix 1.10.2. 

My fix application interacts with a provider that
resets it's sequence number once a week. While at my
end the sequence number resets itself to 1 : 1 at
00:00:00 (UTC) everyday. 

I tried to control it by changing the StartTime and
EndTime (which by default were 00:00:00) in the
QuickFix Settings file but doesn't seem to work. What
is the right way to control sequence reset schedule?

Thanks

Sumit Kumar



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [Quickfix-users] Cancel, Limit & Stop

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

Hi Alberto,

> I've got two doubts around the fix/quickfix transactions:

These questions are general FIX questions; its better to post them on the FPL site in the
forums:

     http://www.fixprotocol.org/discuss/

Please note that you have to register to post questions.

> Case 1: Suppose I've bought some shares at 2$. Now I want to put a limit
> and a stop at 1.50$ and 2.50$. How should I do that? Using an
> OrderCancelReplaceRequest?

NewOrderSingle(MsgType=D, Side=Sell) is appropriate if you want to sell these shares.
In addition, OrdType=4(Stop Limit) together with StopPx=2.50, Price=1.50 and Currency=USD 
should do the job.

> Case 2: Suppose I've bought some GBP/USD and now I want to sell them.
> How should I do that? Using a new sell Order? Using an
> OrderCancelRequest?

dito NewOrderSingle(Side=Sell, ...)

See e.g. http://www.transacttools.net/ttportal/datadict/browser.jsp for details for the 
NewOrderSingle fields.

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] Cancel, Limit & Stop

[Alberto B. <bellido@3.14financial.com>]

Hi

I've got two doubts around the fix/quickfix transactions:

Case 1: Suppose I've bought some shares at 2$. Now I want to put a limit
and a stop at 1.50$ and 2.50$. How should I do that? Using an
OrderCancelReplaceRequest?

Case 2: Suppose I've bought some GBP/USD and now I want to sell them.
How should I do that? Using a new sell Order? Using an
OrderCancelRequest?

Any ideas?
Thank you in advance


   Alberto Bellido

[Quickfix-users] QuickFIX 1.10.2 is now available

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

QuickFIX 1.10.2 is now available at http://www.quickfixengine.org/

A couple of point releases went out before I had a chance to announce  
1.10.0.  You can get the release notes for all versions here: http:// 
www.quickfixengine.org/NEWS

Well now.  It's been a bit longer between releases then normal, but  
here it is.  Not everything we wanted to get in here did, but we will  
be pushing for a 2.0 release and hope to incorporate some of our more  
ambitious goals.

Some of the things you will find in this version is automated support  
for SequenceResets.  If your engine receives one, it will reset your  
sequence numbers and send the appropriate ack.  If you attach a  
ResetSeqNumFlag=Y to your logon message, the engine will reset its  
sequence numbers appropriately.  This flag will also automatically  
attach itself at the appropriate time if you have ResetOnDisconnect  
or ResetOnLogoff set.

You can now reliably stop and start initiators and acceptors as much  
as you like.  Previously once you stopped in initiator or acceptor,  
it wasn't designed to be brought back up and you'd have to throw it  
away.  Now you can call start/stop as much as you like.  Even better,  
the initiator/acceptor will attempt to properly logout of all  
sessions before shutting down.  It will only forcibly take down a  
session if it doesn't respond withing 5 seconds to the logout attempt.

Some things with field validation.  You can turn them off for user  
defined fields with the ValidateUserDefinedFields configuration  
setting.  Also the validation algorithm will now check for required  
fields in the header, trailer, and repeating groups instead of just  
the main message body.

The much wanted method to getSessions from an initiator/acceptor is  
now available in all APIs.

And you can check the release notes for all the details.  Did we miss  
something?  Please enter it into the bugtracker (http:// 
www.quickfixengine.org/bugtracker/).  That's the best way to ensure  
that we don't miss it.  The mailing list has grown a bit much to be  
used as a way to reliably track such things (the developer list alone  
had 190 posts last month).  After reporting something to the list, if  
the discussion reveals a need for action, please help us out by  
entering it into the bugtracker and attaching any relevant log files.

--oren

Re: [Quickfix-users] QuickFIXEngine user experience

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

Hi,


>> When runs as a client (initiator) does not handle properly out of sync 
>> message sequence situation regardless config settings (see bug #19 it 
>> seems to be there for ages).
>
> OK, there is a patch attached. Does it work for you?

Actually, I've found this bug right after fixing this bug.. My fix is quite 
simple I'm adding reset flag to logon message on application side i.e. 
within toAdmin() message call.

>> When runs as server thread accepting connections silently exits on 
>> unknown fields in login message.
>
> Hmmm, could you provide more details here?

Yes. I was trying to logon with Username & Password fields set to fix4.2 
session, w/o adding such fields to the spec first... After such attempt 
quickfix stops from listenning socket.

>> java port does not deal properly with classloaders.
>
> Java API, the (pure) Java port of Steve Bates is in CVS. This is bug 58 
> with patches attached. I did not find time to have a closer look at it, 
> but it will make using QF with JBoss (and other application server) and 
> eclipse much easier.

Actually I was talking about java + native part port. Don't know how to name 
it in case of pure java port presens. The bug is quite simple -- once you 
have either Acceptor or Initiator started, quickfix starts new internal 
thread w/o saving context class loader or at least classloader which has 
loaded Acceptor/Initiator... Later when calls from this thread are made to 
parse incoming messages, system classloader is being used. Hence you can get 
ClassNotFoundException for newly loaded classes.. Right now I'm 
workarounding this by restoring original classloader in fromApp() call..

There is yet another bug (or feature) that may be an issue in multithreaded 
application using quickfix... Quickfix holds a session lock while 
dispatching new message (preventing other threads from sending concurrent 
messages) so if you have to synchronize dispatching thread with another 
thread which in turn also may send a message -- you have a deadlock.. There 
are several fixes for this problem -- either write clearly in docs about 
threading issues, or inject lock management from quickfix core, or at least 
make such locks accessible for application. The last approach has an 
advantage as it would not break existing quickfix applications.

[Quickfix-users] Can I add user defined fields in the DataDictionary file

[George G. <gge...@ho...>]

I have just read the doc about adding user defined fields.
Can I modify FIX40.xml file and add the user defined columns there or need 
to add them in the source code?
Will be using .Net dlls


Thanks

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: [Quickfix-users] QuickFIXEngine user experience

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

Barry Marks wrote:
> I'm currently considering using the QuickFIXEngine
> and I'm looking for information from users who have
> had actual experience with it.

Have a look at this link:

http://www.quickfixengine.org/wikifix/index.php?WhoIsUsingQuickFix

Its part of the now defunct WikiFIX (we have got a lot of spam issues), but this page 
still works.

> The particular areas of interest are
> 
>  - platform used on,
>        i.e., Windows, Linux, Solaris, FreeeBSD, MacOS, mainframe

At the moment, I am not aware of any port to mainframe or AIX. But the other platforms are 
supported (and used).

Please also note the pure Java port of Steve Bates.

>  - reliability

We (www.glox.com) are using QuickFIX in production for more than 2 years, and it proved 
very stable during that time. Of course, there are bugs. But they get fixed and added to 
the unit tests to avoid regression.

I also know of at least 2 exchanges using QuickFIX (SWX and CME).
>  - performance

For more detailed figures, run quickfix/src/pt.cpp on a suitable machine. There have been 
some substantial performance improvements last year.

Speaking for GLOX, we are satisfied with performance and never had any issues related.

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

Re: [Quickfix-users] QuickFIXEngine user experience

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

Nick Evgeniev wrote:
> I've been using quickfix on windows/linux/solaris for sometime.. The 
> most annoying thing with quickfix is broken double parsing, because of 
> atof() usage. So if your platform honors locale settings for atof() call 
> (like Solaris) and your current locale settings have decimal separator 
> other than '.' quickfix will silently drop fraction part on all of your 
> pricess! (damn!) so be sure to set LC_NUMERIC=C prior to running any 
> quickfix application.

Nick, please file a bug report to the bug tracker. Since the formatting of FIX messages is 
defined by the FIX spec, it should not be modified by any locale settings. Do you remember 
of other situations where this could apply (e.g. date/time etc.)? Thanks.

>> - reliability
> 
> There is quite a bit to do in this area.. (requires manual fixing and 
> testing).
> When runs as a client (initiator) does not handle properly out of sync 
> message sequence situation regardless config settings (see bug #19 it 
> seems to be there for ages).

OK, there is a patch attached. Does it work for you?

> When runs as server thread accepting connections silently exits on 
> unknown fields in login message.

Hmmm, could you provide more details here?

> java port does not deal properly with classloaders.

Java API, the (pure) Java port of Steve Bates is in CVS. This is bug 58 with patches 
attached. I did not find time to have a closer look at it, but it will make using QF with 
JBoss (and other application server) and eclipse much easier.

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

Re: [Quickfix-users] QuickFIXEngine user experience

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

Hi,

> I'm currently considering using the QuickFIXEngine
> and I'm looking for information from users who have
> had actual experience with it.  The particular
> areas of interest are
>
> - platform used on,
>       i.e., Windows, Linux, Solaris, FreeeBSD, MacOS, mainframe

I've been using quickfix on windows/linux/solaris for sometime.. The most 
annoying thing with quickfix is broken double parsing, because of atof() 
usage. So if your platform honors locale settings for atof() call (like 
Solaris) and your current locale settings have decimal separator other than 
'.' quickfix will silently drop fraction part on all of your pricess! 
(damn!) so be sure to set LC_NUMERIC=C prior to running any quickfix 
application.

> - reliability
There is quite a bit to do in this area.. (requires manual fixing and 
testing).
When runs as a client (initiator) does not handle properly out of sync 
message sequence situation regardless config settings (see bug #19 it seems 
to be there for ages).
When runs as server thread accepting connections silently exits on unknown 
fields in login message.

java port does not deal properly with classloaders.

> - performance

I do not really care about performance right now... I mean that order 
processing time is always much more than message parsing time. The only 
issue you _probably_ may have is high garbage rate in case you chose the 
most typesafe way programming quickfix. But in reality your order processing 
engine will become bottleneck much sooner.

The only case you should care about performance is when your are about to 
distribute market data (quotes) using fix... all the others are safe. :)

Hope it helps.

[Quickfix-users] QuickFIXEngine user experience

[Barry M. <bar...@ya...>]

I'm currently considering using the QuickFIXEngine
and I'm looking for information from users who have
had actual experience with it.  The particular
areas of interest are

 - platform used on,
       i.e., Windows, Linux, Solaris, FreeeBSD, MacOS, mainframe
 - reliability
 - performance

Any information you can provide will be much appreciated.

Thanks,
Barry

Barry Marks
Logicware, Inc.
Northbrook, IL
bar...@ya...
  

[Quickfix-users] I made a test, it seemed like quickfix can't be used in Eclipse plugins

[panyan <pa...@dh...>]

I made a test, it seemed like quickfix can't be used in Eclipse plugins.
I run run_executor_java.bat as acceptor, use banzai as initiator.
But I changed banzai.java and banzaiApplication.java, removed the UI
part(as the attachment). banzai has a main() method, So in Eclipse,
it can run as a java application, everything is ok, banzai can send and
receive messages. But when I "new Banzai()" at my Eclipse plugins, I meet
new problem. The problem is not in Banzai(), it occurs at a new message 
arrived
from the acceptor. My Eclipse will popup a "Microsoft Visual C++ Runtime 
Libray"
dialogbox, tell me "Program C:\Sun\AppServer\jdk\bin\javaw.exe, This 
application
has requested the Runtime to terminate it in an unusual way. Please contact 
the
application's support team for more information". So I checked 
quickfix_jni.dll's
sourcecode. the problem occured at Conversion.h's 

"inline jobject newMessage( const FIX::Message& message, JVMObject factory 
)" 

method, when this method want "JVMClass type ( "Lquickfix/MessageFactory;" 
);" 

this dialogbox will popup. But when banzai run's in main(), it is all right.
I tryed and tryed, but I can't find why. 

BTW, I also searched maillist history, Girish Subramanya posted 
http://sourceforge.net/mailarchive/message.php?msg_id=8750336, which 
mentioned the same problem, anyone knows has it been resolved? 

panyan
20050626 

Re: [Quickfix-users] message replay

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

The MessageStore isn't really designed for this purpose.  For a couple 
reasons.  First, the MessageStore only stores outgoing messages.  It does 
this in the case it is required to resend one of these messages to the 
counterparty.  It does not keep track of incoming messages at all.

Second, the messages stored there are not guaranteed to be retained.  If the 
counterparty requests a sequence number reset for instance, the storage file 
will be wiped clean.

In general it is not recommended to use QuickFIX to manage your applications 
persistance.  Before returning from a callback, you should take care to 
fully process and persist any data you wish to retain.  As soon as the 
callback returns, that is an indication to QuickFIX that you have taken over 
responisbility for the contents of that message.

Instead I would recommend that you stream the messages you want to replay 
into a file and read them back in when you load your application.  You can 
pass the strings you read into the Message contructor.  You can then pass 
those messages into your MessageCracker in order to process them.

--oren

----- Original Message ----- 
From: "AW" <aar...@gm...>
To: <qui...@li...>
Sent: Monday, June 20, 2005 11:04 AM
Subject: [Quickfix-users] message replay


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

I'm creating a simple client to receive execution reports from a
vendor. QuickFix has performed fantastically. In order to recover from
logic errors on my side when loading the execution reports Id like to
be able to restart at any point during the day and replay all
execution reports I've already seen.

Im looking for a strategy to replay the day's messages out of the
message store each time I startup my application.  Ive been able to
iterate through a file store and read in the messages, but I cant find
a way to restore the messages to the correct type (ie Id like to be
able to a call crack on the message as if it was new).

Is there built-in replay functionality? Is hitting the file store and
reading in the raw messages a safe/recommended way to go about this?

thanks,
--aaron


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

[Quickfix-users] message replay

[AW <aar...@gm...>]

Hi

I'm creating a simple client to receive execution reports from a
vendor. QuickFix has performed fantastically. In order to recover from
logic errors on my side when loading the execution reports Id like to
be able to restart at any point during the day and replay all
execution reports I've already seen.

Im looking for a strategy to replay the day's messages out of the
message store each time I startup my application.  Ive been able to
iterate through a file store and read in the messages, but I cant find
a way to restore the messages to the correct type (ie Id like to be
able to a call crack on the message as if it was new).

Is there built-in replay functionality? Is hitting the file store and
reading in the raw messages a safe/recommended way to go about this?

thanks,
--aaron

Re: [Quickfix-users] ThreadedSocketInitiator tcp session shutdown

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

This is a bug, but it has been fixed in CVS.

--oren

----- Original Message ----- 
From: "H. Steuer" <st...@un...>
To: <qui...@li...>
Sent: Saturday, June 11, 2005 8:36 AM
Subject: [Quickfix-users] ThreadedSocketInitiator tcp session shutdown


> 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
>
> hello,
>
> i just ran into a small issue with the ThreadedSocketInitiator. When the 
> EndTime of a session is reached, QF drops the connection. but in the case 
> of ThreadedSocketInitiator, it seems that the thread responsible for 
> bringing up the tcp connection ThreadedSocketInitiator::socketThread is 
> not removed during session shutdown. therefore it continues trying to open 
> the tcp connection. if it succeeds, it drops the session immediately, as 
> it is out of the session time. of course it is possible that "it is not a 
> bug, it is a feature" and i do have to do cleanup code myself. i just was 
> not able to find a way to get the thread id for a session.
>
> thanks for any hints
>
> cheers,
> heri
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office luge 
> track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
> 

[Quickfix-users] ThreadedSocketInitiator tcp session shutdown

[H. S. <st...@un...>]

hello,

i just ran into a small issue with the ThreadedSocketInitiator. When the EndTime of a session is reached, QF drops the connection. but in the case of ThreadedSocketInitiator, it seems that the thread responsible for bringing up the tcp connection ThreadedSocketInitiator::socketThread is not removed during session shutdown. therefore it continues trying to open the tcp connection. if it succeeds, it drops the session immediately, as it is out of the session time. of course it is possible that "it is not a bug, it is a feature" and i do have to do cleanup code myself. i just was not able to find a way to get the thread id for a session.

thanks for any hints 

cheers,
heri

[Quickfix-users] Regarding Start time and End Time

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

 =A0=0AHi all,=0A       What the Exact use of start time, end time, start d=
ate and end date. =0A                with regards=0A                Rohan p=
ais

[Quickfix-users] Re: [Quickfix-developers] integration of my sql and quick fix

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

On 9 Jun 2005 14:06:38 -0000, rohan joel pais <roh...@re...> wr=
ote:

>            Can Any body send me the exact procedure to follow, while
> integrating MySql with quick fix on linux machine.=20

This is the second time you've asked this question in a too-vague way.
 I replied to your first post, but you seem to have ignored my reply.

What precisely do you need to know?  How to build QF with MYSQL
support?  How to create a database?  How to configure an Application
to use MySQL?

http://quickfixengine.org/quickfix/doc/html/install.html

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

[Quickfix-users] 64-bits JNI troubles ...

[Fabien G. <fab...@pr...>]

Hi

I try to compile/run quickfix v1.9.4 under Redhat ES v3 with dual opteron
(x86_64 arch).
C++ works well but not the JNI library.
As soon as i use libquickfix_jni.so in any java program (even quickfix
example), there are troubles with :
- Sun JVM 1.4 (j2ee 32b)
- Sun JVM 1.5 32b or 64b
- IBM JVM 1.4 32b or 64b
The result is ... exception : core dumped ...
I did set CLASSPATH, -Djava.library.path and jvm found the right library.
1) Does anyone use quickfix java on 64b platform with success ?

I saw in other thread from Tom Wood that he suggests to compile CPP code in
32b mode.
I tried to set CPPFLAGS="-m32" but i obtained incompatibilty error with
"libxml2.so" library.
2) does anyone successfully compile/run in 32-bits mode with 64-bits
platform ? (x86_64)

This is my first post here, please apologize if a forgot some rules :)

[Quickfix-users] integration of my sql and quick fix

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

 =A0=0AHi all,=0A           Can Any body send me the exact procedure to fol=
low, while integrating MySql with quick fix on linux machine.=20

[Quickfix-users] Re: [Quickfix-developers] compiling with my sql support

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

On 7 Jun 2005 05:25:27 -0000, rohan joel pais <roh...@re...> wr=
ote:

>  3.I added the mysql/lib/ and mysql/lib/debug,and java related stuff in t=
he
> search path.

Be more clear here.  Did you add them to the PATH environment variable
or to the VC++ Tools > Options > Projects > VC++ Directories settings?
 Did you add them to the "Library Files" directories?  Do you actually
have a libmysql.lib file anywhere in your MySQL installation
directory?  If so, this is the directory you need to add to the
"Library Files" directory settings.


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

[Quickfix-users] compiling with my sql support

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

 =A0=0AHi,=0A	I am trying to batchbuild of quickfix.dsw with mysql support =
on visual c++,these are the steps I followed=0A1. I added "#define HAVE_MYS=
QL 1" in config_windows.h.=0A=0A2.Ten I opened the quickfix.dsw in visual c=
++=0A=0A3.I added the mysql/lib/ and mysql/lib/debug,and java related stuff=
 in the search path.=0A=0A4.Then I gave the batchbuild.=0A		The build compl=
eted with one error "LNK1104: cannot open file "libMySQL.lib".=0AHas anyone=
 came across such error,please help.How to resolve the issue.=0A				Regards=
=0A						Rohan		=0A	  =20

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 ===

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

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

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
> > 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
> >
> === message truncated ===

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

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

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
> 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
> 
=== message truncated ===