From D.Box, wrt testing:
That plus your Makefile changes should be all we need, right?
There might be some perl, python, or shell scripts that depend on $ORACLE_HOME. At one time the code used perl_dbd_oracle which was a build of the DBI interface for perl. I don't know if it still uses that anywhere.
Scripts using $ORACLE_HOME
- mcProduction (defines it!)
- cdfopr lots of scripts
- ??TriggerDBCode/java/classes ???
- Production/create_tarball
- Level3/calib/DB_EXPORT, Level3/Level3, Level3/utils
- DataFileDB/scripts/
- CalibDB/scripts/truncate_db.pl
- Beamline/scripts/create_beam_tarball.csh
Also for perl_dbd_oracle: http://cdfcodebrowser.fnal.gov/CdfCode/search?v=6.1.6&string=perl_dbd_oracle
Did we have any procedures in place for testing?
We used to have a nightly build with a 'test' target. I know a lot of the oracle infrastructure that it used no longer exists, for instance the test programs connect to a validation oracle instance which no longer exists. And the test target used perl_dbd_oracle to do database setup and teardown , which won't work with oracle_instant_client without a little (maybe a lot of) fiddling.
I would recommend we rebuild everything with the instant client, run all our apps (TrgSim++, ProductionExe, etc) against the database with environment variable DB_DEBUG set to -1 to get a dump of what was read back, and compare it with a dump of our current production set to run against the same database.
Update: 22-Feb-2010 14:37
I ran ProductionExe from both 6.1.4mc and 6.1.4mc.migrate on fcdflnx4 with DB_DEBUG set to -1 and NEVENTS set to 3. The log files include huge numbers of Oracle connection messages, and they do not differ except in dates and timings and directories. The data file was /cdf/spool/belling/bhel0d_sample.pad
From R. Culbertson: 18-Feb-2010
I found 2 differences in shared object structure which broke the MC tarball scripts. Getting past that, I find the oracle_instant_client breaks more of the scripts (it is completely different from oracle_client). However I don't see why the script is tarring up from oracle what it is, and why it is so version specific. I commented that out for now since it will take a while to be precise about it, and now I have tarballs. I put it at 90% chance we didn't need the oracle part anyway. I left the exe's unstripped for now in case we have immediate crashes./cdf/proj/128.monte_carlo/builds/test_sl*
Tomorrow I will continue to try to run a few events unless one of you can take over.
If you have a plan, please proceed, if not, I suggest running ~100 events locally in sandbox mode (use source_me, not setup cdfsoft2) and if that works, then strip exe's and submit ~100K to caf.
But then
I was wrong - it needs oracle stuff. I may be able to solve this quickly, so no need to consider going back to oracle_client yet.