Management of Titles (see section C.3) is intimately connected to SU control, so, if developing a SNOlib application, you will have to understand this aspect of titles management. During initialisation, some SUs perform preprocessing of their titles data. If their titles change during the course of processing, then they have to be recalled to repeat this preprocessing. In order to do that, the Management of Titles (MTT) system uses SU control to communicate with SUs. On the face of it, as almost all SUs use titles, this seems to imply SU control is unavoidable. In fact this is not the case, the MTT system has been designed to work at two levels, with or without SU control. In both cases the first requirement is to tell MTT the current context (i.e. event). This is done automatically by Event I/O (EIO,INP) and Monte Carlo (MCO), as these SUs redefine the current event. Alternatively the routine MT_SET_CONTEXT can be called directly.
To get the titles up to date, you will have to call MT_UPDATE_MEMORY. This routine works through the titles bank set and updates any that need updating. However, it does not request any reinitialisation of SUs; it is up to you to call them directly if necessary. To help, the mask MTT_SU_RIN_MSK, defined in mtt_com.inc, is set up by MT_UPDATE_MEMORY. This has the SU id bit set if the SU needs updating. The following code fragment puts this all together and shows how to set a context by hand, calling MT_UPDATE_MEMORY and then reinitialising INGEO if it is necessary.
include 'id_data_types.inc'
include 'su_mnemonics.inc'
include 'mtt_com.inc'
integer context, iretc
logical memory_updated, tst_mask
* Set context to : MC SNO data, 12am on 1st Jan 1997.
context(1) = 10 * IDDT_MC + IDDT_SNO
context(2) = 19970101
context(3) = 12000000
call mt_set_context( context )
* Update Titles Memory.
call mt_update_memory( 0, memory_updated )
* If any titles have changed, update GEO if its titles
* have changed.
if ( memory_updated ) then
if ( tst_mask( mtt_su_rin_msk, KSU_GEO ) )
+ call ingeo( KSU_REINITIALISE, iretc )
endif
A few SUs are static i.e. they cannot handle title bank changes during execution. Needless to say, these must not be called as illustrated above, although if their titles do change, something else has already gone wrong. If having to reinitialise several SUs it would be wise to reinitialise them in the correct dependency order i.e. if A and B both need to reinitialise and A depends on B then reinitialise B before A.
In contrast, for SNOMAN applications, SU control makes life much easier; just call the routine MT_SYNCHRONISE. This calls MT_UPDATE_MEMORY but then uses SU control to call all SUs, in the correct order, that need to reinitialise. It even knows not to call statics SUs, instead it generates a ZTELL warning.