One reason an MFS may wish to trap the READNEXT call is in order to fulfill READNEXT calls without recourse to the BFS. In OpenInsight, both QUICKDEX.MFS and SI.MFS trap the READNEXT call, returning record keys without passing the call to the BFS.
QUICKDEX.MFS provides a good model for using an MFS to trap READNEXT requests. If the filing system SELECT call has returned a select mode of 1 (latent file select), QUICKDEX.MFS traps the READNEXT call. The MFS reads the %RECORDS% record from the current file, and returns it as the next block of keys. If another READNEXT call comes down to the MFS, QUICKDEX.MFS simply returns a false, since all keys were returned in the first call.
Extended (Resolved) Select
Unlike the simple SELECT statement, the extended BASIC+ SELECT ... BY statement results in a resolved list of record keys. Instead of simply initializing variables, the special SELECT processor executes a series of operations. Only when the operations are completed and when a list of record keys is available does the BASIC+ program proceed to the next statement.
The BASIC+ logic that generates a resolved list looks something like this:
SELECT "FILENAME" BY "FIELD1" SETTING 0 ELSE CALL MSG(@window, "Select failed with status ":STATUS()) RETURN 0 END * resolved list now available * (no BFS access required) DONE = 0 LOOP READNEXT @ID ELSE DONE = 1 UNTIL DONE DO (etc.) REPEAT
In order to resolve the select list, the special SELECT processor must examine each record in the file (or index). As a result, SELECT ... BY generates a series of filing system calls. In effect, the single BASIC+ SELECT statement compresses an entire SELECT ... READNEXT ... READ loop into a single statement, examining each record in the file.
When the READNEXT loop is completed and all records have been assembled, the SELECT processor sorts the records. The result is a resolved select list, with the keys in order according to sort criteria specified in the SELECT ... BY statement. The entire select list is then available in the system list variable and @LIST.ACTIVE is set to 3. Because the SELECT ... BY statement has completely resolved the select list, no further filing system calls are required. The READNEXT processor simply fetches the sorted keys from the system list variable, without requiring filing system READNEXT calls.
Indexed-Based SELECT
If the sort criteria passed in an extended BASIC+ SELECT statement represent indexed fields, there is no need for the SELECT processor to execute an entire SELECT ... READNEXT ... READ loop in order to build a resolved list of keys. Instead, the list can be constructed directly from the Btree index.
The result of this condition is a latent index-based select. This is similar to a latent file-based select condition as established by a simple BASIC+ SELECT. However, it differs in that a latent index-based select can return keys in sorted order.
A latent index-based select condition is not a BFS-level function. If an indexed field is passed as a sort criterion in a filing system SELECT call, SI.MFS traps the call. Other MFSs that follow SI.MFS, and the actual BFS, never receive the SELECT call. SI.MFS returns a select mode of 2 in the RECORD argument (causing @LIST.ACTIVE to be set to 2), indicating an index-based select condition.
SI.MFS will then trap subsequent filing system READNEXT calls, providing blocks of keys out of the Btree index. Again, filing systems that follow SI.MFS will never receive this call, since it is trapped and fulfilled by SI.MFS.
CLEARSELECT MFS Processing
A special call is provided to enable a filing system to clear select lists. The major function of a CLEARSELECT is to clear the system variables (such as the system list variable) used to indicate an active select list.
The call is passed through to the filing system, however, in case the filing system needs to take action when a select list condition is cleared. For example, Linear Hash (RTP57) uses a CLEARSELECT call as an indication that it can reset its sizelock parameter by decrementing it.
