Initialisation

Initialisation of SNOMAN is carried out by a number of routines whose names start with the prefix IN or end with the suffix INI. INMAIN is the top level routine. Initialisation proceeds through 4 distinct phases:-

Core SU Initialisation

INMAIN starts by defining a list of all core software units (SUs). This includes the ZEBRA Memory Manager and Management of Titles. This list is initialised via calls to SU_CALL which in turn calls routines such as INZEBR and MT_INI.

Reading Commands & Titles

Next the user's commands are processed and the JOBP bank is examined to see what additional SUs have to be initialised and a new list formed using SU_ADD. Some SUs require others to be initialised before they themselves can initialise and SU_ADD takes care to order the list so as to allow for these dependencies.

Context Setting

Up to this point there is no well defined context i.e. event date and data type. A context is needed so that SUs can initialise and read the appropriate versions of their titles files. So the new list of SUs is scanned and any that are ``context setters'' called to define an initial context. For example, the event input processor is a context setter, which it does by sneaking a look at the first event.

Active SU Initialisation

Finally, the new SU list is initialised by further calls to SU_CALL.

After all initialisation is complete, ZPHASE is called to tell ZEBRA that the program is entering the operation phase and then control passes to QNEXTE. This is a special KERNLIB (part of the CERN program library) routine that ZEBRA can later call to restore the machine state and start processing the next event; calls to ZTELL requesting the start of a new event eventually transfer control to QNEXTE.