[This message was posted by Hanno Klein of Deutsche Börse Systems <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/bcdce6ba - PLEASE DO NOT REPLY BY MAIL.]
Asking the sender was obviously not meant for a message received in real-time during production, it is meant for the process of agreeing on rules of engagement during a design or testing process. If IOC+AON were the same as FOK, why support two ways to express this? FOK is simpler as it only needs a single field. FIX is not free from ambiguities, why introduce new ones? > Hanno, > > I think there is a Gap. > > IOC is a Time descriptor and AON is a Execution Quantity descriptor and > I see these as two different dimensions ( > http://en.wikipedia.org/wiki/Dimensional_analysis ). For example I see > Price and Quantity as two independent dimensions in FIX. > > Effectinely TimeInForce = IOC + ExecInstruction = AON becomes > TimeInForce 59 = 4 FillOrKill (though this not written anywhere in the > FIX Specs). > > Asking the sender may not be an option in high freqency Algorithmic > trading systems where automated Algorithims have placed this trade (a > voice Robot may answer the call :-( > > Different values in ExecInst 18 belong to different dimensions. Since > this field can contain multiple instructions separated by space, values > from different dimensions may coexist under the mutually exclusive rule > within the same dimension, but I believe some should be seperated into > new FIXTags or removed from 18 and merged into existing FIXTags. For > example, values of 18 > > A (No cross) and B (OK to cross) describe whether a Cross is permitted > > D (Percent of volume), E (Do not increase), F (Do not reduce), G (All or > none) describe behaviour of the Quantity dimension > > J (Reinstate on Trading Halt), K (Cancel on Trading Halt), m (Suspend on > Trading Halt) describe what to do in the event of Trading halt. > > H (Reinstate on system failure), Q (Cancel on system failure) and l > (Suspend on system failure) describe what to do in the event of > System failure > > L (Last peg), M (Mid-price peg), O (Opening peg), P (Market peg), R > (Primary peg), W (Peg to VWAP), d (Peg to Limit Price) decsribe the > Price Peg type. > > g (External Routing Allowed) and h (External Routing Not Allowed) > describe External Routing permission. > > S (Suspend) and q (Release from suspension) describe the Suspend / > Unsuspend behavior. > > (The above values are not a complete list but indicative of the Gap I am > analysing) > > Since ExecInst 18 is used different MessageTypes, we could do a Gap > analysis to see how the different values can be refactored for new > FIX.Version or Service pack. But for the sake of older versions, we > should try to document a matrix of ExecInst values for different message > types and the expected behaviour when some other field like TimeInForce > contains a specific value. > [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
