Options Quotes Irregularity

[JerryS]

Tried everything and this doesn't make sense.

Could not get quotes for SWKS options.  Tried lots of symbols and all worked except SWKS.  Tried two data sources: Yahoo and TDA.  Still no quotes.  Do not see anything unusual about any settings.  Played with settings -- still no quotes for SWKS but every other symbol works.

Finally decided to close MT and reboot.  Now it works.

????????

Somehow it seems that something got corrupted, perhaps something in a temporary file that gets rewritten and therefore repaired when the program is reloaded.  Otherwise, I don't have a clue.

[Jerry Medved]

when you say options did not work, are you referring to individual option symbols in the portfolio? Option chains?

[JerryS]

No quotes for SWKS would fill the options table, and I tried everything I could think of.  Had no problem filling the table when selecting any other symbol.

I didn't want to reboot until I tried everything because if it did work after rebooting, It would be impossible to find the cause.

Finally gave up.  Rebooted.  Requested options data for SWKS.  Table immediately filled.  Problem gone.

Evanescent problems are the worst kind.  Not having access to the source code, I would likely never be able to find its cause.

If it happens again, perhaps there is a log file I could copy and send?

[Jerry Medved]

let me explain how it works. There are two components.  

1) the Option Chain - list of option symbols for a given root symbol. 

2) Option quotes

The chain and quotes do not have to come from the same source.  In fact, some sources support just one or the other but not both. 

When MT retrieves the CHAIN, it caches it for a day.   So if you bring up the chain on the same symbol again, it should not have to retrieve the chain again and just gets the quotes, making it much faster.

I am thinking that maybe, for some reason, the option symbols in the chain retrieved the first time were bad, so the quotes could not be retrieved.  after reboot, you got the chain again and it worked

The other thing that could have happened is if the datafeed for quotes was somehow messed up and the restart fixed it.  

best to send us the log file and we can look at it and see if we can do anything about that.
 

go to FILE / Export/Backup menu (from Dashboard or Portfolio)
Select “To share with others” export file protection option on top right
Leave the checkboxes already checked, and also check LOG FILE.
Export, then email me the exported file please.
NOTE: if emailing that, please give details = what the problem is, what exact symbols you were dealing with and approximately what time that happened so we know where to look in the log

[JerryS]

Received following error after downloading Log file exactly as described:

Medved Trader encountered an Error
Cross-thread operation not valid: Control " accessed from a thread other than the thread it was created on.

I checked directory where MT exists:  C:\Program Files\Medved Trader.

Most recent file is dated 8/22/16 3:15 PM 

That date/time is definitely not today. If a log file was downloaded, it must be somewhere else.

 

Searched entire computer for files of the type *.log  and found nothing later than several hours earlier this morning.

[Jerry Medved]

when you export the log, the location of the export is shown right in the center of the export screen.  Usually in MyDocuments / Medved Trader

[JerryS]

Downloads are transient events which often happen so fast with a wideband connection such that messages aren't around long enough to read.

Therefore, message boxes which require confirmation are a good idea.

I got the log on a second attempt, doing nothing different, and you have mail.

The log was found here (*** = private info):  C:\Users\********\AppData\Local\2GK\Medved Trader

That location was picked by the computer along with the installation program doing whatever it chose -- not me.  My only involvement in the installation was to move the bookmark down to the Taskbar where it belonged (IMO).

----

As another note ... I've written code for many years and have on a few occasions had problems with code working properly on one computer and not working so well on another, and those specific problems were always solved by adding artificial delay within the code at the points that somehow caused the problem.

My biggest problem (many years ago) in that general area was the microsoft mouse driver and its interaction with the video driver.  The final solution was that, while my program had control, I disabled mouse communication to everything but my program and all mouse communication was redirected to a driver that I wrote within my program.  In other words, while my program was active, the MS mouse driver was castrated.

But those were the days when there were a lot of incompatibility issues between hardware and software, mostly related to timing issues.  The most famous I know of was when HP decided to branch out from lab equipment and enter the PC market.  Their first PCs had a lot of software/hardware compatibility issues, mostly because they were so arrogant with their success in creating and selling lab instruments such that they decided they also always knew best when it came to computer cards.  They soon learned otherwise as the problem reports started piling up.  Eventually, HP redesigned their cards.

[Mike Medved]

JerryS - those kinds of kinks have been worked out in modern programming environments, mostly. Nowadays, if you get a bug, there is a very remote possibility that it is not your, programmer's, fault but the OS' or driver's etc. fault, but that kind of thing is a zebra. You don't go looking for zebras

Our problems are often in dealing with extremely multithreaded environment. If everything was running in one thread, oh what a wonderful bugfree world it would be. But the program would not be nearly as fast/responsive.

Although the option chain bug does not seem to be related to threads. As Jerry explained, we cache chains, because getting them is expensive in terms of server access and speed. But the problem with cache of course is if you have bad data in cache. We do sanity checks of course but...

 

As an aside, I started programming in ALGOL-68 on Minsk-22s - .

See those white threads in the back? That's punched tape. Fun stuff.

 

[JerryS]

My first experience with writing software was as a freshman in engineering at U. of Colorado.  The language was MAD, for the IBM 704, and later.  Had to write out or type the code then send it through university mail to a keypunch operator in another building. They would punch the cards and send those to the computer room, wherever that was, and I would get the results a day later.  If there was an error, I would get a full-sheet printout of Alfred E. Newman's face with a few machine-generated notes at the bottom "explaining" possible causes.  Modify code -- repeat till working.  I hated computer programming.  That was also the last year they taught MAD.  The new language would be Fortran.  My MAD experience was worthless.

Years later, I decided computer programming would be a good thing to learn.  After all, a lot of equations for various modulations in communications gear do not have closed-form solutions.  Some feedback loops are up to fifth order and take a very long time to come up with error-free equations which are extremely difficult to interpret without simulation.  What are you going to do with a fifth-order Nyquist plot if you can't wiggle the values around a little and see imediate results?  So one must simulate on the computer.  So I became addicted to programming.

So my resume ended up saying that I was an RF engineer (considered black magic by all other engineers), and that I was proficient in a couple computer languages, and I also new digital hardware pretty well.  Eventually that combination allowed me to get lucrative jobs as a consultant.  A typical situation is that there are bugs in a product.  The software guys know relatively little about digital hardware (and absolutely nothing about RF) so they blame the digital hardware guys for the problems.  The digital hardware guys know relatively little about software (and absolutely nothing about RF) so they blame the software guys for the problems.  Eventually, as neither of those groups can agree on the source of the problems, they blame the radio guys.  When that didn't work, upper management would borrow me from my project for a couple days and ask me to go see what I could find out.  Then they would plead with me to limit my time because they knew that I would get carried away and find perhaps a dozen problems while all that they wanted fixed was that particular one that nobody could fix.

Normally when you see all that finger pointing, it's management that needs to get fixed first.  You can't have an "A" grade company without "A" grade management.  That's because a "B" grade manager can't recognise an "A" grade designer, so they never hire them except by pure accident which doesn't happen often because "A" grade designers are rare.

[Mike Medved]

Don't get me started on big companies' management....