C++ API Help for Laser (Genesis)

If anyone has experience coding in C++ for Laser, I'd really appreciate it if you could let me know. I'm having some minor issues with my code and have not had luck working out the bugs.

Any help would be great.
 
I think it's a fairly Laser-specific problem. When I cancel & replace an order, it goes so fast that occasionally the cancel hasn't finished before the next order goes out. This causes it to go out to the wrong price if the old order turned into the best bid or offer.

I have tried looking at the pendings, but the same thing happens with this. I need it to confirm that the previous order has indeed been confirmed cancelled before a new one is placed.
 
Have you tried waiting for the server to send you a "Cancel confirmed" message for the order you are trying to cancel before sending your replacement order out?
 
giggollo is right, usually you wait for a confirmation before palcing the new order. Some APIs do have a "change order" function.
 
Sounds to me like they're not sending a cancel replace order, but rather a cancel and then a new order.

If you use cancel replace, all the information [the new order and the info on the order to cancel] go in a single message.



Here's some info from NYFIX Fixionary:


The order cancel/replace request is used to change the parameters of an existing order.

Do not use this message to cancel the remaining quantity of an outstanding order, use the Cancel Request message for this purpose.

Cancel/Replace will be used to change any valid attribute of an open order (i.e. reduce/increase quantity, change limit price, change instructions, etc.) It can be used to re-open a filled order by increasing OrderQty.

An immediate response to this message is required. It is recommended that an ExecutionRpt with ExecType=Pending Replace be sent unless the Order Cancel/Replace Request can be immediately accepted (ExecutionRpt with ExecType=Replaced) or rejected (Order Cancel Reject message).

The Cancel/Replace request will only be accepted if the order can successfully be pulled back from the exchange floor without executing. Requests which cannot be processed will be rejected using the Cancel Reject message. The Cancel Reject message should provide the ClOrdID and OrigClOrdID values which were specified on the Cancel/Replace Request message for identification.
Note that while it is necessary for the ClOrdID to change and be unique, the broker's OrderID field does not necessarily have to change as a result of the Cancel/Replace request.

Only a limited number of fields can be changed via the cancel/replace request message. All other fields should be retransmitted as sent in the original order. The fields which can be changed via this message are:

ExecInst
OrderQty
OrdType
Price
HandlInst
TimeInForce
TradingSessionID
EffectiveTime ExpireDate
ExpireTime
MinQty
MaxFloor
StopPx
PegDifference
DiscretionInst
DiscretionOffset
CashOrderQty OrderQty2
OpenClose
CoveredOrUncovered
Side (i.e. sell to sell plus)
MaxShow
LocateReqd

When modifying ExecInst fields in a replacement order, it is necessary to re-declare all ExecInst in the replacement order. ExecInst's will not be carried forward from the original order to the replacement unless re-declared.
http://fixionary.com/
 
Yeas - unless using FIX - you send a separate cancel order followed by a new order. I put the new orders and cancels into a FIFO queue, implemented for each symbol. It only processes the front item in the queue, and only removes the front item when the order is confirmed as pending, or as cancelled.

Then you can also handle rapid fire situations like this:

(Front of queue)
1. Cancel sell PCLN 100.00 - cancel sent, waiting for confirm
2. Add sell PCLN 99.95
3. Cancel sell PCLN 99.95 - when my app sends this, can remove both 2 & 3
(Back of queue)
 
Quote from promagma:

Yeas - unless using FIX - you send a separate cancel order followed by a new order. I put the new orders and cancels into a FIFO queue, implemented for each symbol. It only processes the front item in the queue, and only removes the front item when the order is confirmed as pending, or as cancelled.

Then you can also handle rapid fire situations like this:

(Front of queue)
1. Cancel sell PCLN 100.00 - cancel sent, waiting for confirm
2. Add sell PCLN 99.95
3. Cancel sell PCLN 99.95 - when my app sends this, can remove both 2 & 3
(Back of queue)

Hmm that's true, I've never noticed that NASDAQ's protocols have no cancel replace...
 
Yes, I am cancelling, and then sending a new order. I think I've got the cancels under control now, but I don't think its really the proper way to do it. Thanks for the help guys.

I will probably have a few more minor issues that I will post here over the next few weeks. Help is always appreciated!
 
Quote from LSEtrader:

I think it's a fairly Laser-specific problem. When I cancel & replace an order, it goes so fast that occasionally the cancel hasn't finished before the next order goes out. This causes it to go out to the wrong price if the old order turned into the best bid or offer.

I have tried looking at the pendings, but the same thing happens with this. I need it to confirm that the previous order has indeed been confirmed cancelled before a new one is placed.


do you still need help with this because I can help you. The problem here is that you are not including all the information correctly when sending the order. The C++ Laser API is extremely picky and you need to have everything specified and correct in order for it to work. If you post the code I'll be able to tell you what you need to add / change etc
 
Back
Top