Imported from previous forum
[ original email was from dan leman - dan.leman@sungard.com ]
When attempting to send a single allocation with more then 50-70 allocation details, an overflow occurs in the BodyLength Tag (tag 9 in Message Header - data type int). HAs anyone lese encounterd this problem and is there a suggested work around available for FIX 4.0.
Allocation messages with a large number of repeating group instances will generate large (in FIX terms) messages. As of FIX 4.2 (March 2000), the spec removed the "end range value" (or max value) of 9999. That value in prior versions was somewhat arbitrary and it became obvious that such a restriction should not be imposed by the spec.
I would recommend that you attempt to gain counterparty agreement to bi-laterally support BodyLength values > 9999 in FIX versions prior to 4.2 for such a problem.
> When attempting to send a single allocation with more then 50-70 allocation details, an overflow occurs in the BodyLength Tag (tag 9 in Message Header - data type int). HAs anyone lese encounterd this problem and is there a suggested work around available for FIX 4.0.
>
[ original email was from Chris Lambert - chris.lambert@cmg.com ]
> When attempting to send a single allocation with more then 50-70 allocation details, an overflow occurs in the BodyLength Tag (tag 9 in Message Header - data type int). Has anyone lese encounterd this problem and is there a suggested work around available for FIX 4.0.
The overflow is because in FIX 4.0 BodyLength was restricted to 4 chars (i.e. max 9999), rather than because it is an ‘int’ (i.e. no decimal point). This restriction was removed in FIX 4.2 (released in 2000).
If this is a correct analysis of your situation then possible workrounds might be to upgrade to FIX 4.2 or, if this is not possible for now, have the FIX engine vendor remove the validation/limitation on BodyLength.