Console Automation 101 - Part II
by Alan Sadowsky and Chris Haag

The dictionaries define automatic data processing as: “The science of processing information by computers or electronic equipment, using techniques which reduce human intervention.” This general definition fits the subject of console automation quite well because it leaves the degree of “human intervention” up to you. When planning for console automation, one of the first issues you're going to have to deal with is the question of operator involvement. On the surface, this may appear to be a “no-brainer”, but if you think about it for a bit, you're going to slowly realize that this first simple decision is going to influence almost every other decision you'll need to make in the course of your efforts.

While there are any number of alternatives available to you when considering operator interface, for the purpose of this discussion, let's narrow the field to three generic options: Complete Operator Control (COC), Occasional Operator Control (OOC), and Zero Operator Control (ZOC).

Complete Operator Control
The assumption with the COC approach is that an operator will always be sitting at the console, and will always initiate necessary tasks or processes at his or her discretion. Now before you jump up and say “That's what our operators do now… why bother automating?”, consider the following. Some TPF shops have opted to automate via a Graphical User Interface (GUI). In these cases, many (if not all) of the normal operations procedures are automated, but it takes an operator to invoke them. For example, when it's time to run Capture, the operator could action a menu bar, select the Capture utility from a drop-down list, and start the utility all with the click of a mouse button. From that point on, the operator has only to monitor the progress of the Capture while the automation enters the necessary commands to obtain the proper tape drives, manage tape logging, issue the appropriate ZFCAP commands, etc.. The operator is relieved of the TPF functional aspects of the process, yet still retains overall control of the process.

The COC scenario requires experienced, knowledgeable operators. Suppression of console messages is largely inhibited since it is the operator, not the automation that monitors system activity. Additionally, the development platform for the automation will have to be one that provides the GUI point and click (or drag and drop) interface between the operator and the automation itself; something like Visual C++, Visual Basic, or VX/REXX. Recognize that in addition to creating the underlying automation logic, you also have to create and maintain the GUI interface layer as well. This may be a minimal concern given the ease of the “visual” development platforms available, but there's no getting around the reality of additional time to design, additional work to develop, and additional code to support a COC environment.

Occasional Operator Control
This is likely to be the most common “flavor” of automation found in TPF shops today. I say that only because in addition to the high degree of comfort it provides for many “old-timers” in senior management, it is also the transition stage for those on their way to Zero Operator Control environments. OOC shops have the advantage of completely automating some procedures, while leaving others for the operator to manage manually. Tasks such as running utilities, network monitoring, or perhaps exception processing can all be completely automated requiring no operator intervention what-so-ever. On the other hand, on-demand type functions like loading an OLD or running a PDU would be operator responsibilities.

An OOC environment doesn't dictate the need for highly experienced operators, since many operator procedures will have been fully automated. In an OOC environment you might think more along the lines of selectively experienced operators. Now to clarify my next point, let me define what I mean by “fully automated”.

Any procedure that is activated automatically, whether triggered by a scheduling process or in response to a message or condition presented on the console, and executes to completion without the intervention of an operator, is considered to be “fully automated”.

Given this definition, the need for a GUI interface goes right out the window…no pun intended. Your choices of development platforms (language) are now either increased or reduced depending on you own personal opinions and preferences. This isn't a problem, just something for you to be aware of since your choice of language will affect your design and development time. In our opinion, the OOC approach is the best development approach to take since it provides the greatest degree of flexibility for all concerned. The real icing on the cake however is that intelligent decisions made in the planning and creation of your OOC environment will guide you to a logical and relatively painless transition to what we have hidden behind door number 3… zero operator control.

Zero Operator Control
The ultimate goal… the true meaning of life… the achievement of spiritual harmony… to boldly go where no man has gone before… ZOC is all of these things and more! Certainly the most ambitious of challenges, ZOC offers the greatest rewards. First and foremost the reduction in operator headcount and salaries is significant. Figuring a total staff of 12 to provide 7x24 coverage at an arbitrary salary of $30,000 per person, ZOC would reduce the Operations budget by $360,000. Now I didn't say it would save the company $360,000 since these people wouldn't necessarily be fired, but rather trained and moved into other positions within the company. Now factor in the consequences of attendance issues, sick leave, disciplinary matters, personality conflicts, operator training, resignations, human error… and the list of potential benefits grows even more with the advent of ZOC.

On the other hand however, let's not overlook the work effort that's going to be required to get you to ZOC. I'm not saying it's going to be any more difficult than moving to COC or OOC, just much more time consuming. What you want to achieve here is the creation of a collection of programs and database targets that will monitor everything appearing on the console screen, and take appropriate action when specific events occur. It's really quite simple. It's just going to take a whole lot of time to do it… relative of course to the number of people working on the project.

The easiest part of the effort is what we can all refer to as the “normal” process scenario - a process is initiated at its scheduled time and it runs to completion without exception. Creating the programs or procedures to deal with normal processing is usually a breeze. It's incorporating the “what-ifs” where life starts to get interesting. For example: What if the application has a problem, issues a dump, and exits? What if it becomes necessary to pause or abort the process? What if the system crashes during the process? All of these things must be considered and coded for, because you know as well as I do, they will happen. Speaking from our own experience, we can tell you that this is the fun part of the puzzle. This is the piece with the greatest challenges, and the greatest rewards.

Well this should give most of you something to think about for a while. We'll start to get into some details and specifics with our next installment, and as always we'll do our best to answer specific questions you may have. We can be reached at: tpf_today@prodigy.com.