FIX Support » Order change from limit to market rejected Sep 02, 2014 @ 09:35 AM (Total replies: 2) | |||||
Hi Vitaliy, Thank you for the clarification. I think you should update the FIX documentation (dated August 08, 2013) as on page 33 it shows an example of a Limit order being successfully replaced by a market order. The example is titled : Multi-leg Futures with Replace Here are the relevant messages from the example. vic 138 NewOrderSingle Account: VIC05, ClOrdID: 635114266629771870, OrderQty: 10, OrdType: LIMIT, Price: -10000, Side: BUY, Symbol: ES FTS -U3,+Z3, TransactTime: 20130806-22:57:42, CFICode: FMXXXN vic 139 OrderCancelReplaceRequest Account: VIC05, ClOrdID: 635114266633047870, OrderQty: 1, OrdType: MARKET, OrigClOrdID: 635114266629771870, Side: BUY, Symbol: ES FTS -U3,+Z3, TransactTime: 20130806-22:57:43, CFICode: FMXXXN OEC_TEST 138 ExecutionReport Account: VIC05, AvgPx: 0.00, ClOrdID: 635114266633047870, CumQty: 0, ExecID: OECFIX:635114265775047870:3, OrderID: 2014876, OrderQty: 1, OrdStatus: NEW, OrigClOrdID: 635114266629771870, Side: BUY, Symbol: ES FTS -U3,+Z3, TransactTime: 20130806-22:57:43, ExecType: REPLACED, LeavesQty: 1, SecondaryOrderID: 2014877, MultiLegReportingType: MULTILEG, CFICode: FMXXXN Michael Hall |
|||||
FIX Support » Order change from limit to market rejected Sep 02, 2014 @ 05:40 AM (Total replies: 2) | |||||
The FIX order server is rejecting a change of a limit order to a market order. Error message is "Unsupported change. Field: Type". Shouldn't the server allow limit orders to be changed to market orders? Thanks, Michael. Michael Hall |
|||||
FIX Support » Logout message in response to a Logon message May 21, 2014 @ 12:50 PM (Total replies: 1) | |||||
After a possible disconnection from the OEC FIX server, OEC server keeps sending a Logout message in response to a Logon message. What do you need in the Logon message to log me on ? FIX message history below (Password masked) I send a heartbeat: 8=FIX.4.4 9=58 35=0 34=1575 49=MHall9108 52=20140521-16:14:15.608 56=OEC 10=240 No response from OEC server so I send another one: 8=FIX.4.4 9=58 35=0 34=1576 49=MHall9108 52=20140521-16:14:45.886 56=OEC 10=252 No response to that so time for a test request message: 8=FIX.4.4 9=67 35=1 34=1577 49=MHall9108 52=20140521-16:15:00.887 56=OEC 112=TEST 10=009 Perhaps I’ve been logged off so I send a Logon message: 8=FIX.4.4 9=134 35=A 34=1 49=MHall9108 52=20140521-16:15:28.890 56=OEC 98=0 554=password 12003=b 98=0 108=30 141=Y 10=063 And some more: 8=FIX.4.4 9=134 35=A 34=1 49=MHall9108 52=20140521-16:16:00.891 56=OEC 98=0 554=password 12003=b 98=0 108=30 141=Y 10=055 until OEC responds with a Logout message: 8=FIX.4.4 9=51 35=5 34=1 49=OEC 52=20140521-16:25:15 56=MHall9108 10=131 So I try to Logon again: 8=FIX.4.4 9=134 35=A 34=1 49=MHall9108 52=20140521-16:25:17.688 56=OEC 98=0 554=password 12003=b 98=0 108=30 141=Y 10=067 And OEC Logs me out again. 8=FIX.4.4 9=51 35=5 34=1 49=OEC 52=20140521-16:25:17 56=MHall9108 10=133 This continues until I kill the process. Michael Hall |
|||||
FIX Support » OEC FIX/FAST Price Server May 20, 2014 @ 06:40 AM (Total replies: 1) | |||||
Hi, What are the connection parameters of the OEC FIX/FAST Price Server? The latest fix api documentation pdf I have (dated August 08, 2013) says that the demo and the production servers are: Demo environment: sim.openecry.com, port 9301 (NOT ESTABLISHED YET) Production environment: prod.openecry.com, port 9301 (NOT ESTABLISHED YET) Have these been setup ? Thanks, Michael. Michael Hall |
|||||
FIX Support » Market Data for exchange traded spreads from FIX/FAST price server Apr 28, 2014 @ 06:07 AM (Total replies: 1) | |||||
When will the price server have market data for ETS? i.e. for spreads like "ZW FTS +N4,-N5". Thank you. Michael Hall |
|||||
FIX Support » Execution Report cancelled format change request Feb 18, 2014 @ 10:45 AM (Total replies: 1) | |||||
When the FIX server sends an execution report with a status of cancelled it puts the OrigClOrdID in a custom tag 12073 and puts text like "OECFIX:81158285" in the ClOrdID field. This causes Quickfix to throw a number format exception. ClOrdID is short for Client Order ID and should relate to info sent from the client, not random stuff put in by the server (that's what the custom tags are for). Can you change this so the ClOrdID is the Order ID that the client sent and put your custom stuff in the custom tags? FIX message 8=FIX.4.49=28635=834=349=OEC52=20140218-15:03:2056=MHall910897=Y1=E139126=0.000011=OECFIX:8115828514=017=OECFIX:635281848073008860:336337=8115781938=139=441=140218143901000144=0.79554=255=CT-M60=20140218-14:41:39150=4151=1200=201503325=Y377=N461=FXXXXS12073=140218143901000110=027 Michael Hall |
|||||
FIX Support » Test Request message from FIX server when logged on. Jan 31, 2014 @ 04:15 AM (Total replies: 1) | |||||
In the middle of a session, with heartbeats being exchanged the FIX Server sends a Test Message which prompts QuickFix to attempt to logon again. Why does the FIX server send a Test message when it's receiving heartbeats from the client? Should I ignore these when I'm logged on or attempt to logon again? Client heatbeat interval = 15 seconds. P.S. Can you check the clock time on the FIX server as it differs from mine by about 2 minutes and I've set my time based on the time.gov clocks. FIX messages: 8=FIX.4.49=6235=034=82849=OEC_TEST52=20140130-17:02:56.16656=MHall400110=075 8=FIX.4.49=6235=034=61949=MHall400152=20140130-17:02:58.36556=OEC_TEST10=076 8=FIX.4.49=6235=034=82949=OEC_TEST52=20140130-17:03:11.37656=MHall400110=071 8=FIX.4.49=6235=034=62049=MHall400152=20140130-17:03:13.36556=OEC_TEST10=060 8=FIX.4.49=6235=034=83049=OEC_TEST52=20140130-17:03:26.58656=MHall400110=072 8=FIX.4.49=6235=034=62149=MHall400152=20140130-17:03:28.36556=OEC_TEST10=067 8=FIX.4.49=7135=134=83149=OEC_TEST52=20140130-17:03:40.78256=MHall4001112=TEST10=086 8=FIX.4.49=7135=034=62249=MHall400152=20140130-17:03:31.46256=OEC_TEST112=TEST10=078 8=FIX.4.49=6235=034=62349=MHall400152=20140130-17:03:47.36556=OEC_TEST10=070 8=FIX.4.49=14235=A34=149=MHall400152=20140130-17:03:49.37256=OEC_TEST98=0554=XXXXXX12003=1b31ef57-8d6c-4c5e-9fb0-9424a396eac698=0108=15141=Y10=011 8=FIX.4.49=34135=A34=149=OEC_TEST52=20140130-17:03:58.92556=MHall400198=0108=15141=Y Michael Hall |
|||||
FIX Support » Lost order Jan 30, 2014 @ 08:08 AM (Total replies: 0) | |||||
The FIX server "lost" a message sent to it yesterday. My app sent an Order cancel replace request (see FIX messages below) and received an Execution report with status E (PENDING REPLACE) . There was no further Execution report indicating whether the order had been accepted or rejected. Heartbeats were exchanged indicating the server was still up. Is this usual? Am I doing anything wrong? FIX messages: 8=FIX.4.49=6235=034=43949=MHall400152=20140129-19:09:43.91256=OEC_TEST10=085 8=FIX.4.49=19435=G34=44049=MHall400152=20140129-19:09:48.91456=OEC_TEST1=API00221811=140129184242039338=140=241=140129184242039244=0.772754=155=CT-M60=20140129-18:42:59.321200=201503461=FXXXXS10=131 8=FIX.4.49=26335=834=85549=OEC_TEST52=20140129-19:09:57.97656=MHall40011=API0022186=0.000011=140129184242039314=017=OECFIX:635263704071647625:425437=20289127238=139=E41=140129184242039244=0.761654=155=CT-M60=20140129-19:09:57150=E151=1200=201503461=FXXXXS10=039 8=FIX.4.49=6235=034=85649=OEC_TEST52=20140129-19:10:12.70256=MHall400110=073 8=FIX.4.49=6235=034=44149=MHall400152=20140129-19:10:04.91256=OEC_TEST10=067 8=FIX.4.49=6235=034=85749=OEC_TEST52=20140129-19:10:27.91256=MHall400110=083 8=FIX.4.49=6235=034=44249=MHall400152=20140129-19:10:19.91256=OEC_TEST10=074 8=FIX.4.49=6235=034=85849=OEC_TEST52=20140129-19:10:42.10856=MHall400110=078 8=FIX.4.49=6235=034=44349=MHall400152=20140129-19:10:34.91256=OEC_TEST10=072 8=FIX.4.49=6235=034=85949=OEC_TEST52=20140129-19:10:57.31856=MHall400110=088 8=FIX.4.49=6235=034=44449=MHall400152=20140129-19:10:49.91256=OEC_TEST10=079 8=FIX.4.49=6235=034=86049=OEC_TEST52=20140129-19:11:12.52956=MHall400110=076 8=FIX.4.49=6235=034=44549=MHall400152=20140129-19:11:04.91256=OEC_TEST10=072 8=FIX.4.49=6235=034=86149=OEC_TEST52=20140129-19:11:27.73956=MHall400110=086 8=FIX.4.49=6235=034=44649=MHall400152=20140129-19:11:19.91356=OEC_TEST10=080 8=FIX.4.49=6235=034=86249=OEC_TEST52=20140129-19:11:42.94956=MHall400110=087 8=FIX.4.49=6235=034=44749=MHall400152=20140129-19:11:34.91356=OEC_TEST10=078 8=FIX.4.49=6235=034=86349=OEC_TEST52=20140129-19:11:57.14556=MHall400110=082 8=FIX.4.49=6235=034=44849=MHall400152=20140129-19:11:49.91356=OEC_TEST10=085 8=FIX.4.49=6235=034=86449=OEC_TEST52=20140129-19:12:12.35556=MHall400110=078 8=FIX.4.49=6235=034=44949=MHall400152=20140129-19:12:04.91456=OEC_TEST10=079 8=FIX.4.49=6235=034=86549=OEC_TEST52=20140129-19:12:27.56556=MHall400110=088 8=FIX.4.49=6235=034=45049=MHall400152=20140129-19:12:20.91456=OEC_TEST10=069 8=FIX.4.49=6235=034=86649=OEC_TEST52=20140129-19:12:42.77656=MHall400110=090 8=FIX.4.49=6235=034=45149=MHall400152=20140129-19:12:36.91356=OEC_TEST10=076 8=FIX.4.49=6235=034=86749=OEC_TEST52=20140129-19:12:57.98656=MHall400110=100 8=FIX.4.49=6235=034=45249=MHall400152=20140129-19:12:51.91456=OEC_TEST10=075 8=FIX.4.49=6235=034=86849=OEC_TEST52=20140129-19:13:12.18256=MHall400110=081 8=FIX.4.49=6235=034=45349=MHall400152=20140129-19:13:06.91456=OEC_TEST10=077 8=FIX.4.49=6235=034=86949=OEC_TEST52=20140129-19:13:27.39256=MHall400110=091 8=FIX.4.49=6235=034=45449=MHall400152=20140129-19:13:21.91456=OEC_TEST10=075 8=FIX.4.49=6235=034=87049=OEC_TEST52=20140129-19:13:42.60356=MHall400110=075 8=FIX.4.49=6235=034=45549=MHall400152=20140129-19:13:36.91556=OEC_TEST10=083 8=FIX.4.49=6235=034=87149=OEC_TEST52=20140129-19:13:57.81356=MHall400110=085 8=FIX.4.49=6235=034=45649=MHall400152=20140129-19:13:51.91556=OEC_TEST10=081 8=FIX.4.49=6235=034=87249=OEC_TEST52=20140129-19:14:12.00956=MHall400110=075 8=FIX.4.49=6235=034=45749=MHall400152=20140129-19:14:06.91556=OEC_TEST10=083 8=FIX.4.49=6235=034=87349=OEC_TEST52=20140129-19:14:27.21956=MHall400110=085 8=FIX.4.49=6235=034=45849=MHall400152=20140129-19:14:21.91556=OEC_TEST10=081 8=FIX.4.49=6235=034=87449=OEC_TEST52=20140129-19:14:42.42956=MHall400110=086 8=FIX.4.49=6235=034=45949=MHall400152=20140129-19:14:36.91556=OEC_TEST10=088 8=FIX.4.49=6235=034=87549=OEC_TEST52=20140129-19:14:57.63956=MHall400110=096 8=FIX.4.49=6235=034=46049=MHall400152=20140129-19:14:51.91656=OEC_TEST10=078 8=FIX.4.49=6235=034=87649=OEC_TEST52=20140129-19:15:12.84956=MHall400110=092 8=FIX.4.49=6235=034=46149=MHall400152=20140129-19:15:06.91656=OEC_TEST10=080 8=FIX.4.49=6235=034=87749=OEC_TEST52=20140129-19:15:27.04556=MHall400110=087 8=FIX.4.49=6235=034=46249=MHall400152=20140129-19:15:21.91656=OEC_TEST10=078 8=FIX.4.49=6235=034=87849=OEC_TEST52=20140129-19:15:42.25556=MHall400110=088 8=FIX.4.49=6235=034=46349=MHall400152=20140129-19:15:36.91756=OEC_TEST10=086 8=FIX.4.49=6235=034=87949=OEC_TEST52=20140129-19:15:57.46556=MHall400110=098 8=FIX.4.49=6235=034=46449=MHall400152=20140129-19:15:51.91756=OEC_TEST10=084 8=FIX.4.49=6235=034=88049=OEC_TEST52=20140129-19:16:12.67656=MHall400110=086 8=FIX.4.49=6235=034=46549=MHall400152=20140129-19:16:07.91756=OEC_TEST10=087 8=FIX.4.49=6235=034=88149=OEC_TEST52=20140129-19:16:27.89056=MHall400110=091 8=FIX.4.49=6235=034=46649=MHall400152=20140129-19:16:22.91756=OEC_TEST10=085 8=FIX.4.49=6235=034=88249=OEC_TEST52=20140129-19:16:42.10156=MHall400110=074 8=FIX.4.49=6235=034=46749=MHall400152=20140129-19:16:37.91756=OEC_TEST10=092 8=FIX.4.49=6235=034=88349=OEC_TEST52=20140129-19:16:57.31156=MHall400110=084 8=FIX.4.49=6235=034=46849=MHall400152=20140129-19:16:52.91756=OEC_TEST10=090 8=FIX.4.49=6235=034=88449=OEC_TEST52=20140129-19:17:12.52156=MHall400110=080 8=FIX.4.49=6235=034=46949=MHall400152=20140129-19:17:07.91856=OEC_TEST10=093 8=FIX.4.49=6235=034=88549=OEC_TEST52=20140129-19:17:27.73256=MHall400110=091 8=FIX.4.49=6235=034=47049=MHall400152=20140129-19:17:22.91856=OEC_TEST10=082 8=FIX.4.49=6235=034=88649=OEC_TEST52=20140129-19:17:42.94256=MHall400110=092 8=FIX.4.49=6235=034=47149=MHall400152=20140129-19:17:37.91856=OEC_TEST10=089 8=FIX.4.49=6235=034=88749=OEC_TEST52=20140129-19:17:57.13856=MHall400110=096 8=FIX.4.49=6235=034=47249=MHall400152=20140129-19:17:52.91956=OEC_TEST10=088 8=FIX.4.49=6235=034=88849=OEC_TEST52=20140129-19:18:12.34856=MHall400110=092 8=FIX.4.49=6235=034=47349=MHall400152=20140129-19:18:08.91856=OEC_TEST10=090 8=FIX.4.49=6235=034=88949=OEC_TEST52=20140129-19:18:27.55856=MHall400110=102 8=FIX.4.49=6235=034=47449=MHall400152=20140129-19:18:23.91856=OEC_TEST10=088 8=FIX.4.49=6235=034=89049=OEC_TEST52=20140129-19:18:42.76856=MHall400110=094 8=FIX.4.49=6235=034=47549=MHall400152=20140129-19:18:38.91956=OEC_TEST10=096 8=FIX.4.49=6235=034=89149=OEC_TEST52=20140129-19:18:57.97856=MHall400110=104 8=FIX.4.49=6235=034=47649=MHall400152=20140129-19:18:53.91956=OEC_TEST10=094 8=FIX.4.49=6235=034=89249=OEC_TEST52=20140129-19:19:12.17456=MHall400110=085 8=FIX.4.49=6235=034=47749=MHall400152=20140129-19:19:08.92056=OEC_TEST10=088 8=FIX.4.49=6235=034=89349=OEC_TEST52=20140129-19:19:27.38456=MHall400110=095 8=FIX.4.49=6235=034=47849=MHall400152=20140129-19:19:23.92056=OEC_TEST10=086 8=FIX.4.49=6235=034=89449=OEC_TEST52=20140129-19:19:42.59456=MHall400110=096 8=FIX.4.49=6235=034=47949=MHall400152=20140129-19:19:38.92056=OEC_TEST10=093 8=FIX.4.49=6235=034=89549=OEC_TEST52=20140129-19:19:57.80856=MHall400110=101 8=FIX.4.49=6235=034=48049=MHall400152=20140129-19:19:53.92056=OEC_TEST10=082 8=FIX.4.49=6235=034=89649=OEC_TEST52=20140129-19:20:12.00456=MHall400110=073 8=FIX.4.49=6235=034=48149=MHall400152=20140129-19:20:08.92056=OEC_TEST10=075 8=FIX.4.49=6235=034=89749=OEC_TEST52=20140129-19:20:27.21456=MHall400110=083 8=FIX.4.49=6235=034=48249=MHall400152=20140129-19:20:23.92056=OEC_TEST10=073 8=FIX.4.49=6235=034=89849=OEC_TEST52=20140129-19:20:42.42456=MHall400110=084 8=FIX.4.49=6235=034=48349=MHall400152=20140129-19:20:38.92156=OEC_TEST10=081 8=FIX.4.49=6235=034=89949=OEC_TEST52=20140129-19:20:57.63456=MHall400110=094 8=FIX.4.49=6235=034=48449=MHall400152=20140129-19:20:53.92156=OEC_TEST10=079 8=FIX.4.49=6235=034=90049=OEC_TEST52=20140129-19:21:12.84456=MHall400110=072 8=FIX.4.49=6235=034=48549=MHall400152=20140129-19:21:08.92156=OEC_TEST10=081 8=FIX.4.49=6235=034=90149=OEC_TEST52=20140129-19:21:27.04056=MHall400110=067 8=FIX.4.49=6235=034=48649=MHall400152=20140129-19:21:23.92256=OEC_TEST10=080 8=FIX.4.49=6235=034=90249=OEC_TEST52=20140129-19:21:42.25056=MHall400110=068 8=FIX.4.49=6235=034=48749=MHall400152=20140129-19:21:39.92156=OEC_TEST10=087 8=FIX.4.49=6235=034=90349=OEC_TEST52=20140129-19:21:57.46056=MHall400110=078 8=FIX.4.49=6235=034=48849=MHall400152=20140129-19:21:54.92156=OEC_TEST10=085 8=FIX.4.49=6235=034=90449=OEC_TEST52=20140129-19:22:12.67056=MHall400110=074 8=FIX.4.49=6235=034=48949=MHall400152=20140129-19:22:09.92256=OEC_TEST10=088 8=FIX.4.49=6235=034=90549=OEC_TEST52=20140129-19:22:27.88156=MHall400110=085 8=FIX.4.49=6235=034=49049=MHall400152=20140129-19:22:24.92256=OEC_TEST10=077 8=FIX.4.49=6235=034=90649=OEC_TEST52=20140129-19:22:42.07756=MHall400110=080 8=FIX.4.49=6235=034=49149=MHall400152=20140129-19:22:39.92356=OEC_TEST10=085 8=FIX.4.49=6235=034=90749=OEC_TEST52=20140129-19:22:57.28756=MHall400110=090 Michael Hall |
|||||
FIX Support » OSO leg 2 order is not executed afer leg1 filled. Jan 08, 2014 @ 10:53 AM (Total replies: 4) | |||||
Thank you for your quick response. I understand what you're saying but I still think that only the client side should update the ClOrdId (Cl stands for Client) which how it works in other circumstances. But I can work around this. Also while you're updating the documentation on OSOs you might want to change the part that says "OCO/OSO orders are sent using NewOrderList(MsgType=E) message, that's a set of orders is sent as a single message, but processing of the orders is performed for each individual order. That means, if for example, one of list orders is incorrect then all orders in the list will be rejected and for each order ExecutionReport message will be responded." Currently if the first order in the list is incorrect and is rejected the next order in the list has a status of SUSPENDED. See Fix messages below: 8=FIX.4.49=33535=E34=249=MHall400152=20140108-15:37:34.28656=OEC_TEST66=OSO Order 2 Legs68=269=OSO394=373=211=140108153721000167=11=API00221855=LE461=FXXXXS200=20141254=160=20140108-15:37:34.27638=140=244=132.17511=140108153721000267=21=API00221855=LE461=FXXXXS200=20140654=260=20140108-15:37:34.27638=140=144=132.17510=075 8=FIX.4.49=23935=834=249=OEC_TEST52=20140108-15:37:45.99056=MHall40011=API0022186=0.00011=140108153721000114=017=OECFIX:635245560331309946:223937=20286834738=139=A44=132.17554=155=LE60=20140108-15:37:45150=A151=0200=201412461=FXXXXS10=055 8=FIX.4.49=23935=834=349=OEC_TEST52=20140108-15:37:45.99056=MHall40011=API0022186=0.00011=140108153721000214=017=OECFIX:635245560331309946:224037=20286834838=139=A44=132.17554=255=LE60=20140108-15:37:45150=A151=0200=201406461=FXXXXS10=054 202868348 status = SENT 8=FIX.4.49=24235=834=449=OEC_TEST52=20140108-15:37:45.99056=MHall40011=API0022186=011=140108153721000114=017=522549137=20286834738=139=844=132.17554=155=LE58=Order breaks limits.60=20140108-15:37:45103=0150=8151=1200=201412461=FXXXXS10=069 8=FIX.4.49=23235=834=549=OEC_TEST52=20140108-15:37:46.00556=MHall40011=API0022186=0.00011=140108153721000214=017=522549237=20286834838=139=944=132.17554=255=LE58=Auto-Execute60=20140108-15:37:45150=9151=1200=201406461=FXXXXS10=035 Michael Hall |
|||||
FIX Support » OSO leg 2 order is not executed afer leg1 filled. Jan 08, 2014 @ 05:32 AM (Total replies: 4) | |||||
After some further searching through the Fix logs I discovered what is happening. The order server does process the second leg of the OSO but the Execution reports it sends out change the ClOrdID to a server derived value - that looks like a new order number for the server and it adds an extra tag (12073) which contains the ClOrdID. This isn't in my FIX DD so I reject the message (This tag isn't in your API doc either!). Can you put the ClOrdID in the ClOrdID field and the server's additional order number in the 12073 tag? Fix messages: Exec reports... 8=FIX.4.49=24135=834=9649=OEC_TEST52=20140107-16:07:50.79956=MHall40011=API0022186=0.00011=OECFIX:20286737114=017=522380637=20286734438=339=054=255=LE60=20140107-16:07:50150=0151=3200=201406325=Y377=N461=FXXXXS12073=140107154722000110=102 8=FIX.4.49=25935=834=9749=OEC_TEST52=20140107-16:07:50.79956=MHall40011=API0022186=129.92511=OECFIX:20286737114=317=522380731=129.92532=337=20286734438=339=E54=255=LE60=20140107-16:07:50150=F151=0200=201406325=Y377=N461=FXXXXS12073=140107154722000110=250 8=FIX.4.49=28035=834=9849=OEC_TEST52=20140107-16:07:50.79956=MHall40011=API0022186=129.92511=OECFIX:20286737314=317=OECFIX:635245560331309946:138937=20286734438=539=154=255=LE60=20140107-16:07:50150=5151=2198=202867373200=201406325=Y377=N461=FXXXXS12073=140107154722000110=240 Rejects... 8=FIX.4.49=12935=334=11949=MHall400152=20140107-16:07:49.55656=OEC_TEST45=9658=Tag not defined for this message type371=325372=8373=210=125 8=FIX.4.49=12935=334=12049=MHall400152=20140107-16:07:49.55856=OEC_TEST45=9758=Tag not defined for this message type371=325372=8373=210=120 8=FIX.4.49=12935=334=12149=MHall400152=20140107-16:07:49.55956=OEC_TEST45=9858=Tag not defined for this message type371=325372=8373=210=123 Michael Hall |
|||||
FIX Support » OSO leg 2 order is not executed afer leg1 filled. Jan 08, 2014 @ 04:49 AM (Total replies: 4) | |||||
According to the API doc "First order in a list is main order, which triggers the other (child) ones when it filled/completed". There may be a problem with the execution of the second legs of OSO orders. The following describes a situation, along with fix messages where a OSO leg1 is filled but leg2 is neither filled nor rejected. My comments in <brackets>. <Client send NewOrderList message of type OSO with CLOrd ID of 1401071547220000 for leg 1 and 1401071547220001 for leg 2. Leg1 is a limit order, leg2 is a market order which should be placed when leg1 is filled.> 8=FIX.4.49=33335=E34=249=MHall400152=20140107-15:47:35.47556=OEC_TEST66=OSO Order 2 Legs68=269=OSO394=373=211=140107154722000067=11=API00221855=LE461=FXXXXS200=20141254=160=20140107-15:47:35.47438=540=244=132.2511=140107154722000167=21=API00221855=LE461=FXXXXS200=20140654=260=20140107-15:47:35.47538=540=144=132.2510=233 <Order is accepted by server, server assigns the following order numbers leg1 = 202867343, leg2 = 202867344.> 8=FIX.4.49=21535=834=549=OEC_TEST52=20140107-15:47:45.99356=MHall40011=API0022186=0.00011=140107154722000014=017=522378737=20286734338=539=044=132.2554=155=LE60=20140107-15:47:45150=0151=5200=201412461=FXXXXS10=169 8=FIX.4.49=23135=834=449=OEC_TEST52=20140107-15:47:45.99356=MHall40011=API0022186=0.00011=140107154722000114=017=522378637=20286734438=539=944=132.2554=255=LE58=Auto-Execute60=20140107-15:47:45150=9151=5200=201406461=FXXXXS10=001 <Leg1 of order is updated several times using OrderCancelReplaceReject messages, acceptance of which is confirmed by the server. An example ...> 8=FIX.4.49=19235=G34=11549=MHall400152=20140107-16:07:25.51756=OEC_TEST1=API00221811=140107154722002338=540=241=140107154722002244=132.3554=155=LE60=20140107-15:47:35.474200=201412461=FXXXXS10=208 8=FIX.4.49=25635=834=8849=OEC_TEST52=20140107-16:07:26.89956=MHall40011=API0022186=0.00011=140107154722002314=017=OECFIX:635245560331309946:138537=20286734338=539=E41=140107154722002244=13254=155=LE60=20140107-16:07:26150=E151=5200=201412461=FXXXXS10=132 8=FIX.4.49=27335=834=8949=OEC_TEST52=20140107-16:07:26.91556=MHall40011=API0022186=0.00011=140107154722002314=017=OECFIX:635245560331309946:138637=20286734338=539=041=140107154722002244=132.3554=155=LE60=20140107-16:07:26150=5151=5198=202867370200=201412461=FXXXXS10=158 <Just before the first leg is filled....> <Latest ClOrderId number is 1401071547220023> 8=FIX.4.49=25635=834=8849=OEC_TEST52=20140107-16:07:26.89956=MHall40011=API0022186=0.00011=140107154722002314=017=OECFIX:635245560331309946:138537=20286734338=539=E41=140107154722002244=13254=155=LE60=20140107-16:07:26150=E151=5200=201412461=FXXXXS10=132 <<On Message ClOrderId 1401071547220023 status = E > Pending replace 8=FIX.4.49=27335=834=8949=OEC_TEST52=20140107-16:07:26.91556=MHall40011=API0022186=0.00011=140107154722002314=017=OECFIX:635245560331309946:138637=20286734338=539=041=140107154722002244=132.3554=155=LE60=20140107-16:07:26150=5151=5198=202867370200=201412461=FXXXXS10=158 <For ClOrderId 1401071547220023 status = 0 means the order change has been accepted by server> <Client lowers price of ClOrderId 1401071547220023 by order sending following message. New order number is 1401071547220024> 8=FIX.4.49=19235=G34=11849=MHall400152=20140107-16:07:49.39956=OEC_TEST1=API00221811=140107154722002438=540=241=140107154722002344=131.9554=155=LE60=20140107-15:47:35.474200=201412461=FXXXXS10=232 <Order server updates client with ex rep of partial fill (3 of 5 for ClOrderId ending in 1401071547220023)> 8=FIX.4.49=23435=834=9149=OEC_TEST52=20140107-16:07:50.76756=MHall40011=API0022186=132.35011=140107154722002314=317=522380231=132.35032=337=20286734338=539=144=132.3554=155=LE60=20140107-16:07:50150=F151=2200=201412461=FXXXXS10=035 <Order server then sends a pending replace messsge for the new ClOrderId 1401071547220024. > 8=FIX.4.49=26135=834=9249=OEC_TEST52=20140107-16:07:50.78356=MHall40011=API0022186=132.35011=140107154722002414=317=OECFIX:635245560331309946:138737=20286734338=539=E41=140107154722002344=132.3554=155=LE60=20140107-16:07:50150=E151=2200=201412461=FXXXXS10=117 <Order server then sends a pending replace ex rep for the ClOrderId 1401071547220023 but the order 202867343 has actually been filled (tag 150=F (filled) tag 151=0 (remaining quantity of zero)). > 8=FIX.4.49=23435=834=9349=OEC_TEST52=20140107-16:07:50.78356=MHall40011=API0022186=132.35011=140107154722002314=517=522380431=132.35032=237=20286734338=539=E44=132.3554=155=LE60=20140107-16:07:50150=F151=0200=201412461=FXXXXS10=056 <Order server then sends an order cancel reject for ClOrderIdr 1401071547220024 as the order 202867343 to which the ClOrderId has been filled> 8=FIX.4.49=17135=934=9449=OEC_TEST52=20140107-16:07:50.79956=MHall400111=140107154722002437=20286734339=241=140107154722002358=Order Completed60=20140107-16:07:50102=2434=210=192 <Order server then sends details of execution for ClOrderId 1401071547220023> 8=FIX.4.49=24135=834=9549=OEC_TEST52=20140107-16:07:50.79956=MHall40011=API0022186=132.35011=140107154722002314=517=OECFIX:635245560331309946:138837=20286734338=539=B44=132.3554=155=LE60=20140107-16:07:50150=B151=0200=201412461=FXXXXS10=173 <So far so good. But now one would expect the other leg of the OSO to go from status 9 (Suspended), through statuses , A, 0 and 2 as it is a market order. But no. There is no further communication from the order server. Order 202867344 has been lost. Edited by MHall4001 on Jan 8, 2014 at 05:19:16 |
|||||
FIX Support » FAST subscription data stop after 90 seconds Dec 31, 2013 @ 07:44 AM (Total replies: 4) | |||||
Correction, my app is set up to respond with a type 62 (Heartbeat) message. Michael Hall |
|||||
FIX Support » FAST subscription data stop after 90 seconds Dec 31, 2013 @ 06:54 AM (Total replies: 4) | |||||
Does the test FAST API send heartbeats? I check for them but I have never received a message of type 62 from the FAST server. My app is set up to respond to a heartbeat with a type 52 message. Michael Hall |
|||||
FIX Support » FAST subscription data stop after 90 seconds Dec 16, 2013 @ 01:21 PM (Total replies: 4) | |||||
Hi I can request subscription data from the FAST server but updates stop after 90 seconds. I also notice that I’m not receiving Heartbeat (type 62) messages from the server. (and so not sending any back). I'm haven't changed the default heartbeat interval (set in the logon message at 30 seconds). I'm using OpenFAST. Do I need to manually generate Heartbeat responses or re-request the data? Message History: I send two MarketDataRequest messages MarketDataRequest -> {59, V, 1, 1, 1, 0, null, null, null, [ [MDEntries -> {0}] [MDEntries -> {1}] ], [ [Instruments -> {GE, 201503, null, CME, FXXXXS}] ]} MarketDataRequest -> {59, V, 2, 0, 1, 0, null, null, null, [ [MDEntries -> {0}] [MDEntries -> {1}] ], [ [Instruments -> {GE, 201603, null, CME, FXXXXS}] ]} And get the data returned MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 2960, 20131216, 172606000, null}] [MDEntries -> {1, 99.54, 22272, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 2, [ [MDEntries -> {0, 98.745, 7964, 20131216, 172553000, null}] [MDEntries -> {1, 98.75, 1326, null, null, null}] ]} I cancel the second update MarketDataRequest_Cancel -> {57, V, 2, 2} And continue to get updates on the subscribed message MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 2960, 20131216, 172606000, null}] [MDEntries -> {1, 99.54, 22205, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 3044, 20131216, 172606000, null}] [MDEntries -> {1, 99.54, 22205, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 3084, 20131216, 172606000, null}] [MDEntries -> {1, 99.54, 22205, null, null, null}] ]} ……… updates continue until ……… MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 2841, 20131216, 172724000, null}] [MDEntries -> {1, 99.54, 30123, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 2842, 20131216, 172724000, null}] [MDEntries -> {1, 99.54, 29889, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.535, 2842, 20131216, 172724000, null}] [MDEntries -> {1, 99.54, 29886, null, null, null}] ]} Michael Hall |
|||||
FIX Support » FAST Server returns invalid MDReqID if an unsupported request is made. Dec 16, 2013 @ 01:17 PM (Total replies: 4) | |||||
I was trying to connect all through the day and was getting the message " No responder, not sending message" in response to socketInitiator.start(); Anyway today I've been able to logon to the FIX server and have rerun the "unsupported" test and it now works: MarketDataRequest -> {59, V, 1, 1, 1, 0, null, null, null, [ [MDEntries -> {0}] [MDEntries -> {1}] ], [ [Instruments -> {GE, 201503, null, CME, FXXXXS}] ]} MarketDataRequest -> {59, V, 2, 6, 1, 0, null, null, null, [ [MDEntries -> {0}] [MDEntries -> {1}] ], [ [Instruments -> {GE, 201603, null, CME, FXXXXS}] ]} MarketDataRequestReject -> {58, Y, 2, 4, Unsupported SubscriptionRequestType} MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.53, 6784, 20131216, 180734000, null}] [MDEntries -> {1, 99.535, 19244, null, null, null}] ]} New bid = 99.53 MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.53, 6784, 20131216, 180734000, null}] [MDEntries -> {1, 99.535, 19356, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.53, 6784, 20131216, 180734000, null}] [MDEntries -> {1, 99.535, 19380, null, null, null}] ]} and so on.... Michael Hall |
|||||
FIX Support » FAST Server returns invalid MDReqID if an unsupported request is made. Dec 13, 2013 @ 11:34 AM (Total replies: 4) | |||||
Thanks for checking this. I haven't been able to test this as the test FIX server has been down for last two days. Is there any way you can check the test servers are running before you go home each evening? Michael Hall |
|||||
FIX Support » FAST Server returns invalid MDReqID if an unsupported request is made. Dec 11, 2013 @ 07:51 AM (Total replies: 4) | |||||
In testing my application I noticed a problem with the FAST FIX server if a Market Data Message is rejected. It is as follows: My app makes two MD requests as follows - note the second one is invalid so is correctly rejected. MarketDataRequest -> {59, V, 1, 1, 1, 0, null, null, null, [ [MDEntries -> {0}] [MDEntries -> {1}] ], [ [Instruments -> {GE, 201512, null, CME, FXXXXS}] ]} MarketDataRequest -> {59, V, 2, 3, 1, 0, null, null, null, [ [MDEntries -> {0}] [MDEntries -> {1}] ], [ [Instruments -> {GE, 201612, null, CME, FXXXXS}] ]} In response to the first (good) request server correctly replies with: MarketDataSnapshotFullRefresh -> {2, W, 1, [ [MDEntries -> {0, 99.055, 6993, null, null, null}] [MDEntries -> {1, 99.06, 1889, null, null, null}] ]} Sever then correctly rejects the invalid MD request: MarketDataRequestReject -> {58, Y, 2, 4, Unsupported SubscriptionRequestType} but now price updates for the first request come as follows with the MDReqID set to the value of the rejected message when they should have the value of the first message: MarketDataSnapshotFullRefresh -> {2, W, 2, [ [MDEntries -> {0, 99.055, 7499, null, null, null}] [MDEntries -> {1, 99.06, 1889, null, null, null}] ]} MarketDataSnapshotFullRefresh -> {2, W, 2, [ [MDEntries -> {0, 99.055, 6992, null, null, null}] [MDEntries -> {1, 99.06, 1889, null, null, null}] ]} and so on. The MDReqID is the third field in the message (after the "W") . Michael Hall |
|||||
FIX Support » Session Reject for NewOrderList message Dec 05, 2013 @ 12:34 PM (Total replies: 5) | |||||
Hi Vitaliy, Thanks for the reply. I don't understand your message as Order Tag 40 is set in both the legs of the message. One leg is set to 1 the other to 0. Michael. Michael Hall |
|||||
FIX Support » Test Order server rejecting orders with error “LimitPrice is not round to contract's tick size” Dec 05, 2013 @ 09:25 AM (Total replies: 1) | |||||
Test order server is rejecting orders for futures with error “LimitPrice is not round to contract's tick size” All of the messages below were rejected This is also happening for corn and oil futures. FIX messages 8=FIX.4.4 9=158 35=D 34=2 49=MHall4001 52=20131205-13:36:42.987 56=OEC_TEST 1=API002218 11=210 38=10 40=2 44=99.855 54=2 55=GE 60=20131205-13:36:42.987 200=201412 461=FXXXXS 10=085 8=FIX.4.4 9=158 35=D 34=4 49=MHall4001 52=20131205-13:36:47.994 56=OEC_TEST 1=API002218 11=211 38=1 40=2 44=99.9125 54=2 55=GE 60=20131205-13:36:47.994 200=201512 461=FXXXXS 10=094 8=FIX.4.4 9=306 35=8 34=3 49=OEC_TEST 52=20131205-13:36:51.990 56=MHall4001 1=API002218 6=0 11=210 14=0 17=OECFIX:635217933404733522:881248 37=OECFIX:635217933404733522:881247 38=10 39=8 44=99.855 54=2 55=GE 58=LimitPrice is not round to contract's tick size 60=20131205-13:36:51 103=18 150=8 151=10 200=201412 461=FXXXXS 10=247 8=FIX.4.4 9=305 35=8 34=4 49=OEC_TEST 52=20131205-13:36:51.990 56=MHall4001 1=API002218 6=0 11=211 14=0 17=OECFIX:635217933404733522:881250 37=OECFIX:635217933404733522:881249 38=1 39=8 44=99.9125 54=2 55=GE 58=LimitPrice is not round to contract's tick size 60=20131205-13:36:51 103=18 150=8 151=1 200=201512 461=FXXXXS 10=195 and for Corn 8=FIX.4.4 9=154 35=D 34=2 49=MHall4001 52=20131205-14:14:51.754 56=OEC_TEST 1=API002218 11=220 38=1 40=2 44=475 54=2 55=ZC 60=20131205-14:14:51.754 200=201512 461=FXXXXS 10=124 8=FIX.4.4 9=301 35=8 34=2 49=OEC_TEST 52=20131205-14:15:01.183 56=MHall4001 1=API002218 6=0 11=220 14=0 17=OECFIX:635217933404733522:881256 37=OECFIX:635217933404733522:881255 38=1 39=8 44=475 54=2 55=ZC 58=LimitPrice is not round to contract's tick size 60=20131205-14:15:01 103=18 150=8 151=1 200=201512 461=FXXXXS 10=236 and for oil 8=FIX.4.4 9=158 35=D 34=6 49=MHall4001 52=20131205-14:15:06.765 56=OEC_TEST 1=API002218 11=222 38=1 40=2 44=100.78 54=2 55=GCL 60=20131205-14:15:06.764 200=201403 461=FXXXXS 10=081 8=FIX.4.4 9=305 35=8 34=4 49=OEC_TEST 52=20131205-14:15:08.843 56=MHall4001 1=API002218 6=0 11=222 14=0 17=OECFIX:635217933404733522:881258 37=OECFIX:635217933404733522:881257 38=1 39=8 44=100.78 54=2 55=GCL 58=LimitPrice is not round to contract's tick size 60=20131205-14:15:08 103=18 150=8 151=1 200=201403 461=FXXXXS 10=207 Michael Hall |
|||||
FIX Support » Session Reject for NewOrderList message Dec 03, 2013 @ 11:27 AM (Total replies: 5) | |||||
I guess you've changed something as now after sending the same NewOrderList message as it no longer gets rejected. 8=FIX.4.49=31235=E34=249=MHall400152=20131203-16:22:34.38656=OEC_TEST66=Test00168=269=OSO394=373=211=12067=11=API00221855=ZC461=FXXXXS167=FUT200=20141254=160=20131203-16:22:34.38538=140=244=4.66511=12167=21=API00221855=ZC461=FXXXXS167=FUT200=20151254=260=20131203-16:22:34.38538=140=144=4.66510=039 But there is no response from the order server (I would expect a ExecutionReport). Also no response to a couple of OrderStatus messages (one for each leg). 8=FIX.4.49=8435=H34=449=MHall400152=20131203-16:22:54.40056=OEC_TEST1=API00221811=12054=110=113 8=FIX.4.49=8435=H34=549=MHall400152=20131203-16:22:54.40256=OEC_TEST1=API00221811=12154=210=118 Any ideas when this will be working? Michael Hall |