Parsing Repeating Groups.

, ,
1

Imported from previous forum

2

I am having problems with writing a general algorithm for parsing repeating groups. It seems to me that one should be able to use the first field of the repeating group as a delimiter. What I don’t understand is how to find the last field of the last repeating group. How do I know whether a tag is part of the last repeated group, or the first tag after the repeated groups? It seems to me that a field might either be “a first occurence” or the first field after the repeated groups. (I have assumed that optional fields may be specified in some repeated groups, but not necessarily in all. Is this correct?)

I am grateful for any replies.

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I am having problems with writing a general algorithm for parsing repeating groups. It seems to me that one should be able to use the first field of the repeating group as a delimiter. What I don’t understand is how to find the last field of the last repeating group. How do I know whether a tag is part of the last repeated group, or the first tag after the repeated groups? It seems to me that a field might either be “a first occurence” or the first field after the repeated groups. (I have assumed that optional fields may be specified in some repeated groups, but not necessarily in all. Is this correct?)

Certain tags are defined to be part of repeating groups. These are listed in indented bold italics in the 4.0 and 4.1 specs, and the 4.2 spec improves their formatting substantially. This also becomes important because 4.2 has repeating groups within repeating groups.

For instance, to use a simple example from an older spec, the 4.1 Allocation, one repeating group begins with NoExecs. The fields LastShares, ExecID, LastPx, LastCapacity are all considered part of that repeating group. You know you are done when you see any field not part of that repeating group, i.e. you see Side, Symbol, etc.

This logic does fail if someone adds a field not normally in the group. It is very important to clarify any user-defined fields on each FIX connection; this is even more important when a repeating group is involved. Now you can protect against that somewhat by ignoring all >=5000 tags not already pre-configured, so the presence of something user-defined in that repeating group would not cause an issue. But if someone puts a field in that group normally not considered part of that group, i.e. TransactTime, then you have a problem in parsing it.