System Generation Statements › TASK Statement › TASK Statement Usage

TASK Statement Usage

Effect on DC RETURN NEXT TASK CODE

If a DC RETURN NEXT TASK CODE request is issued and the next task code is assigned the INPUT attribute, the task does not execute until the terminal operator enters data. If a DC RETURN NEXT TASK CODE request is issued and the next task code is assigned the NOINPUT attribute, the task executes immediately.

Associating a Task with a PF Key

You can associate a task with a program function (PF) key by specifying task-code in the form PFn. N must be an integer in the range 1 through 24. At runtime, to invoke a task associated with a PF key, the terminal operator presses the appropriate key.

Location Mode under XA Systems

If the DC/UCF system is running under an operating system supporting the XA feature, tasks should be defined with LOCATION IS BELOW unless all programs invoked under the task have been tested to ensure that they can execute in 31-bit addressing mode.

Specifying MAP

Typically, you specify MAP for the first task to be executed in a pseudo-conversational transaction. In this case, the task's initial program, as defined in the INVOKES PROGRAM parameter (see above), must be a map, and the first field of the map must specify the next task code to be initiated. The field can be a variable data field into which the terminal operator will enter the appropriate task code, or it can be a literal field that contains the task code. If a literal field is used, it must be defined with a MODIFY DATA TAG specification of YES and, typically, with the darkened and protected attributes.

Specifying a TASK PRIORITY

For the following task types, the task-priority specified on the PRIORITY clause is the dispatching priority for the task at runtime:

• A task initiated as a result of exceeding a queue threshold
• A startup or shutdown autotask
• A task initiated as a result of a SET TIMER START TASK statement in a COBOL or PL/I program or a #SETTIME macro in an Assembler program, if no priority is specified in the SET TIMER statement or the #SETTIME macro.

  For tasks associated with a logical terminal, the specified priority is added to the values specified in the PRIORITY parameters in the LTERM statement to determine the priority assigned to the task at runtime. If the sum of the above values is greater than 240, a dispatching priority of 240 is assigned. A task that is initiated in one of the following ways is associated with a logical terminal:

  • The task code is entered by the terminal operator in response to the "Enter Next Task Code" prompt
  • The task is initiated as a result of a previous task specifying a next task code parameter on a DC RETURN statement or #RETURN macro
  • The task is an LTERM autotask

Use of Product Codes

When a task code is different from the product name (for example, TASK IDDTCF INVOKES PROGRAM IDMSDDDC, where IDDTCF differs from IDD, the installation default), the PRODUCT CODE parameter relates the task code to the product. The system adds an entry to the task definition element (TDE), listing the task code, referenced by its product code.

The transfer control facility uses the table to switch to a different session. At runtime, the system first scans the list of task codes, then scans the product codes to identify and transfer control to the product requested by the terminal operator.

Specifying commit and rollback options

You can specify options that control the following commit and rollback behavior:

• The type of journal record written on a commit
• Whether a new local transaction ID is assigned on a rollback continue or commit.

You can control whether a COMT or ENDJ journal record is written on a commit operation in which the database session remains active. Writing an ENDJ can reduce recovery time because less data has to be examined to locate the start of a recovery unit. This benefit applies to online recovery, warmstart, and ROLLBACK and ROLLFORWARD recovery operations. ENDJ is most beneficial in cases where long-running transactions perform relatively infrequent updates between commit operations. In cases where update transactions are committed frequently, writing ENDJ journal records might negatively impact the amount of information journaled because another BEGN journal record has to be written before the first update following a commit operation.

Note: ENDJ journal records are always written when system rununits are committed, regardless of the ON COMMIT option specified.

You can control whether a new local transaction ID is assigned following a commit or rollback operation in which the database session remains active. Assigning a new transaction ID reduces the chance of duplicate IDs should this value wrap within a single cycle of a central version. It also has the effect of recording journal statistics separately by commit recovery unit rather than across all recovery units within a database transaction. You can assign a new ID on a commit operation only if you also specify that an ENDJ checkpoint record be written.

Note: A new transaction ID is always assigned when system run units are committed or rolled out.