SDF-A can be used to limit the range of functions either throughout the BS2000 system or for a specific user ID. A system-global limitation must be defined in a system syntax file, a limitation for a specific user ID in a group syntax file.
When defining a limitation in a group syntax file, the relevant system syntax file must be assigned as a reference file (OPEN-SYNTAX-FILE ... SYSTEM-DESCRIPTIONS=) if the definition of the command or statement is not already present in the group syntax file.
Commands, statements, operands and operand values can be disabled either generally (using the REMOVE statement) or for specific operating modes (using the statement MODIFY-xxx ...,DIALOG-ALLOWED=...,DIALOG-PROC-ALLOWED=..,BATCH-ALLOWED=...,BATCH-PROC-ALLOWED=...). In addition, commands may be disabled as a function of the way they are called (CMD-ALLOWED=).
Limiting the functional scope of a command
If the functional scope of a command is to be effectively limited, care must be taken to ensure that the limitation defined cannot be circumvented with the help of other commands. In most cases a limitation can be circumvented with the help of the old ISP commands. These are defined such that their functional scope cannot be modified using SDF-A. They can only be disabled. If they can be called via the MCLP interface, a general lock can have unforeseeable consequences. A sensible precautionary measure would then be to disable these commands for interactive and batch mode only, but not for calls via MCLP (Macro Command Language Processor). However, such a partial disabling can be circumvented relatively easily, e.g. with the help of EDT. The appropriate action is determined by the particular case (see examples 4 and 6). Commands sent with the SDF-P command EXECUTE-CMD (e.g. to divert the command output to a variable) are not subject to the requirements for DIALOG-ALLOWED=..., DIALOG-PROC-ALLOWED=..., BATCH-ALLOWED=... and BATCH-PROC-ALLOWED=..., because they are called via the MCLP interface.
Disabling operands
If an operand is to be disabled, it is usually impossible to predict the consequences on the implementation if the definition of the operand is deleted. To be on the safe side it is advisable merely to mask out the operand at the user interface by means of the statement MODIFY-OPERAND..., PRESENCE=*INTERNAL-ONLY. A default value must then be defined, covered by an operand value defined for the operand.
It is also possible to define a limitation in the functional scope by defining a secret operand and subsequently concatenating it with a visible operand (see example 5, "Example 5: Restricting the set of usable programs").
Limiting operand values
Limitations as to the permissible length or the permissible digit value for operand values can be defined by means of the MODIFY-VALUE statement. Furthermore, in MODIFY-VALUE..., VALUE=(<c-string>(...),...),... you can specify a list of valid input values. All values not listed are then rejected as invalid. The statement MODIFY-VALUE... VALUE=<cstring>(...,OUTPUT=...,) can be used to direct SDF to convert a defined single value to another value before passing it to the implementation or to suppress transfer of the value. In some cases, the limitation can also be imposed by modifying the data type. In the case of operand values defined as fully or partially qualified file names, the specification of the catalog identification, the user ID, a generation number or the designation of a version number as well as the input of wildcards may be declared illegal. Wildcards can also be declared illegal for the data types <alphanum-name>, <composed-name> and <name>.
Limiting the functional scope of a user program
A user program limitation defined in a system or group syntax file can be rendered ineffectual by means of a user syntax file. If the functional scope of a user program is to be limited effectively, care must be taken to ensure that the users concerned cannot define the full functional scope in a user syntax file.
Restricted loading and execution of programs
System administration can restrict the loading and execution of programs to certain user applications (such as EDT), by defining a START-EDITOR command in the UTILITIES or PROGRAMMING-SUPPORT domain of SDF (see example on "Example 4: Permitting only one program (EDT)").
To prevent the commands START-PROGRAM, EXEC, LOAD-PROGRAM and LOAD from being executed directly, system or group syntax files are changed by assigning the attributes DIALOG-ALLOWED=*NO and BATCH-ALLOWED=*NO to these commands. The same attributes must be specified for the commands CALL-PROCEDURE, CALL and DO. This method prevents the direct execution of any program or procedure, but does permit procedure commands to be executed, in which case the procedures called may contain the illegal commands (START-PROGRAM,...).