You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.


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.

  • No labels