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
|
