Summary records are held in the event store ZEBRA dynamic memory i.e. in IQ/RQ. All summaries are of the same length and start with the following header words:-
The include file raa_com_subp.inc
has a set of mnemonics for the
headers. If l_summ is a link to a summary record, then code to access it
could look like this:-
include 'raa_com_subp.inc' include 'z.inc' integer status real*8 time, get_double ... status = iq(l_summ + KRAA_ID) time = get_double(l_summ + KRAA_RUN_TIME)
Although the header is fixed (and messing with it will cause RAA to halt with an error message!), the record can be extended at execution time. The record is built from the RAAR 1 bank which is an n-tuple request bank. It is stored in the file raa.dat. See the bank itself for the rules about extending it. Bear in mind that it is meant to generate one record per event (RAA will warn and ignore the excess if it produces more). It can include cuts as a way to eliminate unwanted events; if RAA cannot get a summary record, it ignores the event entirely.
As explained in the overview, RAA will fix up any time disordering by reordering summary records. However there is a potential problem here: minor time errors could cause an event record to be reordered before the permanent records (see section 2.3.2) that apply to it. So RAA cheats if it finds that reordering an event would move it back passed a permanent record, and gives the event's summary record the run time of the permanent record. This cheat is only to the summary - the full data structure is not changed.