<wait statement>

── WAIT ───────────────────────────────────────────────────────────────►
──┬────────────────────────────────────────────────────────────┬───────┤
  └─ ( ─┬─<string expression>── , ──<wait specification>─┬─ ) ─┘
        ├─<string expression>────────────────────────────┤
        └─<wait specification>───────────────────────────┘

<wait specification>

──┬─ OK ──────────────────────────────────────────────────┬────────────┤
  ├─<real expression>─────────────────────────────────────┤
  ├─<task identifier>─────────────────────────────────────┤
  ├─<task state>──────────────────────────────────────────┤
  ├─<simple task relation>────────────────────────────────┤
  ├─<task mnemonic comparision>───────────────────────────┤
  ├─<task identifier>── ( ──<Boolean task attribute>── ) ─┤
  └─ FILE ──<file title>── IS ── RESIDENT ────────────────┘

<simple task relation>

──<task identifier>── ( ─┬─<integer task attribute>─┬─ ) ──────────────►
                         └─<real task attribute>────┘
──<real relation>──<real expression>───────────────────────────────────┤

Explanation

The WAIT statement enables the job stack to suspend execution until specified conditions are met. The following t options are available in the WAIT statement.

WAIT and WAIT (<string expression>)

The simple form of the WAIT statement causes the job stack to wait for its own exception event. If a string expression is used, it is displayed (up to a maximum of 430 characters) on the ODT. The WAIT statement accepts up to 1799 characters.

WAIT (OK)

The job stack is suspended until an OK is entered from the ODT.

WAIT (<real expression>)

The job stack waits the specified number of seconds and then resumes execution.

WAIT (<task identifier>)

The job stack waits until the task is completed. This statement has no effect on the task when the value of the STATUS attribute for the task is BADINITIATE, TERMINATED, or NEVERUSED.

WAIT (<task state>)

The job stack waits until the task is completed or achieves the given state. This statement has no effect on the task when the value of the STATUS attribute for the task is BADINITIATE, TERMINATED, or NEVERUSED.

WAIT (<simple task relation>)

The job stack waits until either the task is completed or the task attribute satisfies the relation. The job stack waits for its own exception event. The job does not resume execution until this event is caused and one of the previously mentioned conditions is met.

The exception event of the job can be caused by the following:

The real expression in a simple task relation cannot contain another reference to a task identifier.

WAIT (<task mnemonic comparison>)

The job stack waits until the comparison is satisfied.

WAIT (<task identifier> (<Boolean task attribute>))

The job stack waits either until the task is completed or until the Boolean task attribute is TRUE.

WAIT (FILE <file title> IS RESIDENT)

The job stack waits until the file is resident. If the file is absent, a “NO FILE” condition displays.

The exception event of the job need not be caused for this form of the WAIT statement to be completed.

Examples

The following examples illustrate the WAIT statement.

The simple form of the WAIT statement causes the job task to wait for its own exception event to be caused. The WFL job can then wait for several conditions because each condition can cause an exception event. For example:

DO
  WAIT   % wait for exception event
UNTIL ( T1 IS COMPLETED OR
        T2 IS COMPLETED );

To test for several conditions without relying on an exception event, you must use a WAIT (<real expression>) to wait a specified number of seconds before testing the conditions. For example:

DO
  WAIT(60)   % check condition every 60 seconds
UNTIL ( T1(ACCUMPROCTIME) GTR 1000 OR
        FILE A IS RESIDENT );

When a WAIT statement includes a <task state> option, the job stack waits until the task is completed or achieves the given state. This statement has no effect on a task when the value of the STATUS attribute for the task is BADINITIATE, TERMINATED, or NEVERUSED. Therefore, the following statement does not wait if the STATUS attribute is BADINITIATE, TERMINATED, or NEVERUSED. Otherwise, the statement waits until the STATUS attribute for the task is completed:

WAIT (T1 IS COMPLETED)

When a Boolean expression contains a <task state> with an IS, then the condition is TRUE only if the task variable is in the specified state. If the value of the STATUS attribute for the task is BADINITIATE, TERMINATED, or NEVERUSED, then the <task state> Boolean expression with IS always yields a FALSE value. Therefore, the following statement always waits until the STATUS attribute for the task is completed:

DO WAIT UNTIL (T1 IS COMPLETED)

The following are examples of WAIT statements:

WAIT (OK)

WAIT ("NEXT EVENT NOT HAPPENED", OK)

WAIT (30)

WAIT (TSK)

WAIT (TSK IS ACTIVE)

WAIT (TSK (TASKVALUE) EQL 9)

WAIT (TSK (STATUS) IS TERMINATED)

WAIT (TSK (SW1))

WAIT (FILE A IS RESIDENT)

If a WFL job processed an ALGOL task and is waiting, the exception event can be caused in the ALGOL task. For example, the following WFL statements process an ALGOL task and then wait for the TASKVALUE of that task to reach a certain value:

PROCESS RUN X[T];
WAIT (T(TASKVALUE) = 10);

The following ALGOL statements are from the program X, which is referenced in the previous example. These statements set the TASKVALUE to 10 and then cause the exception event of the WFL job. By causing the job exception event, the task enables the job to detect the fact that the TASKVALUE has changed.

MYSELF.TASKVALUE := 10;
CAUSE(MYJOB.EXCEPTIONEVENT);