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).