Console Automation 101
by Alan Sadowsky

One of the things I've wanted to do for several years now is to write a regular column on Console Automation. I've wanted to do this for several reasons. First off, console automation is my primary focus and responsibility at Federal Express Corporation, and those of you that have read some of my previous articles are well aware of how successful our efforts have been. But I'm not here to toot my horn. What I hope to accomplish with this and future articles, is to convey a general understanding and appreciation of what console automation is really all about, and how your organization can benefit by it.

When most people hear the words “console automation” they tend to flashback to the days when your only options were to highlight specific messages in color, or have the console beep at you when a pre-defined condition occurred. Some predecessor packages had script authoring built in, and one or two even provided the ability to write rudimentary automation programs using a REXX interface. Needless to say, the technology has come a long way since those early days, and the options available to us today are virtually unlimited. When considering console automation for TPF, there's a fair amount of groundwork that needs to be done. Too many people are tempted to jump right into actual automation without doing their homework first. Since this is going to be an ongoing column, I'd like to focus on the basics up front, and follow up with details and specifics in future articles.

HURRY UP AND WAIT
The obvious temptation with any new software is to crank it up first, and read the documentation later. If you're playing Quake this type of approach may cause you some frustration, but the loss is basically only one of time, and when you consider the “fun” you've had along the way, the time spent becomes unimportant. When it come to automation however, time is usually not an expendable (at least as far as my boss is concerned), so it is important to get started on the right path. Speaking from experience, there are three significant tasks that need to be completed before you even think about writing any code:

1. Determine what you really want to accomplish.
   Trying to tackle console automation without a pre-defined game plan is a major mistake that will haunt you for the rest of your days. Rather than becoming preoccupied with the journey, your focus at this point should be the destination. If your goal is to highlight specific console messages in color to provide a visual interface to the Operator, that's fine. On the other hand, if your goal is to completely automate the console (potentially eliminating any Operator interface), that's fine also. Be realistic in establishing your objectives, as well as your abilities to accomplish them. The moral here is that without really knowing what you expect to achieve, the odds are you won't achieve much of anything meaningful.
   
2. Gather the proper resources.
   This is the task that is likely to present you with your greatest challenge. I say that with the understanding that the degree of challenge is relative to the degree of automation you've decided on in Step 1. For the purpose of this discussion, let's assume that we're shooting for a high level of automation possibly approaching a “lights out” scenario. In a case like this, the knowledge, skill sets, and cooperation of several different groups need to be merged into a single Automation Group. By teaming an Applications programmer, a Coverage programmer, a Systems programmer, a Communications programmer and an Operator, a collective foundation of experience is now available to address practically every aspect of intended automation - TPF processing, Applications processing, utility processing, and exception processing. Chances are there will be significant “PC” experience in the group already, but if that's not the case, you'd better find someone with those skills because you're going to need them. Now we need to add the proper mix of documentation. At the very least, you're going to need a current copy of the Operations Guide and the Messages and Codes manuals. Ideally, you also want to have copies of any in-house functional documents (am I the only one who remembers “02” and “09” documents?), copies of any in-house procedural documents, and at least 6 months of console logs from the system you plan to automate.
   
3. Take off the blinders.
   Last but certainly not least, is the concept of scope and vision. At one time or another, every programmer has had to “go back” and add code for a particular condition that was somehow overlooked. Most of the time these things are either obscure conditions or things that were thrown into the category of “That'll never happen here!”. In the same vein, many programmers have also had to “go back” and re-write code because new projects and new programs present new dependencies to legacy processing. The point here is twofold. First, consider all of the possibilities, and assume they all have the potential to occur. Second, look to the future, and by that I mean that you should consider the entire spectrum of potential change:

System software upgrades
Be prepared for new Operator commands and responses, changes in existing commands and responses, changes to internal processing (the command is the same, but what happens under the covers has changed), new system errors and/or error messages, etc.

Hardware upgrades
Be prepared for new status displays, new error messages (i.e. sense codes), new recovery procedures, etc.

Database expansion/reorg
Be prepared for changes to Recoup processing, Capture/Restore procedures and frequency, the addition of new device types (i.e. DEVB), new status displays, new configuration displays, etc.

Additional automation
Always be prepared to expand the scope of the automation platform. If you're starting small with a goal of minimal, selective automation, don't fall into the trap of “just making it work”. An excellent example would be if you wrote your initial automation to handle only output tape processing, and six months later you're given a project to automate a utility which involves heavy input tape processing. Since you really don't want two separate automation processes for tape management, initially planning for (if not actually coding for) both input and output tape management will save you a lot of time and aggravation down the road.

Admittedly, these are simple scenarios, but they should give you several things to start thinking about. One of the best things you can do as a team is to play devil's advocate with each other's ideas. You will be amazed at the number of times a colleague will either point out something that's been overlooked, or suggest a much better way to approach a problem. Leave your pride at the door with your blinders, and you'll increase your odds for success many times over.

Winding down this first installment, I want to reiterate the inherent value of operations automation. While FedEx is not alone in the automation arena, I can only speak about those things that I have first-hand knowledge of. Out of the 7500 to 8000 commands entered on the TPF Prime CRAS console every day, only 10 to 20 are entered by an Operator. The remaining commands are entered accurately, and are entered on a scheduled basis or in response to conditions detected by the automation monitoring process. In future articles, I'll be talking about designing your automation, some tools that can make your job easier, automation accomplishments at various TPF shops, and even teaching your automation to “think” for itself. As always, your questions and comments are welcomed, and can be addressed to me via email at tpf_today@prodigy.com.