L2 meeting at MSU Sept 9, 1997
  (Edmunds, Laurens, Linnemann)

The fraction of the monitoring data that is held by a Worker node is handed off
by  Worker to Admin as part of "answer" for an event that was flagged with the
Monitoring  qualifier

"Monitoring" data consists of 2 parts:
    Monitoring per se   fixed format:
        scalers
        circular buffers
    Alarm messages
        variable number, fixed format

Contents of "The Answer" from worker to Admin:
----------------------------------------------
event number
128 bit L2 answer    
flag saying if all input channels were matched in event number
Number of words for L3 readout list
    (varies: short for std event, longer for Mark and Pass event)
Number of words for Monitoring block
Number of words for Error Message block
    monitoring and error message length normally both 0
    nonzero only for events with Monitoring Qualifier
L3 readout pointers block
    list of VME base addresses and Wordcounts for VBD to read
        event from Worker's memory via Universe chip mapping
Monitoring Block: a current snapshot captured after end of Monitor event
    scalers
    circular buffers etc
Alarm messages
    list of new messages since last Monitor event

Admin and worker need to cooperate to safely tuck this information away
    it eventually needs to go to:
        answer, header, and L3 goes to an area associated with a buffer number
        monitoring and alarm block go to a (single) monitoring and alarm area
    
How Admin guarantees delivery of alarms:
DPM memory for monitoring in separate Monitoring and Alarms blocks:
each has header declaring whether data is fresh or not
    this is filled a the very last instant by Admin
    TCC checks it before and after reading 
    TCC marks the data as read after it has read it
Admin simply repaints then marks the Monitoring area
Admin first checks to see whether the alarm area has been read
    if so, puts new alarm messages in buffer and marks as fresh
    if not, appends new alarm messages
[All this protocol has to be finalized and carefully specified to prevent
inconsistent readings of monitoring data while it is being updated, 
and to guarantee delivery of alarm/error messages.]

 
Test stand at FNAL/UIC

early version
1 crate
2 alpha cards
alpha unix workstation
perhaps MBT cards
perhaps another alpha to serve as test data source

later version
add tcc and bit3 cards
    at point want to test download of constants, "script"
        can start off with defaults downloaded with .exe?
        can write "simple" alpha program to read files over TFTP 
            and load into memory
    at point want to exercise monitoring
        how important is monitoring for cal?  errmsgs?
        may be simpler than global...
    at point want to download fake data

final version
add 2nd crate with global, more MBT's

Q: is another full setup required to stay at MSU 
after delivery of final system?