MFS programmers will notice quickly that there is not a one-to-one correspondence between a BASIC+ OPEN statement and an MFS-level OPEN.FILE call. In fact, as a rule, an OPEN.FILE call will be generated only once per session for a given file.
OPEN.FILE Call
The OPEN.FILE call is generated by the BASIC+ interpreter in order to create a file handle for the file. The BFS creates a handle that it will recognize for subsequent read, write, and other record-oriented requests. The format of the file handle is dependent on the BFS being accessed.
Once the file handle has been created and returned from the BFS, the BASIC+ interpreter stores it in field five of the FILES file entry for the file in question. Any file that has already been opened during the current OpenInsight session will have a file handle in this field.
If the BASIC+ interpreter detects a file handle in the FILES file for the file being accessed, it will not generate a call to the filing system to return a handle. Instead, the handle is simply read from the FILES file and returned to the BASIC+ OPEN statement. This results in greater efficiency by lowering the overhead required to return a file handle.
BASIC+ Open File Handle
The file handle returned in the BASIC+ OPEN statement is not identical to that stored in the FILES file. BASIC+ OPEN returns a file handle that contains both the filing system list for a file (the MFS and BFS list) as well as the file handle required by the BFS. The filing system list is the first value (@VM-delimited) of the returned handle, and the BFS file handle is the second value. Multiple MFSs in the file handle are delimited with @SVM.
For example, the BFS EX.BFS might return a file handle looking like this:
\DATA\REV10000
If the file has SI.MFS and SAMPLE.MFS installed, the file handle returned by the BASIC+ OPEN statement will be:
SI.MFS n SAMPLE.MFS n EX.BFS 2 \DATA\REV10000
Updating the File Handle
One implication of storing the file handle is that the handle and MFS information stored in the FILES file must be updated if anything about a file changes that would normally affect the file handle.
A common example is the addition or removal of an MFS to a file. If an MFS is added to a file, the entry in the FILES file must reflect this change. The FILES file is write-protected. As a result, changes to the file handle must be registered indirectly. In essence, the programmer must force the system to clear the file handle in the FILES file, and thereby guarantee that the BASIC+ interpreter generate an OPEN.FILE call to the filing system the next time the file is accessed.
To do so, the programmer should detach and then re-attach the file after making appropriate changes such as installing the MFS.
OPEN Failure
It is rare that a BASIC+ OPEN statement will fail (fall through its ELSE logic) as a result of a BFS OPEN.FILE call.
Within an BASIC+ program, a failure in an OPEN statement (ELSE logic) is likeliest because the file has not been attached. If the file is attached but has not yet been opened, a filing system OPEN.FILE call is made. The BFS can choose to create a file handle in any way it likes, but will typically examine the media map for the volume in question, and read the physical file for information required for the file handle.
At this point, an OPEN will fail only if the information in the media map does not correspond to the file in some way, or if the media map itself had changed since the volume as a whole had been read by the ATTACH_TABLE command. For example, if a media map entry pointed to a DOS (or other operating system) file that did not exist, the filing system will likely detect this mismatch.
The OPEN will thus fail at the BFS level; this is indicated by a return value of false in the STATUS variable.
