Imported from previous forum
[ original email was from Livleen Singh - lsingh@acm.org ]
I have a situation whereby I am getting orders from a client using fix 4.0 sending to a gateway that maps 4.0 to 4.2. I am using fix 4.2 and am on the receiving end of the order flow.
I would like to get some help in understanding the proper flow of messages for a c/r messages. I am not concerned about the mapping as much - yet - but more so am interested in establishing the proper message flow.
In case 1 we:
- receive c/r from C1
- send back a pending cr to C1
- send an out to C1 via tag 39=5 on an exec rpt
- send an exec rpt with 39=0 for new order
In case 2 we:
- recevie c/r from C2
- send back a pending cr to C2
- send an out to C2 via tag 39=5 on an exec rpt
As you can see in case 1 we are forced to send an extra exec rpt with 39=0 as a new order.
Can anyone tell me that "proper" sequence of messages - should I be required to send a new order (as in case 1) to get my CR to work properly??
Thanks for your help
Your case 2 is correct, you dont need the extra 39=0. the 39=5 implies that the order sent in the cancel/replace is now active and all subsequent execution reports sent back will reference the new client order id sent with the cancel/replace. also, if you are using 4.2 and sending back to 4.0, be careful with your tag 39 for the replace pending. FIX 4.2 states that cancel pending uses 39=E whereas all prior versions use 39=6 (used for both cancel pending and replace pending). the party using 4.0 will be expecting 39=6.
> I have a situation whereby I am getting orders from a client using fix 4.0 sending to a gateway that maps 4.0 to 4.2. I am using fix 4.2 and am on the receiving end of the order flow.
>
> I would like to get some help in understanding the proper flow of messages for a c/r messages. I am not concerned about the mapping as much - yet - but more so am interested in establishing the proper message flow.
>
>
> In case 1 we:
> 1. receive c/r from C1
> 2. send back a pending cr to C1
> 3. send an out to C1 via tag 39=5 on an exec rpt
> 4. send an exec rpt with 39=0 for new order
>
> In case 2 we:
> 1. recevie c/r from C2
> 2. send back a pending cr to C2
> 3. send an out to C2 via tag 39=5 on an exec rpt
>
> As you can see in case 1 we are forced to send an extra exec rpt with 39=0 as a new order.
>
> Can anyone tell me that "proper" sequence of messages - should I be required to send a new order (as in case 1) to get my CR to work properly??
>
> Thanks for your help
>
>
>
Sorry…i meant fix 4.2 uses 39=E for replace pending (not cancel pending). cancel pending is still 39=6
> Your case 2 is correct, you dont need the extra 39=0. the 39=5 implies that the order sent in the cancel/replace is now active and all subsequent execution reports sent back will reference the new client order id sent with the cancel/replace. also, if you are using 4.2 and sending back to 4.0, be careful with your tag 39 for the replace pending. FIX 4.2 states that cancel pending uses 39=E whereas all prior versions use 39=6 (used for both cancel pending and replace pending). the party using 4.0 will be expecting 39=6.
>
>
> > I have a situation whereby I am getting orders from a client using fix 4.0 sending to a gateway that maps 4.0 to 4.2. I am using fix 4.2 and am on the receiving end of the order flow.
> >
> > I would like to get some help in understanding the proper flow of messages for a c/r messages. I am not concerned about the mapping as much - yet - but more so am interested in establishing the proper message flow.
> >
> >
> > In case 1 we:
> > 1. receive c/r from C1
> > 2. send back a pending cr to C1
> > 3. send an out to C1 via tag 39=5 on an exec rpt
> > 4. send an exec rpt with 39=0 for new order
> >
> > In case 2 we:
> > 1. recevie c/r from C2
> > 2. send back a pending cr to C2
> > 3. send an out to C2 via tag 39=5 on an exec rpt
> >
> > As you can see in case 1 we are forced to send an extra exec rpt with 39=0 as a new order.
> >
> > Can anyone tell me that "proper" sequence of messages - should I be required to send a new order (as in case 1) to get my CR to work properly??
> >
> > Thanks for your help
> >
> >
> >
>