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:

  CRT ">":
      FNAME = FIELD(COMMAND,’ ‘,2)
      * check to make sure user has access to file, process if OK
      CRT "You are not allowed to perform this operation"
    CASE 1

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:


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.

2 thoughts on “Should end-users have access to TCL?

    • Hi Tony
      Where would you rank the bank accounting department that vilified the new accouting software because it did not allow for one sided journal entries.
      Further investigation by myself established that some years before, when moving to a new machine, IT had supplied such a program to fix up the database.  Apparently the Chief Accountant, who naturally outranked all IT personnel, thought it was a fabulous program and kept it.  No more mucking around in the evening trying to balance, just round it off.  Eventually the bank managed to overpay a chaps credit card by more than a million dollars – no this was not Zimbabwe but Australia – that is how I found it, the chap came in and told us.  However they only stopped doing it when they managed a billion dollar disaster that exceeded the bank’s gross worth 🙂

    • The problem with end-user access to TCL is that it’s un-auditable. There is no documentation available for an item changed with the editor, or an item copied from one file to another. If a company has no audit, they can’t manage their data. I take issue with this sort of lack of control because people then blame the systems rather than the people who run them. Since guys like you and I put a lot of our career focus on Database Management Systems, that means we feel the pain of other people’s bad data management decisions. If a company does have a record of all transactions, but they manage their systems poorly, and they don’t have controls in place to "manage mis-management" then they need to deal with regulators and/or an unforgiving economy. At this point Darwinism takes over – we can’t help too much with that.

Leave a Reply