7 Messages from Subsidiary Tasks

DTASK_SUBSID() is called to check it. Given the PATH and MESSID of the message, the Active Subsidiary Task Action Block (see the TASK library) is searched and the associated action in this task found (or an error). Communications to the parent task for the associated action are set for SUBPAR (SUBPAR_PUTPATH()), then the particular message is handled depending upon the MSGSTATUS.

MESSYS__INFORM

is relayed on to this task’s parent (using SUBPAR_WRITE()).

MESSYS__PARAMREQ

is handled by TASK_ASKPARAM(). It relays the parameter request on to this task’s parent (using SUBPAR_REQUEST() which waits for the MESSYS__PARAMREP reply and returns the value). TASK_ASKPARAM() then returns the value in a MESSYS__PARAMEREP to the subsidiary task.

MESSYS__SYNC

causes this task to synchronise (see Section 9) (in SUBPAR_SYNC()) with its parent and then acknowledge the original message with a MESSYS__SYNCREP to the subsidiary task (using AMS_REPLY()). See

The above are said to be ‘transparent’ messages. If the message is not one of these, the message information is put (TASK_PUT_MESSINFO()) into the Current D-task Action Block in case the associated action requires it later.

If there is a failure in any of the above attempts to relay messages, the subsidiary task is removed from the Active Subsidiary Task Action Block and the action in this task obeyed (DTASK_OBEY()) again.

MESSYS__TRIGGER

causes the associated action in this task to be obeyed (DTASK_OBEY()) as if it were initiated by its parent.

Other MSGSTATUS > 0

is assumed to mean that action is complete in the subsidiary task – the subsidiary task action is cleared from the Active Subsidiary Task Action Block and, again DTASK_OBEY() is called. Failure to relay and other terminations are therefore treated the same.