Should end-users have access to TCL?

I don’t think there is anything fundamentally wrong with "qualified" users getting to TCL, and I’m a big fan of having well educated users rather than intentionally obscuring the powerful environment we have. However, as soon as someone mentions financial data being tweaked, or any sort of possible violations of referential integrity, I start singin’ a different tune. And since TCL access moves quickly from being a power tool to being a chronic source of application corruption, unfortunately I tend toward the position that most environments should simply keep users away from TCL.

I think all DBMS operations performed by non-administrators should be handled in a controlled manner, through facilities provided by the system administrators. (For auditing purposes it can’t hurt to compel admins to use the same controlled methods as other users, just with higher access privileges.) This means putting a wrapper around TCL. Rather than allowing the user to break/end from a menu, or letting a "TCL" command from a menu go to the real TCL, give them a controlled command line of your own. So for example:

BREAK OFF
LOOP
  CRT ">":
  INPUT CMDLINE
  UNTIL CMDLINE = "END"
  GOSUB PROCESS.VERB
REPEAT
BREAK ON
STOP
PROCESS.VERB:
  VERB = FIELD(CMDLINE,’ ‘,1)
  BEGIN CASE
    CASE VERB = "SORT"
      FNAME = FIELD(COMMAND,’ ‘,2)
      * check to make sure user has access to file, process if OK
    CASE VERB = "ED" OR VERB = "SED"
      CRT "You are not allowed to perform this operation"
      GOSUB LOG.UNAUTHORIZED.REQUEST
    CASE 1
      GOSUB LOG.UNHANDLED.REQUEST
  END CASE
RETURN

The idea here is that the user gets A command line, but not THE command line. If you want users to be able to "fix" corrupted data, then provide them with a program and a new verb that is accessible within their shell, so:

>FIX CUSTOMER 1234

will allow them to tweak the customer file, but will give you the opportunity to ensure that R.I. is maintained as well.

One thing to notice about the above is that the user’s verb is FIX. If they don’t know of the existence of the ED or SED commands (or AED or RED or JED or whatever tools you have available in your MV DBMS), then you don’t have to worry about the commands being used.

This approach eliminates the need to trap users on the back-end, with triggers on all files just in case someone does a LISTF and starts picking random files to destroy. The idea here is handle that problem pro-actively, on the front-end of the request, and to only give users access to the files to which they’re authorized.

I’m sure other people have differing opinions on the topic, but if you have one or more installations where end-users are doing things they shouldn’t, then you might want to consider creating a shell process like this just for limited purposes, and building upon it as need arises and time permits.

How do you handle situations where people operate outside of the toolkit that you provide? I’m afraid my position on this is quite stern – if people don’t use the resources as they are told then they should be threatened with penalties including termination. I’ve been in environments where end-users have caused a lot of damage and denied it only until logs were created to prove what was happening. We simply can’t afford to play games like this and people need to know up front what’s expected and what the consequences are. If nothing else, be encouraging, and let people know that if they really need to do something at the command line that you’d like to know what it is so that you can properly manage the activity.