Task Management More on background processing
From "VS Workshop",  Access to Wang, September 1988
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Last month's column provided only light treatment for some important administrative elements of background processing. Let's extend into scheduling, logging, execution options, and use of the SUBMIT statement in Procedure.

Setting up background tasks

Before you can run a background job, you must first have an appropriate task slot in the Non-Interactive job queue. By "appropriate" I mean a slot that is available for use, is associated with the job class submitted, and has sufficient Segment 2 (now referred to as "Modifiable Data Area" (MDA)) space assigned to it. The job of setting up task slots is usually performed by the system administrator, and rarely needs to be changed. The process varies according to whether you are using a 7-level operating system or not.

Background scheduling works the same way as in the Print Queue: you assign a class to each procedure submitted to background and it "floats" to a task slot associated with that class. If more than one task slot is set up for a given class, multiple jobs can be run for that class. This allows you to control whether or not to allow more than one job to run simultaneously. Jobs may also be run in order of priority, since the most important classes (those on the left) are executed before lesser job classes (to the right).

For pre-7 operating systems, the system configuration file sets the number of tasks and the memory allowed for each. To set up background tasks, run the configuration editor (GENEDIT) and select System Options. Note that there is a field for non-interactive tasks and another screen to set the background Segment 2 sizes. Enter the number of tasks and the sizes of each task and save the file; your changes will take effect after the next system restart (IPL).

After the tasks are created you must enter the scheduling and dump options for each task. This is done by entering Operator mode and selecting Control Non-Interactive Tasks (PF'07) from the Command Processor. Position the cursor on the task to be controlled and press PF'11 (Control Scheduling). Enter the procedure classes allowed for that task ('A' through 'Z') and the dump options (yes, no, or program option).

The process of creating background tasks is somewhat different with 7-level operating systems. Rather than using GENEDIT, background tasks can be created or removed at any time through the Initiator Control option within Control Non-Interactive Tasks of the Operator's Console. To use, enter Operator mode and select Non-Interactive Tasks (PF'07). Next, select Initiator Control (PF'11) and enter the scheduling, dump options, and Modifiable Data Area. Changes to scheduling can also be made through Initiator control. (For further information on Initiator Control, refer to the VS System Administrator's Reference.)

One note on background task scheduling: the information you enter, like other scheduling and queue data, is held in the QUEUE file in @SYSWORK on the system volume. Some system problems can result in damage to this file, rendering your entries useless. Since it may be important that queue scheduling be restored for proper operation of non-interactive tasks, you should maintain careful documentation of all scheduling information.

Using procedures to submit jobs

The SUBMIT statement in Procedure language provides all of the options of the SUBMIT PROCEDURE option of the Command Processor, including control over the job ID, class, CPU limit, and dump option. In addition, it can be used to control the usage constants and to pass parameters to another procedure. Let's look closer at each of these features.

Last month I mentioned that the usage constants must be defined for each background task submitted. This means that system defaults will be used unless the background job sets its own values. For example, the system default for print jobs is to spool directly to class 'A'. Since most of us want to be able to control which print files are actually sent to the printer, logon procedures usually reset these values according to user wishes. Surprise! The background jobs you submit use the system defaults unless explicitly set through a SET statement or the ENVIRONMENT option of the SUBMIT statement. If you specify ENVIRONMENT = YES in a SUBMIT procedure statement, your usage constants will be passed to the background job.

The SUBMIT statement also allows other information to be passed to another procedure. This allows you to write a generic background procedure and pass specific information to it through a SUBMIT statement. Such an approach would even allow several jobs to be run from the same procedure with different parameters passed to each.

Using programs to submit jobs

A more complicated approach to submitting jobs involves the use of the SUBMIT ISWUSUB within a program. An example of this might be a program that accepts the user's parameters and creates a procedure that contains these choices, then submits this procedure for processing. The SUBMIT subroutine must be invoked by the program to send the created procedure to the Procedure Queue for processing. The parameters for this subroutine are covered in the VS USERSUBS Reference.

Error handling and debugging approaches within procedures

Since operator intervention is usually not possible and information produced by program dumps is often sketchy, background procedures must be written with extra care. Toward this end, I offer the following suggestions for creating bullet-proof background jobs:

1. Step labels: Use step labels for each step and check the return value before proceeding with the next step. This is particularly important when a step must be successfully accomplished before the next is taken.

2. Use exception exits: Use the ERROR EXIT options of procedure's RUN statement to trap errors in program execution. If appropriate, trap operator cancellations through the CANCEL EXIT option. Return codes should also be considered (e.g. end the procedure with RETURN CODE = [ variable name or step label ] rather than simply RETURN).

3. Run interactively first: run a new procedure interactively before trusting it to the procedure queue. There should be no GETPARMs or other screen activity during the run.

4. Use the TRACE option to log activity: Procedure's TRACE option can be used to log success, record return codes, and track system resources used. I use it to follow first-time runs of background jobs and often leave it in place to log activity. The TRACE function might also be an option triggered through passed parameters in the SUBMIT statement.

If you do not want to insert TRACE statements permanently into your procedure, you might run the procedure through the PROC interpreter temporarily and specify a trace option within PROC. (For further information, see "The TRACER Procedure: Seeing how they run"; ACCESS 87, January 1987, pp. 18-19.)

Other considerations

While the task examples mentioned in this and last month's columns have been ad hoc in nature, there is often a need to submit a procedure every time the system is started. With release 7 operating systems, it is possible to set up a permanent task. To do this, submit the procedure through the Command Processor and specify 'Y' to the PERM ('permanent') option; the job will now remain on the Procedure Queue with a disposition of 'HOLD'. The job will be re-submitted after every IPL. (Note that the HOLD option can also be used with earlier operating systems; however, the job merely remains on the Procedure Queue and must be manually released each time.)

Since many routine tasks might be candidates for background jobs, it is likely that the control and execution of procedures might become progressively more complicated. If you rely on background jobs for much of your administrative work, you should look into commercial background scheduling products to control your jobs. These software products allow you to specify the frequency of runs, time their release, and log the return codes from each. More sophisticated versions even allow you to specify dependencies, such as when a job must successfully execute before others are allowed to run. The modest cost of these products is well worth it if you wish to use background processing to this extent.

References

• VS Programmer's Introduction
  Wang pub. 800-1101-06; August 1983
  
  General overview of background processing, the use of procedures, how to submit a job, the Procedure Queue, and job termination options.

• VS System User's Introduction - Release 7 Series
  Wang pub. 715-0417A; May 1986
  
  More detailed description of the Submit Procedure function and control of the Procedure Queue.

• VS System Operator's Guide - Release 7 Series
  Wang pub. 715-0418A; June 1986
  
  Information on the Initiator Control option of Control Non-Interactive Tasks, error messages, and other operator functions.

• VS Procedure Language Reference
  Wang pub. 800-1205-06; December 1987
  
  Detailed description of the SUBMIT statement and error-handling approaches (ERROR EXIT and CANCEL EXIT). Also describes the TRACE function.

• VS USERSUBS Reference
  Wang pub. 800-1315US-01; August 1982
  
  Information on most of the program subroutines found in the USERSUBS or ISWUSUBS libraries. (For current versions and more up-to-date documentation, order the ISWUSUBS package from the International Society of Wang Users (ISWU), Wang Laboratories, Inc., One Industrial Avenue, M/S 019-350, Lowell, MA 01851.)