Overview | Releases | Download | Docs | Links | Help | RecentChanges

RunNumber

Since tdaq-01-07 we are required to use some kind of fancy spangled run-number server.

See RunNumberOwnServer for instructions on how to create your own standalone run number server.

Within point 1 (tested as sctswinstaller@pc-sct-mon-05) the following seems able to query the "TDAQ Development database":

source /sw/tdaq/setup/setup_tdaq-01-07-00.sh
rn_ls -l -c oracle://devdb10/tdaq_dev_backup -w onlcool

The above was obtained by reverse engineering

/afs/cern.ch/user/i/isolov/www/cgi-bin/rn.pl

The same script indicates also suggests that

rn_ls -l -c oracle://atlas_oksprod/r -w atlas_oks_tdaq

should also generate something interesting within Point 1 ... but I found that command just generated (after a long pause):

[sctswinstaller@pc-sct-mon-05] tdaq > rn_ls -l -c oracle://atlas_oksprod/r -w atlas_oks_tdaq
CORAL exception: Connection string "oracle://atlas_oksprod/r" is not known to the service ( CORAL : "IAuthenticationService::credentials" from "CORAL/Services/XMLAuthenticationService" )
[sctswinstaller@pc-sct-mon-05] tdaq >

Shockingly, the following works OUTSIDE point1 from Cambridge: !!!

[pcfk] /var/pcfl/usera/lester > ssh sctrod@pcei.hep.phy.cam.ac.uk 'source lester-SLC4/camSetup.sh ; rn_ls -l -c oracle://devdb10/tdaq_dev_backup -w onlcool'
Scientific Linux CERN SLC release 4.4 (Beryllium)
Setting up TDAQ Common SW release "tdaq-common-01-05-00"
Setting up DAQ SW release "tdaq-01-07-00"
**** TDAQ_PARTITION is not set.  Although this variable will be ignored by
**** the TDAQ software which will deduce it from OKS, Dave's GUI and 
**** other programs started outside TDAQ will need it.  
**** Attempting to make a guess for it ...
TDAQ_PARTITION being set to "SCT"
Found 3 run number databases:
 - 'NIGHTLY'
 - 'nightly_check'
 - 'p1'
[pcfk] /var/pcfl/usera/lester > 

Comparing at Cambridge the output of:

bash-3.00$ rn_ls -l -c oracle://devdb10/tdaq_dev_backup -w onlcool
Found 3 run number databases:
 - 'NIGHTLY'
 - 'nightly_check'
 - 'p1'

with

bash-3.00$ rn_ls -l -c oracle://atlas_oksprod/r -w atlas_oks_tdaq
CORAL exception: Connection string "oracle://atlas_oksprod/r" is not known to the service ( CORAL : "IAuthenticationService::credentials" from "CORAL/Services/XMLAuthenticationService" )

it seems that there is a magic lookup table somewhere that tells rn_ls where to find the relevant computer to contact for database query. The source of that lookup table seems to be LCG if the follwing circumstantial evidence is anything to go by:

bash-3.00$ find $TDAQ_INST_PATH/.. | grep XMLAuthenticationService
/scratch/tdaq/tdaq-01-07-00/installed/../external/i686-slc3-gcc323-opt/lib/liblcg_coral_XMLAuthenticationService.so
/scratch/tdaq/tdaq-01-07-00/installed/../external/i686-slc3-gcc323-dbg/lib/liblcg_coral_XMLAuthenticationService.so
/scratch/tdaq/tdaq-01-07-00/installed/../external/i686-slc4-gcc34-opt/lib/liblcg_coral_XMLAuthenticationService.so
/scratch/tdaq/tdaq-01-07-00/installed/../external/i686-slc4-gcc34-dbg/lib/liblcg_coral_XMLAuthenticationService.so

Comments from Gio to Martin:

If you need to set it explicitely, then it's true that this is 
not possible, exept by modifying the CLIPS rules for the root
controller. Basically, you need to make a copy of the Root.clips
file in your area (part of package RunControl). Then you need to
modify the rule "defrule sor-message" to read the run number from
IS instead of requesting it from the run number service ( it's
sufficient to comment out the line (bind ?runno
(runnumber-get))). So, it can easily be done, e.g. if you are
running the DAQ with preloaded data which contain already a run
number in the raw data. If this is really needed we could provide
this modified rules file as a patch (or for tdaq-01-08).