Imported from previous forum
I was just wondering why is the data type for MassOrderRequestID (Tag 2423) a string whereas other identifiers such as OrderEntryID (Tag 2430) and OrderRequestID (Tag 2422) are integers? Shouldn’t MassOrderRequestID also be designated as an integer?
MassOrderRequestID follows the regular practice of using a String datatype to also allow alphanumeric identifiers. Some encodings such as SBE and FAST allow to override this in a specific implementation and reduce it to a subset, e.g. integer.
OrderEntryID (entitiy ID) and OrderRequestID (message ID) are in addition to the existing ClOrdID which is a message as well as entity identifier and has a String datatype. You can use ClOrdID if you do not have a purely numerical identifier. The new ID fields were part of EP188 which is about a high performance application layer.
Regards,
Hanno.
Just to clarify isn’t MassOrderRequestID also part of EP188 and isn’t it similar to OrderRequestID? Therefore it should also be integer and not string. These fields are just message identifiers so they don’t come with the overhead associated with CIOrdID.
The way I understand it is that MassOrderRequestID is not similar to CIOrdID therefore it need not be a string.
When using SBE as encoding for high performance, you can reduce the set of valid values from string to integer, i.e. override the standard FIX datatype defined for tag=value and FIXML. We change data types only in very special cases, e.g. timestamp precision to supprt MiFID II.
This is interesting, so does this mean that we could change the semantic type of a field in SBE to be something different than how it is defined in FIX? For example if account has semantic type string but if we would like to use it as integer then I would imagine that the semantic type should also be integer and not string otherwise there will be a mismatch between the binary data type and the semantic type but on the other hand that will also be taking away from how the field is defined for usage in FIX.
No, the semantic type if the FIX data type. You can change the actual type on the wire. It must always allow translation/conversion into the semantic type. For example, if FIX defines something as an integer, you cannot use a semantic type of integer and an actual type of string because you then cannot convert the field into a tag-value encoding. The principle is comparable to FAST but without an explicit reference to the FIX data type from the repository.
Okay thanks so just to clarify both of these examples are not recommended then:
field name=“VersionID” id=“52007” type=“uInt32” description=“VersionID” offset=“38” semanticType=“string”/
field name=“VersionID” id=“52007” type=“string” description=“VersionID” offset=“38” semanticType=“int”/
If I understand your examples correctly then the first is ok (reduction of FIX type string to uint32) and the second is not ok (FIX already reduces it to int and you want to open it up for strings.
But does id=“52007” mean it is a user-defined field? The range above 40000 is reserved for FIX and must not be used.
Okay got it, please don’t worry about 52007, that was only a dummy value