The system automatically provides several task variables, called predeclared task variables, for use by a process. The process can use these task variables to access task attributes of certain related members of the process family.

MYSELF Task Variable

A process can access its own task attributes by way of the predeclared task variable MYSELF.

MYSELF has a special meaning for processes that are descendants of CANDE or MARC sessions. For more information, refer to Tasking from Interactive Sources.

MYJOB Task Variable

A process can use the predeclared task variable MYJOB to access the task attributes of its job. When a job uses MYJOB, it has the same meaning as the MYSELF task variable.

If a BDBASE task, or a descendant of a BDBASE task, uses the MYJOB task variable, MYJOB does not refer to the BDBASE task. Instead, MYJOB refers to the independent process that is the eldest ancestor of the BDBASE task and, therefore, the real head of the process family. In other words, MYJOB refers to the job.

MYJOB has a special meaning for processes that originate from CANDE or MARC sessions or from an ODT. For more information, refer to Tasking from Interactive Sources.

Exception Task

Every process has an associated exception task with which it has a special relationship. There are two aspects to this relationship:

The parent of a dependent process is the default exception task of the process. An independent process, by default, is its own exception task; however, in this case, the exception task relationship embodies only the second of the aspects in the previous list. The EXCEPTIONEVENT of the independent process is not caused when the status of the independent process changes.

A dependent process can use the EXCEPTIONTASK task attribute to access the task variable of any of its ancestors. The process can specify EXCEPTIONTASK repeatedly to access ancestors two or more generations back (for example, the grandparent, great-grandparent, and so on). The following statement assigns an attribute to the grandparent of the process:

MYSELF.EXCEPTIONTASK.EXCEPTIONTASK.SW1:= TRUE;

A process can override the default exception task and assign a different process as the exception task. The following ALGOL statement specifies that the process identified by the task variable TVAR be treated as the exception task:

MYSELF.EXCEPTIONTASK:= TVAR;

The process assigned as the exception task must be the process itself or an ancestor, sibling, or cousin of the process. The exception task cannot be a descendant of the process. An attempt to assign a descendant as the exception task results in the error “UP LEVEL TASK ASSIGNMENT.”

It is recommended that only the process itself or one of its ancestors be assigned as the exception task. If a sibling or cousin is assigned as the exception task, then any attempt to access the exception event of the exception task causes a “NON ANCESTRAL TASK REFERENCE” error. For example, in such a situation, the following statement would cause an error:

CAUSE (MYSELF.EXCEPTIONTASK.EXCEPTIONEVENT);

Assigning a process that is not the parent as the exception task can also have more subtle side effects. Suppose the task is called T and the parent contains a statement such as the following:

WHILE T.STATUS GTR VALUE(TERMINATED) DO
     WAITANDRESET(MYSELF.EXCEPTIONEVENT);

This statement causes the parent to wait until its exception event is caused, at which point it checks the status of T. If T has terminated, the next statement in the parent is executed. If T has not terminated, the parent goes back into a waiting state.

The problem is that, if a parent is not also the exception task for its offspring, then any changes in the offspring's status do not cause the parent's exception event. Instead, changes in the task's status cause the exception event of the process assigned as the exception task. Therefore, the parent continues waiting indefinitely, regardless of any changes in the task's status.

Sometimes, however, it is not desirable for the exception event of a process to be caused whenever the status of any of its offspring changes. For example, the process might be waiting for a HI (Cause EXCEPTIONEVENT) system command. In this case, each of the offspring could be assigned itself as its exception task. This assignment prevents any of the offspring from accidentally causing its parent's exception event.

The MCS that controls a session is the parent of any tasks initiated from that session. By default, therefore, the MCS is also the exception task for any tasks initiated from that session.

Partner Processes

The partner process is the process specified by the task-valued task attribute PARTNER. For a synchronous process, the default value of this attribute is the initiator. However, a process can assign any task variable to this attribute. A process can use the PARTNER task attribute as a convenient means of accessing the task attributes of the partner process. For example, the following ALGOL statement assigns a value to the TASKVALUE task attribute of the partner process:

MYSELF.PARTNER.TASKVALUE:= 3;

The partner process has a special significance for coroutines. For details, refer to “Continuing the Partner Process” in this section.

Other Task Variables

A programmer can make it possible for two sibling or cousin processes to access each other's task variables by declaring the task variables in a common ancestor of the two processes. Internal processes can access task variables that are declared globally in the same object code file as the internal procedure declaration. Task variables can also be passed as parameters to offspring processes.

Private Processes

A private process is a process whose task attributes cannot be altered by any of its descendant processes. Assigning the private process option to the OPTION task attribute causes the process to become a private process. Any descendant process that attempts to access the task attributes of a private process is terminated with the error “NON OWNER WRITE ACCESS OF A PRIVATE TASK.”

Both CANDE and MARC are private processes.