A Sample Selector Database

To follow the example below, you must further have a selector database file with an entry for our data in the example. There is a default selector.db file installed with any YODA version. To find out where it resides type: yoda-v this will print out somthing like

YODA Version 1.5 from May  2 1997 16:47:31
Search Path is .:/usr/local/yoda

The last item in the search path is where you should look for a selector.db file. You can copy it into your current working directory and modify it to fit your needs. It should contain the DUMMY line listed below for the example to work (the lines starting with # are comments and are ignored by YODA.:

#
# selector.db: YODA's selector database file
#
# NAME DATATYPE CONTAINERTYPE C.SUBTYPE SUBEVENTTYPE S.SUBTYPE BYTEOFFSET [DIM] 
#
DUMMY   ulong   3 0 2050 3 0 16
#
# each line not starting with a '#' defines a SELECTOR, which provides a means
# for a defined data access to the TDAS containerevent/subevent structure from
# the YODA interpreter language. each SELECTOR, if found in the eventstream, 
# becomes the name of a scalar variable (or array, see DIM below), which 
# contains the actual data.
#
# NAME:         a unique string to identify the data. this will also be the
#               name for the YODA variable, which will contain the data.
# DATATYPE:     can be one of  { char , uchar, short, ushort, long, ulong,
#               float, double }. this field determines the datatype as it is
#               to be found in the events
# CONTAINERTYPE:the containerevent-typefield value, which must be matched
#               to select the current containerevent for processing
# C.SUBTYPE:    the containerevent-subtypefield value, which must be matched 
#               to select the current containerevent for processing
# SUBEVENTTYPE: the subevent-typefield value, which must be matched
#               to select the current subevent for processing
# S.SUBTYPE:    the subevent-subtypefield value, which must be matched
#               to select the current subevent for processing
# BYTEOFFSET:   the offset in bytes from the beginning of the subevent's
#               data area, where the data is found. this makes it possible
#               to skip arbitrary amounts of data as well as to define
#               selectors for one subevent, each with a different
#               BYTEOFFSET for addressing heterogeneous datastructures
# DIM:          the dimension of the selector, which means the number of
#               dataitems of type DATATYPE which is to be put into the selector
#               variable. DIM > 0 means selector is an array of type DATATYPE
#               with (at most) DIM entries. for variable-length subevents,
#               the actual length is supplied in the scalar variable 
#               NAME_LEN, with NAME as described above.
#               this field is optional. if left out, a scaler variable 
#               is assumed

This database defines DUMMY as pieces of data, all of type unsigned long (32-bit integer values without sign), identified by the 4-tuple 3 0 2050 3. Refer to the section 3.2 for details. For the moment, just take this information as a given ''tag'' to identify the data in the incoming data stream. The next number (0) means that the dummy-data starts with no offset to its ''envelope'' (i.e. no data is to be skipped). The last number (16) means that DUMMY is a field of (at most) 16 subsequent values (each of type unsigned int).

As this line is sufficient to describe our (dummy) data, we now need a file which contains our analysis task.