Imported from previous forum
[ original email was from Kevin J Houstoun - 106333.2651@compuserve.com ]
Is 9=0056 a fix compliant message length?
As opposed to 9=56 ?
We’ve just come across an engine which impliments the fix message length as 9=00NN eg pads all numbers to the max integer length. This is the only integer field it does handle this way all others are handled as ‘normally’
My thoughts are that this is not strictly fix compliant but we should handle it anyway.
Any other views
[ original email was from Bob Lamoureux - blamoureux@bridge.com ]
> Is 9=0056 a fix compliant message length?
>
> As opposed to 9=56 ?
>
First off, let me disclose that this is my FIX engine you are talking about. Just so everyone knows where I’m coming from. Since the very begining, the message length field has been padded out. In earlier specs, it was actaully specified that way. In 4.0 the padding was removed for people who didn’t want to pad, but padding itself should still be valid. Since the field is a decinal number, not to be confused with octal (because of the leading 0), this should pose no problems. The reason this number is padded out in my FIX engine is that I do not know beforehand how long this number will be (9999 is the max my engine will handle) So I pad it out with “9=0000” and then go back and overwrite it later. Other decimal numbers are known before writing them out so they dont need to be padded, but there is nothing in the spec to prevent them from being padded either !?!
I think you should handle this in your FIX engine. As you test with others, you will find that this is not unusual. I have tested with over 20 FIX engines that do the same sort of padding…
Bob Lamoureux
Bridge Information Systems
> We’ve just come across an engine which impliments the fix message length as 9=00NN eg pads all numbers to the max integer length. This is the only integer field it does handle this way all others are handled as ‘normally’
>
> My thoughts are that this is not strictly fix compliant but we should handle it anyway.
>
> Any other views
>
> KevinH@csi.com
>
[ original email was from Kevin J Houstoun - 106333.2651@compuserve.com ]
Sorry I’ve only seen the specs for versions 2.7 thru 4.1.
I’ve tested with 8 other FIX engines and can reveal that this was the first engine that did this. However one other engine did this in beta but not in the later versions.
Also I’ve been told one I’m due to test with next week does this too.
I agree that it makes it easier to code if you assume this field is always 4 digits but people need to be aware of this possible assumption when decoding hence my posting.
I also agree that we should handle it but if it is ‘part of the spec’ it should be included in the spec.
> > Is 9=0056 a fix compliant message length?
> >
> > As opposed to 9=56 ?
> >
> First off, let me disclose that this is my FIX engine you are talking about. Just so everyone knows where I’m coming from. Since the very begining, the message length field has been padded out. In earlier specs, it was actaully specified that way. In 4.0 the padding was removed for people who didn’t want to pad, but padding itself should still be valid. Since the field is a decinal number, not to be confused with octal (because of the leading 0), this should pose no problems. The reason this number is padded out in my FIX engine is that I do not know beforehand how long this number will be (9999 is the max my engine will handle) So I pad it out with “9=0000” and then go back and overwrite it later. Other decimal numbers are known before writing them out so they dont need to be padded, but there is nothing in the spec to prevent them from being padded either !?!
>
> I think you should handle this in your FIX engine. As you test with others, you will find that this is not unusual. I have tested with over 20 FIX engines that do the same sort of padding…
>
> Bob Lamoureux
> Bridge Information Systems
>
>
> > We’ve just come across an engine which impliments the fix message length as 9=00NN eg pads all numbers to the max integer length. This is the only integer field it does handle this way all others are handled as ‘normally’
> >
> > My thoughts are that this is not strictly fix compliant but we should handle it anyway.
> >
> > Any other views
> >
> > KevinH@csi.com
> >
>