C For “old” programmers

 C.1 Introduction to the changes
 C.2 Linking old-style tasks
 C.3 NEEDS list checking
 C.4 DTASK_RPON and DTASK_RPOFF
 C.5 DTASK_ASTSIGNAL and DTASK_TSTINTFLG
 C.6 TASK_ASTMSG ( NAME, LENGTH, VALUE, STATUS )
 C.7 Multiple calls to TASK_ASTSIGNAL, TASK_ASTMSG
 C.8 AST enabling and disabling
 C.9 Message reschedules
 C.10 Timeout on AST and message reschedules
 C.11 Closing down the Parameter system – Global associations

C.1 Introduction to the changes

C-tasks, CD-tasks and D-tasks are now “unfashionable”, but are supported for the time being. That is, all existing ADAM tasks should continue to behave as they did under ADAM V1, except for the following two features.

Firstly, an OBEY to a task will no longer be rejected on the grounds that its NEEDS list is not satisfied. See section C.3 for more details.

Secondly, the VALUE string is only guaranteed to contain the parameter string for the OBEY on first entry to ACT. If the action is rescheduling, the VALUE string will not have retained the parameter string for subsequent entries.

Note that D-tasks are now free to use ERR and MSG and to send messages to other tasks whenever they feel like it (except inside AST routines!).

The characteristics of the new-style “instrumentation" tasks are as follows:

The following sections list all the changes.

C.2 Linking old-style tasks

Old-style D-tasks and CD-tasks may still be linked using DLINK and CDLINK. After re-linking they will use the new fixed-part and exhibit the new behaviour, particularly the improved error reporting. Furthermore, future changes to the fixed-part will be incorporated automatically via a shareable image.

DLINK and CDLINK have the same parameters as ILINK. Procedures DNOSHR and CDNOSHR are withdrawn.

C.3 NEEDS list checking

The fixed-part will no longer reject an OBEY or CANCEL on the grounds that the parameters specified on the NEEDS list do not have suitable values. The only significance of NEEDS lists in ADAM V2 is to specify the order of any command-line parameters – NEEDS constraints no longer have any effect.

C.4 DTASK_RPON and DTASK_RPOFF

These no longer do anything. The fixed-part automatically enables reporting back to whatever process issued the GET/SET/OBEY/CANCEL currently under way.

C.5 DTASK_ASTSIGNAL and DTASK_TSTINTFLG

These routines are being phased-out. TASK_ASTSIGNAL and TASK_TSTINTFLG, which have the same arguments and functionality, should be used instead. The DTASK_ calls will continue to work for the time being.

C.6 TASK_ASTMSG ( NAME, LENGTH, VALUE, STATUS )

This is a new routine, similar in function to TASK_ASTSIGNAL, but allowing a message of length LENGTH to be passed in the character string VALUE. When the main-line code is rescheduled it can extract the message from VALUE.

C.7 Multiple calls to TASK_ASTSIGNAL, TASK_ASTMSG

It is now possible for an AST handler to make multiple calls to TASK_ASTSIGNAL and TASK_ASTMSG during a single execution. The information carried in the call is now sent as a message (rather than entered in a COMMON block) and so the last call does not overwrite the earlier ones.

C.8 AST enabling and disabling

The DTASK fixed-part no longer re-enables ASTs, and the various AST events (timed reschedules and AST reschedules) no longer disable ASTs. This means that execution of outstanding AST handlers is no longer delayed while the main-line code tidies-up from earlier events.

C.9 Message reschedules

The TASK library makes it possible for a task to send an OBEY to another task, and then request the fixed-part to reschedule this action on receipt of the final acknowledgement from the other task. The fixed-part automatically handles message forwarding from the other task.

C.10 Timeout on AST and message reschedules

If the application sets RETVAL and then returns with STATUS requesting an AST or message reschedule, the fixed-part will also set a timed reschedule for the time indicated in RETVAL. If the AST or message event happens first, the timer is cancelled. Implications of this are that if the application has been “accidentally" setting RETVAL in the past, it will now set up a timer, and alternatively, if a single action has been managing to set up multiple timers for itself, it will now only be able to have one outstanding at any one time.

C.11 Closing down the Parameter system – Global associations

The parameter system does not close-down when an instrumentation task action completes. This means that parameters retain their values and remain “active", rather than being returned to the “ground" state. It also means that instrumentation tasks never write global associations. This behaviour is similar to the behaviour for D-tasks, but unlike the behaviour for CD-tasks.