The excellent "Custom Continuous Futures" feature in MultiCharts clearly has the potential to utilize GlobalServer data in theory, but in practice there seems to be a small challenge which may need to be resolved.
Since the most recent contract always needs to be present, at the time of this writing, Custom Futures would theoretically need to recognize the following GlobalServer symbols as a continuous data stream:
"ES201012", "ES201103", "ES201106" and "ESU1"
Note that in the above example, the first three symbols have been automatically "expired" by GlobalServer, and only the most recent symbol is current.
My tests were conducted in the summer of 2009, and at that time I concluded that everything works fine as long as the GlobalServer symbols are not already "expired".
However, one cannot go back very far in history without encountering an expired contract. Therefore, Custom Futures in MultiCharts would need to recognize the GlobalServer "expired format" (which did not work in my tests since the format was not recognized by MultiCharts) and then seemlessly also recognize the "non-expired" format (which worked fine when used all by itself in my tests) and finally both formats would need to be somehow linked to provide one continuous data series in MultiCharts.
One might guess that the workaround for the problem would be to trick GlobalServer into never forcing the expiration of futures contracts. Since that option does not exist to my knowledge, one can at least manually set the expiration date for all futures contracts to about 10 or more years into the future. Due to symbology limitations, we cannot disambiguate 2010 from 2000 or 1990 in GlobalServer when using a symbol format like "ESZ0". That is why GlobalServer automatically changes the format to "ES201012", "ES200012", and "ES199012" upon expiration.
Another workaround would be to pass each non-expired symbol to QuoteManager before it actually expires, and then save data to the local database prior to building Custom Continuous Futures in QuoteManager, because QuoteManager will not force a symbol format change at expiry the way that GlobalServer does. However, the reason we use GlobalServer in the first place is to provide a central database that is simple and easy to manage, and which can serve history to remote MultiCharts nodes via TSDataHub. We don't really gain an advantage when our database work needs to be replicated on each MultiCharts instance in my opinion.
handle GlobalServer expired contracts in Custom Futures?
- Stan Bokov
- Posts: 963
- Joined: 18 Dec 2009
- Has thanked: 367 times
- Been thanked: 302 times
Re: handle GlobalServer expired contracts in Custom Futures?
Is there a particular reason you can't use "ESZ1990", "ESZ2000", and "ESZ2010"? We support this format.
Re: handle GlobalServer expired contracts in Custom Futures?
Thank you for your suggestion.
Unless I am mistaken, the problem is that when using the futures template in GlobalServer there is apparently no way to manually redefine the current symbol format for unexpired futures contracts, and also no way to redefine the historical symbol format for expired futures contracts, yet the two formats are always different as I described in my first post above.
Unless I am mistaken, the problem is that when using the futures template in GlobalServer there is apparently no way to manually redefine the current symbol format for unexpired futures contracts, and also no way to redefine the historical symbol format for expired futures contracts, yet the two formats are always different as I described in my first post above.
- Stan Bokov
- Posts: 963
- Joined: 18 Dec 2009
- Has thanked: 367 times
- Been thanked: 302 times
Re: handle GlobalServer expired contracts in Custom Futures?
Thank you for the quick update. Based on the information I have, you can name the symbols as you wish in GlobalServer. Are you not able to do it?
Re: handle GlobalServer expired contracts in Custom Futures?
My tests indicate that when using the futures template in GlobalServer, one cannot rename an expired symbol, but I was able to rename an unexpired symbol manually to match the format that you previously suggested. I don't yet know what will happen to that symbol after it expires, that should be interesting...
PS- I corrected a typographical error in my first post, it previously read "ES19" for the current GlobalServer symbol, but I corrected it to read "ESU1". Sorry for any confusion which may have been caused.
PS- I corrected a typographical error in my first post, it previously read "ES19" for the current GlobalServer symbol, but I corrected it to read "ESU1". Sorry for any confusion which may have been caused.