Robot Administrator How to automate routine administrative chores
From "VS Workshop",  Access to Wang, October 1992
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

One item in short supply at any computer shop is time. Divided between running a production operation and keeping up with the corporate culture, many DP personnel find they are short of the time they need to perform some routine administrative chores, such as reviewing disk capacity, monitoring jobs run in background, and other tasks. . .ignoring them, that is, until major problems force their attention back.

As an alternative to this scenario, consider one where the processes report to you; that is, they monitor their own activity and inform you when your attention is needed. In such a world, your administrative operations might be reduced to reviewing a condensed log of events and acting on the suggestions of your robot administrator. Too good to be true? With careful analysis of your needs and some attention to detail, perhaps not.

Planning your automated review

The first and most important step is analyzing what jobs you expect to automate and what means you wish to review their progress. Some possible jobs that can be automated include disk capacity monitoring, user counts and activities, system performance statistics, and routine job scheduling. The monitoring process can range from manual review of process steps in a log file all the way up to e-mail messages asking for attention to a specific need.

The key questions to ask during your review include:

• Can this process be made non-interactive? It's best if the processes you wish to run can be performed without tying up a workstation and the time to baby-sit the task.

• How is the job launched?

• Should the task be run at specified times of the week, daily, or as needed? What criteria should determine when?

• Do I need a background scheduler to start tasks?

• How should I be informed of progress or errors? (Choices include immediate Operator Console messages, logs, or e-mail.)

• What do I need for job recovery? If the process fails, what information will I need to understand why?

Some assumptions you might make is that all automated jobs will have to be run in background - sometimes difficult to do in the inherently interactive world of the VS. If an exception reporting philosophy is adopted, there must be confidence in the integrity of the process above all else; there is a great difference between a job that dies without a murmur and the message "no problems to report"!

Once the processes have been identified, the methods for capturing and reporting process status must be decided and the framework constructed. The following are some suggestions for that task.

Getting the message: capturing return codes

The fundamental method for programs to indicate their health is through return codes sent back to the calling program. In the VS world, any non-zero return code can be considered some kind of error or warning; the exact meaning varies between applications. Most Wang utilities and other vendor software have published return code values, but surprisingly few programmers add them to their programs.

VS programming languages have provisions for passing return codes back to calling programs. In COBOL, this is done by setting the value of RETURN-CODE, a built-in variable with a picture of 9(3). Here is an example of how this might be coded:

IF RUN-RETURN NOT = ZERO MOVE 8 TO RETURN-CODE GO TO EXIT-PROGRAM.

Return codes can be intercepted within procedures and any program coded to look for them. The key word here is intercept; care must be taken to gather and use the information. Procedures that wish to make use of return codes must have a valid label associated with the RUN statement and extract the return code from this label. For example, here is a procedure fragment that gets a return code:

PROCEDURE TESTRC - return code example DECLARE &RTNCODE INTEGER R1: RUN FOO IN FOOLIB ON SYSFOO ERROR EXIT IS R1X CANCEL EXIT IS EXIT ENTER INFIL ENTER OUTFIL FILE = OUTFIL R1X: ASSIGN &RTNCODE = R1 EXIT: RETURN CODE = &RTNCODE

This example illustrates a number of key concepts in trapping return codes. The step label R1 holds the return code of the RUN statement, which is later extracted and assigned to the integer variable &RTNCODE in step R1X. The last statement passes this value back to the calling program. The ERROR EXIT statement within the RUN statement assures that program control will remain within the procedure in the event of a run-time error so that the return code will always be captured; without this statement the procedure itself might be canceled in the event of an error in the program. The CANCEL EXIT is invoked if the program is canceled by the user or an operator request and is set here to go directly to the procedure's exit.

Logging run results in procedures

After return codes have been captured within your processes they must report back to you on their status. If you use procedures, an easy way to review process events is to add TRACE statements and review the generated listings periodically. TRACE listings are unbeatable for problem procedures, since they show every program step, the time of execution, the return code, and the values of any procedure variables used. A sample TRACE statement might look like this:

TRACE INTO PROG1 IN #DSBPRT ON SYS222, RESOURCES = YES, SCRATCH = NO, VARIABLES = YES

This sample would append additional information to a single print file every time the procedure was run, showing the system resources required and the contents of procedure variables used. If the SCRATCH option was changed to YES each run of the procedure would generate a new listing each time the procedure was run.

Other logging methods

If you wish to log program runs but don't need the detail of TRACE listings, application logging systems can fill the need. Such systems capture the date of execution and some run-time statistics such are file and screen I/O, system and clock time, and return codes. An example is the SMF system available from the United States Society of Wang Users (USSWU) as a part of their VSAIDS package.

If more immediate attention is required the PROCEDURE verb OPERATOR MESSAGE is available to users of VS OS 7.20 and above. This procedure statement places a message on the Operator's Console similar to alerts for printer errors and other problems. The message can contain up to 66 characters and shows the user ID and time sent. The message will show at all consoles; when acknowledged, it is removed. The syntax is as follows:

OPERATOR MESSAGE = "Process PROG1 needs attention"

Operator messages are useful in directing attention immediately to a problem. One disadvantage is that anyone with access to an Operator Console can acknowledge the message and thus destroy it.

The most involved method of process notification is to generate an e-mail message from the task. Users of Wang Office and Custom Software Services's Internal Mail System (among others) can purchase the tools needed to route messages from programs, adding a new dimension to the logging process. If you choose to go this route, be sure to give some thought to whom should get the message and whom should act as a backup in their absence; don't let critical information stack up just because someone is on vacation!

If none of these notification approaches work for your situation it is always possible to construct your own logging system. The VS OS has a specific file type known as a log file that can be easily added to programs. Log files are consecutive, fixed- length files that are opened SHARED. Unlike other file types, log files do not have to exist before they are used; a WRITE statement will create the file automatically.

The payoff

If you followed this example to its philosophical conclusion, you should be in the Bahamas by now, reviewing your shop's activities via a laptop. Not likely, you say? All right, you still have too much to do and not enough time to do it - but the information you have on routine processes has improved and requires less time to monitor. Over time this should give you more time for the interesting work and less time fighting fires.