|
4.1 Changes
< Previous Next >
Re: Length of ClOrdID - tag 11 - URGENT?
Mitchell Budwick / Consultant
25 May 2005 8:45AM ETI think if you try to lose your dependency on the max size, you will find that it will be less of a problem. typically the legacy systems maxed at 20 chars, especially most ecns. But even some ecns started using 40 byte execids, so even if you had a defined maximum, it wont be consistent across engines and ecns.
The fundamental issue would be your programming language and your representation of these entities. For instance if you were using c++ you can just define it as a cstring or string or CString, ( depending on your variant ) and you would be done. Database is another story. You would have to define what your forecasted maximum would be and just define it as VARCHAR so you wouldnt really be wasting "that much" space.
The best approach would be to revisit your order id creation schema.
Ive found that even in companies that do tens of thousands to hundreds of thousands of orders a day, 20 characters is way more than enough.
as an example look at the order id below.
ABC052305X1000000000
The abc represents a possible use of trader or market maker acronym if needed. Some would like to know the age of the trade on initial inspection so 052305 represents that fact that trade was done on May 23 2005. The X digit can represent a routing schema. Depending on the code, it can represent which line handler it was generated from, or which order router its traders computer resides on. The rest represents the 1 billionth trade of the day. And theoretically, if you use an alphabetical code in the X digit, you can have 26 times 1 billion possible trades for the day. Since that may be overkill, you can shorten the sequence number fields and enhance the X digit field to incorporate more information if needed ( say if a user has more than one login or account ).
Just be glad the original order ids consisting of a 4 byte acronym and a 4 byte sequence number are going the way of the dodo bird :)
-mitch-
B.I.G. Systems LLC
> Is this length based on FIX version. Did it have any limitations for FIX
> 4.1 and that now it has been relaxed?
>
> In FIX 4.1 it says Clorid as char but in 4.2 it is a string. Initially
> we had created a mapping based on our customers requirement, which was
> 12 characters. We had it as 16. Now we get 20 as the length. We need to
> change this but if we know what the maximum size we could have that as
> final instead of changing every now and then.
>
> Regards. Hari.
>
> > > Daniel, You are right on that FIX does not put any limitation on the
> > > size. Altough it is wise to point out that FIX _implementations_ (I
> > > mean FIX egnines) may have limitations coming from a lousy
> > > implementation. (Such as using C strings, with hardcoded size...)
> > >
> > > I am using 17 chars long ClOrdIDs with no problems.
> > >
> > > -gabor
> >
> > Our current systems are limited to a maximum of 40 characters for
> > ClOrdIDs. We definitely have several customers who use more than 17
> > characters.
> >
> > Most FIX engines or applications have hardcoded limitations on the
> > size of many string fields such as ClOrdIDs, ExecIDs, CompIDs etc,.
> > The ones that have the bigger size limits are putting less constraints
> > upon their users/customers. Implementors, please be generous.
> >
> > We even have one customer who forces us to use an 8 character ExecID
> > which is a fairly unpleasant restriction and has caused us to create
> > more software specifically to handle mapping from/to our longer
> > ExecIDs to live with this restriction.
> >
> > JohnP
Re: Length of ClOrdID - tag 11 - URGENT?
Mitchell Budwick / Consultant 25 May 2005 8:45AM ET
|
