Proposed minor change to allow specifying named symbol lists

Keith Rudd

Classification: Public

With the current OpenMAMA functionality for symbol list type requests (MAMA_SUBSC_TYPE_SYMBOL_LIST), it is not possible to request a named symbol list.


Any symbol name specified is ignored and overwritten by “SYMBOL_LIST_NORMAL”.

The assumed semantics is that you always want a list of the entire list of symbols available for the specified source.


This is unnecessarily restrictive. There is no reason why the middleware might not support symbol lists representing other named subsets of the source data, such as all the options for an underlier or all the contracts for a future.

(TREP sources typically do support this for example, but the concept of named symbol lists is by no means TREP-specific)


With a very simple modification, this could be supported.

Just by not overwriting the symbol name if one is specified.

The current behavior can be preserved as the default for backwards-compatibility, by still overwriting with “SYMBOL_LIST_NORMAL” if no symbol is specified.


Also, there are actually two similar subscription types that can be used:


The intended different use for these is not clear – they both are processed exactly the same.

Can anyone shed light on the reason for both existing?

One of these could also be preserved as is for another backward-compatibility option.


A minor change to subscription.c only is required.

Optionally, minor change to subscriptiontype.c, subsctype.c to differentiate between the two types of symbol list request.


I can’t actually contribute to GIT repository myself, so hope someone else will look kindly on this proposed change to implement it!


I can see no downside.





This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to for additional EU corporate and regulatory disclosures and to for information about privacy.

Join to automatically receive all group messages.