1. This exchange step uses the REVIEW_SCHEDULE_REC form record to display a panel asking the operator for the number of the department whose schedule of performance reviews they want to see.
2. This processing step uses the REVIEW_SCHEDULE_GET procedure to retrieve the performance review schedules for the first five employees in the department. The server that the step uses is defined in the task group.
3. This exchange step uses the REVIEW_SCHEDULE_REC form record to display the performance review schedules. The operator can type a function key to see the schedules for five more employees, or can exit the task. The keywords END BLOCK WORK signal the end of the work done in the block.

Action clauses follow block, exchange, and processing steps and control the flow of work within a task. The exchange and processing steps in this example use the CONTROL FIELD action clause which tests a workspace field and directs task flow depending on the results of the test. The block step in this example uses the REPEAT TASK action clause which causes ACMS to repeat the task. This particular task repeats until the CTRL_KEY field contains " FEXT".

You can define tasks as local or global. Global tasks are the default and can be chained to or called by another task or selected from a menu. Local tasks can be chained to or called by another task, but cannot be selected from a menu.

For security reasons, you might want to define a task as local if the task implements its own customer-specific task selection security and does not rely on the ACMS task access control list mechanism.

3.1 Multiple-Step Task Definitions

When a task definition has multiple steps or an exchange step, you always group those steps into a block step. A block step consists of the following five parts:

• Attributes of the block step
• A conditional to start the block step
• Work done in the block step
• Actions taken as a result of the work done in the block step
• Exception handler actions to recover from task execution errors

You use phrases and clauses to describe each of these parts. Block phrases describe attributes of a block step. Unlike clauses and subclauses, phrases do not end in a semicolon (;). All block phrases are optional.

The work of a block step is made up of one or more processing and exchange steps. Use exchange and processing clauses to describe the work.

You can use block conditional clauses to make initial exchange and processing work dependent on the values of workspace fields.

Use action clauses to describe actions you want to take at the end of a block step, exchange step, or processing step. Action clauses are optional in all step definitions.

Exception handler action clauses let you recover from events or errors that would otherwise prevent the task from executing as expected. Exception handler action clauses are optional in all step definitions.

Figure 3-2 shows the structure of a block step.

Figure 3-2 Block Step Structure

In addition to writing tasks that contain multiple exchange and processing steps within a block step, you can write tasks that contain multiple block steps within a block step. A block step that appears within another block step is a nested block. Figure 3-3 shows a block step that nests three other block steps. In this arrangement, the outer block is the root block. A block step that contains another block step is a parent. Because you can create multiple levels of nested blocks, a parent block is not necessarily also the root block.

Figure 3-3 Nested Block Arrangement

A task definition cannot contain more than one root block. Therefore, to define a task that contains multiple blocks, you must nest blocks within the root block.

ACMS also lets you use a conditional clause at the block step level to structure your task. By using one of ADU's four block conditional clauses (CONTROL FIELD, IF THEN ELSE, SELECT FIRST, or WHILE DO), you can make the flow of the task dependent on the values of workspace fields. Example 3-3 shows an example of a task definition that uses a block conditional clause with nested blocks to direct the task flow.

Example 3-3 Task Definition with Nested Blocks

REPLACE TASK CAR_RESERVATION_TASK DEFAULT SERVER IS CAR_RESERVATION_SERVER; DEFAULT FORM IS CAR_RESERVATION_FORM; WORKSPACES ARE RENTAL_CLASSES_WKSP, CONTROL_WKSP, RESERVATIONS_WKSP, COMPANIES_WKSP, MSG_WKSP; BLOCK WORK WITH FORM I/O IS (1) GET_RENTAL_INFO: EXCHANGE TRANSCEIVE RECORD RENTAL_CLASSES_FORM_REC, RESERVATIONS_FORM_REC SENDING RENTAL_CLASSES_WKSP RECEIVING RESERVATIONS_WKSP WITH RECEIVE CONTROL CONTROL_WKSP; CONTROL FIELD IS CONTROL_WKSP.CTRL_KEY " FEXT" : EXIT TASK; END CONTROL FIELD; (2) CHECK_CAR_AVAIL: PROCESSING CALL VERIFY_AVAILABILITY USING RESERVATIONS_WKSP, ACMS$PROCESSING_STATUS; CONTROL FIELD IS ACMS$T_STATUS_TYPE "B" : GET ERROR MESSAGE; MOVE ACMS$T_STATUS_MESSAGE TO MSG_WKSP.MESSAGE_PANEL; GOTO NEXT EXCHANGE; "G" : GOTO STEP CHECK_CORP_DISCOUNT; END CONTROL FIELD; (3) DISPLAY_ERROR_MSG: EXCHANGE SEND RECORD MSG_FORM_REC SENDING MSG_WKSP; ACTION IS GOTO STEP GET_RENTAL_INFO; (4) CHECK_CORP_DISCOUNT: BLOCK WORK IS IF (COMPANIES_WKSP.CREDIT_CHECK_FLAG = "1") THEN (5) DISPLAY_DISCOUNT_RATE: BLOCK WORK IS PROCESSING CALL RECOMPUTE_RATES USING RENTAL_CLASSES_WKSP, ACMS$PROCESSING_STATUS; EXCHANGE SEND RECORD RENTAL_CLASSES_FORM_REC SENDING RENTAL_CLASSES_WKSP WITH RECEIVE CONTROL CONTROL_WKSP; CONTROL FIELD IS CONTROL_WKSP.CTRL_KEY " FEXT" : EXIT TASK; END CONTROL FIELD; END BLOCK WORK; ELSE (6) PROCESSING NO PROCESSING; ACTION MOVE "DISCOUNT NOT APPLIED" TO MSG_WKSP.MESSAGE_PANEL; EXCHANGE SEND RECORD MESSAGE_FORM_REC SENDING MSG_WKSP; END IF; END BLOCK; END BLOCK; END DEFINITION;

CAR_RESERVATION_TASK is an example of an inquiry task that a car rental agency might use to provide information to customers about the availability of cars on particular dates. The task uses a block conditional clause with a nested block to determine if the customer is eligible for a corporate discount and, if so, what the new rate is.

The task definition contains several block steps within a root block. The workspaces RENTAL_CLASSES_WKSP, CONTROL_WKSP, RESERVATIONS_WKSP, COMPANIES_WKSP, and MSG_WKSP are available to all steps in the task. The default DECforms form used by exchange and processing steps in the task is CAR_RESERVATION_FORM.

(1) is an exchange that uses the RENTAL_CLASSES_FORM_REC form record to display a panel asking the terminal operator for car rental information, and the RESERVATIONS_FORM_REC form record to map the rental data to the RESERVATIONS_WKSP workspace.

(2) is a processing step that uses the VERIFY_AVAILABILITY procedure to check that the type of car requested is available for the date requested. The server that the step uses is defined in the task group.

If the type of car requested is not available for the specified date, control passes to (3), an exchange step that displays a message to the terminal operator.

(4) is a nested block that uses the IF THEN ELSE conditional clause to determine what work to perform. If the value of the CREDIT_CHECK_FLAG field in the COMPANIES_WKSP workspace is 1, meaning that the customer is eligible for a corporate discount, ACMS performs the work in the DISPLAY_DISCOUNT_RATE block step. Because the CHECK_CORP_DISCOUNT block appears within the root block and contains other block steps, it is both a nested block and a parent block.

The processing part of (5) calls the RECOMPUTE_RATES procedure to calculate a corporate discount rental rate. The exchange part of (5) then sends the new rental information to the form for display to the terminal operator.

If the value of the CREDIT_CHECK_FLAG field is not 1, ACMS performs the work associated with the ELSE keyword. The action part of (6) moves the message DISCOUNT NOT APPLIED to the CONTROL_WKSP workspace, and the exchange step sends the message to the form for display to the terminal operator.

Use the BLOCK clause in a task definition to indicate that the task contains a block step. Figure 3-4 shows the structure of the syntax you use to define a block step.

Figure 3-4 Structure of Block Step Syntax

Each phrase and clause described in this chapter is identified according to its type or types, as follows:

• Block step phrase
• Block conditional clause
• Exchange step clause
• Processing step phrase or clause
• Action clause
• Exception handler action clause

The following sections describe these phrases and clauses. The reference section lists these phrases and clauses alphabetically, indicating in parentheses the type of phrase or clause.

3.3 Block Step Phrases

Use block phrases to describe attributes that apply to all the steps in a block step. All block phrases are optional. If you use one or more block phrases, you must precede the first one with the WITH keyword. In addition, do not use a semicolon (;) at the end of a block phrase.

A nested block inherits the attributes that you assign to its parent block. The only attributes that you can change on a nested block are server context and distributed transaction. At run time, when ACMS finishes processing a nested block and returns control to the parent block, the attributes originally assigned to the parent block become effective again.

Table 3-2 lists the block phrases and gives a brief description of each. If you use any of the block phrases listed in Table 3-2, you must define them at the start of a block step before defining the work to be done.

Table 3-2 Block Step Phrases

Phrase	Description
CANCEL ACTION	Describes the processing done when a task cancel occurs.
TRANSACTION	Identifies the block step as a distributed transaction; all work within the block must either complete successfully or be rolled back.
FORM I/O	Declares that exchange steps in a block use DECforms to interface with the terminal.
NO TERMINAL I/O	Declares that exchange steps in a block do not interface with the terminal.
REQUEST I/O	Declares that exchange steps in a block use TDMS to interface with the terminal.
SERVER CONTEXT	Specifies whether or not server process context is retained between steps in a block step.
STREAM I/O	Specifies that the exchange steps in a block step use ACMS streams to interface with the terminal user or other task submitter.

Figure 3-5 shows the structure of the syntax you use in defining block phrases.

Figure 3-5 Block Step Phrases Syntax

Block conditional clauses let you test the values of workspace fields to determine what block, exchange, or processing steps to perform. Block conditional clauses are optional, but they significantly increase your ability to structure ACMS task definitions. Block conditional clauses can appear only at the top of the block step. Table 3-3 lists the block conditional clauses and gives a brief description of each.

Table 3-3 Block Conditional Clauses

Clause	Description
CONTROL FIELD	Names a text workspace control field that ACMS tests before doing block, exchange, or processing work.
IF THEN ELSE	Specifies a Boolean expression that ACMS tests before doing block, exchange, or processing work.
SELECT FIRST	Specifies one or more Boolean expressions that ACMS tests before doing block, exchange, or processing work.
WHILE DO	Specifies a Boolean expression that ACMS repeatedly tests. As long as the expression evaluates to true, ACMS performs the corresponding block, exchange, or processing work.

The CONTROL FIELD block conditional clause lets you test a value, and, based on that value, perform a block, exchange, or processing step. The IF THEN ELSE clause lets you branch to one of two steps, depending on the result of a Boolean expression.

The SELECT FIRST clause can test multiple Boolean expressions. The WHILE DO clause lets you create a loop where ACMS performs the block, exchange, or processing work as long as the specified Boolean expression holds true.

Figure 3-6 shows the syntax you use to define block conditional clauses.

Figure 3-6 Block Conditional Clauses Syntax

ACMS lets you use only one type of I/O per task. Therefore, any exchange or processing work that a block conditional clause uses must be consistent with the forms product that the block step uses. For example, if you assign the FORM I/O attribute to a block, meaning that the block uses DECforms, exchange steps within that block cannot use TDMS clauses (READ, WRITE, or REQUEST); and processing steps cannot use REQUEST I/O.

Because ACMS lets you nest blocks, you can nest block conditional clauses to test for multiple conditions before performing any exchange or processing work. Figure 3-7 shows a sample structure that nests a SELECT FIRST block conditional clause within an IF THEN ELSE block conditional clause.

Figure 3-7 Block Conditional Clauses with a Nested Block

Exchange steps handle interaction with the terminal user and typically use DECforms form records. The clauses you use for an exchange step describe the work to be done in that step. There are no phrases that declare special attributes of exchange steps as there are for processing steps.

Table 3-4 lists the exchange clauses and gives a brief description of each.

Table 3-4 Exchange Step Clauses

Clause	Description
Conditional
CONTROL FIELD	Names a text control field that ACMS tests before doing work for the step.
IF THEN ELSE	Specifies a Boolean expression that ACMS tests before doing work for the step.
SELECT FIRST	Specifies one or more Boolean expressions that ACMS tests before doing work for the step.
WHILE DO	Specifies a Boolean expression that ACMS repeatedly tests. As long as the expression evaluates to true, ACMS performs the corresponding work.
Unconditional
NO EXCHANGE	States that no output or input is done in the exchange.
READ	Transfers information from the terminal exception line to a task workspace.
RECEIVE	Transfers information from DECforms form data items to a task workspace.
REQUEST	Names a TDMS request that handles interaction between the user and the task.
SEND	Transfers information from a task workspace to DECforms form data items.
TRANSCEIVE	Combines SEND and RECEIVE operations in that order.
WRITE	Transfers information from a task workspace to the terminal exception line.

RECEIVE, SEND, and TRANSCEIVE are DECforms clauses; READ, REQUEST, and WRITE are TDMS clauses. ACMS lets you use only one type of I/O per task. Therefore, if you specify FORM I/O at the block step level, exchange steps within that block step cannot use TDMS clauses. Likewise, if you specify REQUEST I/O at the block step level, exchange steps within that block cannot use DECforms clauses. The default I/O method for exchange steps is REQUEST I/O.

Define the work of an exchange step conditionally or unconditionally. To define conditional work, you must include one of the following unconditional clauses in a CONTROL FIELD, IF THEN ELSE, SELECT FIRST, or WHILE DO clause:

• NO EXCHANGE
• READ
• RECEIVE
• REQUEST
• SEND
• TRANSCEIVE
• WRITE

The CONTROL FIELD clause lets you test a text value and, based on that value, do work in an exchange step using one of the unconditional exchange clauses.

The IF THEN ELSE clause branches to one of two unconditional clauses depending on the result of a Boolean expression.

The SELECT FIRST clause allows you to test multiple values using Boolean expressions. If ACMS encounters a Boolean expression that is true, it performs work in an exchange step using one of the unconditional exchange clauses.

The WHILE DO clause lets you create a loop. As long as the specified Boolean expression holds true, ACMS performs the corresponding unconditional exchange clause.

Figure 3-8 shows the syntax you use to define an exchange step.

Figure 3-8 Exchange Step Clause Syntax

An exchange step can include only one exchange clause to do work for the step. If the exchange step starts with a condition test, there can be only one exchange clause for each value in the CONTROL FIELD, IF THEN ELSE, SELECT FIRST, or WHILE DO clause that creates the condition.

The action part of the step can include action clauses that describe what action you want ACMS to take once the work of the exchange step is done. Action clauses are explained in Section 3.8.

A task that is to be called from a remote node must do all its I/O in exchange steps and not in processing steps. For I/O restrictions on tasks to be accessed remotely, see Section 3.11.

3.6 Processing Step Phrases and Clauses

Processing steps handle the processing work for a task, such as computation and reading from or writing to a file. To do this work, a processing step uses one of the following:

• Called subroutine in a procedure server
• Called task
• OpenVMS image
• DCL command or procedure
• DATATRIEVE command or procedure

If you use a processing step to call a task, you can pass workspaces to that task for read, write, or modify purposes. When the called task completes, ACMS returns control to the calling task, and execution continues with the action part of the calling step.

A routine or called task can return a status value to a calling task. The calling task can use this value, or the contents of a task workspace field can be modified by the routine or called task to control subsequent task execution. The called task and the calling task must reside in the same task group.

For more information on calling tasks from processing steps, see CALL TASK Clause (Processing) in Section 3.12 , and Compaq ACMS for OpenVMS Writing Applications .

In a multiple-step task, different processing steps can use different servers and different types of servers. However, a task can retain process context only within one server at a time, unless the processing steps are part of a distributed transaction.

Use processing step clauses to describe the work done in a processing step. You can also use optional processing step phrases at the start of a processing step to describe characteristics of the step. Processing step phrases are similar to block step phrases.

Table 3_5 and Table 3-6 list the processing phrases and clauses and give a brief description of each.

Table 3-5 Processing Step Phrases

Phrase	Description
TRANSACTION	Identifies the processing step as a distributed transaction. All work within the processing step must either complete successfully or be rolled back.
NONPARTICIPATING SERVER	Instructs ACMS to exempt the server from participating in a previously declared distributed transaction.
[NO] TERMINAL I/O	Declares whether or not the processing step communicates with the terminal.
REQUEST I/O	Names TDMS as the means of communication between a processing step and the terminal.

Table 3-6 Processing Step Clauses

Clauses	Description
Conditional
CONTROL FIELD	Names a text field that ACMS tests before doing work for a processing step.
IF THEN ELSE	Specifies a Boolean expression that ACMS tests before doing work for the step.
SELECT FIRST	Specifies one or more Boolean expressions that ACMS tests before doing work for the step.
WHILE DO	Specifies a Boolean expression that ACMS repeatedly tests; as long as the expression evaluates to true, ACMS performs the corresponding work.
Unconditional
CALL [PROCEDURE]	Names a procedure that ACMS uses to do work for a processing step.
CALL TASK	Names a task to be called by a processing step.
DATATRIEVE COMMAND	Names a DATATRIEVE command to do the processing work for a processing step.
DCL COMMAND	Names a DCL command to do the processing work for a processing step.
IMAGE	Names an OpenVMS image to do the processing work for a processing step.
NO PROCESSING	States that no processing is done in a processing step.

The work you define in processing steps must be either conditional or unconditional. Defining conditional and unconditional work is described in Section 3.5.

Figure 3-9 shows the syntax you use to define a processing step.

Figure 3-9 Processing Step Syntax

Once you use processing phrases and clauses to define the attributes and work of a processing step, you can use action clauses to describe the actions to take at the end of the step. These clauses are described in Section 3.8.