Imported from previous forum
As defined in the FIX 4.3 specification messages of type Trade Capture
Report and Mass Quote Acknowledgement cannot always be parsed
unambiguously.
These are the only two FIX 4.3 messages where fields with the same tag
id appear more than once in the definition of the message as it appears
in the specification.
In Trade Capture Report (MsgType = AE) the fields SettImntTyp (#63) and
FutSetDate (#64) appear near the beginning of the message and again
latter in a repeating group.
So the following sequeuce (where ‘+’ indicates <SOH>):
+63=A+64=B+552=1+37=C+
Can be parsed unambiguously as:
SettImntTyp = A
FutSetDate = B
NoSides = 1
-> OrderID = C
But the following sequence:
+552=1+37=C+63=D+64=E
Can be parsed as either:
NoSides = 1
-> OrderID = C
-> SettImntTyp = D
-> FutSetDate = E
Or as:
NoSides = 1
-> OrderID = C
SettImntTyp = D
FutSetDate = E
I.e. there is no way to determine whether SettImntTyp and FutSetDate are
part of the repeating group. In the specification they are marked as
optional elements of both the containing message and the repeating
group.
The FIX specification states:
"Except where noted, fields within a message can be defined in any
sequence (Relative position of a field within a message is
inconsequential.)"
"Fields within repeating data groups must be specified in the order that
the fields are specified in the message definition within the FIX
specification document."
So while in the specification SettImntTyp and FutSetDate are listed
first above the repeating group that also contains them it is valid in
an actual message to place an instance of SettImntTyp and FutSetDate
(that correspond to the first appearance in the specification) below an
instance of the repeating group that may or may not also contain
instances of them.
So for the example sequence shown above it is not possible to tell
whether the SettImntTyp and FutSetDate are part of the repeating
sequence or correspond to the the SettImntTyp and FutSetDate listed
before the repeating sequence in the specification.
This problem also occurs for the fields TradingSessionID (#336) and
TradingSessionSubID (#625) in the definition of the Mass Quote
Acknowledgement (MsgType = b).
These problems were introduced as the result of changes made for 4.3 -
they don’t appear in 4.2.
In 4.2 a similar problem occurs with Text, EncodedTextLen and
EncodedText appearing twice in List Status. Somebody obviously spotted
this problem as it is fixed in 4.3 with a new sequence of tags,
ListStatusText, EncodedListStatusTextLen and EncodedListStatusText
introduced to replace the first instance of the repeated sequence that
appeared in 4.2.
The fact that this fix for List Status was introduced in 4.3 implies to
me that someone was aware of this kind of problem but no one checked the
changes introduced in 4.3 to make sure the same problem was not
introduced to any messages as a result.
This problem does not occur in any messages in 4.0 or 4.1.
I’d appreciate any comments on this - especially if you think this is
not a specification bug (I’ve talked this through with a number of
people and they all started off refuting my assetion only to eventually
agree after some argument so please think carefully about what I’ve
said).
The reason this problem occurs is the line already quoted from the
specification:
"Except where noted, fields within a message can be defined in any
sequence (Relative position of a field within a message is
inconsequential.)"
If the fields in FIX messages had to be ordered as they appear in the
specification document (as is the case for fields within repeating
sequences) there’d be no problem.
Looking forward and interested to hearing from you - yours,
George.
WebSphere MQSeries Integrator Adapter Development - IBM Dublin
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
George,
You are correct in your analysis. These are errors in the specification. I believe both have been caught as errata items.
Here is the reply regarding Trade Capture Report posted by Sandy Dinetz from DTCC to an earlier post:
"These tags should only be defined once. They should be in the message body, not within the NoSides block. Thanks for pointing this out, as it is an error.
Sandy Dinetz
DTCC"
Regarding the Mass Quote Acknowledgement, the TradingSessionID(336) and TradingSessionSubID(625) should be in the repeating group only - not in the beginning of the message. TradingSessionID was moved to the repeating group to provide more flexibility in generating quotes for multiple trading sessions. We forgot to remove it from the base message at that time.
Both of these items have been captured as errata items.
Jim
> As defined in the FIX 4.3 specification messages of type Trade Capture
> Report and Mass Quote Acknowledgement cannot always be parsed
> unambiguously.
>
> These are the only two FIX 4.3 messages where fields with the same tag
> id appear more than once in the definition of the message as it appears
> in the specification.
>
> In Trade Capture Report (MsgType = AE) the fields SettImntTyp (#63) and
> FutSetDate (#64) appear near the beginning of the message and again
> latter in a repeating group.
>
> So the following sequeuce (where ‘+’ indicates <SOH>):
>
> +63=A+64=B+552=1+37=C+
>
> Can be parsed unambiguously as:
>
> SettImntTyp = A
> FutSetDate = B
> NoSides = 1
> -> OrderID = C
>
> But the following sequence:
>
> +552=1+37=C+63=D+64=E
>
> Can be parsed as either:
>
> NoSides = 1
> -> OrderID = C
> -> SettImntTyp = D
> -> FutSetDate = E
>
> Or as:
>
> NoSides = 1
> -> OrderID = C
> SettImntTyp = D
> FutSetDate = E
>
> I.e. there is no way to determine whether SettImntTyp and FutSetDate are
> part of the repeating group. In the specification they are marked as
> optional elements of both the containing message and the repeating
> group.
>
> The FIX specification states:
>
> “Except where noted, fields within a message can be defined in any
> sequence (Relative position of a field within a message is
> inconsequential.)”
>
> “Fields within repeating data groups must be specified in the order that
> the fields are specified in the message definition within the FIX
> specification document.”
>
> So while in the specification SettImntTyp and FutSetDate are listed
> first above the repeating group that also contains them it is valid in
> an actual message to place an instance of SettImntTyp and FutSetDate
> (that correspond to the first appearance in the specification) below an
> instance of the repeating group that may or may not also contain
> instances of them.
>
> So for the example sequence shown above it is not possible to tell
> whether the SettImntTyp and FutSetDate are part of the repeating
> sequence or correspond to the the SettImntTyp and FutSetDate listed
> before the repeating sequence in the specification.
>
> This problem also occurs for the fields TradingSessionID (#336) and
> TradingSessionSubID (#625) in the definition of the Mass Quote
> Acknowledgement (MsgType = b).
>
> These problems were introduced as the result of changes made for 4.3 -
> they don’t appear in 4.2.
>
> In 4.2 a similar problem occurs with Text, EncodedTextLen and
> EncodedText appearing twice in List Status. Somebody obviously spotted
> this problem as it is fixed in 4.3 with a new sequence of tags,
> ListStatusText, EncodedListStatusTextLen and EncodedListStatusText
> introduced to replace the first instance of the repeated sequence that
> appeared in 4.2.
>
> The fact that this fix for List Status was introduced in 4.3 implies to
> me that someone was aware of this kind of problem but no one checked the
> changes introduced in 4.3 to make sure the same problem was not
> introduced to any messages as a result.
>
> This problem does not occur in any messages in 4.0 or 4.1.
>
> I’d appreciate any comments on this - especially if you think this is
> not a specification bug (I’ve talked this through with a number of
> people and they all started off refuting my assetion only to eventually
> agree after some argument so please think carefully about what I’ve
> said).
>
> The reason this problem occurs is the line already quoted from the
> specification:
>
> “Except where noted, fields within a message can be defined in any
> sequence (Relative position of a field within a message is
> inconsequential.)”
>
> If the fields in FIX messages had to be ordered as they appear in the
> specification document (as is the case for fields within repeating
> sequences) there’d be no problem.
>
> Looking forward and interested to hearing from you - yours,
>
>
> George.
>
> WebSphere MQSeries Integrator Adapter Development - IBM Dublin
>
>