4 Receiving Control Messages

DTASK_DTASK() firstly calls DTASK_PRCNAM() to get the name by which the task is to register with the ADAM message system. This will be the name set in ICL_TASK_NAME by the controlling task – DTASK_PRCNAM() does not involve the message system. The task then registers with this name by calling AMS_INIT() (from DTASK_INIT()).

A loop is then entered, which continues until a bad STATUS is found. Within the loop most errors will be handled, but an MSP error probably means that no more messages can be sent or received so the task will exit.

Within the loop:

• The path for SUBPAR output is first set to 0 – i.e. the task is not handling a message from another task. There should be no output but if there is it will go to stdout.
• AMS_RECEIVE() with infinite timeout waits for a message – The message may come from a controlling task or user interface, or may be generated internally, by a timeout for example. Certain control messages such as connection requests are handled invisibly by AMS_RECEIVE() but it returns when it receives a normal message (message function MESSYS__MESSAGE), a new transaction is started and the message status (MSGSTATUS) indicates the type of message.
• The message is handled. This may involve sending and receiving further messages as part of the same transaction.
• The transaction is closed by sending a final acknowledgement with an appropriate message status.