THIS MORNING (Start an) informal discussion to -Clearly identify all open issues, categorize them and build an action plan -Possibly identify (new) contributing people to help attacking each problem -Make a plan, specifically setting dates for dry runs (to be expanded and continued offline...)

RUN CONTROL INTEGRATION, INITIALIZATION, ETC. - Is the system initialization complete and reliable? - Do we need new features in the run control? - Does the present XML file configuration scheme require some change (e.g. incremental file handling, tolerance on missing parameters, etc.) ? - Are the informations available in the run database enough (e.g. number of triggers in the burst and other EOB information)? - Do we need more tools, besides the web page, to query/write information to/from this database (e.g. burst data quality flags written by offline reprocessing)?

TDC/TEL62 GENERIC SYSTEM - Do we have evidence of any hardware failures? - Are clock phase settings completely defined? - Which input rate limitations were observed? - Which (instantaneous/integrated) rate measurement do we have at our disposal? How is this information used? - Which is the hit distribution model (in time and among channels) for CEDAR, CHOD, CHANTI, RICH, LAV? - Which are the known limitations in the FW? - Which trigger rate limitations were observed? - Which output rate limitations were observed? Up to which data rate towards the farm was the system tested? - Is all required diagnostics information recorded in the EOB? Or elsewhere? - Are all possible errors logged? How should we keep the log information across bursts?

- Which kind of errors are possible during a burst? Are all errors conditions recorded? How should the system react to such errors? Which ones must be fatal and which ones are allowed to be handled within the system to avoid stopping the data taking? - How does the system fail (input data, trigger) when it is overloaded beyond design specs? How should the data input be limited in this case? - How to monitor the possible data loss due to the filling of the TDC single-channel buffer for a single-channel instantaneous rate peak? For which systems can this occur (channel signal shapes and dead times for each detector)? - Is some online data processing (e.g. channel remapping, time offset subtraction) required at the beginning of the DAQ chain? Both for the main data flow and the trigger primitive generation input? - Do we still have FW compilation issues in different places? - Do we have solid evidence of change in functionality depending on compilation? Can implement incremental compilation to avoid it?

OTHER DAQ SYSTEMS - What is missing for the integration of the other DAQ systems (STRAWS, GTK, SAC/IRC) in the common framework? - Do we have at present any evidence of any limitation in the LKr readout? - Which kind of error monitoring and data checking is available there?

DIGITAL TRIGGER - How deeply was the trigger generation primitive FW tested, and how? Up to which data input rate? - Which monitoring information are available from the primitive generation FW (in EOB)? - Communication between TELs: hardware? Common FW? Specific FW for LAV and RICH? - LKr trigger: how far was it tested and how? Which kind of diagnostics/monitoring do we have available from it? L0TP - Which are the intrinsic limitations of the L0TP(s)? - Which kind of diagnostics is available to verify the correctness of the number of triggers sent? - Are all the useful informations made available from the L0TP to the offline data? Does the farm processing need to exploit part of these?

DATA AND FARM - What is missing to perform a detector time alignment in a fast and stable way? - Which kind of diagnostics is available to check data integrity? Internal data consistency? Consistency between detectors? Lack of data transmission failures? When is such information used? When is a burst marked as bad? - Which kind of errors were identified in data? Do we have the tools to identify the source or the errors? - Do we have a common official automatic checking routine? When and where is it run (e.g. L1)? Who maintains it? How are shifters informed? - Is it useful to extract some informations from the EOB events to fill/update a database? Where and when should this be done?

L1/L2 - Where is the information on the version and cuts performed in L1/L2 for a given run stored and made available? - Do we have a procedure to process (offline) the collected data through L1 and L2? - Do we have a procedure to process the MC data through L1 and L2? - Do we have a flexible downscaling mechanism in L1/L2? Where are the settings for it set/recorded? RECONSTRUCTION/MONITORING - Do we have a standard official reconstruction code? - Do we have a standard official online version to be used for online monitiring? How should this be improved? - Do the existing programs need further integration?

TESTS - Which tools are available to stress the system as a whole without beam? What else is needed and how can it be implemented? - Which significative test procedures can be performed without beam? - Which is the best and most effective schedule for collective tests at CERN in the incoming weeks? What should be tested when?