How was FIXimate built for FIX.5.0SP2?

, ,
1

Imported from previous forum

2

[ original email was from John Prewett - jprewett@lavatrading.com ]
Looking in MsgContents.xml for MsgID=1024 (StandardHeader), I can see: Position 1 = Tag 8 (BeginString) Position 2 = Tag 9 (BodyLength) Position 3 = Tag 35 (MsgType) ->Position 4 = Tag 49 (SenderCompID) Using FIXimate for FIX.5.0SP2, I can see: Position 1 = Tag 8 (BeginString) Position 2 = Tag 9 (BodyLength) Position 3 = Tag 35 (MsgType) ->Position 4 = Tag 1128 (ApplVerID) Should these be different? Thanks JohnP

3

John I think this has to do with the Position being viewed as an integer instead of decimal - also values in MsgContents.xml

FIXimate is consistent with MsgContents and is derived from it.

But you ask a good question I would like to answer on creation of FIXimate.3.0

A single XSLT 2.0 script integrates the production repository into the unified repository. The unified repository is then used by another XSLT 2.0 script (fairly sophisticated little program) to produce FIXimate3.0.

Looking in MsgContents.xml for MsgID=1024 (StandardHeader), I can see:
Position 1 = Tag 8 (BeginString) Position 2 = Tag 9 (BodyLength)
Position 3 = Tag 35 (MsgType) ->Position 4 = Tag 49 (SenderCompID)

Using FIXimate for FIX.5.0SP2, I can see: Position 1 = Tag 8
(BeginString) Position 2 = Tag 9 (BodyLength) Position 3 = Tag 35
(MsgType) ->Position 4 = Tag 1128 (ApplVerID)

Should these be different?

Thanks

JohnP