|
4.2 Changes
< Previous Next >
Re: 41 - OrigClOrdID
Ryan Pierce (FPL Technical Director) / FIX Protocol Ltd.
18 Feb 2009 10:38AM ET [Correction; sorry if you get this twice.]
To further clarify:
The party sending the order is "optimistic" that a change will succeed. If a change hasn't been acknowledged, the party sending the order will send another change or cancel using ClOrdID of the last change as the OrigClOrdID of the next change or cancel. Note that this is only true if a change isn't rejected.
The party accepting the order is "pessimistic" that a change will succeed in choosing its ClOrdID. In other words, if that party responds with a Pending Replace for ClOrdID=Y, OrigClOrdID=X, and a partial fill occurs before a Replaced messages is sent, then ClOrdID=X.
I hope this helps.
> Your message no 2 (Cancel Request) would have OrigClOrdID = Y,
> ClOrdID = Z
>
> Look thru "D16– One cancel/replace request is issued followed
> immediately by another – broker processes sequentially" on page 219
> (221 of 283) of FIX.4.2 spec
>
> > Hello guys,
> >
> > I've got a question regarding the definition of tag 41, "OrigClOrdID":
> >
> > I have the following scenario:
> >
> > 1.) I send a CancelreplaceRequest for an existing order ClientOrderID
> > = Y, OrigClOrdID = X
> > 2.) Before receiving any response, I send directly a Cancel request
> > Message, nearly in the sam millisecond.
> >
> > Which value must the OrigClOrdID have:
> >
> > a.) OrigClOrdID = X, because it's the ClOrdId we konw as confirmed by
> > the exchange, or
> > b.) OrigClOrdID = Y, because this is the last ClOrdID we know tthat
> > we've sent.
> >
> > Any help with this issue would be much appreciated!
> >
> > Many thanks and kind regards, Eva
Re: 41 - OrigClOrdID
Ryan Pierce (FPL Technical Director) / FIX Protocol Ltd. 18 Feb 2009 10:38AM ET
|
