CONSEQ ANALYSIS.
---------------

Conseqs are boundaries of dataspans of the same mode in the BFST within which all minor frames are of the same continuity (DISC is constant).  Before the onset of conseq analysis, procedure BFST_SET_MNFSKIP is called to set the minor frame skip (MNFSKIP) at every first occurence of a new continuity.  The latter is done because conseqs range from the first occurence of a skip, up to and before the next skip.  

Conseq analysis is done in two steps: first within procedure BFST_FILL_TIMES then within procedure BFST_REFILL_TIMES.  Procedure BFST_FILL_TIMES examines all the conseqs in the BFST but because it's a forward ordered process it is not able to infer major frames datetimes for minor frames using information from conseqs up ahead in the processing chain since these conseqs have yet to be analyzed and filled; 
therefore procedure BFST_REFILL_TIMES as its name implies re-analyzes the BFST's conseqs and recovers more data because conseqs ahead in the processing chain have been filled and provide baseline minor frames that
the conseq analysis most often requires.

Procedure BFST_FILL_TIMES starts off by finding out if the MNFSKIP was set for the last minor frame unpacked in the BFST.  The latter is done to determine if the last minor frame is a conseq by itself, if it's part of the last conseq in the BFST.  Because conseqs are identified by consecutive occurences of MNFSKIP, the last conseq in the BFST will be missed if the MNFSKIP isn't set at the last unpacked minor frame.  When procedure BFST_FILL_TIMES determines that it's necessary to set the MNFSKIP, it records its action into variable ACTION1, and, at the end of the conseq analysis, the MNFSKIP for the last minor frame will be reset to its original value.
 
Two tables are created by procedure BFST_FILL_TIMES: UNIQUE_TIME and UNIQUE_UMFC.  Table UNIQUE_TIME contains all not null UMFDTs from the BFST for minor frames that are not failed and don't have their DATEERR flag raised.  Table UNIQUE_UMFC contains all not null UMFC from the BFST for minor frames that are not failed (note that at this stage, the UMFCERR flag has not yet been set).  The latter two tables are created because they are relatively of a much small size than the BFST and therefore take much less time to scan.  After table UNIQUE_UMFC is created, procedure BFST_CHECK_UNPACKED_TIMES is invoked to correct UMFDTs that have the same integer fraction but show a slight shift in the decimal secionds (for more information on this process see the section titled CORRECTING UMFDT IN THE BFST).

Once procedure BFST_FILL_TIMES has identified the boundaries of a conseq in the BFST, sub-predures CS_DT and CS_UMFC are called to find out the number of distinct UMFDT and UMFC present respectively in the first conseq.  The last two numbers effectively represent the STATE of a conseq.  At this stage, the state of the conseq under examination is recorded into table CS_STATE_REPORT.  The latter table stores information on the state of all the conseqs found in the BFST after every run of the Oracle rules.  Table XX shows an example of output from table cs_state_report.







       Table XX.  Sample output from CS_STATE_REPORT Table.
                        
        __________________________________________________
        | MIN_ID   MAX_ID   NUM_DT   NUM_UMFC   CS_STATE |
        |-------- -------- -------- ---------- ----------|
        |    1       101       1         1         11    |
        |  102       281       1         1         11    |
        |  282       309       1         1         11    |
        |  310       512       1         1         11    |
        |  513       544       1         1         11    |
        |  545       766       1         1         11    |
        |  767       820       0         1         01    |
        |  821       859       0         1         01    |
        |  860       887       1         1         11    |
        |  888      1131       1         1         11    |
        | 1132      1264       2         1         21    |
        | 1265      1511       1         1         11    |
        --------------------------------------------------
        Note that CS_STATE is simply a concatenation of 
        NUM_DT and NUM_UMFC.

Once the state of a consert has been determined, the name of the procedure to invoke is querried from table CS_LOOKUPT.  This table stores the name of the procedures that BFST_FILL_TIMES must invoke based on what the state of the conseq is (see Table XX). Note that S_CS_DT or S_CS_UMFC = 2 simply means that there are two or more UMFDT or UMFC in a conseq. 
     
                     Table XX.  Output from CS_LOOKUPT.
                   --------------------------------------
                   | S_CS_DT   S_CS_UMFC      ACTION    |
                   |--------- ----------- --------------|
                   |    0          0       ACTION_CS_00 |
                   |    0          1       ACTION_CS_01 |
                   |    0          2       ACTION_CS_02 |
                   |    1          0       ACTION_CS_10 |
                   |    1          1       ACTION_CS_11 |
                   |    1          2       ACTION_CS_12 |
                   |    2          0       ACTION_CS_20 |
                   |    2          1       ACTION_CS_21 |
                   |    2          2       ACTION_CS_22 |
                   --------------------------------------
                   Note that the leading two characters in 
                   the action column represent are simply a
                   concatenation of S_CS_DT and S_CS_UMFC.

The purpose of using state recognition in conseq analysis is to eliminate the confusion and unnecessary complexity that may result from using a series of nested IF blocks programatically.  The following paragraphs describe what "ACTION" is taken for each state of a conseq.

    ACTION_CS_00.  In this state of a conseq, there are no UMFDT or UMFC     
    present.  The datetime in the conseq can only be computed from the 
    GRT (for more details on this procedure, see the section titled
    COMPUTING THE TIME FROM THE GRT).  If we are able to compute a time 
    from the GRT, we use that time to fill minor frames in that conseq 
    and alert the analysts to what has taken place, else the conseq is
    not filled and procedure BFST_CALC_TIME_GRT will output a message as 
    to why the rules were unable to compute a time based on the GRT.

    ACTION_CS_01.  In this state of a conseq, there are no UMFDT and one 
    UMFC present.  The UMFC present and its DISC are selected from table 
    UNIQUE_UMFC and passed in to procedures BFST_CALC_TIME_GRT and  
    BFST_CALC_TIME_UMFC which will attempt to compute the major frame 
    time from the GRT and the UMFC respectively (see sections COMPUTING  
    THE TIME FROM THE GRT and COMPUTING THE TIME FROM THE UMFC).  The 
    datetime values returned from the latter two procedures are passed    
    into procedure BFST_GRTvsUMFC which will comparison and determine 
    how the conseq will be filled, if at all (for more information on
    procedure BFST_GRTvsUMFC see the section titled COMPARING 
    DATETIME_GRT VERSUS DATETIME_UMFC).
 
    ACTION_CS_02.  In this state of a conseq, there are no UMFDT and two 
    or more UMFC present.  If more than two UMFC are present in a 
    conseq, the analyst is informed of the event and a message stating 
    that the state is not currently being handled is outputed.  More 
    than two UMFC may be present in a conseq if the data is currupted.  
    The analyst should examine the data closely to devise a rule that 
    would handle this state which thus far has not occurred.  If Two 
    UMFC are present in a conseq, a count of how often each one is 
    unpacked is querried from table unique_umfc into variables NUM_UMFC2 
    and NUM_UMFC3.
    
        If NUM_UMFC2 equals 1 and NUM_UMFC3 is greater than one, clearly 
        UMFC2 is in error and the UMFCERR flag is set for that minor 
        frame in the BFST.  At this stage, the rest of the process is 
        equivalent to that of ACTION_CS_01 with UMFC3 passed as argument 
        to procedure BFST_CALC_TIME_UMFC. 

        If NUM_UMFC3 equals 1 and NUM_UMFC2 is greater than one, clearly 
        UMFC3 is in error and the UMFCERR flag is set for that minor 
        frame in the BFST.  At this stage, the rest of the process is 
        equivalent to that of ACTION_CS_01 with UMFC2 passed as argument 
        to procedure BFST_CALC_TIME_UMFC. 

        If both UMFC2 and UMFC3 are unpacked more than once, the analyst 
        is informed of the event and a message stating that the state is 
        not currently being handled is outputed.  Though this state has
        never been observed, it may occur if the data is currupted, 
        therefore the analysts should examine the data closely to devise 
        a rule that would handle such a state.

    ACTION_CS_10.  In this state of a conseq, there is one UMFDT and no 
    UMFC.  Since a datetime is present, it is used to fill the minor 
    frames in the conseq.  
 
    ACTION_CS_11.  In this state of a conseq, there is one UMFDT and one 
    UMFC.  This is the state most often reported in table 
    cs_state_report.  An EUMFC is computed based from the UMFDT in the 
    conseq and compared to the UMFC that was originally originally 
    unpacked.  The EUMFC is computed with a call to procedure 
    BFST_CALC_UMFC, a description of which can be found in the section 
    titled COMPUTING AN EUMFC.
  
        If the EUMFC is equal to UMFC there UMFC is not in error.  The 
        conseq is filled with UMFDT.  

        If EUMFC could not be computed (for reasons that are explained 
        in the section titled COMPUTING AN EUMFC), the conseq is 
        nonetheless filled with the UMFDT and the analys this informed 
        to the fact that the UMFC in the conseq could not be verified 
        against that expected for the UMFDT.

        If the EUMFC does not equal the UMFC in the conseq, two courses 
        of action are available.

            If the UMFC in the conseq was unpacked only once, the minor 
            frame where it was unpacked is flagged with a MFCERR and the 
            conseq is filled with the UMFDT.  Note that the latter 
            action infers that the counter is in error and not the 
            datetime and this is because the time is a six bits number 
            which at this stage in reconstruction has already gone 
            through a validating process as explained in the section 
            titled SETTING THE DATE ERROR FLAG, whereas the counter is a 
            one byte number which has not yet been checked.

            If the UMFC in the conseq was unpacked more than once, this 
            is a case where we have an UMFC consistently unpacked and 
            clearly not in error.  Either the EUMFC computed from the 
            UMFDT is in error (formula error or baseline major frame 
            error: see COMPUTING THE UMFC) or the UMFDT is in error (for 
            example the UMFDT may have been computed using the wrong 
            year and has somehow passed all the previous checks.  In 
            this case what may happen next depends on the analysts: they 
            may manually verify that the EUMFC was correctly computed 
            and wheather the UMFDT in the conseq was in error.  

                If the UMFDT is in error, the analysts may turn on a 
                switch that will enable procedure ACTION_CS_11_S1 which 
                will attempt to estimate what the time in the conseq 
                should be from the UMFC (see the section titled 
                COMPUTING THE MFT FROM THE UMFC).  

                In the event that there was an error in the formula that 
                estimated the EUMFC, the analysts may simply reprocess 
                the data with the corrected formula and the state should 
                not reoccur.

    ACTION_CS_12. In this state of a conseq, there is one UMFDT and two 
    or more UMFC present.  If more than two UMFC are present in a 
    conseq, the analyst is informed of the event and a message stating 
    that the state is not currently being handled is outputed.  More 
    than two UMFC may be present in a conseq if the data is currupted.  
    The analyst should examine the data closely to devise a rule that 
    would handle this state which thus far has not occurred.  If Two 
    UMFC are present in a conseq, a count of how often each one is 
    unpacked is querried from table unique_umfc into variables NUM_UMFC2 
    and NUM_UMFC3.
    An EUMFC for the UMFDT in the conseq is next computed with a call to 
    function BFST_CALC_UMFC.
        
        If the EUMFC can be determined, it is compared against both 
        UMFC2 and UMFC3 which were originally unpacked in the conseq.

            If EUMFC is different from both UMFC2 and UMFC3, the analyst 
            is informed of the event and a message stating that the 
            state is not currently being handled is outputed.  The 
            analyst should examine the data closely to devise a rule 
            that would handle this state which thus far has not 
            occurred.

            If EUMFC is equal to UMFC2 and not equal to UMFC3, what 
            happens next depends on how often UMFC3 was unpacked.
            
                If UMFC3 was unpacked only once, it is clearly in error 
                and the MFCERR flag is set at the minor frame where 
                UMFC3 was unpacked.
               
                If UMFC3 was unpacked more than once, the analyst is 
                informed of the event and a message stating that the 
                state is not currently being handled is outputed.  The 
                analyst should examine the data closely to devise a rule 
                that would handle this state which thus far has 
                not occurred.

            If EUMFC is equal to UMFC3 and not equal to UMFC2, what 
            happens next is similar to that described in the last two 
            paragraphs.

        If the EUMFC can not be determined, the analyst is informed of 
        the event and a message stating that the state is not currently 
        being handled is outputed.  The analyst should examine the data 
        closely to devise a rule that would handle this state which thus 
        far has not occurred.  

    ACTION_CS_20.  In this state of a conseq, there are two or more 
    UMFDT and no UMFC present. If more than two UMFDT are present in a 
    conseq, the analyst is informed of the event and a message stating 
    that the state is not currently being handled is outputed.  More 
    than two UMFDT may be present in a conseq if the data is currupted.  
    The analyst should examine the data closely to devise a rule that 
    would handle this state which thus far has not occurred.  If two 
    UMFDT are present in a conseq, they are both querried from table 
    unique_time into variables FP_UMF_DATETIME2 and FP_UMF_DATETIME3.  A
    third datetime, DATETIME_GRT, is computed from the GRT with a call 
    to procedure BFST_CALC_TIME_GRT.

        If DATETIME_GRT can't be computed, the analyst is informed of 
        the event and a message stating that the state is not currently 
        being handled is outputed.  The state is not being handled 
        because we are unable to compare DATETIME_GRT against 
        FP_UMF_DATETIME2 and FP_UMF_DATETIME3.  For reasons why
        DATETIME_GRT can't be computed see the section titled COMPUTING 
        THE TIME FROM THE GRT.

        If DATETIME_GRT can be computed, it is differentiated against 
        FP_UMF_DATETIME2 and FP_UMF_DATETIME3 into variables DIFF1 and 
        DIFF2.  These two differences will help us determined how close 
        within tolerance are FP_UMF_DATETIME2 and FP_UMF_DATETIME3 from 
        DATETIME_GRT.  

            The time that is the closest to DATETIME_GRT within 
            tolerance is filled in the conseq.  The time one of 
            FP_UMF_DATETIME2 and FP_UMF_DATETIME3 that isn't close to 
            DATETIME_GRT within tolerance is flagged with DATEERR.  
 
            If both FP_UMF_DATETIME2 and FP_UMF_DATETIME3 are not close 
            to DATETIME_GRT within tolerance, the analyst is informed of 
            the event and a message stating that the state is not 
            currently being handled is outputed.  The analyst should 
            examine the data closely to devise a rule that would handle 
            this state which thus far has not occurred.

    ACTION_CS_21.  In this state of a conseq, there are two or more 
    UMFDT and one UMFC present.  If more than two UMFDT are present in a 
    conseq, the analyst is informed of the event and a message stating 
    that the state is not currently being handled is outputed.  More 
    than two UMFDT may be present in a conseq if the data is currupted.  
    The analyst should examine the data closely to devise a rule that 
    would handle this state which thus far has not occurred.  If Two 
    UMFDT are present in a conseq, they are both querried from table 
    unique_time into variables FP_UMF_DATETIME2 and FP_UMF_DATETIME3.  
    Next, EUMFCs for the latter two times are computed by procedure 
    BFST_CALC_UMFC into variables EUMFC2 and EUMFC3.  

        If both EUMFC2 and EUMFC3 can be computed, it is now a question 
        of determining which of the two match the MFC unpacked in that 
        conseq.  The datetime whose EUMFC match that unpacked in the 
        conseq is used to fill and the other UMFDT is flagged with a 
        DATEERR.  If neither EUMFC2 nor EUMFC3 match the UMFC in the 
        conseq, the analyst is informed of the event and a message 
        stating that the state is not currently being handled is 
        outputed.  The analyst should examine the data closely to devise
        a rule that would handle this state which thus far has not 
        occurred.  If both EUMFC2 and EUMFC3 are the same and equal to 
        the UMFC unpacked in the conseq, the analyst is informed of the 
        event and a message stating that the state is not currently 
        being handled is outputed.  The latter event may occur if both 
        UMFDTs are very close to one another and previous rules failed 
        to correct this because they used too large a tolerance in their 
        checking of the UMFDTs.  In any case, the analyst should examine 
        the data closely to see if the tolerance used when checking the 
        UMFDT (done in procedure BFST_CHECK_UNPACKED_TIMES explained in 
        the section titled CORRECTING UMFDT IN THE BFST) in the BFST 
        should be increased, or devise a rule that would handle this 
        state which thus far has not occurred.

        If only one of EUMFC2 and EUMFC3 can be computed, that one is 
        compared to the UMFC in the conseq and should they be equal, the 
        conseq is filled with the UMFC we could compute and the DATEERR 
        flag is raised at the minor frame where the other datetime (that 
        for which an EUMFC could not be computed) was unpacked.  If the 
        EUMFC we could compute is not equal to that unpacked in the 
        conseq, the analyst is informed of the event and a message 
        stating that the state is not currently being handled is 
        outputed.  The analyst should examine the data closely to devise 
        a rule that would handle this state which thus far has not 
        occurred.
 
        If both EUMFCs can't be computed, the analyst is informed of the 
        event and a message stating that the state is not currently 
        being handled is outputed.  The analyst should examine the data 
        closely to devise a rule that would handle this state which thus 
        far has not occurred.

    ACTION_CS_22.  In this state of a conseq, there are two or more 
    UMFDT and two or more UMFC.  Should there be more than two UMFDT or 
    more than two UMFC in the conseq, the analyst is informed of the 
    event and a message stating that the state is not currently being 
    handled is outputed.  More than two UMFDT or UMFC may be present in 
    a conseq if the data is currupted.  The analyst should examine the 
    data closely to devise a rule that would handle this state which 
    thus far has not occurred.  If Two UMFDT and two UMFC are present in 
    the conseq, the UMFDT are querried into variables FP_UMF_DATETIME2 
    and FP_UMF_DATETIME3, and the UMFC are querried into variables UMFC2 
    and UMFC3.  Next, EUMFCs for FP_UMF_DATETIME2 and FP_UMF_DATETIME3 
    are computed by procedure BFST_CALC_UMFC into variables EUMFC2
    and EUMFC3.  

        If both EUMFC2 and EUMFC3 can be computed, it is now a question 
        of determining which of the two match any of the MFCs unpacked 
        in that conseq.  The datetime whose EUMFC match any of the MFC 
        unpacked in the conseq is used to fill and the other UMFDT is 
        flagged with a DATEERR.  The UMFC that does not match any of 
        those computed is flagged with a MFCERR.  If both EUMFC2 and 
        EUMFC3 are equal to none of the MFCs unpacked in the conseq, the 
        analyst is informed of the event and a message stating that the 
        state is not currently being handled is outputed.  The analyst 
        should examine the data closely to devise a rule that would 
        handle this state which thus far has not occurred.

        If only one of EUMFC2 and EUMFC3 can be computed, that one is 
        compared to the UMFCs in the conseq and should it equal any of 
        then, the conseq is filled with the UMFC we could compute and 
        the DATEERR flag is raised at the minor frame where the other 
        datetime (that for which an EUMFC could not be computed) was 
        unpacked.  The UMFC that does not match that computed s flagged 
        with a MFCERR.  If the EUMFC we could compute is not equal to 
        that unpacked in the conseq, the analyst is informed of the 
        event and a message stating that the state is not currently 
        being handled is outputed.  The analyst should examine the data 
        closely to devise a rule that would handle this state which thus
        far has not occurred.

        If both EUMFCs can't be computed, the analyst is informed of the 
        event and a message stating that the state is not currently 
        being handled is outputed.  The analyst should examine the data 
        closely to devise a rule that would handle this state which thus 
        far has not occurred.

Once all conseqs have been analyzed and appropriate "ACTIONS" have been taken, procedure BFST_FILL_TIMES is ended.  Note that temporary tables unique_time and unique_umfc are not dropped here because they will be
used in lieu of the BFST from now on for efficiency and faster table scans.

Next in the conseq analysis, procedure BFST_REFILL_TIMES is executed to go over all the conseqs once again and hopefully, for conseqs where a MFT could not be computed because of lack of a base MFT, one may now be
found since conseqs ahead in the chain may now have a MFT.  Usually conseqs that benefit from this reprocessing are those at the begining and at the end of the BFST.  Procedure BFST_REFILL_TIMES is almost
identical in content to procedure BFST_FILL_TIMES except that conseqs will we are certain have already been filled, are not reprocessed and temporary tables unique_time and unique_umfc do not need to be recreated.  Having outlived its usefullness at the end of procedure BFST_REFILL_TIMES, temporary table unique_umfc is dropped.

CORRECTING UMFDT IN THE BFST.
-----------------------------

The UMFDT in the BFST may at times show a shift in the subseconds within minor frames of the same major frame.  Correcting the UMFDT is handled by procedure BFST_CHECK_UNPACKED_TIMES.  To correct the UMFDT, 
BFST_CHECK_UNPACKED_TIMES uses a tolerance of 1 millisecond.  All the distinct UMFDT and their counts are selected in turn from table unique_time (for more details on table unique_time see the section titled CONSEQ ANALYSIS) into variables FP_UMF_DATETIME1 and COUNT1.  Next, all other distinct time which are close to FP_UMF_DATETIME1 within tolerance and their times are selected into variables FP_UMF_DATETIME2 and COUNT2. 

If COUNT1 is greater than COUNT2, this means that there are more UMFDT in the BFST which are equal to FP_UMF_DATETIME1, and ipso facto we replace every occurence of FP_UMF_DATETIME2 with FP_UMF_DATETIME1 in
the BFST.

Alternatively, if COUNT2 is greater than COUNT1, this means that there are more UMFDT in the BFST which are equal toFP_UMF_DATETIME2, and ipso facto we replace every occurence of FP_UMF_DATETIME1 with FP_UMF_DATETIME2 in the BFST.  

If both COUNT1 and COUNT2 are equal, this means FP_UMF_DATETIME1 and FP_UMF_DATETIME2 were unpacked an equal number of time.  In this case, the time with the smallest UMNFC is used to filled the BFST because
it is the time closest to the begining of the major frame.


COMPUTING AN EUMFC.
-------------------



COMPUTING THE TIME FROM THE GRT.
------------------------------------


COMPUTING THE TIME FROM THE UMFC.
---------------------------------



SETTING THE MINOR FRAME QUALITY RANK.
-------------------------------------

We set the minor frame Quality Rank in order for AD to be able to set the Minor Frame Quality Byte (MFQB).

In the instrument records that AD builds, there are three independent minor frame quality flags: one for the Frame Sync Error (FSERR), one for the Minor Frame Counter Error (MNFCERR), and one for the minor frame
being a filled frame.  These are coded into a single byte, the MFQB.

The FSERR flag is provided by the frame synchronizer to AD, so it is available from AD which stores it in the BFST for each minor frame.

The MNFCERR flag is set as a result of BFST processing by Oracle in procedure BFST_SET_MNFCERR, since it is at that point that the minor frame can positively be determined to have an invalid counter using the 
rules that:

    Within the established dataspan, if an unpacked minor frame counter 
    is inconsistent with consistent preceding and following minor frame 
    counters, this minor frame is suspect.  If the minor framed counter
    for the frame in question, estimated from the minor frame ground 
    receipt datetime, does not match the one stored in the UMNFC column, 
    set the MNFCERR flag and store the estimated minor frame counter as 
    the minor frame counter for all further references to this minor 
    frame.  For more information on setting the MNFCERR see the section 
    titled SETTING THE MINOR FRAME COUNTER ERROR FLAG.

In addition to setting the MNFCERR flag, other flags for other detected data errors are also set, for example an invalid Major Frame Counter value (MFCERR), an invalid Mode value (MODEERR), or an invalid major
frame floating point Datetime value (DATEERR).  These error flags are set and inserted in the BFST internally during reconstruction, and are used to rank minor frames along with the aforementioned error flags.  The combination of the ranking assignments for the various error flags, and a limit on the worst minor frame rank which is deemed acceptable, provide a means of implementing a very general set of minor frame selection criteria.  We call the rank we assign to valid minor frames based on the combination of all the available minor frame quality flags, the Quality Rank (QR).

Note that we do not assign a QR to minor frames which have been eliminated from consideration for use in major frame reconstruction by having the MNFFF set, for any of the reasons we have stated in the preceeding rules, summarized below:

    Summary of Reasons for Minor Frame Elimination from Reconstruction 
    (MNFFF = 1)
    --------------------------------------------------------------------

    - Minor frame is inverted (procedure xxx).
    - Minor frame could not be identified (procedure xxx).
    - Minor frame may have an uncorrectable counter (procedure xxx).
    - Time lines were inconsistent between contigs of the same major 
      frame (procedure xxx).

The following is the logic followed by Oracle to assign a qualtity rank to each minor frame of a reconstructed major frame:

    The following procedures set the various error flags that 
    cummulatively, will result in a QR assigment:

        - BFST_SET_DATEERR.  Sets the date error flag.
        - BFST_SET_MNFCERR.  Sets the minor frame counter error flag.
        - BFST_SET_MODEERR.  Sets the mode error flag.
        - UPDATE_CDM.  While determining what the Current Data Mode 
          (CDM) of a major frame is, this procedure may set the MODEERR 
          flag if its analysis of a group of minor frames concludes so 
          (see the section titled SETTING THE MODEERR FLAG AND ASSIGNING 
          A CDM TO A MAJOR FRAME).
        - ACTION_CS_01, ACTION_CS_02, ACTION_CS_12, ACTION_CS_21, 
          ACTION_CS_22 and all other procedures discussed in the section 
          titled CONSEQ ANALYSIS.
    
     During a reconstruction session, a temporary table called QUAL_COMP 
     is created by procedure CREATE_QUAL_COMP.  The purpose of this 
     table is to store for a comparison at a later stage, the quality 
     information for minor frames of major frames which were unpacked in 
     different sessions (for a complete description of this and other 
     tables see file TABLES_DESC.txt).  During a reconstruction
     session and within the execution of procedure BFST_CHECK_SUBT1 
     (which is a sub-procedure of procedure INSERT_POINTERS), it is 
     determined that a minor frame for a major frame had already been 
     found in an earlier session when in the process of assigning the 
     current session's SPOINTER to this minor frame, one is found to 
     have already been assigned.  In this case procedure 
     BFST_RECORD_QUAL is invoked with the following arguments:
       
        - Time.  The major frame datetime to which the minor frame 
          belongs.
        - UMNFC_cur.  The unpacked minor frame counter of the minor 
          frame.
        - CELL_VALUE.  The small pointer that had been previously 
          assigned to the minor frame.
        - ROWID1.  The rowid of the current major frame, in one of the 
          subtables where the minor frame that has been found again is 
          stored.
       
    Within procedure BFST_RECORD_QUAL The current SPOINTER is compared 
    to that passed in as argument (CELL_VALUE). If both SPOINTERs are 
    identical this means that we are merely reprocessing the same set
    of tables and therefore there is no improved minor frame quality is 
    to be expected from this reprocessing.  If both SPOINTERs are not 
    the same we next find out from querrying table MNFFPT, what the 
    Anotated Minor Frame File (AMF_FILE) names corresponding to these 
    two SPOINTERs is.  If both AMF_FILEs are the same, this means that 
    we are reprocessing the same set of tables (with different names 
    because of the timestamp) and therefore there is no improved minor 
    frame to be expected from this reprocessing.  If both AMF_FILEs are 
    not the same, we querry the BFST in which the minor frame had
    previously been found, for the QR of that minor frame.  
    
    We next insert into table QUAL_COMP the unpacked major frame 
    floating point datetime, the unpacked minor frame counter of the 
    minor frame in question, the SPOINTER of the current session, the QR 
    that had been previously assigned to this minor frame, and the rowid 
    of the current major frame datetime in one of the subtables where 
    the minor frame that had been found again is stored.  This end the 
    execution of sub-procedure BFST_RECORD_QUAL for this minor frame of 
    the major frame under examination.

    After all the procedures which set the various error flags in the 
    BFST for the current session have been executed, procedure 
    BFST_ASS_QRANK is executed next.  Within procedure BFST_ASS_QRANK 
    all the BFSTs that have their SPOINTERs stored in the temporary 
    table SPOINTERT, and which entries will be referenced in the recipe 
    table are are querried for the following: ID, FSERR, MNFCERR, 
    MFCERR, MODEERR, and DATEERR.  Note that table SPOINTERT stores all 
    the SPOINTERs for all the major frames that will be reconstructed.  
    We next querry the MNFQT for the QR which matches the assignment set 
    of error flags returned by the previous querry.  The quality rank 
    obtained is updated in the BFST under consideration, at the location 
    (ID) of the minor frame being examined.  All minor frames that 
    eventually will be part of the recipe go through this quality rank 
    rank assignment.

    After all the major frames present in the WFST have been processed, 
    table QUAL_COMP may either be empty (i.e. no minor frames of major 
    frames that had previously been found were found again) or populated
    (i.e. minor frames of major frames that had previously been found 
    were found again).  Following the execution of procedure 
    BFST_ASS_QRANK, procedure BFST_COMP_QUAL is invoked next.  Should 
    table QUAL_COMP not be empty, all rows in the table are selected in 
    turn.  For each minor frame, the current QR is compared to the 
    quality rank determined during a previous reconstruction session.  
    If the overall quality of the minor frame has improved, the subtable 
    where that minor frame resides is updated to point to the SPOINTER 
    (BFST) of better quality.  Next, the Current WFST is updated to 
    indicate that information on the major frame has improved.  The 
    latter step is necessary because it is by querrying the WFST's 
    indicator column (INDICATOR = 1) that Oracle will know which major 
    frame to generate a recipe for.  For each major frame for which an 
    improvement in the quality of its minor frame is detected, a message 
    is outputed to the buffer to alert the analysts of the event.

The minor frame selection criteria applies if more than one minor frame with the same minor frame counter exists, which has been associated with the same major frame.  In this case, we select the best available minor frame (the one with the lowest QR) based on the minor frame quality flags using a rating scheme indicated in Table XX, and set the fill flag according to the value of the fill Limit_Quality_Rank.  In the example below, Limit_Quality_Rank = 3, means that we have elected to set the fill flag for a minor frame having a QR = 3 or above.  Any minor frame that is determined to be the best available, which also has its fill flag set, is to result in a fill frame being generated to replace that minor frame.  This means that there are two situation in which a minor frame will have to be filled:

    a. because it is simply not present in the Bad Frame Log File (BFLF) 
       and has no entries in the BFST, the fill flag is set.  Such fill 
       frame are assigned QF = 32 (see Table XX).
    b. because although it exists in the BFLF, and has an entry in the 
       BFST, it still will have a fill frame substituted for it in the 
       reconstructed major frame because its filling is set due to its 
       QR being too poor (QR >= Limit_Quality_Rank).

              
 




























         Table XX: Example of Quality Rank Assignments _____________________________________________________________________
|  QRANK   FSERR   MNFCERR   MFCERR   MODEERR   DATEERR   FILLFLAG  |
| ------- ------- --------- -------- --------- --------- ---------- | 
|    0       0        0         0        0         0          0     |
|    1       1        0         0        0         0          0     |
|    2       0        1         0        0         0          0     |
|    3       0        0         1        0         0          1     |
|    4       0        0         0        1         0          1     |
|    5       1        0         0        1         0          1     |
|    6       1        1         0        0         0          1     |
|    7       1        0         1        0         0          1     |
|    8       0        1         1        0         0          1     |
|    9       0        1         0        1         0          1     |
|   10       0        0         1        1         0          1     |
|   11       1        1         1        0         0          1     |
|   12       0        1         1        1         0          1     |
|   13       1        0         1        1         0          1     |
|   14       1        1         0        1         0          1     |
|   15       1        1         1        1         0          1     |
|   16       0        0         0        0         1          1     |
|   17       1        0         0        0         1          1     |
|   18       0        1         0        0         1          1     |
|   19       0        0         1        0         1          1     |
|   20       0        0         0        1         1          1     |
|   21       1        0         0        1         1          1     |
|   22       1        1         0        0         1          1     |
|   23       1        0         1        0         1          1     |
|   24       0        1         1        0         1          1     |
|   25       0        1         0        1         1          1     |
|   26       0        0         1        1         1          1     |
|   27       1        1         1        0         1          1     |
|   28       0        1         1        1         1          1     |
|   29       1        0         1        1         1          1     |
|   30       1        1         0        1         1          1     |
|   31       1        1         1        1         1          1     |
|   32      N/A      N/A       N/A      N/A       N/A         1     |
---------------------------------------------------------------------

If there are multiple minor frame entries with the same best rank available for a given value of the minor frame counter for the given major frame, we select the first entry.  If the fill flag is set, Oracle will pass the instruction to fill this minor frame when it generates the reconstruction recipe.

The recontruction recipe will also include for each minor frame the QR, so that AD will be able to set the MNFQB for every minor frame.  There is an array of these MNFQBs stored in every instrument record sent to
DPS so that it has the data quality (as defined for the MNFQB, see Table XX) of every minor frame in the major frame for which the major frame from which the instrument record was built.  The MNFQB only records 
FSERR, MNFCERR, and FILLFLAG, so if we assume the QR was assigned as shown in Table XX above, AD would use the QR to set the minor MNFQB as follows:







Table XX: Example of Converting BFST Quality Rank to the MNFQB used by 
          DPS
             
      ___________________________________________________________ 
      | Quality  |  Minor Frame Quality Byte                    |
      | Rank     |  bit 0 = FSERR flag, bit 1 = MNFCERR flag,   |
      |          |  bit 2 = fill frame flag, bit 3-7 = spare    |
      |          |  7654 3210 (binary bits)      X (decimal)    |
      -----------------------------------------------------------
      |     0    |  0000 0000                    0              |
      |     1    |  0000 0001                    1              |
      |     2    |  0000 0010                    2              |
      |     3    |  0000 0100                    4              |
      |     4    |  0000 0100                    4              |
      |     5    |  0000 0101                    5              |
      |     6    |  0000 0111                    7              |
      |     7    |  0000 0101                    5              |
      |     8    |  0000 0110                    6              |
      |     9    |  0000 0110                    6              |
      |    10    |  0000 0100                    4              |
      |    11    |  0000 0111                    7              |
      |    12    |  0000 0110                    6              |
      |    13    |  0000 0101                    5              |
      |    14    |  0000 0111                    7              |
      |    15    |  0000 0111                    7              |
      |    16    |  0000 0000                    0              |
      |    17    |  0000 0001                    1              |
      |    18    |  0000 0010                    2              |
      |    19    |  0000 0100                    4              |
      |    20    |  0000 0100                    4              |
      |    21    |  0000 0101                    5              |
      |    22    |  0000 0111                    7              |
      |    23    |  0000 0101                    5              |
      |    24    |  0000 0110                    6              |
      |    25    |  0000 0110                    6              |
      |    26    |  0000 0100                    4              |
      |    27    |  0000 0111                    7              |
      |    28    |  0000 0110                    6              |
      |    29    |  0000 0101                    5              |
      |    30    |  0000 0111                    7              |
      |    31    |  0000 0111                    7              |
      |    32    |  0000 0100                    4              |
      ----------------------------------------------------------- 



SETTING THE MINOR FRAME COUNTER ERROR FLAG.
-------------------------------------------

The MNFCERR flag is set in procedure BFST_SET_MNFCERR whis may be summarized as follows:  if an UMNFC is inconsistent with consitent preceeding and following minor frame counts, this minor frame is suspect.  We next check to see if the GRT of the suspect minor frame is consistent with its neighbors using these formulas:
    
  NPER = (FP_UMNFGR_DATETIME1_2 - GRTBASE) / MNFDP1_2;

  REMAINDER := ABS((FP_UMNFGR_DATETIME1_2 - GRTBASE) - NPER * MNFDP1_2);

  NPER refers to the number of minor frame downlink periods (MNFDP) that 
  the minor frame being checked is away from the baseline minor frame.
    
    FP_UMNFGR_DATETIME1_2 refers to the ground receipt time of the 
    suspect minor frame being evaluated.

    GRTBASE refers to the ground receipt time of the baseline minor 
    frame in the conseq.  Within procedure BFST_SET_MNFCERR the first 
    minor frame is in the conseq is always used the baseline.
  
    MNFDP1_2 refers to the MNFDP of the minor frame being evaluated.

    REMAINDER refers to how far away from the baseline minor frame the 
    minor frame being evaluated ought to be.

If REMAINDER is greater than a tolerance value stored in the missions_parameters table, then the minor frame being evaluated is flagged with a fail flag in the current session's BFST (MNFFF = 1); else the expected UMNFC is computed using the following formula: 
    
    EUMNFC := ROUND (ABS ((UMNFCBASE + DIRECTION1 * 
              (FP_UMNFGR_DATETIME1_2 - GRTBASE)/MNFDP1_2)));

    EUMNFC refers to the minor frame counter expected for the minor 
    frame being evaluated.

    DIRECTION1 refers to the order in which the data is arranged: 
    forward order (real time pass) or 
    backward order (real time).

    UMNFCBASE refers to the baseline UMNFC of the minor frame used to 
    correct the one that is being evaluated.

    Note that the Oracle ROUND function as used in the above equation 
    rounds to the nearest higher integer if the result has a decimal 
    greater than or equal to 0.5 or to the nearest lower integer if the 
    result has a decimal les than 0.5.  All minor frames for which their 
    counters had to be estimated have their UMNFCERR flag raised.


SETTING THE DATE ERROR FLAG.
----------------------------

The DATEERR is set at three levels: during AD by LabVIEW, during conseq analysis (see the section titled CONSEQ ANALYSIS) and in procedure BFST_SET_DATEERR.  

During AD by LabVIEW, all unpacked major frame datetimes are checked for date error by LabVIEW using a base datetime obtained as follows: at the begining of an AD session, LabVIEW querries the AFST for a baseline datetime (FPbase) that is closest to the first unpacked datetime in the BFST (which we'll call FP), provided that FPbase is no earlier or later than two days from FP.  If such a time is found, LabVIEW next determines how many periods away (NPER, periods away from the mission's low period (Pmin)) FP is from FPbase.  A SCALE variable is computed next using the following two equations sequentially:
    
    SCALE = int (NPER / 20) + 1;

    SCALE = min (SCALE,10);

The SCALE, which is no more than 10 periods away, is used as shown in the followind equations to set the DATEERR flag:

    DT = abs (FP - FPbase);
  
    NPER = INT (DT / Pmin);

    Pdiff = abs (NPER*Pmin - DT);

    DT = Difference in time;
    
    Pdiff = Difference in periods;
    
    DATEERR = 1 if Pdiff > Ptol * SCALE;
  
    Ptol = Tolerance in the period's fluctuation = .0000050

If a baseline datetime could not be obtained from the AFST, time FP is used as the baseline to compare against the next time in the AMF_FILE (which we'll call FP2).  If MOD (abs((FP2 - FP) / Pmin), Pmin) < Ptol
then the DATEERR flag is not raised.  Should FP2 pass the DATEERR test, it becomes the new baseline against which the next time unpacked in the AMF_FILE will be compared.  If FP2 does not pass the DATEERR test, it 
is flagged and FP remains the baseline time against which the next time in the AMF_FILE will be compared.  This process of checking the time in the AMF_FILE continues untill all unpacked times have bee checked.

During conseq analysis, depending on the state of the conseqs, a DATEER may be set if an unpacked time is found to be invalid, or if a computed time (computed based on the GRT or the UMFC) is found to be inconsistent with what's expected for that conseq.

Within procedure BFST_SET_DATEERR all not null major frames floating point datetimes, their ID (which is a unique pointer to a minor frame in a BFST), and the minor frame ground receipt datetimes are querried from
the current sessions's BFST.  Also querried is the mission's launch date stored in the MISSIONS_PARAMETERS table.  For every minor frame, if the floating point datetime is strictly greater that its GRT or < than the mission's launch date, the DATEERR flag is raised (DATEERR = 1) for that minor frame for that session's BFST.

SETTING THE MODE ERROR FLAG AND ASSIGNING A CDM TO A MAJOR FRAME.
-----------------------------------------------------------------

The MODEERR flag is set at two levels: during the execution of procedure BFST_SET_MODEERR and during the execution of procedure UPDATE_CDM.

Within procedure BFST_SET_MODEERR, all of the current BFST's unpacked CDM are unpaked are checked against those stored in table CDM_MFPT.  Table CDM_MFPT stores all of the mission's  CDM and their corresponding
MFP.  CDMs are integers that range from 0 to 15.  Each CDM is associated with a MFP.  There is a MODEERR when the associated MFP for an unpacked CDM is 0; therefore procedure BFST_SET_MODEERR flags all minor frames with CDMs that correspond to a MFP of zero with a mode error (MODEERR = 1).  It should be noted that the CDM represent the primary mode index which range is restricted to the size of the data record header
telemetry mode indicator minus 1.  

The purpose of procedure UPDATE_CDM is to compare all the unpacked CDM for each major frame for which a recipe will be generated.  UPDATE_CDM starts off with the creation of table temp1, a description of which can be found in file TABLE_DESC.txt.  Next, all major frames for which a recipe will be generated are selected from the WFST, along with all the BFSTs that will be referenced in the recipe table.  Within each BFST, all UMNFC, CDM, MODEERR, and MNFFILE (Minor Frame File, equivalent to the name of the BFST) are querried and inserted into table temp1 if they belong to the major frame currently under evaluation and if their UMNFC is divisible by five.  The latter restriction is imposed because it is only at UMNFC divisible by five that a CDM is unpacked.  

Note that at this point in procedure UPDATE_CDM, table temp1 contains UMNFC, CDM, MODEERR, and MNFFILE for minor frames of one of the major frames to be reconstructed.  Next, the number of distinct CDM for minor 
frames in table temp1 with an UMNFC divisible by five is counted into variable NUM_CDM, along with the number of minor frames with MODEERR = 1 and UMNFC divisible by five which is counted into variable NUM_ERR.  If NUM_ERR and NUM_CDM are equal with NUM_ERR not being equal to zero, or if NUM_CDM is equal to zero, the major frame under evaluation is assigned a CDM of 256.  In summary, a CDM of 256 is assigned to a major 
frame if none of its minor frames have their UMNFC divisible by five or if all of those that have their UMNFC unpacked also report a DATEERR.  

If NUM_CDM is equal to one, this value of the CDM is querried from table temp1 and inserted into the WFST as the one to be used for the major frame under evaluation.  

If NUM_CDM is equal to two, this means that there are two distinct unpacked CDMs for a major frame.  A count of how many times each CDM is unpacked is querried next from table temp1.  The cdm to be used for the
major frame under evaluation is the one the most often unpacked provided that its counter part is unpacked only once.  In the latter case the minor frame where the CDM was unpaked only once is flagged with MODEERR.
If both CDM are unpacked more than once, if both are unpacked exactly once, or if there are more than two unpacked cdm for a major frame, a cdm of 128 is assigned to the major frame.  
 
CDMs for unknown modes were added so that all of the downstream processing can detect and avoid processing such major frames.  In conclusion 128 denotes a transitional mode and 256 denotes an unknown mode.   




TRENDING.
---------
There are two Oracle tables that are used for trending: Trend_Time and Recipe2.

    Trend_Time:  This table is made of two columns which store the 
    floating point major frame datetime and the umpacked major fame 
    counter.

    Recipe2: This table contains the recipe that was generated during a 
    trending session.

At the onset of trending, Labview querries the AFST for grade 1 major frame times and counters that are in a specified timespan.  The set returned by the latter querry is inserted into table Trend_Time for
recipe generation.  Two Oracle procedures are involved in the generation of a recipe from the entries in table Trend_Time.  

Procedure TREND_GEN_RECIPE is invoked in SQLPLUS by Labview during trending should there be a need to reconstruct major frames within a timespan.  This procedure takes no arguments.  At the onset of trending   
reconstruction, pre-existing entries in table recipe2 are deleted to make way for new ones.  The Missions_Parameters table is querried for two quantities: lim_qrank and max_qrank.  Lim_qrank represents the limit quality rank, which sets the cut-off boundary from where minor frames will be filled.  All minor frames with a quality rank greater than or equal to lim_qrank will be filled.  Max_qrank represents the 
maximum quality rank that a minor frames can have.  Minor frames that have not been found are assigned a quality rank equal to max_qrank, which means that they will be filled.  For more information about quality rank assignment see SETTING THE MINOR FRAME QUALITY RANK.  

Next in the execution of procedure TREND_GEN_RECIPE, a sub-procedure called TREND_GEN_RECIPE2 is invoked to actually generate the recipe for all the major frames found in table trend_time.  Sub-procedure 
TREND_GEN_RECIPE2 takes the following arguments:

    Subtable (VARCHAR2 type, IN mode).  This represents the name of the 
    table which contains the BFST pointers for a range of minor frames 
    for all major frames.

    Low_index (NUMBER type, IN mode).  This represents the lowest minor 
    frame counter in the range of minor frames stored in a subtable.

    High_index (NUMBER type, IN mode).  This represents the highest 
    minor frame counter in the range of minor frames stored in a 
    subtable.

    Lim_qrank (NUMBER type, IN mode).  This represents the limit quality 
    rank, which sets the boundary from where minor frames will be 
    filled.

    Max_qrank (NUMBER type, IN mode).  This represents the maximum 
    quality rank that a minor frame can have.

    NMFIRT (INTEGER type, OUT mode).  This represents the Number of 
    Major Frames in the Recipe2 Table.  This value is returned to 
    procedure TREND_GEN_RECIPE.

Because there are five subtables that store information for a set range of minor frame counters, sub-procedure TREND_GEN_RECIPE2 is invoked five times, each time corresponding to the following minor frame counter ranges: 0 to 50, 51 to 100, 101 to 150, 151 to 200, and 200 to 249.

The execution of sub-procedure TREND_GEN_RECIPE2 starts up with the initialization to zero of the count1 variable which represents the number of major frames in the recipe2 table.  Next, the trend_time table is
querried in a loop for all major frame floating point datetimes and their associated unpacked major frame counters.  For each floating point datetime returned by the previous querry, a corresponding rowid is querried from the subtable (the one passed in as first argument in the sub-procedure) for that same datetime.  The rowid is a binary value maintained by Oracle, that uniquely represents the location of each row 
of data in the database.  A rowid is the fastest way to retrieve a row in the Oracle system.  Once the rowid has been retrieved (still within the first loop), a 'FOR LOOP' is started for a range of low_index
to high_index with increments of 1.  Within this 'FOR LOOP' the subtable is querried, at the previously selected rowid, for every minor frame's pointer.  If a major frame's minor frame has no pointer (i.e.
variable POINTER1 is null) this means that this minor frame has not been found, therefore the following message is inserted into table recipe2 in the appropriate columns, as an example:

    ' 2910644844.589406 fill minor frame 136 QF = 32 233 '
    (note that 233 represents the UMFC).

If a major frames's minor frame has a pointer (i.e. variable POINTER1 is not null), this pointer is used to querry table MNFFFPT (Minor Frame File Pointer table) for the BFST where this minor frame was found.  
The minor frame location and the quality rank are extracted from the BFST and should the quality rank be greater than the limit quality rank a fill message similar to the one above is inserted in table recipe2,
else the following message is inserted into table recipe2 in the appropriate columns, as an example: 

    ' 2910644844.589406 get from file WIND1997189201006294BAD minor 
    frame 137 at location, 23, QF = 32 233'
    (note that 233 represents the UMFC). 

Once the 'FOR LOOP' has completed, table trend_time is querried for the major frame time next in line to be reconstructed, until all major frames have been processed.  Once all the major frame times have been 
processed, sub-procedure TREND_GEN_RECIPE2 returns the number of major frames in table recipe2 to procedure TREND_GEN_RECIPE which in turn re-invoked sub-procedure TREND_GEN_RECIPE2 this time passing in as arguments a different subtable and its associated range of minor frame counter indices.

Once all the subtables have been processed in sub-procedure TREND_GEN_RECIPE2, procedure TREND_GEN_RECIPE outputs the number of major frames reconstructed (i.e. NMFIRT) and all entries in table trend_time are deleted to make way for ones that will be inserted by the next trending session.








List of acronyms:
-----------------

UMFDT: Unpacked Major Frame Datetimes.

AFST: Acumulated Frames Statistics Table.

FSERR: Frame Synchronizer Error.

MNFQB: Minor Frame Quality Byte.

MNFCERR: Minor Frame Counter Error.

QR: Quality Rank.

UMNFC: Unpacked Minor Frame Counter.

MNFFILE: Minor Frame File name.

AD: Assembly and Decommutation.

MODEERR: Mode Error.

MFCERR: Major Frame Counter Error.

DATEERR: Date Error.

GFST: Good Frames Statistics Table.

MNFFF: Minor Frame Fail Flag.

BFST: Bad Frames Statistics Table.

MFP:  Major frame period.

UMFC: Unpacked Major Frame Counter.

MNFQT: Minor Frame Quality Table.

NMFIRT: Number of Major Frames in Recipe(2) Table.

AD: Assemby/Decommutation.

AMF_FILE: Annotated Minor Frame File.

MNFSKIP: Minor Frame Skip.

UMFDT: Unpacked Major Frame Datetimes.

NUM_UMFC2: Number of times UMFC2 is unpacked in a conseq.

NUM_UMFC3: Number of times UMFC3 is unpacked in a conseq.

DISC: Discontinuity flag.

GRT: Ground Receipt Time.

NUM_CDM: Number of distinct CDM for minor frames with UMNFC divisible by 
         five in temporary table temp1.

NUM_ERR: Number of minor frames with MODEERR=1 and UMNFC divisible by 
         five in temporary table temp1.

CDM: Current Data Mode.

EUMNFC:  Refers to the minor frame counter expected for the minor frame 
         being evaluated.

MNFDP: Refers to the Minor Frame Downlink Period.

GRTBASE: Refers to the baseline ground receipt datetime.

NPER: Refers to the number of MNFDP that the minor frame being checked 
      is away from the base minor frame.

UMNFCBASE: Refers to the baseline UMNFC of the minor frame used to 
           correct the one that is being evaluated.

SPOINTER: Small Pointer.

LPOINTER: Large Pointer.


