Is there a problem in this template XML?

, ,
1

Imported from previous forum

2

Our stable FIXFAST lib has run into a decoding problem against the msg encoded from the following XML. The problem happened at dealing with fields such as SecurityID and Symbol which are defined as strings with Delta operation.

Can you help to see if the template XML is flawed? We generate code from the XML file as part of lib. Thanks.

3

Our stable FIXFAST lib has run into a decoding problem against the msg encoded from the following XML. The problem happened at dealing with fields such as SecurityID and Symbol which are defined as strings with Delta operation.

[xml snipped]

The XML is syntactically valid.

You didn’t specify what was going wrong. “run into a decoding problem” is a bit vague.

Can you instrument the generated code? You need to see the dictionary value, the subtraction length, the delta value, and the resulting string to determine if the string delta operation is being applied correctly.

You might also try decoding the data with OpenFAST or QuickFAST to determine whether the problem lies in the encoded data or the generated decoder.

Dale

4

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.

Is this correct? Or should be the subtraction length be 6 in this case.

Thanks.

Our stable FIXFAST lib has run into a decoding problem against the msg encoded from the following XML. The problem happened at dealing with fields such as SecurityID and Symbol which are defined as strings with Delta operation.

[xml snipped]

The XML is syntactically valid.

You didn’t specify what was going wrong. “run into a decoding problem” is a bit vague.

Can you instrument the generated code? You need to see the dictionary value, the subtraction length, the delta value, and the resulting string to determine if the string delta operation is being applied correctly.

You might also try decoding the data with OpenFAST or QuickFAST to determine whether the problem lies in the encoded data or the generated decoder.

Dale

5

I used FAST Interoperability Portal (http://fast.fixprotocol.org/templates.html) to check the encoded msg, and it passed the decoding.
Therefore I was able to get the values on what they should be.

Now I’m trying to understand how the subtraction length is supposed to work.

Here’s a table I derived theoretically from that message(i.e. what the values should be):

prevValue subtractLength nextValue

NULL 0 48=9993001

NULL 1 55=TF0Z99

NULL 1 455=999030

999030 4 455=9993001

9993001 8 455=BRBMEFTF0N30

NULL 1 107=ENGINE 3

9993001 7 48=4800560 ←
TF0Z99 7 55=WING12 ←
BRBMEFTF0N30 13 455=480056

480056 1 455=4800560

4800560 8 455=BRBMEFWIN197

For the arrow lines, how come the subtractLength is 7 for both prevValue, 9993001 is size 7 while TF0Z99 is size 6?

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.

Is this correct? Or should be the subtraction length be 6 in this case.

Thanks.

Our stable FIXFAST lib has run into a decoding problem against the msg encoded from the following XML. The problem happened at dealing with fields such as SecurityID and Symbol which are defined as strings with Delta operation.

[xml snipped]

The XML is syntactically valid.

You didn’t specify what was going wrong. “run into a decoding problem” is a bit vague.

Can you instrument the generated code? You need to see the dictionary value, the subtraction length, the delta value, and the resulting string to determine if the string delta operation is being applied correctly.

You might also try decoding the data with OpenFAST or QuickFAST to determine whether the problem lies in the encoded data or the generated decoder.

Dale

6

I’m not sure experimenting with one set of data is a useful way to determine how FAST encoding/decoding works.

Read the documentation that you can download from here: http://www.fixprotocol.org/fast

You will discover for example that a NULL prior value and a 1 subtraction value should produce an ERR D7.

It may be you are confusing an empty string with a string containing only a null character. These are distinct cases. The second case cannot be represented using a traditional C string, but it can be represented in C++ in an std::string containing a single null character.

Dale

I used FAST Interoperability Portal (http://fast.fixprotocol.org/templates.html) to check the encoded msg, and it passed the decoding.
Therefore I was able to get the values on what they should be.

Now I’m trying to understand how the subtraction length is supposed to work.

Here’s a table I derived theoretically from that message(i.e. what the values should be):

prevValue subtractLength nextValue

NULL 0 48=9993001

NULL 1 55=TF0Z99

NULL 1 455=999030

999030 4 455=9993001

9993001 8 455=BRBMEFTF0N30

NULL 1 107=ENGINE 3

9993001 7 48=4800560 ←
TF0Z99 7 55=WING12 ←
BRBMEFTF0N30 13 455=480056

480056 1 455=4800560

4800560 8 455=BRBMEFWIN197

For the arrow lines, how come the subtractLength is 7 for both prevValue, 9993001 is size 7 while TF0Z99 is size 6?

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.

Is this correct? Or should be the subtraction length be 6 in this case.

Thanks.

Our stable FIXFAST lib has run into a decoding problem against the msg encoded from the following XML. The problem happened at dealing with fields such as SecurityID and Symbol which are defined as strings with Delta operation.

[xml snipped]

The XML is syntactically valid.

You didn’t specify what was going wrong. “run into a decoding problem” is a bit vague.

Can you instrument the generated code? You need to see the dictionary value, the subtraction length, the delta value, and the resulting string to determine if the string delta operation is being applied correctly.

You might also try decoding the data with OpenFAST or QuickFAST to determine whether the problem lies in the encoded data or the generated decoder.

Dale

7

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.
Is this correct? Or should be the subtraction length be 6 in this case.

The \0 character is not special in FAST. It is a first class character that may anywhere in a string (although it does trigger extra some encoding/decoding issues when it is the first character.) Thus in your example the subtraction value is 6 (unless there is an invisible \0 somewhere in your example.)

A subtraction value of seven in this case should trigger an ERR D7 error. Because this is a dynamic error a compliant FAST decoder is required to report this.

8

Hello Charles,

We have two different cases for

The first one is when presence = optional and the second one is when the field is mandatory.

If a field can be mandatory or optional, and if it is actually composed of two parts (in delta strings, there is an int component that gives the subtraction length, and there is the string component), the first part is encoded as mandatory or optional (i.e., the integer part is encoded as mandatory or optional – for instance, the value 7 can be encoded as 0x87 if mandatory, 0x88 if optional) and the second part is considered as mandatory (in this case, the string part).

The SecurityID field is mandatory (so the value for the subtraction length is encoded as a mandatory integer – it is “unchanged”), but the SecurityDescription is optional (so the value for the subtraction length is encoded as an optional integer, i.e., we need to add +1 to the value in order to have the “NULL” integer value available for encoding).

Hope this helps,

Julio Monteiro
BM&FBovespa Trading Systems Department

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.

Is this correct? Or should be the subtraction length be 6 in this case.

Thanks.

Our stable FIXFAST lib has run into a decoding problem against the msg encoded from the following XML. The problem happened at dealing with fields such as SecurityID and Symbol which are defined as strings with Delta operation.

[xml snipped]

The XML is syntactically valid.

You didn’t specify what was going wrong. “run into a decoding problem” is a bit vague.

Can you instrument the generated code? You need to see the dictionary value, the subtraction length, the delta value, and the resulting string to determine if the string delta operation is being applied correctly.

You might also try decoding the data with OpenFAST or QuickFAST to determine whether the problem lies in the encoded data or the generated decoder.

Dale

9

Hi Julio,

Is there any chance that the “Message examples” section on this site:
http://www.bmfbovespa.com.br/en-us/services/market-data/UMDF.aspx?Idioma=en-us
will be updated with these newer FAST data?

I would be very interested in testing these newer data feeds.

-Mike

We have two different cases for

The first one is when presence = optional and the second one is when the field is mandatory.

If a field can be mandatory or optional, and if it is actually composed of two parts (in delta strings, there is an int component that gives the subtraction length, and there is the string component), the first part is encoded as mandatory or optional (i.e., the integer part is encoded as mandatory or optional – for instance, the value 7 can be encoded as 0x87 if mandatory, 0x88 if optional) and the second part is considered as mandatory (in this case, the string part).

The SecurityID field is mandatory (so the value for the subtraction length is encoded as a mandatory integer – it is “unchanged”), but the SecurityDescription is optional (so the value for the subtraction length is encoded as an optional integer, i.e., we need to add +1 to the value in order to have the “NULL” integer value available for encoding).

Hope this helps,

Julio Monteiro
BM&FBovespa Trading Systems Department

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.

Is this correct? Or should be the subtraction length be 6 in this case.

Thanks.

10

Hello Mike,

We are expecting to upload new FAST example data compatible with this template version until the end of next week.

Thank you for your interest in testing!

Best regards,
Julio Monteiro
BM&FBovespa Trading Systems Department

Hi Julio,

Is there any chance that the “Message examples” section on this site:
http://www.bmfbovespa.com.br/en-us/services/market-data/UMDF.aspx?Idioma=en-us
will be updated with these newer FAST data?

I would be very interested in testing these newer data feeds.

-Mike

We have two different cases for

The first one is when presence = optional and the second one is when the field is mandatory.

If a field can be mandatory or optional, and if it is actually composed of two parts (in delta strings, there is an int component that gives the subtraction length, and there is the string component), the first part is encoded as mandatory or optional (i.e., the integer part is encoded as mandatory or optional – for instance, the value 7 can be encoded as 0x87 if mandatory, 0x88 if optional) and the second part is considered as mandatory (in this case, the string part).

The SecurityID field is mandatory (so the value for the subtraction length is encoded as a mandatory integer – it is “unchanged”), but the SecurityDescription is optional (so the value for the subtraction length is encoded as an optional integer, i.e., we need to add +1 to the value in order to have the “NULL” integer value available for encoding).

Hope this helps,

Julio Monteiro
BM&FBovespa Trading Systems Department

Thanks Dale.
The “problem” is with the subtraction length for string delta operation.
For example, when the prev value is “ABCDEF”, the next value should be “WING12”. what should the subtraction length be?
Currently the exchange conveys 7, which counts the \0 for a c-string.

Is this correct? Or should be the subtraction length be 6 in this case.

Thanks.