Imported from previous forum
Hey all,
What message would I send in response to a OrderMassStatusRequest when the request has an empty result. I saw a RequestForPositionsAck that is usable for this means on PositionReport batch requests but I did not see anything similiar yet for OrderMassStatusRequest/ExecutionReports.
any insight? thanks
-Andre
It says in the fix spec to reply with an execution report, but if the reply has no orders in it what would i use? I was thinking of using an execution report and setting the TotNumReports field equal to 0, but I would not have any of the other mandatory fields because it would not really be an order at this point it would be more like a ack reply.
Should I use Business Message Reject?
Hey all,
What message would I send in response to a OrderMassStatusRequest when
the request has an empty result. I saw a RequestForPositionsAck that is
usable for this means on PositionReport batch requests but I did not see
anything similiar yet for OrderMassStatusRequest/ExecutionReports.any insight? thanks -Andre
Well nothing like a delay 5 years too late - apologies Andre.
Mikael of NGM and Hanno Klein have both pointed out the missing features and inconsistencies across queries / subscriptions within FIX. The issue with OrderMassStatusRequest remains as of SP2.
My proposal for FIX.5.0SP2 and earlier following Andre’s suggestion for a response to OrderMassStatusRequest where no orders are returned that meet the criteria is to use the ExecutionReport:
…
MsgType[35]=8
…
OrderID[37]=NONE
MassStatusReqID[584]=(value specified on request)
TotNumReports[911]=0
LastRptRequested[912]=Y
ExecID[17]=0
ExecType[150]=I (OrderStatus)
OrderType[39]=0 (New)
55=[N/A] ** Instrument block is required field so use the official empty value**
54=7 (Undisclosed) ** unfortunately a required field - would listen to any reasonable alternative **
LeavesQty[151]=0 ** required **
CumQty[14]=0 ** required **
AvgPx[6]=0 ** required **
It isn’t pretty but: 1) It is simple 2) consistent with the use of Execution Report (the work horse or “jack of all trades” for orders or “jack of all orders” for trades).
Actually the more I think about this - it ain’t that bad - in fact it seems straight forward and understandable.
Shouldn’t the OrdStatus (39) of the Execution Report be Rejected (8)?
Well nothing like a delay 5 years too late - apologies Andre.
Mikael of NGM and Hanno Klein have both pointed out the missing features and inconsistencies across queries / subscriptions within FIX. The issue with OrderMassStatusRequest remains as of SP2.My proposal for FIX.5.0SP2 and earlier following Andre’s suggestion for a response to OrderMassStatusRequest where no orders are returned that meet the criteria is to use the ExecutionReport:
…
MsgType[35]=8
…
OrderID[37]=NONE
MassStatusReqID[584]=(value specified on request)
TotNumReports[911]=0
LastRptRequested[912]=Y
ExecID[17]=0
ExecType[150]=I (OrderStatus)
OrderType[39]=0 (New)
55=[N/A] ** Instrument block is required field so use the official empty value**
54=7 (Undisclosed) ** unfortunately a required field - would listen to any reasonable alternative **
LeavesQty[151]=0 ** required **
CumQty[14]=0 ** required **
AvgPx[6]=0 ** required **It isn’t pretty but: 1) It is simple 2) consistent with the use of Execution Report (the work horse or “jack of all trades” for orders or “jack of all orders” for trades).
Actually the more I think about this - it ain’t that bad - in fact it seems straight forward and understandable.
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.
Jim - An Execution Report with an OrdStatus of Rejected is the expected response to an Order Status Request for an unknown ClOrdID. I was wondering whether the same should be the case for a Mass Order Status Request where no orders match the specified criteria. In both cases no orders match the specified criteria (ClOrdID in the case of the Order Status Request, one or more criteria in the case of the Mass Order Status Request).
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.
Lalin - that is a very interesting argument and a worthwhile point to raise. I think the counter argument to your point is that OrderStatusRequest looking for a specific order and that order is not found would be a reason to reject the request. However, in the case of OrderMassStatusRequest if there are no orders - I am not sure that request has been rejected as invalid - there were simply no orders - you are not looking for a specific order. However, I can see validity and justification in own both cases. You could an the argument that setting the status to Rejected would be consistent with OrderStatusRequest for order not found. However, I still keep coming back to the fact - if you don’t know the status of your orders, say you have had a catastrophic failure and need to start a new FIX session, you send in a request and find you have no orders - this is a valid response - the response is not rejected - it is satisfied by reporting that there are zero orders.
Jim - An Execution Report with an OrdStatus of Rejected is the expected response to an Order Status Request for an unknown ClOrdID. I was wondering whether the same should be the case for a Mass Order Status Request where no orders match the specified criteria. In both cases no orders match the specified criteria (ClOrdID in the case of the Order Status Request, one or more criteria in the case of the Mass Order Status Request).
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.
Going forward I agree with you Aaron and think you are correct as we are:
-
Planning on deprecating the OrderMassCancelRequest/OrderMassCancelReport using the OrderMassActionRequest/OrderMassActionReport instead.
-
We decided it was important not to include status as one of the OrderMassActions - meaning that we are keeping the OrderMassStatusRequest.
As you say we should add an OrderMassStatusReport. This point was raised I believe by Mikael of NGM on one of the GExMC calls.
But for FIX.5.0SP2 and earlier where this is not possible - I think the ExecutionReport approach is a reasonable solution.
Sounds familiar…
IMHO the 35=AF needs a paired 35=AF-ack response message with a field similar to tag 750(TradeRequestStatus)so that this scenario (valid request with no business data to return) can be catered for elegantly by responding with the 35=AF-ack and a status of e.g. 0=nothing to return, with some other valid states eg 1=accepted expect data to follow, 2=rejected etc etc.
The 35=8 solution would get you through as would using a 35=AQ for the ack, although both need some finessing…
Lalin - that is a very interesting argument and a worthwhile point to raise. I think the counter argument to your point is that OrderStatusRequest looking for a specific order and that order is not found would be a reason to reject the request. However, in the case of OrderMassStatusRequest if there are no orders - I am not sure that request has been rejected as invalid - there were simply no orders - you are not looking for a specific order. However, I can see validity and justification in own both cases. You could an the argument that setting the status to Rejected would be consistent with OrderStatusRequest for order not found. However, I still keep coming back to the fact - if you don’t know the status of your orders, say you have had a catastrophic failure and need to start a new FIX session, you send in a request and find you have no orders - this is a valid response - the response is not rejected - it is satisfied by reporting that there are zero orders.
Jim - An Execution Report with an OrdStatus of Rejected is the expected response to an Order Status Request for an unknown ClOrdID. I was wondering whether the same should be the case for a Mass Order Status Request where no orders match the specified criteria. In both cases no orders match the specified criteria (ClOrdID in the case of the Order Status Request, one or more criteria in the case of the Mass Order Status Request).
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.
I concur and support the way forward after SP2 as described by Jim. I also think we should live with what we have for OrderStatusRequest. I can understand Lalin’s argument and am aware of similar discussions within our organization. A request to find an order is valid even if the order cannot be found. On the other hand the request is not honored and the rejection refers to the requested action (get me information for this order) which is denied. Rejection means that there is no difference whether you had sent the request or not. Fields such as XXXRequestResult and XXXRequestStatus are more flexible to handle rejections, empty result sets, unauthorized requests etc.
Going forward I agree with you Aaron and think you are correct as we are:
Planning on deprecating the OrderMassCancelRequest/OrderMassCancelReport using the OrderMassActionRequest/OrderMassActionReport instead.
We decided it was important not to include status as one of the OrderMassActions - meaning that we are keeping the OrderMassStatusRequest.
As you say we should add an OrderMassStatusReport. This point was raised I believe by Mikael of NGM on one of the GExMC calls.
But for FIX.5.0SP2 and earlier where this is not possible - I think the ExecutionReport approach is a reasonable solution.
Sounds familiar…
IMHO the 35=AF needs a paired 35=AF-ack response message with a field similar to tag 750(TradeRequestStatus)so that this scenario (valid request with no business data to return) can be catered for elegantly by responding with the 35=AF-ack and a status of e.g. 0=nothing to return, with some other valid states eg 1=accepted expect data to follow, 2=rejected etc etc.
The 35=8 solution would get you through as would using a 35=AQ for the ack, although both need some finessing…
Lalin - that is a very interesting argument and a worthwhile point to raise. I think the counter argument to your point is that OrderStatusRequest looking for a specific order and that order is not found would be a reason to reject the request. However, in the case of OrderMassStatusRequest if there are no orders - I am not sure that request has been rejected as invalid - there were simply no orders - you are not looking for a specific order. However, I can see validity and justification in own both cases. You could an the argument that setting the status to Rejected would be consistent with OrderStatusRequest for order not found. However, I still keep coming back to the fact - if you don’t know the status of your orders, say you have had a catastrophic failure and need to start a new FIX session, you send in a request and find you have no orders - this is a valid response - the response is not rejected - it is satisfied by reporting that there are zero orders.
Jim - An Execution Report with an OrdStatus of Rejected is the expected response to an Order Status Request for an unknown ClOrdID. I was wondering whether the same should be the case for a Mass Order Status Request where no orders match the specified criteria. In both cases no orders match the specified criteria (ClOrdID in the case of the Order Status Request, one or more criteria in the case of the Mass Order Status Request).
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.
Hanno, Can you confirm that this problem is going to be addressed in SP3?
Thanks!
I concur and support the way forward after SP2 as described by Jim. I also think we should live with what we have for OrderStatusRequest. I can understand Lalin’s argument and am aware of similar discussions within our organization. A request to find an order is valid even if the order cannot be found. On the other hand the request is not honored and the rejection refers to the requested action (get me information for this order) which is denied. Rejection means that there is no difference whether you had sent the request or not. Fields such as XXXRequestResult and XXXRequestStatus are more flexible to handle rejections, empty result sets, unauthorized requests etc.
Going forward I agree with you Aaron and think you are correct as we are:
Planning on deprecating the OrderMassCancelRequest/OrderMassCancelReport using the OrderMassActionRequest/OrderMassActionReport instead.
We decided it was important not to include status as one of the OrderMassActions - meaning that we are keeping the OrderMassStatusRequest.
As you say we should add an OrderMassStatusReport. This point was raised I believe by Mikael of NGM on one of the GExMC calls.
But for FIX.5.0SP2 and earlier where this is not possible - I think the ExecutionReport approach is a reasonable solution.
Sounds familiar…
IMHO the 35=AF needs a paired 35=AF-ack response message with a field similar to tag 750(TradeRequestStatus)so that this scenario (valid request with no business data to return) can be catered for elegantly by responding with the 35=AF-ack and a status of e.g. 0=nothing to return, with some other valid states eg 1=accepted expect data to follow, 2=rejected etc etc.
The 35=8 solution would get you through as would using a 35=AQ for the ack, although both need some finessing…
Lalin - that is a very interesting argument and a worthwhile point to raise. I think the counter argument to your point is that OrderStatusRequest looking for a specific order and that order is not found would be a reason to reject the request. However, in the case of OrderMassStatusRequest if there are no orders - I am not sure that request has been rejected as invalid - there were simply no orders - you are not looking for a specific order. However, I can see validity and justification in own both cases. You could an the argument that setting the status to Rejected would be consistent with OrderStatusRequest for order not found. However, I still keep coming back to the fact - if you don’t know the status of your orders, say you have had a catastrophic failure and need to start a new FIX session, you send in a request and find you have no orders - this is a valid response - the response is not rejected - it is satisfied by reporting that there are zero orders.
Jim - An Execution Report with an OrdStatus of Rejected is the expected response to an Order Status Request for an unknown ClOrdID. I was wondering whether the same should be the case for a Mass Order Status Request where no orders match the specified criteria. In both cases no orders match the specified criteria (ClOrdID in the case of the Order Status Request, one or more criteria in the case of the Mass Order Status Request).
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.
Yes, subscriptions and snapshots (outside of market data) are being analyzed and the idea is to add an Extension Pack to SP2 which would then automatically be rolled into SP3. Once drafted, it will likely be discussed in the Global Exchanges & Markets Committee first. Look out for a posting in the section PROPOSALS but I believe it is still a few weeks away.
Hanno, Can you confirm that this problem is going to be addressed in SP3?
Thanks!
I concur and support the way forward after SP2 as described by Jim. I also think we should live with what we have for OrderStatusRequest. I can understand Lalin’s argument and am aware of similar discussions within our organization. A request to find an order is valid even if the order cannot be found. On the other hand the request is not honored and the rejection refers to the requested action (get me information for this order) which is denied. Rejection means that there is no difference whether you had sent the request or not. Fields such as XXXRequestResult and XXXRequestStatus are more flexible to handle rejections, empty result sets, unauthorized requests etc.
Going forward I agree with you Aaron and think you are correct as we are:
Planning on deprecating the OrderMassCancelRequest/OrderMassCancelReport using the OrderMassActionRequest/OrderMassActionReport instead.
We decided it was important not to include status as one of the OrderMassActions - meaning that we are keeping the OrderMassStatusRequest.
As you say we should add an OrderMassStatusReport. This point was raised I believe by Mikael of NGM on one of the GExMC calls.
But for FIX.5.0SP2 and earlier where this is not possible - I think the ExecutionReport approach is a reasonable solution.
Sounds familiar…
IMHO the 35=AF needs a paired 35=AF-ack response message with a field similar to tag 750(TradeRequestStatus)so that this scenario (valid request with no business data to return) can be catered for elegantly by responding with the 35=AF-ack and a status of e.g. 0=nothing to return, with some other valid states eg 1=accepted expect data to follow, 2=rejected etc etc.
The 35=8 solution would get you through as would using a 35=AQ for the ack, although both need some finessing…
Lalin - that is a very interesting argument and a worthwhile point to raise. I think the counter argument to your point is that OrderStatusRequest looking for a specific order and that order is not found would be a reason to reject the request. However, in the case of OrderMassStatusRequest if there are no orders - I am not sure that request has been rejected as invalid - there were simply no orders - you are not looking for a specific order. However, I can see validity and justification in own both cases. You could an the argument that setting the status to Rejected would be consistent with OrderStatusRequest for order not found. However, I still keep coming back to the fact - if you don’t know the status of your orders, say you have had a catastrophic failure and need to start a new FIX session, you send in a request and find you have no orders - this is a valid response - the response is not rejected - it is satisfied by reporting that there are zero orders.
Jim - An Execution Report with an OrdStatus of Rejected is the expected response to an Order Status Request for an unknown ClOrdID. I was wondering whether the same should be the case for a Mass Order Status Request where no orders match the specified criteria. In both cases no orders match the specified criteria (ClOrdID in the case of the Order Status Request, one or more criteria in the case of the Mass Order Status Request).
Lalin - I thought about that. If the submission of an OrderMassStatusRequest reveals there are no orders that match the criteria of the request - that is a valid response. If it were an invalid request - then an OrdStatus of rejected would be appropriate.
I do admit that putting OrdStatus=0 (New) doesn’t quite seem correct (justification was this was a new request). However, Rejected seems to be less correct in this case.
Would be interesting to get some additional viewpoints on this.