Page History

When executing record-oriented calls such as READ.RECORD and WRITE.RECORD, the MFS does not know the OpenInsight file name of the file it is accessing. The only file information available to the MFS at the time is the file handle.

Some MFSs require access to the name of the file as seen by users. For instance, an audit trail MFS will likely wish to stamp the OpenInsight file name on entries in the log. Many MFSs must also use the file name, or information based on it, to open and access related files. An example is SI.MFS, which must open the ! file associated with a data file.

Modifying the File Handle

A second method is to make the OpenInsight file name part of the file handle. This guarantees that the file name is always available whenever the file handle is passed to the MFS.

In this method, the MFS traps the OPEN.FILE call as the BFS is returning the file handle back to BASIC+. During an OPEN.FILE call, the OpenInsight file name is available in the NAME argument. The MFS simply concatenates the file name onto the file handle with a delimiter before returning to the calling program. The BASIC+ program itself is not affected; it merely stores the handle until the next statement requiring it is executed.

When concatenating the two arguments, the MFS should avoid using delimiter characters that might otherwise appear in either argument. Characters to avoid include "!", "_", and "." (all of which frequently appear in the OpenInsight file name), as well as subvalue and value marks, which appear in the handle.

When subsequent file handle-oriented calls are made to the MFS, the handle will be returned to the MFS exactly the way the MFS has constructed it. The MFS must then strip the file name from the handle before passing the handle on for further processing.

The following code fragment illustrates how the OPEN.FILE logic might look in an MFS that is tracking the OpenInsight file handle:

OPEN.FILE:
FS = DELETE(BFS,1,1,1)
NEXTFS = FS<1,1,1>
CALL @NEXTFS(CODE, FS, HANDLE, NAME, FMC,RECORD,STATUS)
* add filename onto front of file handle,
* delimit with special character
RECORD = NAME:@TM:RECORD
RETURN

In this example, the MFS delimits the file name and file handle with a text mark (@TM). The same MFS uses logic as illustrated below to parse the file name out of the handle for the MFS calls that require a file handle:

* all following labels share the same logic
CLEARSELECT:
SELECT:
READNEXT:
READ.RECORD:
READO.RECORD:
WRITE.RECORD:
DELETE.RECORD:
LOCK.RECORD:
UNLOCK.RECORD:
* get clear file name, strip from file handle
FILE.NAME = FIELD(HANDLE, @TM , 1)
REAL.HANDLE = FIELD(HANDLE, @TM , 2)
FS = DELETE(BFS, 1, 1, 1)
NEXTFS = FS<1,1,1>
CALL @NEXTFS(CODE,FS,REAL.HANDLE,NAME,FMC,RECORD, STATUS)
RETURN.

Maintaining a Filename Table

Yet another means for tracking the OpenInsight file name is for the MFS to maintain a table of file names and handles. This method is useful if the MFS programmer does not wish to carry the filename on the file handle for fear of interfering with other filing systems.

One strategy is to create a labelled common area in the MFS.  In a simple scenario, the common area contains two dynamic arrays, one for file names and one for file handles.

When a file is first opened, the MFS traps both the file name and the file handle after the BFS has returned these. The MFS stores the file name in one array, and the file handle in the corresponding location in the second array. When access to the file name is required, the MFS can locate the file handle in its array, and extract the corresponding file name.

Because the file handle can change during a session -- for example, if a file has an MFS added and is reattached -- the file handle is updated in the labelled common area each time the file is opened.

The following example code fragment illustrates a method to establish the arrays. In this example, the file name is stored as passed to the MFS, in the format filename*application.

COMMON /FILENAME/ FILES.ARRAY,HANDLES.ARRAY
(other processing here)
OPEN.FILE:
* call BFS in order to get file handle
FS = DELETE(BFS,1,1,1)
NEXTFS = FS<1,1,1>
CALL @NEXTFS(CODE, FS, HANDLE, NAME, FMC,RECORD, STATUS)
* load handle and file name into labelled
common
IF STATUS THEN
  LOCATE NAME IN FILES.ARRAY USING @FM SETTING POS THEN
    HANDLES.ARRAY<POS> = RECORD
  END ELSE
    FILES.ARRAY<-1> = NAME
    HANDLES.ARRAY<-1> = RECORD
  END
END
RETURN

Once the arrays have been established, the MFS can extract the file name at any time that it has the file handle available.  The following code fragment illustrates a method by which the READ.RECORD logic might extract the file name:

READ.RECORD:
* search handle array to get position
LOCATE HANDLE IN HANDLES.ARRAY USING @FM SETTING POS THEN
  * extract corresponding file name
  FILE.NAME = FILES.ARRAY<POS>
END
FS = DELETE(BFS,1,1,1)
NEXTFS = FS<1,1,1>
CALL @NEXTFS(CODE, FS, HANDLE, NAME,FMC, RECORD, STATUS)
RETURN