Thread: [Quickfix-developers] MiscFeeType (139)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Malinka R. <ael...@gm...> - 2009-02-17 21:05:47
|
It appears there is some confusion regarding MiscFeeType (tag 139). According to http://b2bits.com/fixopaedia/fixdic44/index.html it is a Int field. According to http://www.transacttools.net/ttportal/datadict/browser.jsp it is a Char field. If it is supposed to be a char it has the impossible values of 10 : Per transaction, 11 : Conversion, 12 : Agent. QuickFix treats it as a Char however it does not have 10, 11 and 12 available, has this been a change to the FIX spec? What would be the best solution? treate it as an IntField or treate it as a StringField? |
|
From: Grant B. <gbi...@co...> - 2009-02-17 23:49:47
|
In C++, a char can be treated like an int. Values 10, 11, and 12 can be assigned to a char without a problem. If you have C++ code such as "char x = 8;", then x will not be storing the character "8", but the unsigned integer value 8, which is intended to be interpreted as the ASCII character with code 8 (see http://www.asciitable.com/). In the FIX spec, value 139 is specified as a char. Note: A char and an int are not exactly the same. On many (most?) implementations, a char is 8 bits wide, and thus can only range from 0-255. On Tue, Feb 17, 2009 at 3:05 PM, Malinka Rellikwodahs <ael...@gm...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > It appears there is some confusion regarding MiscFeeType (tag 139). > According to http://b2bits.com/fixopaedia/fixdic44/index.html it is a > Int field. According to > http://www.transacttools.net/ttportal/datadict/browser.jsp it is a > Char field. If it is supposed to be a char it has the impossible > values of 10 : Per transaction, 11 : Conversion, 12 : Agent. > > QuickFix treats it as a Char however it does not have 10, 11 and 12 > available, has this been a change to the FIX spec? What would be the > best solution? treate it as an IntField or treate it as a StringField? > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Malinka R. <ael...@gm...> - 2009-02-18 00:46:38
|
On Tue, Feb 17, 2009 at 16:38, Grant Birchmeier <gbi...@co...> wrote: > In C++, a char can be treated like an int. Values 10, 11, and 12 can > be assigned to a char without a problem. > > If you have C++ code such as "char x = 8;", then x will not be storing > the character "8", but the unsigned integer value 8, which is intended > to be interpreted as the ASCII character with code 8 (see > http://www.asciitable.com/). yes and 8 != '8' (56), and in QF the 139 value of "Markup" is '8' 56 if displayed as an int. If the FIX spec expected a integral value of 8 to be interpreted as Backspace, then they could not have a value of 1 (Start of Header) which is the FIX field delimiter > In the FIX spec, value 139 is specified as a char. Which would be the a single Ascii value not an integer between 0-255 otherwise they would have specified the Field as an integer. > Note: A char and an int are not exactly the same. On many (most?) > implementations, a char is 8 bits wide, and thus can only range from > 0-255. > Also this does not answer the question of why another source would refer to the field as being of type Int |
|
From: Grant B. <gbi...@co...> - 2009-02-18 02:56:18
|
After further investigation, I see I was wrong. And I'm hesitant to say this, but the most recent 4.4 spec seems to be in error for field 139 'MiscFeeType'. FIX spec (Vol 1) defines char as such: char: Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case sensitive (i.e. m ≠ M). Since ASCII codes 0-12 are not alphanumeric, the spec really does mean characters '1', '2', etc. And yes, '10', '11', and '12' are, indeed, impossible in this context. You can see this erroneous definition in the fixml.4.4.dtd document (http://www.fixprotocol.org/specifications/fix4.4livedtd/index.html). QuickFIX's FIX44.xml completely omits '10'-'12', as does the QuickFIX/J 4.4 API. In FIX 5.0, this field type has been changed to 'string', so I guess somebody noticed the error and fixed it. So, Malinka, you were right. You should set this field to be chars '1'-'9'. If you need to use values '10'-'12', you have a problem. If you control both the server and client, you can change '10'-'12' to other characters, such as 'a' 'b' 'c', in the FIX44.xml file and then recompile QuickFIX for both sides. That might be the easiest thing to do. If you don't need to use values '10'-'12', then I suggest you do nothing! -Grant On Tue, Feb 17, 2009 at 6:46 PM, Malinka Rellikwodahs <ael...@gm...> wrote: > On Tue, Feb 17, 2009 at 16:38, Grant Birchmeier > <gbi...@co...> wrote: >> In C++, a char can be treated like an int. Values 10, 11, and 12 can >> be assigned to a char without a problem. >> >> If you have C++ code such as "char x = 8;", then x will not be storing >> the character "8", but the unsigned integer value 8, which is intended >> to be interpreted as the ASCII character with code 8 (see >> http://www.asciitable.com/). > > yes and 8 != '8' (56), and in QF the 139 value of "Markup" is '8' 56 > if displayed as an int. > > If the FIX spec expected a integral value of 8 to be interpreted as > Backspace, then they could not have a value of 1 (Start of Header) > which is the FIX field delimiter > >> In the FIX spec, value 139 is specified as a char. > > Which would be the a single Ascii value not an integer between 0-255 > otherwise they would have specified the Field as an integer. > >> Note: A char and an int are not exactly the same. On many (most?) >> implementations, a char is 8 bits wide, and thus can only range from >> 0-255. >> > > Also this does not answer the question of why another source would > refer to the field as being of type Int > |
|
From: Malinka R. <ael...@gm...> - 2009-02-18 03:24:23
|
would changing the QF field to String and then recompiling to match FIX 5.0 work also?, it seems that treating it as a string as far as FIX goes should also work, now I don't need to use the values 10-12 and I do control both sides, I just wanted to make sure I was following the FIX spec as closely as I can with the features I was implementing, Thank you for the input I'll likely just continue treating it as a char and just ignore the missing values On Tue, Feb 17, 2009 at 21:50, Grant Birchmeier <gbi...@co...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > After further investigation, I see I was wrong. And I'm hesitant to > say this, but the most recent 4.4 spec seems to be in error for field > 139 'MiscFeeType'. > > FIX spec (Vol 1) defines char as such: > char: Single character value, can include any alphanumeric character > or punctuation except > the delimiter. All char fields are case sensitive (i.e. m ≠ M). > > Since ASCII codes 0-12 are not alphanumeric, the spec really does mean > characters '1', '2', etc. And yes, '10', '11', and '12' are, indeed, > impossible in this context. You can see this erroneous definition in > the fixml.4.4.dtd document > (http://www.fixprotocol.org/specifications/fix4.4livedtd/index.html). > > QuickFIX's FIX44.xml completely omits '10'-'12', as does the QuickFIX/J 4.4 API. > > In FIX 5.0, this field type has been changed to 'string', so I guess > somebody noticed the error and fixed it. > > So, Malinka, you were right. You should set this field to be chars > '1'-'9'. If you need to use values '10'-'12', you have a problem. If > you control both the server and client, you can change '10'-'12' to > other characters, such as 'a' 'b' 'c', in the FIX44.xml file and then > recompile QuickFIX for both sides. That might be the easiest thing to > do. > > If you don't need to use values '10'-'12', then I suggest you do nothing! > > -Grant > > > On Tue, Feb 17, 2009 at 6:46 PM, Malinka Rellikwodahs > <ael...@gm...> wrote: >> On Tue, Feb 17, 2009 at 16:38, Grant Birchmeier >> <gbi...@co...> wrote: >>> In C++, a char can be treated like an int. Values 10, 11, and 12 can >>> be assigned to a char without a problem. >>> >>> If you have C++ code such as "char x = 8;", then x will not be storing >>> the character "8", but the unsigned integer value 8, which is intended >>> to be interpreted as the ASCII character with code 8 (see >>> http://www.asciitable.com/). >> >> yes and 8 != '8' (56), and in QF the 139 value of "Markup" is '8' 56 >> if displayed as an int. >> >> If the FIX spec expected a integral value of 8 to be interpreted as >> Backspace, then they could not have a value of 1 (Start of Header) >> which is the FIX field delimiter >> >>> In the FIX spec, value 139 is specified as a char. >> >> Which would be the a single Ascii value not an integer between 0-255 >> otherwise they would have specified the Field as an integer. >> >>> Note: A char and an int are not exactly the same. On many (most?) >>> implementations, a char is 8 bits wide, and thus can only range from >>> 0-255. >>> >> >> Also this does not answer the question of why another source would >> refer to the field as being of type Int >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Grant B. <gbi...@co...> - 2009-02-18 05:13:29
|
Yes, changing the fieldtype to String in the FIX44.xml would probably work as well. On Tue, Feb 17, 2009 at 9:24 PM, Malinka Rellikwodahs <ael...@gm...> wrote: > would changing the QF field to String and then recompiling to match > FIX 5.0 work also?, it seems that treating it as a string as far as > FIX goes should also work, now I don't need to use the values 10-12 > and I do control both sides, I just wanted to make sure I was > following the FIX spec as closely as I can with the features I was > implementing, Thank you for the input I'll likely just continue > treating it as a char and just ignore the missing values > > On Tue, Feb 17, 2009 at 21:50, Grant Birchmeier > <gbi...@co...> wrote: >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> After further investigation, I see I was wrong. And I'm hesitant to >> say this, but the most recent 4.4 spec seems to be in error for field >> 139 'MiscFeeType'. >> >> FIX spec (Vol 1) defines char as such: >> char: Single character value, can include any alphanumeric character >> or punctuation except >> the delimiter. All char fields are case sensitive (i.e. m ≠ M). >> >> Since ASCII codes 0-12 are not alphanumeric, the spec really does mean >> characters '1', '2', etc. And yes, '10', '11', and '12' are, indeed, >> impossible in this context. You can see this erroneous definition in >> the fixml.4.4.dtd document >> (http://www.fixprotocol.org/specifications/fix4.4livedtd/index.html). >> >> QuickFIX's FIX44.xml completely omits '10'-'12', as does the QuickFIX/J 4.4 API. >> >> In FIX 5.0, this field type has been changed to 'string', so I guess >> somebody noticed the error and fixed it. >> >> So, Malinka, you were right. You should set this field to be chars >> '1'-'9'. If you need to use values '10'-'12', you have a problem. If >> you control both the server and client, you can change '10'-'12' to >> other characters, such as 'a' 'b' 'c', in the FIX44.xml file and then >> recompile QuickFIX for both sides. That might be the easiest thing to >> do. >> >> If you don't need to use values '10'-'12', then I suggest you do nothing! >> >> -Grant >> >> >> On Tue, Feb 17, 2009 at 6:46 PM, Malinka Rellikwodahs >> <ael...@gm...> wrote: >>> On Tue, Feb 17, 2009 at 16:38, Grant Birchmeier >>> <gbi...@co...> wrote: >>>> In C++, a char can be treated like an int. Values 10, 11, and 12 can >>>> be assigned to a char without a problem. >>>> >>>> If you have C++ code such as "char x = 8;", then x will not be storing >>>> the character "8", but the unsigned integer value 8, which is intended >>>> to be interpreted as the ASCII character with code 8 (see >>>> http://www.asciitable.com/). >>> >>> yes and 8 != '8' (56), and in QF the 139 value of "Markup" is '8' 56 >>> if displayed as an int. >>> >>> If the FIX spec expected a integral value of 8 to be interpreted as >>> Backspace, then they could not have a value of 1 (Start of Header) >>> which is the FIX field delimiter >>> >>>> In the FIX spec, value 139 is specified as a char. >>> >>> Which would be the a single Ascii value not an integer between 0-255 >>> otherwise they would have specified the Field as an integer. >>> >>>> Note: A char and an int are not exactly the same. On many (most?) >>>> implementations, a char is 8 bits wide, and thus can only range from >>>> 0-255. >>>> >>> >>> Also this does not answer the question of why another source would >>> refer to the field as being of type Int >>> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X