Work Flow Language (WFL) Programming Reference Manual WFL

86001047-506_Work_Flow_Language_Programming_Reference_7.0_Nov2001 86001047-506_Work_Flow_Language_Programming_Reference_7.0_Nov2001

WFL WFL

User Manual: WFL

Open the PDF directly: View PDF .
Page Count: 468

Download
Open PDF In Browser	View PDF

Unisys e-@ction
ClearPath Enterprise
Servers
Work Flow Language (WFL)
Programming Reference Manual

ClearPath MCP Release 7.0
November 2001

Printed in USA
8600 1047–506

Unisys e-@ction
ClearPath Enterprise
Servers
Work Flow Language (WFL)
Programming Reference Manual

UNISYS

û 2001 Unisys Corporation.
All rights reserved.

ClearPath MCP Release 7.0
November 2001

Printed in USA
8600 1047–506

NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information
described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to
purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the
products described in this document are set forth in such agreement. Unisys cannot accept any financial or other
responsibility that may be the result of your use of the information in this document or software material, including
direct, special, or consequential damages.
You should be very careful to ensure that the use of this information and/or software material complies with the laws,
rules, and regulations of the jurisdictions with respect to which it is used.
This document is not a contract and does not create any representations or warranties by Unisys. All applicable
representations, warranties and covenants are contained only in the applicable agreement signed by the parties.
The information contained herein is subject to change without notice. Revisions may be issued to advise of such
changes and/or additions.
Notice to Government End Users: This is commercial computer software or hardware documentation developed at
private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard
commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data
rights clauses.
Correspondence regarding this publication can be e-mailed to doc@unisys.com.

Unisys, ClearPath, and e-@ction are registered trademarks of Unisys Corporation in the United States and other
countries. All other brands and products referenced in this document are acknowledged to be the trademarks or
registered trademarks of their respective holders.

Unisys e-@ction
ClearPath Enterprise
Servers

Unisys e-@ction
ClearPath
Enterprise
Servers

Work Flow Language (WFL)

Work Flow
Language (WFL)

Programming Reference
Manual

Programming
Reference
Manual

ClearPath MCP Release
7.0

ClearPath MCP
Release 7.0

8600 1047–506

Bend here, peel upwards and apply to spine.

Contents
Section 1.

WFL Capabilities ................................................................1–1
About This Manual ................................................................................ 1–1
Overview of WFL .................................................................................. 1–2
Task Initiation ........................................................................................ 1–3
Other Task Initiation Statements ......................................... 1–3
Task Specifications .............................................................. 1–5
Data Specifications .............................................................. 1–6
Flow of Control Statements................................................. 1–7
Processing Data ................................................................... 1–7
Subroutine Control .............................................................................. 1–10
Task Control ........................................................................................ 1–13
File Handling ........................................................................................ 1–16
File Management ................................................................................ 1–18
Communication ................................................................................... 1–20
Job Format .......................................................................................... 1–22

Section 2.

Job Initiation .....................................................................2–1
Overview ............................................................................................... 2–1
Sources for Job Initiation....................................................................... 2–2
START and WFL Commands from CANDE
Sessions .......................................................................... 2–2
START Statements from Running WFL Jobs ...................... 2–5
Operator Display Terminals (ODTs) ..................................... 2–6
Menu-Assisted Resource Control (MARC) .......................... 2–7
Distributed Systems Services.............................................. 2–7
User Programs in Other Languages .................................... 2–9
Magnetic Tapes ................................................................. 2–10
Job Continuation after a Task Fails ..................................................... 2–11
Job Restart after a Halt/Load............................................................... 2–12
ON RESTART Statement ................................................... 2–15
Dummy Files ...................................................................... 2–15

Section 3.

Job Structure.....................................................................3–1
Overview ............................................................................................... 3–1
Job Syntax ............................................................................................. 3–1
Job Structure ....................................................................... 3–1

8600 1047–506

iii

Contents

Job Contents ....................................................................... 3–2
Job Format........................................................................... 3–2
AT Hostname....................................................................... 3–3
Job Title................................................................................................. 3–4
Job Parameter List ................................................................................ 3–5
Job Disposition...................................................................................... 3–8
Job Attribute List................................................................................... 3–9
Resource-Limiting Attributes............................................. 3–10
CLASS Specification ........................................................................... 3–12
FETCH Specification ........................................................................... 3–13
STARTTIME Specification ................................................................... 3–14
Declaration List ................................................................................... 3–16
Statement List..................................................................................... 3–17
WFL Job Example ............................................................................... 3–19
Section 4.

Declarations...................................................................... 4–1
Overview............................................................................................... 4–1
Declaration Syntax ................................................................................ 4–1
Scope of Declarations.......................................................... 4–2
Variable Initialization............................................................. 4–2
Constant Identifiers............................................................................... 4–3
Boolean Variables.................................................................................. 4–4
Integer Variables ................................................................................... 4–5
Real Variables........................................................................................ 4–6
String Variables ..................................................................................... 4–7
File Variables ......................................................................................... 4–8
Task Variables ....................................................................................... 4–9
Subroutines ......................................................................................... 4–10
Subroutine Parameters ...................................................... 4–11
Global Data Specifications .................................................................. 4–13

Section 5.

Task Initiation ................................................................... 5–1
Overview............................................................................................... 5–1
Task Initiation Statements .................................................................... 5–1
Task Equation........................................................................................ 5–3
Task Attributes ...................................................................................... 5–4
Task Attribute Assignment ................................................................... 5–8
Complex Task Attribute Assignments ................................................ 5–11
ACCESSCODE Assignment............................................... 5–12
CORE Assignment............................................................. 5–13
CURRENTDIRECTORY Assignment.................................. 5–14
FAMILY Assignment ......................................................... 5–15
OPTION Assignment ......................................................... 5–17
PRINTDEFAULTS Assignment .......................................... 5–19
RESOURCE Assignment ................................................... 5–21
SUPPRESSWARNING Assignment ................................... 5–22
USERCODE Assignment ................................................... 5–23
Using Task Variables ........................................................................... 5–24
Assigning Task Attributes .................................................. 5–25

8600 1047–506

Contents

Reusing Task Variables ...................................................... 5–27
Interrogating Task Attributes ............................................. 5–29
Interrogating Task Status .................................................................... 5–30
File Attribute Inquiry ............................................................................ 5–31
Interrogating Complex Task Attributes ............................................... 5–31
MYJOB and MYSELF Predeclared Task Variables .............................. 5–32
File Equations ...................................................................................... 5–33
Causing the Task to Use a Different Input or Output
File ................................................................................. 5–34
Changing the Attributes of Files Used by the Task ........... 5–35
Causing the Task to Read from a Data Specification......... 5–35
How the Task Can Override WFL File Equations............... 5–35
Resolving Repeated File Equations to the Same File ........ 5–36
Global File Assignment........................................................................ 5–37
Using Remote Files ............................................................................. 5–38
File Attribute Assignment.................................................................... 5–39
Device Kind Assignment ..................................................................... 5–40
Serial Number Assignment ................................................................. 5–41
Using File Attributes............................................................................ 5–42
Assigning File Attributes .................................................... 5–44
Interrogating File Attributes ............................................... 5–45
Nonresident Files ............................................................... 5–46
Library Equation................................................................................... 5–48
Overriding WFL Library Equations ..................................... 5–48
Resolving Repeated Library Equations to the Same
Library ............................................................................ 5–49
Database Equation .............................................................................. 5–50
Local Data Specifications .................................................................... 5–51
Section 6.

Statements ........................................................................6–1
Overview ............................................................................................... 6–1
WFL Statement Groupings.................................................................... 6–2
ABORT Statement................................................................................. 6–5
ACCESS Statement............................................................................... 6–6
ADD Statement ..................................................................................... 6–7
ALTER Statement.................................................................................. 6–8
Archive Subsystem ............................................................................. 6–17
ARCHIVE Backup Statement ............................................. 6–19
ARCHIVE Statement Options ............................................ 6–22
ARCHIVE Disk Volume....................................................... 6–23
ARCHIVE Disk Volume Attribute List................................. 6–24
ARCHIVE Tape Volume...................................................... 6–25
ARCHIVE Tape Volume Attribute List ................................ 6–26
ARCHIVE CD Volume......................................................... 6–34
ARCHIVE CD Volume Attribute List................................... 6–35
ARCHIVE Task Equation List.............................................. 6–37
ARCHIVE MERGE Statement ............................................ 6–38
ARCHIVE PURGE Statement ............................................. 6–39
ARCHIVE RELEASE Statement ......................................... 6–40
ARCHIVE RESTORE Statement......................................... 6–41

8600 1047–506

Contents

ARCHIVE ROLLOUT Statement ........................................ 6–43
Assignment Statements ..................................................................... 6–46
BIND Statement.................................................................................. 6–48
CASE Statement ................................................................................. 6–49
CATALOG Statement.......................................................................... 6–50
CHANGE Statement ........................................................................... 6–52
COMPILE or BIND Statement ............................................................ 6–54
Naming the Object Code File ............................................ 6–55
Choosing a Compiler ......................................................... 6–55
Binding............................................................................... 6–56
Object Code File Disposition ............................................. 6–56
Task Variables .................................................................... 6–57
Compiler Task Equation List .............................................. 6–58
File, Library, and Database Equations and Task
Attributes....................................................................... 6–59
Local Data Specifications................................................... 6–60
Compound Statement......................................................................... 6–62
COPY or ADD Statement .................................................................... 6–63
Copying Files ..................................................................... 6–65
Library Maintenance .......................................................... 6–66
COPY Options.................................................................... 6–68
COPY Request................................................................... 6–74
Copying Files from Tape or CD-ROM ................................ 6–95
COPY and ADD Statement Examples ............................. 6–105
COPY File Transfer Services............................................ 6–109
CREATE LIBMAINTDIR Statement................................................... 6–121
CRUNCH Statement ......................................................................... 6–124
DISPLAY Statement.......................................................................... 6–125
DO Statement ................................................................................... 6–126
GO Statement ................................................................................... 6–127
IF Statement ..................................................................................... 6–128
INITIALIZE Statement ....................................................................... 6–130
INSTRUCTION Statement................................................................. 6–131
LOCK Statement ............................................................................... 6–132
LOG Statement ................................................................................. 6–133
MKDIR Statement............................................................................. 6–134
MODIFY Statement .......................................................................... 6–135
MOVE Statement.............................................................................. 6–137
Null Statement .................................................................................. 6–140
ON Statement ................................................................................... 6–142
OPEN Statement............................................................................... 6–145
PASSWORD Statement .................................................................... 6–146
PB Statement.................................................................................... 6–147
PRINT Statement .............................................................................. 6–148
Printing Portions of a File................................................. 6–151
PROCESS Statement ........................................................................ 6–153
PTD Statement.................................................................................. 6–155
PURGE Statement ............................................................................ 6–156
RELEASE Statement......................................................................... 6–157
REMOVE Statement ......................................................................... 6–158
REPLACE Statement ........................................................................ 6–160
RERUN Statement ............................................................................ 6–161

8600 1047–506

Contents

RESTORE Statement ........................................................................ 6–162
Library Maintenance ........................................................ 6–164
RESTORE Statement Options ......................................... 6–165
RESTORE Tape and CD-ROM Attributes......................... 6–166
RETURN Statement .......................................................................... 6–169
REWIND Statement .......................................................................... 6–170
RUN Statement ................................................................................. 6–171
SECURITY Statement........................................................................ 6–177
START Statement.............................................................................. 6–181
STOP Statement ............................................................................... 6–185
Subroutine Invocation Statement...................................................... 6–186
UNWRAP Statement......................................................................... 6–189
USER Statement ............................................................................... 6–192
VOLUME Statement ......................................................................... 6–193
Tape Volume Security ...................................................... 6–199
VOLUME ADD Statement with Tape Security
Subsystem................................................................... 6–200
WAIT Statement................................................................................ 6–204
WHILE Statement ............................................................................. 6–207
WRAP Statement .............................................................................. 6–208
Section 7.

Expressions........................................................................7–1
Overview ............................................................................................... 7–1
Boolean Expressions ............................................................................. 7–2
Boolean Primary................................................................... 7–3
Integer Expressions............................................................................... 7–9
Integer Primary .................................................................. 7–10
Real Expressions ................................................................................. 7–13
Real Primary ....................................................................... 7–14
String Expressions............................................................................... 7–17
String Primary .................................................................... 7–18
Mnemonic Primaries ........................................................................... 7–28
Constant Expressions.......................................................................... 7–29
Boolean Constant Expression ............................................ 7–30
Integer Constant Expression.............................................. 7–31
Real Constant Expression .................................................. 7–32
String Constant Expression................................................ 7–33

Section 8.

Basic Constructs................................................................8–1
Overview ............................................................................................... 8–1
Invalid and Valid Characters................................................................... 8–2
Valid Character Elements..................................................... 8–2
Identifiers............................................................................................... 8–3
Constants .............................................................................................. 8–4
Names ................................................................................................... 8–6
File Names, Titles, and Directories ....................................................... 8–8
Using String Primaries......................................................................... 8–13
Restrictions on the Use of String Primaries....................... 8–13
Passing Parameters to a Task............................................ 8–14

8600 1047–506

vii

Contents

Copying Multiple Files ....................................................... 8–15
Section 9.

WFL Control Options......................................................... 9–1
Overview............................................................................................... 9–1
ERRORLIMIT Option............................................................................. 9–2
INCLUDE Option ................................................................................... 9–3
LIST Option ........................................................................................... 9–5
NEWSEGMENT Option......................................................................... 9–6

Appendix A. Sample WFL Jobs .............................................................. A–1
Overview............................................................................................... A–1
Compiling a Program............................................................................. A–2
Initiating Other Jobs.............................................................................. A–6
Updating Files ....................................................................................... A–7
Appendix B. Reserved Words, Predefined Words, and Keywords .......... B–1
Overview............................................................................................... B–1
Reserved Words ................................................................................... B–2
Predefined Words ................................................................................. B–2
Keywords .............................................................................................. B–4
Appendix C. Understanding Railroad Diagrams .................................... C–1
Railroad Diagram Concepts................................................................... C–1
Paths.................................................................................... C–1
Constants and Variables ...................................................... C–2
Constraints........................................................................... C–3
Following the Paths of a Railroad Diagram ........................................... C–6
Railroad Diagram Examples with Sample Input.................................... C–7
Appendix D. Related Product Information............................................. D–1

Index

viii

.............................................................................................. 1

8600 1047–506

Tables
5–1.
5–2.
5–3.
5–4.

Task Attribute Groupings.................................................................................... 5–4
Expressions for Task Attribute Inquiry ............................................................. 5–29
File Attribute Types .......................................................................................... 5–42
Expressions for File Attribute Inquiry ............................................................... 5–45

C–1.

Elements of a Railroad Diagram .........................................................................C–2

8600 1047–506

Tables

8600 1047–506

Section 1
WFL Capabilities
Work Flow Language (WFL) is used for constructing jobs that compile or run programs.
WFL includes variables, expressions, and flow-of-control statements that offer the
programmer a wide range of capabilities with regard to task control.

About This Manual
This manual is a complete language reference for WFL users, whether they are
beginning users just learning WFL, or experienced users who need to check on the
details of a particular construct.

Purpose and Scope
Although this manual sometimes mentions specific task attributes or file attributes, it
does not describe these attributes in great detail. For detailed information regarding task
attributes, refer to the Task Attributes Programming Reference Manual. For detailed
information about file attributes, refer to the File Attributes Programming Reference
Manual.
This manual also mentions some specific system commands that are entered at an
operator display terminal (ODT). For detailed information about these commands, refer to
the System Commands Operations Reference Manual.

Audience and Prerequisites
The audience for this manual consists of programmers and operators who need to write
jobs that initiate and control tasks.
The user is assumed to have had prior experience with programming in a blockstructured language (for example, ALGOL, COBOL, RPG, or some other block-structured
language). However, there is no single programming language the user needs to know to
understand this manual. Additionally, the user is assumed to be familiar with ClearPath
MCP systems, at least to the extent of knowing how to create and edit files by using
CANDE or the Editor.
If you are not familiar with ClearPath MCP systems, you should first read the MCP/AS
System Administration Guide and the MCP/AS System Operations Guide. If you are not
familiar with the concepts of process initiation and process control, you should first read
the Task Attributes Programming Reference Manual. If you prefer to learn by example,
consider reading WFL Made Simple.

8600 1047–506

1–1

Overview of WFL

How to Use This Manual
This manual is intended primarily for reference, although a new user can learn a great
deal about WFL by reading the first five sections. Section 6, “Statements,” begins with a
functional grouping of the various WFL statements, and then presents descriptions of
the statements in alphabetical order for quick reference.
Railroad diagrams are used to illustrate WFL syntax. If you are not familiar with this type
of syntax notation, you should read Appendix C, “Understanding Railroad Diagrams.”
Some WFL constructs share a common syntax. In certain instances, these constructs
share the same railroad diagram. For example:

ÚêÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄ/2\ÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
The syntax for many WFL constructs is rather complex. To show an appropriate level of
detail, most railroad diagrams use basic constructs that are explained elsewhere in the
manual. You can quickly locate the more detailed syntax for these subordinate constructs
using the index.

Overview of WFL
WFL is used for constructing jobs that compile or run programs. WFL is a true
programming language with its own compiler that either produces an object code file
used in running a job or executes a job interpretively. A WFL job is always recompiled
each time it is run.
WFL can initiate programs that are written in any of the languages accepted on A Series
systems. It is a high-level language with flow-of-control structures and subroutines
analogous to those found in ALGOL. However, WFL includes features related to task
control that would be difficult or impossible to duplicate in any of the other available
languages.
One advantage to initiating tasks through WFL instead of through CANDE or some other
means is that a WFL job is automatically restarted if it is interrupted by a halt/load. This
capability is discussed under “Job Restart after a Halt/Load” in Section 2.
WFL accepts jobs from a large variety of sources. With a few exceptions, identical jobs
can be presented to WFL from all of the available sources. Section 2, “Job Initiation,”
describes the different sources from which WFL will accept jobs.
WFL supports the MultiLingual System (MLS). All error or warning messages given by
the WFL compiler can be translated into another language with the Message Translation
Utility. For more information, refer to the MLS Guide and the MSGTRANS Operations
Guide.

1–2

8600 1047–506

Task Initiation

WFL and the MCP must be the same release level to function properly. If the release
levels are not the same, WFL waits on an AX condition before freezing. It is possible to
proceed with a mismatched WFL by entering AX OK, but unexpected results might
occur. To declare a WFLSupport library that is the same release level as the MCP, use
the System Library (SL) command. To terminate the waiting WFLSupport library, enter
AX DS or use the Unlock (LP-) command and the Discontinue (DS) command.
The following pages outline the various capabilities of WFL and present example WFL
jobs. While most of the WFL statements will be mentioned here, you should refer to
Section 6, “Statements,” for a more complete description of a particular statement.

Task Initiation
The two basic capabilities of WFL are compiling and running programs. The two WFL
statements that correspond to these capabilities are called:

•

COMPILE

•

RUN

Other Task Initiation Statements
The other WFL statements that initiate tasks include:

•

COPY and ADD for copying files

•

BIND for invoking the Binder

•

PB for running the SYSTEM/BACKUP utility

•

PTD for initiating peripheral testing routines

•

LOG for running the LOGANALYZER utility

•

START for initiating other WFL jobs from the current job

Tasks initiated by any of these statements are executed serially; that is, the job waits for
the task to complete before continuing on to the next statement. However, any task can
be made to run asynchronously by preceding the task initiation statement with the word
PROCESS. Asynchronous tasks run in parallel with the job.
The START statement normally causes the job to be compiled synchronously and
executed asynchronously. A PROCESS START causes both the compile and execution to
occur asynchronously with the job.
An asynchronous task can also be initiated by a subroutine invocation statement that
occurs within a PROCESS statement. A subroutine invocation statement normally does
not initiate a task.

8600 1047–506

1–3

Task Initiation

Example
The following example shows a simple form of the COMPILE and RUN statements:
?BEGIN JOB RUNPROG;
COMPILE (JONES)OBJECT/ALGOL/TEST WITH ALGOL LIBRARY;
COMPILER FILE CARD(TITLE=ALGOL/TEST ON MYPACK);
RUN (JONES)OBJECT/ALGOL/TEST;
?END JOB.
The COMPILE statement in this example specifies that the object code file titled
(JONES)OBJECT/ALGOL/TEST is to be saved. (Other variations in the COMPILE
statement can be used to specify whether the object code file is to be run immediately,
saved and run immediately, or whether the source file is to be compiled for syntax only.)
The line beginning COMPILER FILE CARD is a file equation that tells the ALGOL compiler
the name of the source file to use as input. The RUN statement causes the program to
execute. The file title specified in the RUN statement must be the title of the object code
file (not the source file) of the program.

1–4

8600 1047–506

Task Initiation

Task Specifications
The following types of specifications can be included in a task initiation statement:

•

Task attribute assignments

•

Library equations

•

File equations

•

Database equations

•

Local data specifications

Many task attributes with very diverse functions are available through WFL. Some of
them can be used to access information about the task execution, such as accumulated
processor and I/O time. Other functions alter the way the program is run, such as
specifying the priority to be assigned to a task or the usercode a task is to run under.
The task attributes available through WFL are listed under “Task Attributes” in Section 5.
For a more detailed description, refer to the task attribute descriptions in the Task
Attributes Reference Manual.
File equations can be used to modify attributes of the files used by a program, or can
cause the program to use different files than it normally would have. For example, file
equations can cause the program to read input from a different source than is specified
in the program, and write output to a different destination than is specified in the
program. This feature of WFL eliminates the need for many time-consuming alterations
and recompilations of existing programs.
For more information, see “File Equations” and “Task Equation” in Section 5 for further
information. Individual file attributes are described in the File Attributes Reference
Manual.

Examples
In the following example, the task attribute PRIORITY specifies the priority to be
assigned to the task:
?BEGIN JOB COMP/DATA;
RUN (RAJA)OBJECT/COMP/DATA; % Run the desired program with
PRIORITY=50; % a priority of 50
?END JOB.
The following example uses a file equation:
?BEGIN JOB WFLTEST;
RUN (WALLY)OBJECT/ALGOL/TEST;
FILE TERMIN(TITLE=WFLIN,KIND=DISK); %
%
%
%
?END JOB.

8600 1047–506

Causes the program to
read from the disk file
WFLIN, instead of the
file TERMIN

1–5

Task Initiation

Data Specifications
Data specifications supply input to a program that expects input from a card reader file
during execution; that is, a file declared in the program as being of kind READER.
A data specification can also be used in place of any input file the program reads by
file-equating the title of the input file to the title of the data specification in the WFL job,
and by declaring the type of input file to READER.
Two kinds of data specifications are available:

•

Local data specifications

•

Global data specifications

A global data specification can be declared at the start of a job, and can be used by more
than one task.

Example
The following example illustrates a job that uses a global data specification:
?BEGIN JOB INTREF;
DATA INPUT
% Begin global data specification
7
11
?
% End global data specification
RUN (WENDY)OBJECT/INT/REF;
FILE TERMIN(TITLE=INPUT,KIND=READER); % Causes the program to
% read from the global
% data specification INPUT
% instead of the file
% TERMIN.
?END JOB.

1–6

8600 1047–506

Task Initiation

Flow of Control Statements
The WFL jobs in the examples presented thus far have been set up to execute
statements in sequential order. However, WFL also enables you to execute statements
conditionally or repeatedly by using flow-of-control statements. The flow-of-control
statements include:

•

WHILE

•

CASE

•

The IF statement executes a certain statement only if the value of a particular Boolean
expression is TRUE.
The DO statement and the WHILE statement are both used to cause repeated execution
of a statement or set of statements. Both statements evaluate a Boolean expression
before each repetition is initiated, to decide whether to do it again. The DO statement
differs from the WHILE statement in that it checks the Boolean expression at the end of
the loop instead of at the start; the statements included in the loop are therefore
guaranteed to execute at least once.
The CASE statement chooses one of several possible alternative actions, depending on
the value of the variable or case expression that follows the word CASE.
Whenever the syntax of a flow-of-control statement calls for a statement to be included,
that statement can be another flow-of-control statement. Therefore, flow-of-control
statements can be nested to form complex flow-of-control structures.

Processing Data
The use of conditional statements implies that the job is going to be processing some
data that can vary at run time. The following kinds of data can vary at run time:

•

WFL jobs that are stored on disk and initiated by a START statement can have
parameter values passed to them.

•

During the course of a WFL job, the job can inspect the values of task attributes
associated with tasks that were initiated in the job. Certain task attributes record task
history. The WFL job can then make decisions about what to do next based on the
history of the task that was initiated.

•

The job can also inspect the values of file attributes or test whether a file with a
given title is resident, and then make decisions accordingly.

•

The job can include ACCEPT functions that will prompt you to supply input at run
time and will cause the job to wait for your reply.

8600 1047–506

1–7

Task Initiation

Examples
The following WFL job illustrates a use of the IF statement:
?BEGIN JOB WFLTEST;
TASK COMPOK;
DISPLAY "COMPILING NOW";
COMPILE (SFL)OBJECT/SORT/PROC WITH ALGOL [COMPOK] LIBRARY;
COMPILER FILE CARD(TITLE=SORT/PROC ON MYPACK);
IF COMPOK IS COMPILEDOK THEN
BEGIN
DISPLAY "COMPILED SUCCESSFULLY";
DISPLAY "RUNNING SORT/PROC";
RUN (SFL)OBJECT/SORT/PROC;
END
ELSE
DISPLAY "COMPILE NOT SUCCESSFUL --- WILL NOT RUN";
?END JOB.
This example first compiles a program, then inspects a task variable named COMPOK to
see whether the compile was successful. If the compile was successful, the Boolean
expression COMPOK IS COMPILEDOK evaluates to TRUE. In this case, the program that
was compiled will be run. If the compile was not successful, then no attempt is made to
run the program.
The DISPLAY statements in this example display messages at the ODT (and also at the
CANDE terminal where the job was initiated).
The following example illustrates one use of the CASE statement:
?BEGIN JOB WFLTEST(STRING COMPTYPE);
CASE COMPTYPE OF
BEGIN
("SYNTAX"):
COMPILE (MAINT)OBJECT/ORD WITH COBOL74 SYNTAX;
COMPILER FILE CARD(TITLE=ORD,KIND=DISK);
("GO"):
COMPILE (MAINT)OBJECT/ORD WITH COBOL74 GO;
COMPILER FILE CARD(TITLE=ORD,KIND=DISK);
("LIBRARY"):
COMPILE (MAINT)OBJECT/ORD WITH COBOL74 LIBRARY;
COMPILER FILE CARD(TITLE=ORD,KIND=DISK);
("LIBRARY-GO"): COMPILE (MAINT)OBJECT/ORD WITH COBOL74 LIBRARY GO ;
COMPILER FILE CARD(TITLE=ORD,KIND=DISK);
ELSE: DISPLAY "INCORRECT COMPILE TYPE ENTERED";
END;
?END JOB.
In this example, a WFL job has been constructed that enables a user to compile a
particular file in any of four possible ways according to the string parameter specified in
the START statement.
The following table lists four START statements, each with a different string parameter
specified and the results of each statement.

1–8

8600 1047–506

Task Initiation

Statement

Result

START WFLTEST(“SYNTAX”)

Compiles the file ORD to check for syntax errors,
but does not save the object code file.

START WFLTEST(“GO”)

Compiles and runs the file ORD, but does not
save the object code file.

START WFLTEST(“LIBRARY”)

Compiles the file ORD, and saves the object code
file as (MAINT)OBJECT/ORD.

START WFLTEST(“LIBRARY-GO”)

Compiles the file ORD and runs the object code
file. The object code file is saved as
(MAINT)OBJECT/ORD.

The following is an example of the DO statement:
?BEGIN JOB WFLTEST(INTEGER REPS);
INTEGER INTREPS := 0;
DO BEGIN
RUN (WALLY)OBJECT/STOCK/PLAN;
INTREPS := INTREPS + 1;
END
UNTIL INTREPS = REPS;
?END JOB.
This job runs the program (WALLY)OBJECT/STOCK/PLAN the number of times specified
in the parameter of the START statement that initiated this job. For instance, START
WFLTEST(7) runs the program (WALLY)OBJECT/STOCK/PLAN seven times.

8600 1047–506

1–9

Subroutine Control

Subroutine Control
A WFL job can include any number of subroutines, and each subroutine can contain
further subroutine declarations within itself. In addition, a subroutine can contain
statements invoking itself, or other subroutines in the WFL job. (The rules concerning
which subroutines can be invoked from a given subroutine are discussed under “Scope
of Declarations” in Section 4.)
WFL enables an identifier to be associated with a statement or group of statements. This
can be accomplished by using the subroutine declaration. Once a subroutine has been
declared, it can be invoked in the WFL job by using the identifier associated with it. The
subroutine is a convenient shorthand for referring to a piece of code that the WFL job is
going to invoke repeatedly.

Examples
The WFL subroutines can be invoked with parameters that pass values to the
subroutines. Consider the following example:
?BEGIN JOB WFLCHART(REAL VALUE1, REAL VALUE2, REAL VALUE3);
SUBROUTINE RUNCHART(REAL RVAL VALUE); % Beginning of subroutine
BEGIN % declaration
RUN (PORT)CHART/COL/NAV(RVAL);
END RUNCHART; % End of subroutine
% declaration
% WFL job statements follow
DISPLAY "RUNNING WITH FIRST VALUE SUPPLIED";
RUNCHART(VALUE1);
DISPLAY "RUNNING WITH SECOND VALUE SUPPLIED";
RUNCHART(VALUE2);
DISPLAY "RUNNING WITH THIRD VALUE SUPPLIED";
RUNCHART(VALUE3);
?END JOB.
This job is initiated with a START statement that has three real numbers specified as
parameters. The job then calls on the subroutine RUNCHART three times, each time
supplying a different parameter value to the subroutine. This method saves code
repetition when a lengthy subroutine is called.

1–10

8600 1047–506

Subroutine Control

The following example is a subroutine that invokes itself:
?BEGIN JOB WFLINV(INTEGER VALUE1, INTEGER VALUE2);
SUBROUTINE DISPLAYONE;
DISPLAY "IT WORKED ALL RIGHT";
SUBROUTINE RUNINV(INTEGER IVAL1);
BEGIN
RUN (PARTS)OBJECT/OLD/INV(IVAL1);
STATION=MYSELF(SOURCESTATION);
DISPLAYONE;
IVAL1 := IVAL1 + 1;
IF IVAL1 LEQ VALUE2 THEN
RUNINV(IVAL1);
END;
RUNINV(VALUE1);
DISPLAYONE;
?END JOB.
This job accepts two integer values as parameters. The job uses the first job parameter
as a parameter in the RUN statement for the program OBJECT/OLD/INV. This program is
run several times, with an increase in the value of the parameter each time, until the
parameter equals the value of the second parameter that was supplied to the job.
This example shows several kinds of subroutine invocations that are available. The outer
block of the WFL job calls on the subroutines RUNINV and DISPLAYONE. The subroutine
RUNINV also calls on the subroutine DISPLAYONE, which was previously defined.
Further, the subroutine RUNINV calls on itself, so that it will continue repeating as long
as the expression in the IF statement evaluates to TRUE.

8600 1047–506

1–11

Subroutine Control

The following example illustrates the use of the RETURN statement as a means of
exiting a subroutine early:
?BEGIN JOB WFLTEST(INTEGER VALUE1);
TASK T;
SUBROUTINE RUNTEST(INTEGER IVAL1);
BEGIN
RUN (WALLY)OBJECT/TEST(IVAL1) [T];
IF T ISNT COMPLETEDOK THEN
RETURN;
IVAL1 := IVAL1 + 1;
IF IVAL1 LEQ 7 THEN
RUNTEST(IVAL1);
END;
RUNTEST(VALUE1);
?END JOB.
This example runs the program (WALLY)OBJECT/TEST repeatedly. However, if the task
variable T indicates the program did not run successfully, the RETURN statement is
invoked to cause the subroutine to be exited. The remaining statements in the
subroutine will then be bypassed, and control will pass back to the parent of the
subroutine (in this case, the outer block of the WFL job).

1–12

8600 1047–506

Task Control

Task Control
Several WFL statements are available to control the execution of a task. These
statements determine

•

When a task is run

•

When a task is terminated

•

How a task responds to error conditions

•

What usercode a task runs under

These statements are referred to broadly as task control statements.

Task Control Statements
Task control statements include the following:

•

ABORT

•

STOP

•

WAIT

•

USER

The ABORT and STOP statements are available for terminating a job or task prematurely.
The difference between the two statements is that the ABORT statement displays
messages indicating that the job or task was terminated abnormally, while the STOP
statement indicates a normal termination. Generally these statements are used as part of
an IF statement or CASE statement, so that the job or task is terminated only if the
specified conditions are met.
The WAIT statement suspends job execution until some specified condition is met. The
uses of the WAIT statement include the following:

•

To cause the job to wait for an asynchronous task to complete, or to wait until the
asynchronous task achieves a specified state

•

To cause the job to wait until a file becomes resident

•

To cause the job to wait for an OK message from the user

8600 1047–506

1–13

Task Control

Examples
This example illustrates a use of the ABORT statement:
?BEGIN JOB WFLTEST;
TASK COMPOK;
COMPILE (WALLY)OBJECT/MENU/PLAN WITH PASCAL [COMPOK] LIBRARY;
COMPILER FILE CARD(TITLE=MENU/PLAN ON MUNCHPACK);
IF COMPOK IS COMPILEDOK THEN
RUN (WALLY)OBJECT/MENU/PLAN
ELSE
ABORT "UNSUCCESSFUL COMPILE";
?END JOB.
This job first attempts to compile the source file MENU/PLAN. If the compile was
successful, the job will run the object code file that was the result of the compilation. If
the compile was not successful, the job is terminated abnormally by the ABORT
statement and the message “UNSUCCESSFUL COMPILE” is displayed.
The following example illustrates a use of the WAIT statement:
?BEGIN JOB WFLTEST;
TASK TEST1, TEST2;
PROCESS RUN (WALLY)OBJECT/SORTIT [TEST1];
PROCESS RUN (WALLY)OBJECT/SORT2 [TEST2];
DO
WAIT
UNTIL TEST1 IS COMPLETED AND TEST2 IS COMPLETED;
RUN (WALLY)OBJECT/COLLATE;
?END JOB.
In this example, two asynchronous tasks are started by PROCESS statements. A
DO-UNTIL loop follows, instructing the job to wait until both asynchronous tasks are
completed before continuing.
The USER statement provides another form of task control. This statement changes the
usercode the WFL job is running under to the specified usercode. The tasks initiated by
the WFL job will then inherit the new usercode, and its associated privileges.

1–14

8600 1047–506

Task Control

The following is an example of the USER statement in a job:
?BEGIN JOB RECEIVABLE;
RUN OBJECT/INTEREST;
USER=SCROOGE/CALC;
RUN OBJECT/PENALTIES;
RUN (CRATCHIT)OBJECT/CREDIT;
?END JOB.
In this example, the first RUN statement runs the program OBJECT/INTEREST under the
job’s original usercode, which was determined at the time of job initiation. The USER
statement then changes the job’s usercode to usercode SCROOGE, which has CALC as
its password. The remaining two programs that the job initiates are then run under
usercode SCROOGE, even though the object code file for the last one resides under
usercode CRATCHIT.
The usercode of the job can also be set by specifying the USERCODE task attribute as a
job attribute, and the usercode for an individual task can be set by specifying the
USERCODE for that task.

8600 1047–506

1–15

File Handling

File Handling
Although a WFL job cannot read from or write to files itself, it provides considerable
control over the files that programs initiated through WFL can read from or write to. The
main tool that provides this control is file equation, which is discussed under “Task
Initiation” earlier in this section. In addition, there are several statements available in
WFL that provide even more flexibility in file handling.

File Handling Statements
Files can be opened in WFL by using the OPEN statement. The file specified in this
statement is opened with the I/O capabilities specified in the NEWFILE attribute,
FILEUSE attribute, or other attributes of the file. If the NEWFILE attribute or the
FILEUSE attribute is not assigned, an attempt is made to open the specified file for both
input and output. Refer to the File Attributes Reference Manual for more information
about file attributes.
The following table lists five statements that close files in different ways.

Statement

Result

CRUNCH

Closes a file and returns the unused portion of the last row of the
file to the system. Once a file is crunched, it takes up less space,
but can no longer be expanded. This statement is used for disk files
only.

LOCK

Closes the file and, except for disk or pack files, saves the unit the
file resides on so that it is inaccessible to the system.

PURGE

Removes a file and frees the area it was occupying for reuse.

RELEASE

Closes and releases a file.

REWIND

Closes a file and rewinds it. For a magnetic tape file, this means that
the tape is rewound. For a disk file, the record pointer is reset to the
first record of the file.

A WFL job can interrogate the attributes of a file. To do this, the file must first be
declared in the job with certain minimal attributes specified. In addition, the file must be
opened.

1–16

8600 1047–506

File Handling

Examples
The following job examines a file to determine whether it is a COBOL74 or COBOL85
file, and chooses the corresponding compiler:
?BEGIN JOB COBOLCOMP(STRING SYMBOL);
FILE SYMBOLF;
STRING COMPNAME;
SYMBOLF (TITLE=#SYMBOL,KIND=DISK,NEWFILE=FALSE,
DEPENDENTSPECS=TRUE);
OPEN (SYMBOLF);
IF SYMBOLF (FILEKIND) = "COBOL74SYMBOL" THEN
COMPNAME := "COBOL74"
ELSE
COMPNAME := "COBOL85";
COMPILE OBJECT/#SYMBOL WITH #COMPNAME LIBRARY GO;
COMPILER FILE CARD (TITLE=#SYMBOL,KIND=DISK);
?END JOB.
The following subroutine uses the file opening and closing capabilities of WFL to create
dummy files (empty files that can be used to indicate that some particular event has
occurred in the job). Because subroutines cannot contain file declarations, file F is
declared globally.
SUBROUTINE MAKE(STRING FILENAME);
BEGIN
F (TITLE = #FILENAME, KIND = DISK, NEWFILE = TRUE);
OPEN (F);
LOCK (F);
END MAKE;
Refer to “Job Restart after a Halt/Load” in Section 2 for an example of why you might
want to use a job to create dummy files.

8600 1047–506

1–17

File Management

File Management
WFL provides several statements for managing files. These include the following:

•

COPY statement

•

ADD statement

•

CHANGE statement

•

REMOVE statement

•

SECURITY statement

File Management Statements
The COPY statement copies files on disk or tape. The new copy of a file can be created
with a different usercode or file name, and the file can be copied to other disk or tape
units using library maintenance or to other hosts using distributed systems services
(DSS).
The ADD statement also copies files. However, the ADD statement will not copy a file if
a file with the same title already resides at the destination. Also, the destination specified
must be a disk. The ADD statement is useful for adding a directory of files to a disk
where some of the files are already resident and are to be preserved.
The CHANGE statement changes the names of files on a disk.
The REMOVE statement removes files from disk.
The SECURITY statement changes the security specifications of files on a disk. The
various security settings affect whether the file can be read or changed by tasks running
under other usercodes.

1–18

8600 1047–506

File Management

Examples
The following example copies a file from a disk to a tape, specifying a different usercode
and file name for the new copy:
COPY (ID)FILEA AS (JONES)NEWF FROM ORDS (DISK) TO SAVEA (TAPE);
The following example copies a directory of files to a disk on another host:
ADD (ID)F/= FROM ORDS (DISK) TO SAVEA (DISK, HOSTNAME=MLM);
The following example changes the name of a directory of files residing on a pack named
STORPACK:
CHANGE COMPJOBS/= ON STORPACK TO QCOMPS/=;
The following example removes files from two different packs:
REMOVE MAXERRS FROM PARTS, BADERRS FROM STORPACK;
The following example changes the security of a file to PUBLIC (thus enabling any user
free access to the file):
SECURITY NOVA/DATA/NINER PUBLIC;

8600 1047–506

1–19

Communication

Communication
WFL includes several statements that help inform you about what a job is doing. These
statements include the following:

•

DISPLAY statement

•

ACCEPT function

•

INSTRUCTION statement

•

FETCH specification

In addition, these statements enable input to modify the activity of a job.

Communication Statements
The DISPLAY statement can be used to display a message at a specific point during job
execution. The DISPLAY message appears at the ODT, in the job log, and at the CANDE
or MARC station that initiated the job (if it was initiated through CANDE or MARC).
The ACCEPT function will ask you to supply input to the job while it is running. The
ACCEPT function will display the specified message and will wait for you to return a
value by way of the AX (Accept) system command.
The INSTRUCTION statement stores information about the job in a form that you can
display at any time during job execution by using the IB (Instruction Block) system
command.
The FETCH specification stores a message that you can display by using a PF (Print
Fetch) system command, and suspends initiation of the job until the message has been
displayed. The FETCH specification is intended to be used for informing you about what
resources are required by the job.

1–20

8600 1047–506

Communication

Examples
The following example includes DISPLAY statements:
?BEGIN JOB WFLTEST(STRING DAY);
DISPLAY "CALL WILLIS AT EX. 3574 IF RUN-TIME ERRORS OCCUR";
RUN (ODDCOM)OBJECT/COPY/FACTORS(DAY);
DISPLAY "GET INPUT FROM ARCH. TAPE 143 IF FILE REQUIRED";
RUN (ODDCOM)OBJECT/FT/VERIFY(DAY);
?END JOB.
This example runs two programs that are each preceded by a display message informing
the user what to do if certain conditions occur.
The following example shows a use of the ACCEPT function:
?BEGIN JOB;
STRING FN, PK;
FN := ACCEPT("ENTER NAME OF FILE DESIRED");
PK := ACCEPT("ENTER NAME OF PACK DESIRED");
RUN (OPR)DAILY/UPDATE;
FILE IN (TITLE = #FN ON #PK);
?END JOB.
In this example, the values submitted by you are used in a file equation for a RUN
statement. The job could have been written to receive the same values from you by way
of a start parameter list. However, in that case you would have to know in advance what
parameters to supply. The ACCEPT function, on the other hand, displays a message
informing you what type of information to enter next.

8600 1047–506

1–21

Job Format

Job Format
The following features are available to increase the readability of a WFL code:

•

Free formatting

•

Comments

•

Subroutine ending identifiers

Free formatting enables WFL constructs to be entered in any column of a line and
continue over any number of lines. You can use varying amounts of indentation to
indicate the nesting of constructs. However, the invalid character must appear in the first
column.
A percent sign (%) can appear in any column of a line, and will cause the WFL compiler
to ignore the remainder of the line, which can be used for comments.
The identifier that identifies a subroutine can be repeated after the END statement for
that subroutine. In cases where subroutines are nested, this feature helps eliminate
confusion about which subroutine is being ended.

Example
The following example illustrates the use of a nested subroutine ending identifier:
SUBROUTINE SUBOUTER;
BEGIN
SUBROUTINE SUBNESTED;
BEGIN
.
.
END SUBNESTED;
.
.
END SUBOUTER;

1–22

% Beginning of outer subroutine
% Beginning of nested subroutine

% End of nested subroutine

% End of outer subroutine

8600 1047–506

Section 2
Job Initiation

Overview
A program written in WFL is referred to as a job. During execution, a job normally
executes as a task with its own object code file. However, certain statements can be
executed interpretively. This means that no object code file is produced by the WFL
compiler; the statement is executed directly by the WFL compiler.
The statements ALTER, CHANGE, PRINT, REMOVE, RERUN, SECURITY, and START are
executed interpretively in the following situations:

•

When one of the above statements is the only statement appearing after the CANDE
WFL command

•

When one of the above statements (except the PRINT statement) is entered
individually at an ODT, rather than as part of a job

•

When a job originating from a user program by way of an array consists only of one
of the above statements

These situations are described in detail in “START and WFL Commands from CANDE
Sessions,” “Operator Display Terminals (ODTs),” and “User Programs in Other
Languages” later in this section.
A WFL job can initiate other tasks. Examples of tasks are compilations and executions of
user programs. The job task controls the execution of the tasks it initiates.

8600 1047–506

2–1

Sources for Job Initiation

Sources for Job Initiation
The following pages describe how to initiate WFL jobs from each of the possible
sources, and discuss limitations specific to each source.

START and WFL Commands from CANDE Sessions
To run WFL jobs from a CANDE session, use the WFL command or the START
command.

WFL Command
The WFL command causes CANDE to pass any following text to the WFL compiler. This
enables a user to type WFL, followed by a WFL statement or even a job, and transmit
the entire job at once. The WFL job can extend over any number of lines.
The phrases BEGIN JOB and END JOB can be omitted from a job entered after the WFL
command in CANDE. Refer to Section 3, “Job Structure,” for the formal syntax of a job.
Note: Jobs submitted through the CANDE WFL statement cannot include a CLASS,
FETCH, or STARTTIME specification. In addition, the job cannot contain data
specifications, or the INCLUDE control option. Any WFL control options must be
followed by a semicolon (;) to separate them from the rest of the job.
When WFL jobs are initiated from a CANDE session in this way, any messages
generated by the job are displayed at the terminal where the job originated, as well as at
the ODT. The terminal also queues CANDE commands entered while the WFL job was
running and executes them after the job is completed. CANDE control commands the
exception to this rule; they are executed immediately.
The statements CHANGE, PRINT, REMOVE, RERUN, SECURITY, and START are
executed interpretively if one of them is the only statement following the CANDE WFL
command. This means that no object code file is produced by the WFL compiler in these
cases; the statement is executed directly by the WFL compiler.

2–2

8600 1047–506

Sources for Job Initiation

Storing Jobs in Disk Files
WFL jobs can also be saved in files on disk. To do this, you should first use the CANDE
MAKE command to create a file of type JOB. You can then enter the complete job into
the file, either in CANDE, the Editor, or some other text entry utility. For further details,
refer to the CANDE Operations Reference Manual and the Editor Operations Guide.
The question mark (?) preceding the BEGIN JOB and END JOB constructs in column 1
can cause strange results in some text entry utilities. In these cases, it might be
necessary to enter the question mark in column 2, and shift the line to the left later.
More than one job can be stored in a single disk file. The jobs will be compiled and
executed in the order that they appear in the file.
Note: If a file contains more than one job, none of the jobs can include a job parameter
list.

START Command
A WFL job saved in a file can be initiated using the CANDE START command, followed
by the name of the file, and any parameters being passed to the WFL job. Refer to the
CANDE Operations Reference Manual for the detailed syntax of this command.
The START command passes the contents of the file directly to the WFL compiler for
processing. The contents of the file must be a complete WFL job, including the BEGIN
JOB and END JOB constructs. The job can include data specifications, unlike WFL jobs
submitted through the CANDE WFL command.
Any messages from the job are displayed at the originating terminal as well as at the
ODT. However, the terminal remains free to accept any CANDE commands that are
entered and responds immediately, even if they are not control commands.

8600 1047–506

2–3

Sources for Job Initiation

Other CANDE Commands
The following CANDE commands directly invoke WFL statements that have the same
names:

•

ADD

•

COPY

•

START

Therefore, it is not necessary to precede these commands with WFL. Several other
CANDE commands have the same names as WFL statements, but do not invoke WFL,
and in some cases have different syntax or functions than their WFL counterparts. These
statements include:

•

ACCESS

•

PASSWORD

•

BIND

•

REMOVE

•

CHANGE

•

RUN

•

COMPILE

•

SECURITY

•

STOP

•

LOG

To invoke these WFL statements in CANDE, you must precede the statements with the
CANDE WFL command, or include them in a job file and initiate the job with a START
command.
Note: WFL jobs originated from CANDE sessions inherit the usercode of the CANDE
session unless a USERCODE job attribute specification is included in the job. The job
inherits the family specification associated with the usercode it is running under unless a
FAMILY job attribute specification is included in the job.

2–4

8600 1047–506

Sources for Job Initiation

START Statements from Running WFL Jobs
Running WFL jobs can initiate other WFL jobs through the WFL START statement, which
is described in detail in Section 6, “Statements.” The WFL START statement has the
same effect as the CANDE START statement.
Only jobs stored on disk can be initiated by the START statement. Such a job can include
any of the WFL constructs defined in this manual.
Once the job has been started, it has no further connection with its parent job.
Discontinuing the parent job does not affect the job that was started from it, and
termination of the started job also does not affect the parent job.
Any messages generated by the started job are directed to the same source as
messages from the parent job. For example, if the parent job is initiated from CANDE,
then messages from both the parent job and the job started by the parent job would
appear at the originating terminal.
Note: The started job inherits the usercode and family assigned to the parent job
unless the started job includes USERCODE or FAMILY job attribute specifications.

8600 1047–506

2–5

Sources for Job Initiation

Operator Display Terminals (ODTs)
Initiate WFL jobs from an ODT using one of the following methods:

•

Use the START statement to initiate a job stored in a disk file.

•

Type the complete job at the ODT and transmit the job.
When a complete job is entered at the ODT, it should begin with the BEGIN JOB
construct. It is not necessary to append the END JOB construct to the job, since
WFL will add this automatically.
Note: A complete job entered at an ODT cannot include data specifications. Any
WFL control option must be followed by a semicolon (;) to separate it from the rest
of the job.

A number of WFL statements are recognized by the CONTROLLER and are passed to
WFL automatically, even if they are not preceded by a BEGIN JOB heading. These
statements include the following:

•

ABORT

•

BIND

•

PASSWORD

•

SECURITY

•

ACCESS

•

CATALOG

•

PROCESS

•

START

•

ADD

•

CHANGE

•

PTD

•

USER

•

ALTER

•

COMPILE

•

REMOVE

•

VOLUME

•

ARCHIVE

•

Asynchronous subroutine invocation

•

CHANGE

•

COMPILE

•

COPY

•

LOG

•

MODIFY

•

OPEN

•

PTD

•

REMOVE

•

RUN

•

START

•

WAIT

If one of the following statements contains an ACCEPT function, a job rollout is
attempted before the statement:

•

CASE

•

Assignment statement

•

File attribute statement

•

Task attribute statement

•

WHILE

A job rollout is also attempted after the WAIT statement. The WAIT statement is the
only statement where a job rollout is executed both before and after the statement. This
occurs because the WAIT statement is often used to synchronize processed tasks, and
attempting the job rollout both before and after the WAIT statement helps to ensure that
a successful job rollout is completed.

8600 1047–506

2–13

Job Restart after a Halt/Load

When waiting for a long task to be completed before initiating a halt/load, it is important
to consider that the job rollout is executed by the WFL job after the task is completed.
Waiting for the task to go to “End of Task” is not sufficient to ensure that the job rollout
is completed. For example:
?BEGIN JOB RESTART/EXAMPLE/3;
% job rollout point #1
PROCESS RUN OBJECT/PROG1;
% job rollout point #2 (not successful because of active task)
WAIT(OK);
% job rollout point #3
.
.
.
?END JOB.
If the intention is to wait until OBJECT/PROG1 is completed before halt loading (so
PROG1 will not have to be restarted), it is important to allow “job rollout point #3” to be
executed. The job would restart at “job rollout point #1”, which obviously would not be
the desired result.
The following example illustrates how to avoid the potential problem by enabling the job
rollout to be successfully completed before the possible halt/load:
?BEGIN JOB RESTART/EXAMPLE/4;
TASK T1,T2;
PROCESS RUN OBJECT/PROG1 [T1]
PROCESS RUN OBJECT/PROG2 [T2]
WAIT (T1 IS COMPLETED);
WAIT (T2 IS COMPLETED)
%%% A successful job rollout will be executed here %%%
WAIT ("Okay to halt/load now", 60);
.
.
.
?END JOB.
However, the contents of most file or task variables are not saved across a halt/load.
They will have the following values:

•

Most of the attributes of file variables are returned to what they were immediately
after the original file declaration.

•

Most of the attributes of task variables are set to their system default values. This
has the same effect as reinitializing the task variable with the INITIALIZE statement.
Any task attribute assignments that occurred prior to the halt/load are not restored,
including any that were included in the task variable declaration.

The values of constant identifiers that appear in the job parameter list are saved across a
halt/load.

2–14

8600 1047–506

Job Restart after a Halt/Load

ON RESTART Statement
The ON RESTART form of the ON statement can be used to specify
actions to be taken if job execution is interrupted by a halt/load. Any statement or group
of statements can be specified in the ON RESTART statement. The following kinds of
actions might be desirable:

•

File and task variables can be reassigned the correct values.

•

Job execution can be restarted at a particular point in the job, by using a GO
statement.

If a halt/load occurs in the middle of a job, job execution restarts at the most recent
successful job rollout. If during the halt/load process the JOBDESC file is removed, jobs
with STARTTIME specifications are also removed. Therefore, no jobs are restarted. For
details, refer to the ??RJ (Remove JOBDESC File) primitive command in the System
Commands Reference Manual.
The ON RESTART statement is processed after a halt/load only if a successful job rollout
occurred after the ON RESTART statement.
Some jobs include statements that interrogate a task variable to find out whether a task
completed successfully or abnormally. However, the value of the task variable is not
retained across a halt/load. An alternative method for storing information about whether a
task completed successfully is to declare a Boolean variable in the job expressly for this
purpose, and assign a value of TRUE or FALSE to the variable after the task completes.
The value of the Boolean variable is saved across a halt/load, so it can always be
interrogated later.
A useful technique for keeping track of exactly how far job execution had progressed
before a halt/load occurred is to declare an integer variable and increment the value of
that variable at several stages during the job. The ON RESTART statement can include
statements that inspect the value of this integer variable and cause different actions to
occur according to the value stored.

Dummy Files
Another method for storing information about job execution is to have the job create
dummy files at specified points during the job execution, or whenever certain conditions
are met. The job can then use the file residence inquiry to establish whether such files
have been created, and make decisions based on their presence or absence.
Refer to “File Handling” in Section 1 for an example of a subroutine that can be used to
create dummy files. The file residence inquiry is described under “Interrogating File
Attributes” in Section 5.
For more detailed information about restarting WFL jobs after a halt/load, see the Task
Management Programming Guide.

8600 1047–506

2–15

Job Restart after a Halt/Load

2–16

8600 1047–506

Section 3
Job Structure

Overview
This section describes the overall structure of a WFL job, and discusses the job attributes
and specifications that can be included at the beginning of a job.

Job Syntax
The following syntax represents a complete WFL job:

ÄÄÂÄÄÄÄÄÂÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄ BEGIN ÄÄ JOB ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÀÄÄÙ ÀÄ AT ÄÄÄÙ
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄ ; ÄÄÄÄÄë
ÀÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄÄÙ ÀÄÄÙ
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄë
ÀÄÄÙ ÀÄÄÙ
ÄÄÂÄÄÄÄÄÂÄ END ÄÄ JOB ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄÄÙ

Job Structure
A job is composed of three parts:

•

Job heading

•

Job body

•

End of job

Job Heading
The job header initializes the job by means of the following elements:

•

construct (optional)

•

Job parameter list (optional)

•

Hostname constant (optional)

•

Job disposition (optional)

•

BEGIN JOB expression (required)

•

Job attribute list (optional)

•

Job title (optional)

8600 1047–506

3–1

Job Syntax

Job Body
The job body contains the operational part of the job and consists of

•

Declaration list (optional)

•

Statement list

End of Job
The end of job terminates the operation of the job and contains the following elements:

•

construct (optional)

•

END JOB expression

Job Contents
The contents of WFL jobs are extremely flexible. The only two elements that appear in all
WFL jobs are the BEGIN JOB and END JOB constructs. The WFL compiler adds these
statements around single WFL statements that are entered through CANDE or at the
ODT. The other elements are optional.

Job Format
The formatting of WFL jobs is also flexible. WFL constructs can begin in any column of a
line, can continue over one line onto the next, and can include varying amounts of space
between words. Also, multiple statements can appear on a line, as long as they are
separated by semicolons (;). The only restriction is that the construct must appear in
the first column.
The construct before the BEGIN JOB construct is optional and has no effect on the
job. The construct before the END JOB construct is optional normally, but is required
if an AT hostname constant specification is included in the job. Refer to “Invalid and Valid
Characters” in Section 8 for information about the construct.
Comments can be entered into the job by preceding them with a percent sign (%). Any
input following the percent character on a line is ignored by the WFL compiler. However,
input that precedes the percent sign on a line is treated as part of the job.
WFL control options can be included anywhere in the job, as long as they appear on a
line with a dollar sign ($) in the first or second column. These options are discussed in
Section 9, “WFL Control Options.”
Note: A WFL job must be entered in all uppercase letters. Only comments or strings
can contain lowercase letters.

3–2

8600 1047–506

Job Syntax

AT Hostname
The AT hostname constant specification causes a job initiated on one system to be
compiled and run on another system.
The WFL compiler at the receiving host system compiles the job; the sending host does
not analyze the contents of the job, except for the END JOB construct. If the END JOB
construct is missing, an “UNEXPECTED END OF FILE” error message is issued.
The hostname specified must be an available host in a BNA or Open Systems
Interconnection (OSI) network.
If the host specified is not available, the job compilation is aborted and the error message
“UNKNOWN HOST SPECIFIED” is displayed. The CANDE ?HN command or the
HOSTNAME (Host Name) system command can be used before the job is started to
determine what BNA hosts are available. The CANDE ?AT local host NW OSIGATEWAY
command or the NW OSIGATEWAY system command can be used to determine what
OSI hosts are available.
A null character within a quoted string causes the transferred job to be incorrectly
terminated, which causes erroneous syntax errors at the receiving host. This incorrect
termination occurs because the sending host does not analyze the contents of the job;
the sending host transfers data to the receiving host only until a null character is reached.
Using the START FOR SYNTAX statement is not allowed for jobs that include an AT
hostname constant specification. Doing so generates the following syntax error:
START FOR SYNTAX IS ONLY VALID FOR LOCAL HOST

Example
The following job will run at the system named SF6B:
?AT SF6B BEGIN JOB ADDIT;
.
.
.
?END JOB.

8600 1047–506

3–3

Job Title

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

Explanation
The job title specifies the name of the job. The job name appears in the

•

BOJ and EOJ messages displayed by the job

•

Active entry display at the ODT

•

Job summary generated by a job

•

System log

The job title must be included if there is a job parameter list or job disposition in the job;
otherwise, the job title is optional.
Though the syntax for a job title is the same as that for a file title constant, the job title
does not have to be the name of any file. There is no connection between the job title of
a job and the title of the file it is stored in. For the syntax of a file title constant, see “File
Names, Titles, and Directories” in Section 8.
The job name can also be assigned by including the NAME attribute in the job attribute
list for the job. Note that the NAME attribute overrides the job name in the .
If neither a job title nor a NAME job attribute is included in the job, the WFL compiler
assigns a name to the job.

Examples
The following are examples of job headings that include valid job titles:
?BEGIN
?BEGIN
?BEGIN
?BEGIN

3–4

JOB
JOB
JOB
JOB

RUNPROG;
DATA/SURVEYOR;
(WALLY)MENU/PLAN;
(LAO)OLD/DOC ON FORMSPK;

8600 1047–506

Job Parameter List

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄ ( ÄÁÄÂÄÄÂÄÁÄ ) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÃÄÄ´
ÃÄÄÄÄÄ´
ÀÄÄÄÙ

ÄÄ BOOLEAN ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄ´
ÀÄ OPTIONAL ÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ DEFAULT ÄÄ = ÄÄÄÙ

ÄÄ INTEGER ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄ´
ÀÄ OPTIONAL ÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ DEFAULT ÄÄ = ÄÄÄÙ

ÄÄ REAL ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄ´
ÀÄ OPTIONAL ÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ DEFAULT ÄÄ = ÄÄÄÙ

ÄÄ STRING ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ´
ÀÄ OPTIONAL ÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ DEFAULT ÄÄ = ÄÄÄÙ

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

8600 1047–506

3–5

Job Parameter List

Explanation
A job parameter list declares constant identifiers and assigns them the values supplied in
the START statement that initiated the job. The constant identifiers retain their original
values throughout the job. They can be one of the following types:

•

BOOLEAN

•

INTEGER

•

REAL

•

STRING

These constant identifiers can be used in a WFL job in most of the places a constant or
an expression of the appropriate type is permitted. (For example, a Boolean constant
identifier can be used wherever a Boolean constant, Boolean constant expression, or
Boolean expression is permitted.)
The keyword OPTIONAL indicates that an actual parameter does not need to be passed
for that job parameter. If an actual parameter is not passed, the default values are
assigned as follows:

Type

Default Value

Boolean

FALSE

Integer

Real

String

"" (two double quotation marks)

Default values can also be specified with the DEFAULT clause following the keyword
OPTIONAL. The specified default value is ignored if an actual parameter is provided.
A job parameter list can only be used in WFL jobs that are stored on disk and initiated
through a CANDE, MARC, or WFL START statement. If a job initiated from another
source includes a job parameter list, then it must be compiled for syntax only (see the
description of the SYNTAX job disposition later in this section).
A job that includes an AT hostname constant specification cannot have a job parameter
list, unless all the job parameters are optional. When more than one job is stored in a disk
file, none of the jobs can contain job parameter lists.

3–6

8600 1047–506

Job Parameter List

Example
Consider the statement START (WALLY)RUNPROG(23.8, 7), which initiates the following
job:
?BEGIN JOB RUNPROG (REAL VAL1, REAL VAL2);
REAL INVAL;
INVAL := VAL2 * VAL2;
RUN OBJECT/WALLY/COUNTER(VAL1);
RUN OBJECT/WALLY/COUNTER(INVAL);
?END JOB.
This job runs the program OBJECT/WALLY/COUNTER twice, first with a parameter value
of 23.8, and then with a parameter value of 49 (because INVAL was assigned the square
of the VAL2 parameter).

8600 1047–506

3–7

Job Disposition

ÄÄÂÄÄÄÄÄÄÄÂÄ SYNTAX ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ FOR ÄÙ

Explanation
The SYNTAX job disposition compiles a job for syntax checking only. When the job is
initiated, the WFL compiler simply compiles it and displays a list of any syntax errors in
the job. This job disposition is beneficial when you only need to debug a job.

Example
The following is an example of a job heading that includes a SYNTAX job disposition:
?BEGIN JOB GEO/ANLYS FOR SYNTAX;

3–8

8600 1047–506

Job Attribute List

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄÂÄÄÂÄ ; ÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄ´
ÀÄÄÄÄÙ

Explanation
The job attribute list assigns task attributes and job specifications to the job. The CLASS
specification, FETCH specification, and STARTTIME specification can only be applied to a
job and are described under their own headings later in this section.
The syntax for task attribute assignment is described in Section 5, “Task Initiation,” later
in this manual. The types and the meanings of the task attributes recognized by the WFL
compiler are described in the Task Attributes Reference Manual.
Attributes not assigned to values in the job attribute list are assigned values by the
system on the following basis:

•

Certain attributes inherit values associated with the usercode the job is originated
from, such as the CLASS, CHARGECODE, FAMILY, CONVENTION, PRIORITY, and
USERCODE attributes. These values are stored in USERDATA locator nodes in the
USERDATAFILE. For information about the USERDATAFILE, refer to the Security
Administration Guide.

•

Other attributes can inherit values associated with the class (or queue) of the job. A
class can have default values and/or maximum values specified for the PRIORITY,
MAXPROCTIME, MAXIOTIME, or ELAPSEDLIMIT attributes. A job is discontinued if
the job attribute list specifies greater resource limits than those associated with the
class of the job.

•

Attributes assume their default values if they are not included in the job attribute list
and do not receive values from the usercode or class of the job. The attributes that
limit resource usage default to their maximum possible values.

Task attributes can also be assigned to specific tasks initiated by a job. Refer to the
Section 5, “Task Initiation,” for a description of how to assign task attributes to specific
tasks.
Task attributes associated with a job can be changed or interrogated later in the job by
using the MYJOB predeclared task variable.
Note: A string primary cannot be used in job-related task attribute assignments unless
you use the MYJOB or MYSELF predeclared task variable syntax. Refer to “MYJOB and
MYSELF Predeclared Task Variables” in Section 5 for details.

8600 1047–506

3–9

Job Attribute List

Resource-Limiting Attributes
Resource-limiting attributes affect the total resources available to a job and all its tasks
when such attributes are included in the job attribute list. Resource-limiting attributes
include the following:

•

ELAPSEDLIMIT

•

MAXIOTIME

•

MAXLINES

•

MAXPROCTIME

•

MAXWAIT

•

PRINTLIMIT

•

PUNCHLIMIT

While these attributes can also be set for specific tasks, the accumulated resource usage
of the job and all its tasks cannot exceed the values set for these attributes for the job.
Some of the job attribute values are inherited by the tasks initiated by a job. The
inheritance status of each attribute is listed in the Task Attributes Reference Manual.
The HOSTNAME task attribute has no effect when it is used in a job attribute list, but an
AT hostname constant specification can be used instead. Refer to “AT Hostname”
earlier in this section for details.
If a particular task attribute is assigned values more than once in a job attribute list, the
last assignment overrides the previous ones.
The job attribute list is terminated by the appearance of any construct that is not a job
attribute assignment.
USER is accepted as a synonym for the USERCODE task attribute when it is entered as
part of a job attribute list. If the USER statement is the first statement of a job, it is
interpreted as part of the job attribute list rather than as an executable statement. The
specified USERCODE is validated during the compilation as a new usercode logging on
for the duration of the job execution.
Note: Changing the usercode of the job causes the job to run under the new usercode
with job attributes specified in the USERDATAFILE. If the usercode of the job is changed,
job messages will stop appearing at the originating terminal even though the job
continues to execute normally.
File equations cannot be included in the job attribute list. A statement beginning with
FILE is interpreted as a file declaration and terminates the job attribute list.

3–10

8600 1047–506

Job Attribute List

Example
The following example job includes a number of common job attribute assignments:
?BEGIN JOB COMPJOB;
CLASS = 3;
USERCODE = JOHN/JUAN;
CHARGECODE = SHIPPING;
MAXPROCTIME = 60;
PRIORITY = 80;
RUN (WALLY)POSTAGE/SUMMARY ON SHIPPK;
?END JOB.

8600 1047–506

3–11

CLASS Specification

ÄÄÂÄ CLASS ÄÂÄ = ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ QUEUE ÄÙ

Explanation
The CLASS specification assigns the number of the queue desired for the job. (QUEUE is
a synonym of CLASS.)
For more information on managing WFL jobs in queues, refer to the System
Administration Guide.

Examples
The following job extracts include CLASS specifications:
?BEGIN JOB COMP;
CLASS = 5;
?BEGIN JOB CLASSVAL(INTEGER CL);
CLASS = CL;

3–12

8600 1047–506

FETCH Specification

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄ FETCH ÄÄ = ÄÁÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

Explanation
The FETCH specification provides operators with information about the job.
One or more strings can be included in the FETCH specification. Initiation of a job is
suspended if it includes a FETCH specification; the job appears in the waiting entries list
at the ODT with a “REQUIRES FETCH” message. The FETCH messages can be
displayed using the PF (Print Fetch) system command. The job can be reactivated using
the CANDE OK command or the OK system command.
If the system option 19 (NOFETCH) is set, the FETCH attribute does not suspend job
initiation. However, it is still possible to use the PF system command to display the fetch
message associated with a job. System options are set or displayed using the OP
(Options) system command.

Example
?BEGIN JOB UPDATE;
FETCH = "THIS JOB NEEDS THREE TAPE DRIVES";
RUN NIGHTLY/UPDATE;
?END JOB.

8600 1047–506

3–13

STARTTIME Specification

ÄÄ STARTTIME ÄÄ = ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ + ÄÄÄÙ ÀÄ ON ÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ + ÄÄÄÙ

ÚêÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÚêÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄ/2\ÄÄÁÄ : ÄÄÄ/2*\ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

ÄÄÂÄÄÄ / ÄÄ
ÄÄ / ÄÂÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³
ÀÄÄ´
³ ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³
ÃÄÁÄ/5*\ÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³
ÀÄÁÄ/7*\ÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄ /2\ ÄÄ ÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄ /4*\ ÄÄ ÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

Explanation
The STARTTIME specification delays job initiation until the specified start time.
The time construct specifies the time of day on a 24-hour clock. The time and time
interval constructs are of the form HH: MM, where HH specifies the hour (or number of
hours) and MM specifies the minute (or number of minutes). HH must be less than 24,
and MM must be less than 60. The minute values must be 2-digit numbers. If a time
interval is specified, that time interval is added to the current time.
The day, hour, and month values can either be a 1-digit or a 2-digit number.

3–14

8600 1047–506

STARTTIME Specification

The date construct can be input either in the Gregorian format: mm/dd/yy or mm/dd/yyyy,
or the Julian format: yyddd or yyyyddd. If a 5-digit is used as the
STARTTIME value, the first two digits signify the year and the last three digits signify the
day of the year. If a 7-digit is used, the first four digits signify the year
(including the century) and the last three digits signify the day of the year. For example, if
you input either 94293 or 1994293, they will both equal day 293 of 1994.
If a day interval is specified, that number of days is added to the current date.
If the time is specified without a date or day interval, the current date is used.
The FS (Force Schedule) system command can be used to cause job initiation to proceed
immediately, without waiting for the specified start time. For a description of the FS
command, refer to the System Commands Reference Manual.

Examples
The following job begins execution after 10:00 p.m. on March 20, 1990:
?BEGIN JOB EXAMPLE1;
STARTTIME = 22:00 ON 03/20/90;
.
.
.
?END JOB.
The following job begins execution a minimum of 1 hour and 30 minutes after entering
the system:
?BEGIN JOB EXAMPLE2;
STARTTIME = +1:30;
.
.
.
?END JOB.
The following job is executed on host BLUE and begins execution after 11:00 a.m.
according to the system clock on host BLUE:
?AT BLUE BEGIN JOB;
STARTTIME = 11:00;
.
.
.
?END JOB.

8600 1047–506

3–15

Declaration List

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄÄÄ ; ÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

Explanation
Declarations define constants, variables, subroutines, and global data specifications.
Declarations of variables can also include initial value assignments. The following types of
variables are available in WFL: BOOLEAN, INTEGER, REAL, STRING, FILE, and TASK. For
details about the declarations available in WFL, refer to Section 4, “Declarations.”
All declarations for the job must precede all statements in the job, and the declarations in
a subroutine must precede all the statements in that subroutine.
More than one declaration can appear on a line, as long as each declaration is followed by
a semicolon (;).

Example
The following job segment illustrates the use of declarations:
CONSTANT DEBUG = FALSE;
BOOLEAN TFVAL,
SUBTVALU;
FILE FILE1(TITLE=(ODCOM)FIXIT ON PACK);
INTEGER INTVAL := 43;
REAL RLVAL := 19.67,
RLVAL2 := 16.8;
STRING STRNGVL := "Test Run";
TASK DOUBAT (PRIORITY=75,INFILE(TITLE=(WALLY)DATA/SAVER));
DATA INPUT/PREP
43
69
128
? % End of data
SUBROUTINE PROVIT;
BEGIN
RUN (RAJA)DATA/PREP(TFVAL,INTVAL,STRNGVL,RLVAL);
FILE INPUT (TITLE=INPUT/PREP,KIND=READER);
END PROVIT;

3–16

8600 1047–506

Statement List

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³
ÀÄÁÄÄÄ : ÄÁÄÙ

Explanation
The statements in a WFL job are grouped together in a statement list. More than one
statement can appear on a line, while a lengthy statement can continue across several
lines. Individual statements are distinguished by a statement separator.
The usual statement separator is a semicolon (;) appearing at the end of a statement.
However, an invalid character at the start of a line also acts as a statement separator.
Each statement can be preceded by one or more label identifiers. These label identifiers
can then be referred to by GO statements in the job. GO statements transfer control to
the point in the job where the specified label identifier appears.
Refer to Section 6, “Statements,” for descriptions of all the statements available in WFL.

Examples
In this first example, the semicolon signals the end of a statement.
BEGIN JOB SEPARATOR/EXAMPLE1;
IF DECIMAL( TIMEDATE(HHMMSS) ) < 120000 THEN
DISPLAY "Good Morning, it is now: "
& TIMEDATE(DISPLAY)
ELSE
DISPLAY "Good Afternoon, it is now: "
& TIMEDATE(DISPLAY);
WAIT(5); DISPLAY "Bye";
?END JOB.
In this next example, the invalid character—the question mark (?)—in the first column of
a statement implies the end of the previous statement. A semicolon must be used to
separate multiple statements appearing on a single line.
?BEGIN JOB SEPARATOR/EXAMPLE2
?IF DECIMAL( TIMEDATE(HHMMSS) ) < 120000 THEN
DISPLAY "Good Morning, it is now: "
& TIMEDATE(DISPLAY)
ELSE
DISPLAY "Good Afternoon, it is now: "
& TIMEDATE(DISPLAY)
?WAIT (5); DISPLAY "Bye"
?END JOB.

8600 1047–506

3–17

Statement List

The following example shows the use of statement label identifiers:
?BEGIN JOB LABEL/EXAMPLE3;
STRING S;
RETRY:
COPY X AS Y;
IF FILE Y ISNT RESIDENT THEN
BEGIN
AX:
S:= ACCEPT("FILE Y NOT COPIED. AX: RETRY, OR AX: SKIP");
IF S = "RETRY" THEN
GO TO RETRY
ELSE IF S = "SKIP" THEN
ABORT
ELSE
GO TO AX;
% Ask again.
END;
?END JOB.

3–18

8600 1047–506

WFL Job Example

WFL Job Example
The following example illustrates a complete WFL job:
?BEGIN JOB EXAMPLE
(STRING TESTNAME,INTEGER TESTNUMBER);
NAME=EXAMPLE/#STRING(TESTNUMBER,*);
% Job attribute
USERCODE = WFL/MANUAL;
% Job attribute
CLASS = 2;
% Job attribute
TASK TCOMP, TRUN;
% Variable declaration
COMPILE #(TESTNAME & STRING(TESTNUMBER,*))[TCOMP] WITH ALGOL[TRUN] GO;
COMPILER DATA CARD
% The COMPILE statement is
BEGIN
% followed by a local data
INTEGER I;
% specification containing the
DISPLAY ("P IS RUNNING"); % program being compiled.
DISPLAY ("NOW ABORT");
% For information about local
I=I/0;
% data specifications, see the
END.
% "Task Initiation" section.
?
% End of data.
IF TCOMP IS COMPILEDOK THEN
DISPLAY "COMPILED OK"
ELSE ABORT "*DID NOT COMPILE";
IF TRUN IS COMPLETEDOK THEN
DISPLAY "RAN OK"
ELSE ABORT "** RUN ABORTED";
?END JOB.

8600 1047–506

%
%
%
%
%
%
%

Displays message if compile
is successful.
Aborts job if compile
fails.
Displays messages if run
is successful; otherwise,
aborts job.

3–19

WFL Job Example

3–20

8600 1047–506

Section 4
Declarations

Overview
Declarations define constants, variables, subroutines, and global data specifications.
Statement label identifiers are not declared. Refer to “Statement List” in Section 3 for a
discussion of label identifiers.

Declaration Syntax
The following syntax represents the declarations available in a WFL job:

ÄÄÂÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄÄÄÄÄÄÄ´
ÃÄÄÄÄÄ´
ÀÄÄÙ

Explanation
All declarations in a job must follow the job attribute list and must precede any
statements. All declarations in a subroutine must follow the BEGIN statement for the
subroutine and must precede any executable statements in the subroutine.
Declarations can occur in any order.

8600 1047–506

4–1

Declaration Syntax

Scope of Declarations
Declarations can occur either at the job level or within subroutines. Declarations
occurring at the job level can define:

•

Global variables

•

Subroutines

•

Global data specifications

Items declared at the job level can be referenced anywhere in the job, including in any of
the subroutines.
Variables and subroutines declared within a subroutine are local to that subroutine. They
can only be used in the subroutine they are declared in, and in subroutines nested within
that subroutine. Local variables are reinitialized each time the subroutine is invoked.
Note: A variable or subroutine cannot be referenced before its declaration. For
example, a subroutine cannot make use of a globally declared variable unless the
declaration of that variable occurs before the declaration of the subroutine.
Special care should be taken when assigning values to a global variable in an
asynchronous subroutine. Refer to the “PROCESS Statement” in Section 6,
“Statements,” for further information.

Variable Initialization
The initial value of a variable can be specified in the declaration; if it is not, the default
value for that variable type is applied to the variable. The initial value of a variable is
stored before the execution of the first statement in the job or subroutine.
Boolean, integer, real, and string variables retain their values across a halt/load. However,
the contents of file and task variables are not saved. Refer to “Job Restart after a
Halt/Load” in Section 2 for details.
The INITIALIZE statement assigns a value of NEVERUSED to the STATUS task attribute
of the specified task variable, and restores the default values to all other task attributes
and file equations associated with that task variable.

4–2

8600 1047–506

Constant Identifiers

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄ CONSTANT ÄÁÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

ÄÄÂÄ
ÃÄ
ÃÄ
ÀÄ

= ÄÂÄÄ´
= Ä´
= ÄÄÄÄÄÄÄ´
= ÄÄÄÙ

Explanation
A constant declaration declares one or more constant identifiers and assigns their value.
A constant identifier can be one of the following type:

•

Boolean

•

Integer

•

Real

•

String

The constant declaration enables constant values to be referenced by name rather than
by specifying the actual values throughout the job.
The type of each constant identifier being declared is determined by the type of the
constant expression to the right of the equal sign (=). The constant expression can be
specified using literal values, previously declared constant identifiers, and job
parameters.
The values of constant identifiers are retained across a halt/load.

Example
The following example represents the use of constant identifiers:
CONSTANT
NAME = "ABCDEFGHIJKLMNOPQRSTUVWXYZ-_",
NUMBERS = "0123456789",
PI = 3.14159,
DEBUG = FALSE,
MAXRETRY = 10,
MAXSTRINGCHARS = 256,
UC = "GEORGE",
INPUTNAME = "INPUT/1",
PK = "USERS",
INPUTTITLE = "(" & UC & ")" & INPUTNAME PK;

8600 1047–506

4–3

Boolean Variables

ÄÄ BOOLEAN ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ëÄÁÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÁÄÄÄÄÄ´
ÀÄ := ÄÄÄÙ

Explanation
A Boolean declaration declares a variable of type BOOLEAN. The default initial value of a
Boolean variable is FALSE.
If the := Boolean constant expression clause is specified for a Boolean identifier, this
Boolean constant expression is used as the initial value for that Boolean identifier.
The values of Boolean variables are saved across a halt/load and are restored when the
job restarts.

4–4

8600 1047–506

Integer Variables

ÄÄ INTEGER ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ëÄÁÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÁÄÄÄÄÄ´
ÀÄ := ÄÄÄÙ

Explanation
An integer declaration declares a variable of type INTEGER. The default initial value of an
integer variable is 0.
If the := integer constant expression clause is specified for an integer identifier, this
integer constant expression is used as the initial value for that integer identifier.
The values of integer variables are saved across a halt/load and are restored when the job
restarts.

8600 1047–506

4–5

Real Variables

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄ REAL ÄÁÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÁÄÄÄÄ´
ÀÄ := ÄÄÄÙ

Explanation
A real declaration declares a variable of type REAL. The default initial value of a real
variable is 0.
If the clause := real constant expression is specified for a real identifier, this real constant
expression is used as the initial value for that real identifier.
The values of real variables are saved across a halt/load and are restored when the job
restarts.

4–6

8600 1047–506

String Variables

ÄÄ STRING ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ëÄÁÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÁÄÄÄÄÄÄÄ´
ÀÄ := ÄÄÄÙ

Explanation
A string declaration declares a variable of type STRING. The default initial value of a string
variable is a null string ("").
The values of a string variable are saved across a halt/load.
If the := string constant expression clause is specified for a string identifier, this string
constant expression is used as the initial value for that string identifier.

Example
The following example illustrates the declaration of string variables:
STRING STR1, STR2;
STRING STR3 := "STRVAL";

8600 1047–506

4–7

File Variables

ÄÄ FILE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ëÄÁÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÁÄÄÄÄ´
³
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄ¿
³
ÀÄ ( ÄÁÄÄÁÄ ) ÄÙ

Explanation
A file declaration defines a logical file with the specified file attributes. A file declared in a
WFL job can be used in either of two ways:

•

To enable file attribute inquiries.
If the declared file is associated with a physical file, the file identifier can be used in
expressions that return the values of attributes of the physical file. This subject is
discussed under “Interrogating File Attributes” in Section 5.

•

To enable a task to use a declared file.
If a file is declared in a global file assignment, the global file assignment causes a
task to use the declared file in place of a file that the task would normally use. This
subject is discussed under “File Equations” in Section 5.

WFL cannot directly read from or write to the declared file. However, the file equation
capabilities of WFL do provide considerable control over the choice of files that will be
used by a task. Refer to “File Equations” in Section 5 for further details.
Note: File declarations cannot occur in a subroutine.
The WFL job can also include input data for a task, in the form of data specifications.
Refer to “Global Data Specifications” later in this section and “Local Data Specifications”
in Section 5 for further details.
File attributes included in a file declaration must be assigned constants or constant
expressions. Attributes of type name, file name, or title must be assigned constants only.
File attribute values associated with a file variable are not saved across a halt/load. Refer
to “Job Restart after a Halt/Load” in Section 2 for further details.
Note: The use of the file identifier SUMMARY should be avoided for printer files. If a
printer file is declared in WFL with a file identifier of SUMMARY, and a job summary is
generated with the default title of SUMMARY, the printer file declared in WFL will be
lost. This occurs because the job summary file will overwrite the file declared in WFL.
To create a printer file in WFL with the file identifier SUMMARY, either use the
JOBSUMMARY task attribute to suppress the job summary, or use the
JOBSUMMARYTITLE task attribute to assign a different name to the job summary file.

4–8

8600 1047–506

Task Variables

ÄÄ TASK ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄë
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ëÄÁÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÁÄÄÄÄÄ´
ÀÄ ( ÄÄÄÄ ) ÄÙ

ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄÁÄÂÄÄÂÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Explanation
The task declaration declares task variables, which can be associated with particular
tasks in a task initiation statement.
If a task initiation statement includes a task variable, then any task attribute assignments
or file equations that have been specified for that task variable are applied to the task.
The values assigned to file and task attributes in a task declaration must be constants or
constant expressions. Attributes of type name, file name, or title must be assigned
constants only.
Any task attribute values or file equations associated with a task variable are not saved
across a halt/load. Refer to “Job Restart after a Halt/Load” in Section 2 for further details.
Task variables can be assigned task attribute values or file equations later in the job by
the task assignment statement. Refer to the assignment statement in Section 6,
“Statements,” for a description of the task assignment statement.
The task variable can also be used for inquiries about the values of any task attributes
associated with the task, including those task attributes that record task status and task
history. This is possible by using various WFL expressions, which are described in
Section 7, “Expressions.”
WFL provides two predefined task variables. The following task variables can be used to
interrogate the values of attributes in the job:

•

MYSELF

•

MYJOB

Refer to “Using Task Variables” in Section 5 for a discussion of the uses of the task
variables, including the MYSELF and MYJOB task variables.

8600 1047–506

4–9

Subroutines

ÄÄ SUBROUTINE ÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄë
ÀÄÄÙ
ëÄ ; ÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄÄÙ
subroutine parameters>
ÚêÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ , ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÄÄ ( ÄÁÄÂÄ BOOLEAN ÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÂÄÁÄ ) ÄÄÄÄÄÄÄÄÄÄ´
³
ÀÄ VALUE ÄÙ ³
ÃÄ INTEGER ÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄ´
³
ÀÄ VALUE ÄÙ ³
ÃÄ REAL ÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄ´
³
ÀÄ VALUE ÄÙ
³
ÃÄ STRING ÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄ´
³
ÀÄ VALUE ÄÙ ³
ÃÄ FILE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄ TASK ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

ÄÄ BEGIN ÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄ END ÄÄÄÄÄÄÄÄÄÄÄÄë
ÀÄÄÙ ÀÄÄÙ
ÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
ÀÄÄÙ

Explanation
A subroutine declaration identifies a series of statements that are executed when the
subroutine is invoked by a subroutine invocation statement. The subroutine invocation
statement is described in Section 6, “Statements.”
The simplest form of a subroutine consists of the subroutine heading, followed by a
single statement. Declarations and multiple statements can be included in the
subroutine, but they must be bracketed by the words BEGIN and END.
Any kind of WFL declaration can be included in a subroutine except for file declarations
and global data specifications. However, subroutines can include local data
specifications, and references to global data specifications and files that are declared
globally. Variables declared in a subroutine are local to that subroutine (refer to “Scope of
Declarations” earlier in this section).
The WFL statements are described in Section 6, “Statements.”
WFL enables a subroutine identifier to be repeated after the end of the subroutine. This
feature helps create WFL jobs that are easier to read, especially in cases where nested
subroutines occur. If a subroutine identifier is specified after END, it must be the same
subroutine identifier specified at the start of the declaration.

4–10

8600 1047–506

Subroutines

A subroutine declaration can include another subroutine declaration within itself. This is
referred to as nesting. Subroutines can be nested to a maximum of 10 levels.
Note: WFL jobs that have nested subroutines can result in larger code files due to the
new Long Name Call/LNMC, Long Value Call/LVLC code, which replaces Name
Call/NAMC, Value Call/VALC and uses more bytes. If the WFL compiler issues a warning
message that a code segment exceeds its capacity, then you must split the statements
in that subroutine into multiple subroutines. Ignoring the warning message can result in
the initiation or compilation of a WFL job being aborted.

Subroutine Parameters
The subroutine parameters specification can be included in the subroutine heading to
declare parameters for the procedure. These parameters are assigned values taken from
the statement that invoked the subroutine. The parameters are treated as local variables
within the subroutine; they can be interrogated or assigned new values anywhere within
the subroutine or within any subroutines nested within it.
Declarations in a subroutine cannot declare an identifier that has the same name as any
of the parameters of that routine. Each parameter in the parameter list must be preceded
by a keyword specifying the parameter type.
A parameter is considered to be call-by-reference unless it is followed by the word
VALUE, which indicates that the parameter is call-by-value. Task and file variables can
only be call-by-reference.
Note: Any changes made to the value of a call-by-reference parameter in the course of
the subroutine also change the value of the variable that was passed to that parameter.
By contrast, any changes made to the value of a call-by-value parameter in the course of
the subroutine do not affect the value of the variable that was passed to that parameter.
If a constant or an expression is passed as a parameter in the subroutine invocation
statement, that parameter is passed by value whether or not VALUE is specified for that
parameter. When a real parameter is passed to an integer in a subroutine call, it requires
integer truncation and treats the real parameter as an expression. Because an expression
is passed as a parameter, that parameter is passed by value.
When a parameter is a string expression, the string expression can contain up to
1026 characters. Within the subroutine, however, the string parameter cannot be
assigned directly to a string variable, because a string variable has a maximum length of
256 characters.

Example
The following example illustrates the use of subroutines:
?BEGIN JOB SUBSHOW;
INTEGER VAL1 := 7,
% Global variable declarations
VAL2 := 11;
% Begin subroutine declaration

8600 1047–506

4–11

Subroutines

SUBROUTINE FIRSTSUB(INTEGER PARAM1, INTEGER PARAM2 VALUE);
BEGIN
PARAM1 := PARAM1 * 2;
% Changes made to the values of the
PARAM2 := PARAM2 * 2;
% parameters
END FIRSTSUB;
% End subroutine declaration
FIRSTSUB(VAL1,VAL2);
% Subroutine invocation
RUN (RAJA)AREA/MEASURE(VAL1,VAL2); % Task initiation
?END JOB.
In this example, the global variables VAL1 and VAL2 are assigned values of 7 and 11,
respectively. The subroutine invocation statement passes the variables VAL1 and VAL2
as values for the parameters PARAM1 and PARAM2. PARAM1 is therefore assigned a
value of 7, and PARAM2 is assigned a value of 11. The subroutine contains statements
that double the values of these parameters to 14 and 22, respectively.
The RUN statement that follows the subroutine invocation statement passes VAL1 and
VAL2 to the program (RAJA)AREA/MEASURE. The values the program receives are 14
and 11. This occurs because the change made to the value of the call-by-reference
parameter PARAM1 also affects the global variable VAL1 that was passed to it. The
change made to the call-by-value variable PARAM2 does not affect VAL2.

4–12

8600 1047–506

Global Data Specifications

ÄÄÂÄ DATA ÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ%
ÀÄ EBCDIC ÄÙ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ%
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

One or more card images or records of EBCDIC data.

Explanation
A global data specification contains data that can be used as input by programs initiated
in the job. The global data specification is read as if it were a card reader input file, and
can be closed and reopened or read by more than one task.
The file name constant identifies the global data specification. The file name constant
cannot contain a usercode or an asterisk (*).
The data images must be of the type specified at the start of the global data
specification. The types of global data specifications are defined as follows:

Data Type

Meaning

DATA

Allows any characters in the EBCDIC character set.

EBCDIC

A synonym for DATA.

The data images should begin on the line or card image following the global data
specification heading.
Note: Any data following the heading on the same line is ignored.
Tasks are read from the global data specification as if they were an input file, and each
line of data images is treated as a new record of the input file. A record in a disk file
created by CANDE with a FILEKIND=JOBSYMBOL contains data in columns 1 through
80, spaces in columns 81 and 82, and the sequence number in columns 83 through 90.
Since the default MAXRECSIZE that a program uses when reading these data images is
14 words (84 characters), care must be taken to ensure that unwanted characters are not
included in the data.
Note: To ensure that no unwanted information is read from columns 81 through 84 of
the data images, equate UNITS to CHARACTERS and MAXRECSIZE to 80.
The construct that terminates the global data specification also separates the data
specification from the next declaration or statement; it is not necessary to follow the data
specification with a semicolon (;).

8600 1047–506

4–13

Global Data Specifications

For a global data specification to be used by a task, the task initiation statement should
contain a file equation equating the TITLE file attribute to the file name constant specified
in the global data specification. The file equation should also equate the KIND attribute of
the file to READER.
When more than one task uses the same global data specification as input, each task
begins reading at the start of the deck. WFL also enables you to use local data
specifications, which provide input for a single task only. Refer to “Local Data
Specifications” in Section 5 for a further description of this capability.
A global data specification can appear only in jobs stored in disk files and initiated by a
START statement, or in jobs submitted through card readers.
Note: Global data specifications can occur only in the outer block of a job; that is, they
cannot be declared in subroutines.

Example
The following job uses a global data specification:
?BEGIN JOB SURF/METER;
DATA WAVE/HEIGHTS
% Begin global data specification
3.5
1.2
23.4
?
% End global data specification
RUN (WALLY)SURF/ANALYZE;
FILE WAVEIN(TITLE=WAVE/HEIGHTS,KIND=READER);
RUN (WALLY)SURF/REPORT;
FILE WAVES(TITLE=WAVE/HEIGHTS,KIND=READER);
?END JOB.

4–14

8600 1047–506

Section 5
Task Initiation

Overview
A task is a process that runs in its own stack. This section discusses the various task
initiation statements, task attribute assignments, file equations, task variables, and the
use of local data specifications to provide input to a task.

Task Initiation Statements
Explanation
The following table lists all the WFL statements that initiate tasks. For more information
about a particular statement, refer to Section 6, “Statements.”

Statement

Effect

ADD

Copies files that are not already resident on the destination.