MDEntryType(269) is a Char

, ,
1

Imported from previous forum

2

We developed Market Data service based on v4.2, supporting 0, 1, 2 and adding a few custom MDEntryType=L,M,N, etc. No clash with v4.4 either.

We wanted to use ‘A’, ‘C’ but found they clash in v4.4. And more serious is that our custome MDEntryType(269)=L, M, N clash in v5.0.

Would anyone please advise how we can avoid clashing with the standard moving forward? Since we can anticipate what other letters will be used.

I have in mind using lowercase letter in the range ‘a-z’ for custome MDEntryType. Is that advisable?

What other options do we have?

Thanks.
cs

3

I am surprised that you are able to use custom enum values in the first place. You should normally get a syntax error from your FIX engine for that. Normally you would use custom fields with a name similar to the standard field name where you can use whatever value you want. This would also avoid any overlaps with enum values being introduced in higher versions.

Some fields with numerical enum values have reserved the 100+ range for custom values to address your issue. This is not the case for MDEntryType.

Regards,
Hanno.

We developed Market Data service based on v4.2, supporting 0, 1, 2 and
adding a few custom MDEntryType=L,M,N, etc. No clash with v4.4 either.

We wanted to use ‘A’, ‘C’ but found they clash in v4.4. And more serious
is that our custome MDEntryType(269)=L, M, N clash in v5.0.

Would anyone please advise how we can avoid clashing with the standard
moving forward? Since we can anticipate what other letters will be used.

I have in mind using lowercase letter in the range ‘a-z’ for custome
MDEntryType. Is that advisable?

What other options do we have?

Thanks. cs

4

That depends on the engine. For engines like QuickFix, a modification to the data dictionary (available in XML files, one for each FIX version) suffices for allowing custom enums to be used.

I agree with Hanno about the usage of MDEntryType, since it is not provisioned in the spec that this tag can have custom enum values. But at the same time, I do understand that it is very possible that one may have specific information that falls into the Market Data category and is not covered by the specification. The limitation of the enum values then represents an issue. One option would be to use a separate message to convey your data, but that may not fullfil the necessities of your architecture.

Doing a quick browse on the current FIX specs of a few Exchanges, there was at least one case of collisions of custom MDEntryType values with new values inserted in 5.0. For a better answer to your question, you may have better luck bringing it up with the Market Data Optimization Group.

Regards,
Jochen

I am surprised that you are able to use custom enum values in the first
place. You should normally get a syntax error from your FIX engine for
that. Normally you would use custom fields with a name similar to the
standard field name where you can use whatever value you want. This
would also avoid any overlaps with enum values being introduced in
higher versions.

Some fields with numerical enum values have reserved the 100+ range for
custom values to address your issue. This is not the case for
MDEntryType.

Regards, Hanno.

We developed Market Data service based on v4.2, supporting 0, 1, 2 and
adding a few custom MDEntryType=L,M,N, etc. No clash with v4.4 either.

We wanted to use ‘A’, ‘C’ but found they clash in v4.4. And more
serious is that our custome MDEntryType(269)=L, M, N clash in v5.0.

Would anyone please advise how we can avoid clashing with the
standard moving forward? Since we can anticipate what other letters
will be used.

I have in mind using lowercase letter in the range ‘a-z’ for custome
MDEntryType. Is that advisable?

What other options do we have?

Thanks. cs