Imported from previous forum
I’ve read the previous messages about repeating groups to see if they are applicable to my particular problem. Some of the questions are quite relevant but the responses don’t answer my question.
There is no specific delimiter for the end of a group. It is possible that a field may be used in a group and outside of it. It is possible that a field may be in a repeating group and also immediately follow the group, preventing detection of the end of the group.
Here’s an example of the logic that I am having problems with:
tag definitions
p1
p2
p3
p4
n1
r1
r2
r3
repeating group defined as
n1 = number of repeats in this group
r1, r2, r3, p3 = elements of this group in
order
Message comes across as:
p1
p2
n1 = 4
r1, r2, p3
r1, r3, p3
r1, r2
r1
p3
p4
If P3 is defined as part of a repeating group and also as a field that can occur as part of the primary message, how do I programmatically determine whether or not the last P3 is part of the group or part of the primary message?
= = = = =
From the spec I have the following:
- 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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.
· If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a "delimiter" indicating a new repeating group entry.
· The NoXXX field which specifies the number of repeating group instances occurs once for a repeating group and must immediately precede the repeating group contents.
= = = = =
If someone could please clarify the logic required to parse this message format, or confirm that the protocol “has a hole” and there’s no real work-around, I’d sincerely appreciate it.
Thanks,
Frank LaPiana
A FIX message should not specify that a given tag appear both within a repeating group and outside of that repeating group. Any such cases would be considered an error in the spec which should be corrected via an Errata.
> I’ve read the previous messages about repeating groups to see if they are applicable to my particular problem. Some of the questions are quite relevant but the responses don’t answer my question.
>
> There is no specific delimiter for the end of a group. It is possible that a field may be used in a group and outside of it. It is possible that a field may be in a repeating group and also immediately follow the group, preventing detection of the end of the group.
>
> Here’s an example of the logic that I am having problems with:
>
> tag definitions
> p1
> p2
> p3
> p4
> n1
> r1
> r2
> r3
>
> repeating group defined as
> n1 = number of repeats in this group
>
> r1, r2, r3, p3 = elements of this group in
> order
>
> Message comes across as:
> p1
> p2
> n1 = 4
> r1, r2, p3
> r1, r3, p3
> r1, r2
> r1
> p3
> p4
>
> If P3 is defined as part of a repeating group and also as a field that can occur as part of the primary message, how do I programmatically determine whether or not the last P3 is part of the group or part of the primary message?
>
> = = = = =
> From the spec I have the following:
>
> 4. 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. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.
>
> · If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a “delimiter” indicating a new repeating group entry.
>
> · The NoXXX field which specifies the number of repeating group instances occurs once for a repeating group and must immediately precede the repeating group contents.
>
> = = = = =
>
> If someone could please clarify the logic required to parse this message format, or confirm that the protocol “has a hole” and there’s no real work-around, I’d sincerely appreciate it.
>
> Thanks,
> Frank LaPiana
>
>