Imported from previous forum
Tag 1618 (RelationshipRiskEncodedSecurityDescLen) refers to itself instead of tag 1619 (RelationshipRiskEncodedSecurityDesc). The tag description says
“Byte length of encoded (non-ASCII characters) RelationshipRiskEncodedSecurityDesc (1618) field.”
It should be “Byte length of encoded (non-ASCII characters) RelationshipRiskEncodedSecurityDesc (1619) field.”
Similarly, Tag 1620(RiskEncodedSecurityDescLen) refers to itself instead of Tag 1621(RiskEncodedSecurityDesc).
Thank you for bringing this to our attention. We will make the correction in the next service pack release.
Tag 1618 (RelationshipRiskEncodedSecurityDescLen) refers to itself
instead of tag 1619 (RelationshipRiskEncodedSecurityDesc). The tag
description says“Byte length of encoded (non-ASCII characters)
RelationshipRiskEncodedSecurityDesc (1618) field.”It should be “Byte length of encoded (non-ASCII characters)
RelationshipRiskEncodedSecurityDesc (1619) field.”Similarly, Tag 1620(RiskEncodedSecurityDescLen) refers to itself instead
of Tag 1621(RiskEncodedSecurityDesc).
[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
> Tag 1618 (RelationshipRiskEncodedSecurityDescLen) refers to itself
instead of tag 1619 (RelationshipRiskEncodedSecurityDesc). The tag
description says“Byte length of encoded (non-ASCII characters)
RelationshipRiskEncodedSecurityDesc (1618) field.”It should be “Byte length of encoded (non-ASCII characters)
RelationshipRiskEncodedSecurityDesc (1619) field.”Similarly, Tag 1620(RiskEncodedSecurityDescLen) refers to itself instead
of Tag 1621(RiskEncodedSecurityDesc).
Thanks for letting us know.
I’m wondering how you found this. Were you considering implementing the Parties Reference Data messaging in FIX 5.0 SP2, or was it by chance that you found this?
If the former, I need to inform you that the Parties Reference Data messaging introduced in FIX 5.0 SP2 has been substantially overhauled by the Extension Pack 105. I strongly suggest against implementing Parties Reference Data as implemented in SP2, and suggest that instead you implement the EP105 version.
This issue has already been fixed by EP105, “Parties Reference Data Extensions” which was ratified at the end of last month. We are still working on coding this as an Extension Pack to the Repository. However, I can say that this EP deletes 1618 and 1619. 1620 is renamed, and it properly refers to 1621.
Tag 1618 (RelationshipRiskEncodedSecurityDescLen) refers to itself
instead of tag 1619 (RelationshipRiskEncodedSecurityDesc). The tag
description says“Byte length of encoded (non-ASCII characters)
RelationshipRiskEncodedSecurityDesc (1618) field.”It should be “Byte length of encoded (non-ASCII characters)
RelationshipRiskEncodedSecurityDesc (1619) field.”Similarly, Tag 1620(RiskEncodedSecurityDescLen) refers to itself
instead of Tag 1621(RiskEncodedSecurityDesc).Thanks for letting us know.
I’m wondering how you found this. Were you considering implementing the
Parties Reference Data messaging in FIX 5.0 SP2, or was it by chance
that you found this?If the former, I need to inform you that the Parties Reference Data
messaging introduced in FIX 5.0 SP2 has been substantially overhauled by
the Extension Pack 105. I strongly suggest against implementing Parties
Reference Data as implemented in SP2, and suggest that instead you
implement the EP105 version.This issue has already been fixed by EP105, “Parties Reference Data
Extensions” which was ratified at the end of last month. We are still
working on coding this as an Extension Pack to the Repository. However,
I can say that this EP deletes 1618 and 1619. 1620 is renamed, and it
properly refers to 1621.
I stumbled upon this issue while transforming the repository into a custom format for private use.