The Shadow Knows A beginner's guide to background processing
From "VS Workshop",  Access to Wang, August 1988
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

We've concentrated recently on the theoretical aspects of VS systems, so I think it's time to turn to topics with more direct application. This column and the next will focus on non-interactive (background) processing, a useful and often under-utilized aspect of the VS. We'll begin this month with a look at background processing in general terms, concluding next time with programming considerations when using background jobs. Since so few users are regularly involved with background processing, I assume that it's use is little understood; therefore, the discussion this month is basic and intended to be a review.

I must admit to being somewhat a beginner in non-interactive jobs myself. Since the predominant use of the VS is through the workstation, it is easy to overlook the benefits of the humble "batch" job. Recently, though, I built a small disk maintenance system that runs in background every night after all users are gone. As a result, most of our routine disk maintenance is performed this way and I am free to concentrate on more interesting projects.

Processing modes

On the VS, a task may be interactive (foreground) or non-interactive (background). Interactive tasks, as the name implies, interact directly with the user through the workstation screen. Non-interactive tasks wait on a queue until it is their turn, then run without user attention or interaction. Most of us spend the majority of our time with foreground tasks, though those of us responsible for system operation are familiar with the background tasks associated with Wang Systems Networking, Word Processing, or other applications.

When a foreground (interactive) job is run, the task assumes control of that terminal and no other processing may take place until it completes. During the course of the job, information may be requested from the user and messages may be displayed. For example, a report program may prompt for the date range to be selected, then display the number of records processed to allow the user to gauge the amount of processing time remaining.

Most error conditions can also be handled interactively. For example, if the program failed to find a necessary file during processing, a correction GETPARM screen would appear, requesting additional information from the user; if satisfied, processing would continue.

Background processing also assumes control of a task until completed, but the task in this case is a position on the background queue instead of a workstation. When a job is run in background, it is place on the background queue and waits until any other jobs of that class are completed before starting. Background tasks are also non-interactive; that is, all the information required to perform the task must be present before the run is started. Naturally, releasing a job to background processing frees the user's workstation for other purposes.

Following the example above, any prompts to the screen - including the date range or record count screens mentioned above - would abort a background job. One exception to this rule is with correction GETPARMs; with recent operating systems such error conditions trigger messages on the operator's console and can be resolved without aborting the job. It follows that programs that cannot be completely proceduralized (e.g. have workstation screens that are not GETPARMs) cannot be run in background.

From this discussion, it should seem clear that background jobs have many practical applications but require careful attention to detail to avoid problems during the run. Let's cover the two major elements needed to run background jobs: a position on the Procedure Queue and a procedure to control the job.

What do you need?

In order to use background processing, you must meet two requirements. First, the process must be controlled by a procedure. This procedure selects the programs to be run, the files to be processed, and even the usage constants in effect during the run. In other words, you must define the operating environment for the job.

The second requirement is that the procedure must be placed on the Procedure Queue using a class associated with one or more positions in the Queue. The Procedure Queue is similar in use to other queues, such as the Print Queue: tasks are associated with a class and the task finds the position or positions on the queue that relate to that class. As with other queues, releasing a task under a class that is not present on the Procedure Queue results in "limbo" for the job; that is, it is not run and no error message is displayed.

While HELP key access is not required to use background processing, users without such access cannot monitor their own jobs. In some cases, Operator privileges may be needed for control purposes. Both of these should be considered for advanced users of background processing.

Setting up for background processing

Before you can use any background tasks your system must be configured with at least one background task slot. The process for setting this up depends on whether you are using a Release 6 or Release 7 operating system. Since your system probably has such a slot already configured, I will assume here that this requirement has been met. (The GENEDIT and INITIATOR CONTROL methods of setting up background task slots will be covered next month.)

Let's check for the classes and number of background slots available. To do this, find a terminal with Operator privileges, press PF07 from the Operator's console (Control Non-interactive Tasks) and review the queue screen displayed. The first tasks showing will be enclosed by brackets ("[" and "]"); these are dedicated tasks for system purposes such as inter-system communications and support for Word Processing printers. Further down you should see at least one position with a status of "AVAILABLE"; these are the open job slots we are looking for.

As with other queues, the Procedure Queue uses a one-character alphabetic class to control which of the background slots is eligible to run the job. The use of procedure class to control the actions of the Procedure Queue is largely of interest to more advanced users of background processing, and will be covered next month; for the moment, we will assume that you have at least one slot eligible and that it works with class "A".

SUBMIT: Getting things started

Background jobs may be sent to the Procedure Queue from the Command Processor (if the HELP key has not been disabled), through a SUBMIT statement in a procedure, or through the SUBMIT subroutine in a program. Let's cover access through the Command Processor first.

To submit a procedure from the workstation, press HELP to get to the Command Processer, then PF12 (SUBMIT Procedure). The screen will prompt for the file, library, and volume of the procedure file, and also such items as the run ID, class, status (run immediately or hold on the queue), and several program dump options. Users of Release 7 operating systems will see an additional item that establishes the procedure as permanent; if selected, the procedure will be submitted automatically after every system restart (IPL).

There are several other items visible from the Submit Procedure screen that relate to actions taken by the system during the run. The DUMP option allows the user to set the amount of information printed by the system if the job fails; this option may be left up to the program itself or overridden for more or less information. The CPU LIMIT option will stop the job if the amount of main processor time allotted is exceeded, and the ACTION option will control the action (pause, warn, or cancel) taken by the system in that event. The default is for neither option, which is suitable for most purposes.

Other means of submitting jobs

Since not every potential user of background processing has access to the HELP key, other methods of releasing jobs might be more appropriate. Jobs may also be released using the SUBMIT subroutine (an ISWUSUB) or through the SUBMIT statement in a procedure. To use either of these approaches you must write a program or procedure that submits the procedure to actually be run (confused yet?). For example, an application might consist of a front-end program that prompts for the parameters of the job (such as the date range in the example above) then passes these items to a procedure that is run in background.

The SUBMIT function also works well with jobs that are completely non-interactive - so-called "batch" jobs. Examples include jobs that process new transactions entered during the day and post them to a master file.

The background procedure

Naturally, the procedure you use for background processing will vary according to the needs of the process. Again, virtually any procedure that can be run without workstation interaction can be run in background mode. Some programs (including FINDTEXT, a text search utility available from ISWU) even recognize whether the task is in foreground or background and limit workstation interaction accordingly.

Extra care must be taken with procedures where it is important to recognize the success or failure of any preceding step. For example, a procedure that builds a work file and then posts that file to a master file must detect any errors creating the work file in the first step and abort processing. Again, any procedure that has been carefully constructed should be able to meet this requirement.

Next month we'll cover more on job scheduling, logging, and error handling approaches.