Disabling a Function From Within an MFS [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Disabling a Function From Within an MFS ======

One of the roles played by an MFS is that of monitoring specific functions and disabling them under certain circumstances. An example is that of a security MFS that monitors all reads and writes to a file, and permits only authorized users to execute these functions.

The standard method for disabling a function is for the MFS to set the STATUS argument to false, and to execute a [[return|RETURN statement]] immediately. The MFS should normally not call subsequent filing systems, since these may proceed with the operation (such as creating a file or updating a record), reset the value of STATUS, or set the value of other variables used in detecting the success of an operation.

In many cases, the BASIC+ command that generated the MFS call will fall through its ELSE logic when detecting a status of false. This is the case, for instance, for the BASIC+  [[read_row|Read_Row subroutine]]. Many System Monitor commands will also post a message indicating that the command could not be executed.

The program fragment below illustrates a simple method for disabling the READ.RECORD code:

<code>
READ.RECORD:

  GOSUB CHECK.SECURITY

  IF SECURITY.CHECK = PASSED$ THEN

    GOSUB NEXT.MFS

  END ELSE

    STATUS = 0

  END

  RETURN
</code>
 

This method of disabling functions means that a subsequent MFS does not have an opportunity to act upon the code being called. This has implications for the ordering of MFSs. For example, if an audit trail MFS is required to log an attempt to read, write or delete all records -- even if these functions are not successful -- the audit trail MFS must precede any security MFS that might abort the record operation.

Not all functions translate a status value of false directly into a failure. For example, a BASIC+ [[select|SELECT statement]] does not look at the return value of STATUS. Instead, the [[select|SELECT statement]] examines the value of RECORD to determine whether a select condition is active. The value of RECORD is translated into the value of the system variable @LIST.ACTIVE, which is in turn read by subsequent [[readnext|READNEXT statements]]. If RECORD (and by extension, @LIST.ACTIVE) is false, a [[readnext|READNEXT statement]] will fall through its ELSE logic.