Before integration of these changes I tagged 3_0_BRANCH as lester-20540112d-cambridgePriorToOxfordB3Updates (note my misspelling 2054 instead of 2005).
I then integrated the important changes into 3_0_BRANCH, and then tagged as lester-20050112e-cambridgeAfterOxfordB3Updates.
Testing was done at Cambridge on 3 modules.
Some scans were found to abort (Scan aborted histogramming stalled) at the end of the scan after all the data was (apparently) successfully all extracted.
This was found to be a consequence of a thus-far-unnoticed things-go-wrong-of-you-dont-have-a-module-in-group-0 bug.
The problem was fixed in SctApi/SctApiHisto?.cxx (version 1.106.2.20).
New version to be called 3.2 to avoid confusing 3.1 with 3.01.
3_0_BRANCH was tagged as SctRodDaq_3_2_RC1.
Am trying to create a test release on the based on SctRodDaq_3_2_RC1 based on instructions in BuildingARelease. Note that the part telling you to source the setup_gcc32.sh is online-19 specific and will have to be updated when we come to build releases for online-22, I think.
The release finisheed building and is available at http://www.hep.phy.cam.ac.uk/atlas/macro-assembly/DAQ/welcome.html
Am now testing the binary release -- am keeping a log of tweaks needed to make it run on SctRodDaqReleaseCandidatesFor3.2Testing.