Imported from previous forum
[ original email was from Carlyle Gordon - junk@gordonvideo.com ]
What happens when a new exchange mnemonic is created and your current FIX version obviously does not yet know this new mnemonic? Will you need to use the next version of FIX(assuming it will include this new mnemonic)? Or can you just update your OMS somehow and recertify all your connections?
How are expected values validated in fix? For example in FIX 4.0 for tag <125>, the only valid values are “P” and “F”(not sure on case). What if I send “125=r”? What happens exactly? Where does this get stopped and how does what ever stops this actually stop it? Where are the list of acceptable values stored for validation? My guess is the OMS.
[ original email was from Kevin Young - kyoung@youngfe.com ]
Answers to your questions really rely on the FIX engine you are using. See http://www.fixprotocol.org/implementation-guide/engine.shtml for more details about Implementing FIX with FIX engines.
I’m not quite sure what you mean by a new exchange mnemonic, but there is no field for mnemonic. Most likely, you will be passing a configurable value via your FIX engine in one of several fields to identify the exchange (ExDestination, TargetCompID, TargetSubID, etc). You will not need to upgrade to the next version, you will need to define a field value to be passed via your FIX engine.
Values are validated by the receiving FIX engine. Most FIX engines have an xml definition file or data dictionary describing the fields, it’s properties as well as it’s valid values. Per your example, unless the receiving FIX engine adds ‘R’ as an enum/option, then most likely the FIX engine will reject your cancel.
What happens when a new exchange mnemonic is created and your current
FIX version obviously does not yet know this new mnemonic? Will you need
to use the next version of FIX(assuming it will include this new
mnemonic)? Or can you just update your OMS somehow and recertify all
your connections?How are expected values validated in fix? For example in FIX 4.0 for tag
<125>, the only valid values are “P” and “F”(not sure on case). What if
I send “125=r”? What happens exactly? Where does this get stopped and
how does what ever stops this actually stop it? Where are the list of
acceptable values stored for validation? My guess is the OMS.
[ original email was from Carlyle Gordon - junk@gordonvideo.com ]
The tag in question is tag 30, which is LastMkt. Valid values are Exchange mnemonics such as
Answers to your questions really rely on the FIX engine you are using. See http://www.fixprotocol.org/implementation-guide/engine.shtml for more details about Implementing FIX with FIX engines.
I’m not quite sure what you mean by a new exchange mnemonic, but there
is no field for mnemonic. Most likely, you will be passing a
configurable value via your FIX engine in one of several fields to
identify the exchange (ExDestination, TargetCompID, TargetSubID, etc).
You will not need to upgrade to the next version, you will need to
define a field value to be passed via your FIX engine.Values are validated by the receiving FIX engine. Most FIX engines have
an xml definition file or data dictionary describing the fields, it’s
properties as well as it’s valid values. Per your example, unless the
receiving FIX engine adds ‘R’ as an enum/option, then most likely the
FIX engine will reject your cancel.What happens when a new exchange mnemonic is created and your current
FIX version obviously does not yet know this new mnemonic? Will you
need to use the next version of FIX(assuming it will include this new
mnemonic)? Or can you just update your OMS somehow and recertify all
your connections?How are expected values validated in fix? For example in FIX
4.0 for tag
<125>, the only valid values are “P” and “F”(not sure on case). What
if I send “125=r”? What happens exactly? Where does this get
stopped and how does what ever stops this actually stop it? Where
are the list of acceptable values stored for validation? My guess
is the OMS.
[ original email was from Kevin Young - kyoung@youngfe.com ]
The same would apply; the receiving FIX engine would have to define an agreed upon value in their xml definition file similar to this:
For something customized like this, if there is no Reuters Exchange Mnemonic, you would have to agree upon a value with your counterparty, or agree upon an existing or custom tag to specify this information in.
The tag in question is tag 30, which is LastMkt. Valid values are
Exchange mnemonics such asAnswers to your questions really rely on the FIX engine you are using.
See http://www.fixprotocol.org/implementation-guide/engine.shtml for
more details about Implementing FIX with FIX engines.I’m not quite sure what you mean by a new exchange mnemonic, but there
is no field for mnemonic. Most likely, you will be passing a
configurable value via your FIX engine in one of several fields to
identify the exchange (ExDestination, TargetCompID, TargetSubID, etc).
You will not need to upgrade to the next version, you will need to
define a field value to be passed via your FIX engine.Values are validated by the receiving FIX engine. Most FIX engines
have an xml definition file or data dictionary describing the fields,
it’s properties as well as it’s valid values. Per your example, unless
the receiving FIX engine adds ‘R’ as an enum/option, then most likely
the FIX engine will reject your cancel.What happens when a new exchange mnemonic is created and your
current FIX version obviously does not yet know this new mnemonic?
Will you need to use the next version of FIX(assuming it will
include this new mnemonic)? Or can you just update your OMS somehow
and recertify all your connections?How are expected values validated in fix? For example in FIX
4. for tag
<125>, the only valid values are “P” and “F”(not sure on case). What
if I send “125=r”? What happens exactly? Where does this get
stopped and how does what ever stops this actually stop it?
Where are the list of acceptable values stored for validation?
My guess is the OMS.