Tag Missing Error is ambiguous for Security Definition Response when repeating groups tag count varies.

[doconnellRJO]

When using a FIX XML Dictionary to map inbound security definition response messages a missing tag error is generated which correctly indicates the missing tag number to add or edit.

However, when a security definition response message with multiple subgroups is parsed and found to have varying counts of tags between the subgroups a missing tag number is generated but references the first tag field that is not expected, rather then the first missing field. Another way is to say the missing tag(s) is not indicated, but the next mapped tag in the FIX XML dictionary.

The parsing logic for subgroups should indicate via a tag missing error the first missing field from the FIX XML Dictionary subgroup, as it does correctly when subgroups share the same number of fields. A suggestion would be to continue parsing the correct security definition subgroups and indicate an error in one of the subgroups, rather then reject the entire group.

In the scenario that exposed this issue a security definition response with 49 subgroups was received but threw away the entire response when the 14th subgroup was found to have a missing tag that was not in the FIX XML dictionary that the previous 13 subgroup did have. The missing tag error indicated a missing field that was clearly present and defined, which made finding the actual missing a tag a multi day challenge.

[gbirchmeier]

Can you be more specific about the situation that triggered this issue? Can you paste the actual "missing tag error" message that you saw?

Also, what was the group, and what was the "missing tag"?

And this whole sentence doesn't entirely make sense to me:

the 14th subgroup was found to have a missing tag that was not in the FIX XML dictionary that the previous 13 subgroup did have.

I think what you meant was:

the 14th subgroup included a tag that was not in our FIX XML; the previous 13 subgroups did not have this tag.

Is that more accurate?

[doconnellRJO]

Hi gbichmeier,

I would agree with the second statement, and yes it is more accurate to our situation.

The message indicated here:
8=FIX.4.2�9=118�35=3�34=24�49=####50=########52=20150916-22:00:18.687�56=###�45=1331�58=Tag appears more than once�371=9014�372=d�10=229�

Here is a comparison between the two subgroups:

311=5091396 �309=MPE FMU0015! �308=IFLL�305=8 �313=201509�314=18�9013=0.050 �9040=0.050 �9041=1.0 �307=MSCI Europe NTR (EUR) - Stnd Index Future - ICEU - Sep15 �763=0�1039=C�9014=1.0�9017=100.0�326=18�998=point �318=EUR�9083=3�9084=0�9061=15524�9030=1�9031=1�9032=0.050�9091=IFLL.MPE�9092=1�9093=0�9094=1.0�9095=Futures

311=91956461�309=L FMZ0015_OMCA0000950003121615�308=IFLL�305=8�310=OPT �313=201512�314=16�9013=0.0050�9040=0.0050�9041=1.0�315=1�316=95.000�9041=1.0�307=Three Month Sterling Future - ICEU - Dec15 �763=0�1039=P�9014=1.0�9017=1250 �326=18�998=Value per whole point �318=GBP�9083=4 �9085=3�9032=6.2500

[gbirchmeier]

And which was the field that was missing from your XML file?

[doconnellRJO]

The field was NoUnderlyingSecurityAltID which itself had a subgroub of 2 other tags:

From Security Definition Response Fields:
group name="NoUnderlyingSecurityAltID" required="N">
field name="UnderlyingSecurityAltID" required="N"/>
field name="UnderlyingSecurityAltIDSource" required="N"/>
/group

From Field Definitions:

field number="457" name="NoUnderlyingSecurityAltID" type="INT" />
field number="458" name="UnderlyingSecurityAltID" type="STRING" />
field number="459" name="UnderlyingSecurityAltIDSource" type="STRING" />