Article from Stratagy's newsletter - winter 1996 issue

In the previous article we talked about the importance and benefits of the pro-active approach to managing the Stratus as opposed to being reactive to the system. In the next series of articles, I will suggest simple and very practical solutions that you can easily implement yourself or turn to one of the many third-party software solutions that are available today. The biggest threat to the application and to your business is still human error. Folks talk to us about complying with the toughest and most rigid security and audit standards and regulations. At the same time, they allow their operators to share a common "generic" user-ids, share passwords and in many cases register everyone as privileged users whether it is really necessary or not.

The first step that we always recommend is to remove access to the unrestricted command line (the "ready" prompt) and replace it with a secure set of menus. What are the immediate benefits?

The new "menu-ed" user:

Is set and defined ahead of time
Does not have to type commands or learn about arguments and system parameters
Has access only to those command or sub-menus that you've allocated for him and to nothing else
Has no way of making costly mistakes by accidentally executing any high-risk commands
Is constantly monitored and audited

You will be able to cut down your training effort and be able to rely on novice operators without compromising yours system. In addition, since everything is executed through a menu, you will get complete audit-trail logs of all system and support activities. So what's the next step?

You must first identify users with limited or known requirements. The obvious candidates will be most likely you system operators, novice users, or folds who periodically log into your system are require limited access. Next, based on their function in the organization, identify for each operator or group, the commands or activities that they are required to execute. There is no such thing as an operator that "needs to do everything"! Any repeated activities, procedures or existing "check-lists" could be used. Next, break your list down to different areas which you'll later turn into sub-menus, such as system-troubleshooting, application control, communications, backups and restores, network management and anything else that comes to your mind - be creative.

Menus must be started from the user's start_up.cm command macro and must not allow the user to break out of the system back to the uncontrolled "ready" prompt. Your menu should have a "logout" menu item that will terminate the session and log the user out of the system. Make sure that menus can be easily adjusted based on user's profiles and other factores that may be important to your such as time-of-day or the terminal-name. You can later add password protection, audit reports and other important features to your menus.

In the next article we'll cover the automation of process scheduling, monitoring, recovery and other aspects of process and application management.