Re: [Quickfix-developers] Interpretation of OrdStatus inOrderCancelReject message?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Scott

Looking at those FIX messages, the second cancel you are sending is using 
the ClOrdID of the original cancel message as the OrigClOrdID (i.e. you are 
trying to cancel a cancel), so when the server replies with a CancelReject 
for it, the OrdStatus should be Rejected as that ClOrdID has been processed 
(with the PendingCancel execution report).

HTH
Keith

----- Original Message ----- 
From: "Scott Mitchell" <rs...@pr...>
To: <qui...@li...>
Sent: Tuesday, February 12, 2008 12:25 PM
Subject: [Quickfix-developers] Interpretation of OrdStatus 
inOrderCancelReject message?

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi all,
>
> I'm interested in people's thoughts on the interpretation of the
> OrdStatus (39) field of an OrderCancelReject (35=9) message.  The 4.2
> spec simply says this is the "OrdStatus value after this cancel reject
> is applied", which I've always taken to mean the status of the complete
> order chain after the cancel reject has been applied.  This
> interpretation has served us well, until we recently had to integrate
> with a server (a home-grown one, I believe) that always sets 39=8
> (Rejected) on any OrderCancelReject, yet still sends subsequent
> execution reports for the order.  This seems bogus to me - it's the
> cancel request that is being rejected, not the order - but the server
> vendor insists their behaviour is valid.  They may be correct within the
> letter of the spec but my feeling is that this violates the spirit of
> the protocol at least; although we will probably implement a workaround
> for this case regardless, I'd still like to be able to claim some moral
> high ground and produce some evidence that their implementation is
> incorrect.
>
> So what do other people think - how should 39=8 in an OrderCancelReject
> be handled?
>
> Below is a sample message sequence demonstrating what I'm talking about
> - the client attempts to cancel an order that's already in the Pending
> Cancel state and gets an OrderCancelReject with 39=8 (excuse dodgy line
> wrapping):
>
> 8=FIX.4.2 9=178 35=D 34=228 49=FIXAPAMA 52=20080125-14:44:38 56=TDPX
> 1=TD580IT 7 08470615C6 CDS 5J9535E 11=1:168:72278 21=1 38=500 40=2 44=99
> 47=J 54=1 55=RIM 60=20080125-08:44:38 100=110 114=N 10=170
>
> 8=FIX.4.2 9=236 35=8 34=469 49=TDPX 52=20080125-14:44:38 56=FIXAPAMA 6=0
> 11=1:168:72278 14=0 17=FIXAPAMA-70080125-95-0 20=0 30=110 31=0 32=0
> 37=FIXAPAMA-70080125-95 38=500 39=A 44=99 47=J 54=1 55=RIM 59=0
> 60=20080125-14:44:38 99=0 150=A 151=500 167=CS 10=158
>
> 8=FIX.4.2 9=236 35=8 34=470 49=TDPX 52=20080125-14:44:38 56=FIXAPAMA 6=0
> 11=1:168:72278 14=0 17=FIXAPAMA-70080125-95-1 20=0 30=110 31=0 32=0
> 37=FIXAPAMA-70080125-95 38=500 39=0 44=99 47=J 54=1 55=RIM 59=0
> 60=20080125-14:44:38 99=0 150=0 151=500 167=CS 10=117
>
> 8=FIX.4.2 9=147 35=F 34=230 49=FIXAPAMA 52=20080125-14:44:39 56=TDPX
> 11=1:170:12012 37=FIXAPAMA-70080125-95 38=500 41=1:168:72278 54=1 55=RIM
> 60=20080125-08:44:39 10=015
>
> 8=FIX.4.2 9=242 35=8 34=472 49=TDPX 52=20080125-14:44:39 56=FIXAPAMA
> 6=99 11=1:168:72278 14=200 17=FIXAPAMA-70080125-95-2 20=0 30=110 31=99
> 32=200 37=FIXAPAMA-70080125-95 38=500 39=1 44=99 47=J 54=1 55=RIM 59=0
> 60=20080125-14:44:38 99=0 150=1 151=300 167=CS 10=190
>
> 8=FIX.4.2 9=254 35=8 34=473 49=TDPX 52=20080125-14:44:39 56=FIXAPAMA
> 6=99 11=1:170:12012 14=200 17=FIXAPAMA-70080125-95-3 20=0 30=110 31=0
> 32=0 37=FIXAPAMA-70080125-95 38=500 39=1 41=1:168:72278 44=99 47=J 54=1
> 55=RIM 59=0 60=20080125-14:44:39 99=0 150=6 151=300 167=CS 10=251
>
> 8=FIX.4.2 9=147 35=F 34=232 49=FIXAPAMA 52=20080125-14:44:39 56=TDPX
> 11=1:172:72279 37=FIXAPAMA-70080125-95 38=500 41=1:170:12012 54=1 55=RIM
> 60=20080125-08:44:39 10=013
>
> 8=FIX.4.2 9=143 35=9 34=474 49=TDPX 52=20080125-14:44:39 56=FIXAPAMA
> 11=1:172:72279 37=NONE 39=8 41=1:170:12012 58=Order Not Found (Too late
> to cancel?) 434=1 10=006
>
> 8=FIX.4.2 9=239 35=8 34=478 49=TDPX 52=20080125-14:44:39 56=FIXAPAMA
> 6=99 11=1:168:72278 14=200 17=FIXAPAMA-70080125-95-4 20=0 30=110 31=0
> 32=0 37=FIXAPAMA-70080125-95 38=500 39=4 44=99 47=J 54=1 55=RIM 59=0
> 60=20080125-14:44:39 99=0 150=4 151=300 167=CS 10=047
>
>
> Cheers,
>
> Scott
>
> -- 
> Dr Scott Mitchell, Apama Connectivity Engineering Manager, Cambridge UK
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers 