The first procedure simply selects, for the range of specified dates lookup_date_1 and lookup_date_2, all prices from equities that are to be analysed. These equities are selected from the instruments_list_temp_2_02 table that was produced by the Instrument Filter procedures. The selection of the prices are looked up in both the NYSE and Nasdaq master tables that fall into the specified dates for analysis. Results from the queries are then impacted into the instrument_analysis_01t table.
This procedure creates a table showing all instruments to be analysed filtered by the appropriate dates for the analysis. The table is ordered by instrument code and the effective dates. Within the procedure a new instrument code is created that considers the possibility that the underlying asset might have had splits, and so the values for the strike in the original entry for the instrument had the previous strike. Given that the underlying has undergone a split, the exchange gives a new instrument code to the option. But since the master table is updated daily, the previous entries for the same instrument now have an instrument code that reflected the previous strike and obviously are not altered. Having this situation, the MySQL procedure would consider these 2 codes as 2 different options, the old one having the last price at the last day before the split, and the new one starting the day of the split. Hence, when ordered in the final table, the results would not reflect a continuity and the model would not produce appropriate results. The calculation of this procedure, and all the intermediate queries within, is performed to produce this new instrument code to provide a unified code that lets the final results have all the history of the option chain before and after the underlying has undergone a split.
The results of instanalysis-02 are impacted in a table and the date of the procedure is written as SP_run_start.