Mark, It turns out that I had inappropriately scoped the variables. As long as the database handle was correctly scoped, it was available for later use. And based upon your recommendation, I did set up external perl routines that were executed with 'do' and was successful in using the database handle.
Somehow, I think there is a need for more articles along the lines of what Jim Brown wrote. What I was doing was just different enough that I could not really make the right connections between programming in Perl vs programming in Perl inside of SEC. Thanks again, Tim Peiffer On 12/10/10 8:19 PM, Tim Peiffer wrote: > How do you expose a database handle in later rules? Do you have an > example using the module method you offer? > > Please advise, > Tim > > On 12/10/10 8:15 PM, Mark D. Nagel wrote: >> On 12/10/2010 6:04 PM, Tim Peiffer wrote: >>> How do I log into a database at startup/reload, and pass the database >>> handle, or expose it to subsequent rules? I have successfully logged >>> into a database and select suitable information. Unfortunately, if I >>> comment out the 'use DBI' and 'DBI->connect', and insert a rule >>> (rule 1) >>> that is caught on a startup internal event, the same lookup fails when >>> dereferencing the database handle. Since the database is defined in a >>> previous rule, it is unitialized at the time of the call in rule 2. >>> >>> How do I pass the database handle from one rule to another? >> I find it easiest to encapsulate all my setup like this in a module, >> then you just do: >> >> # load library module on startup/reload >> type=Single >> ptype=RegExp >> continue=TakeNext >> pattern=(SEC_STARTUP|SEC_RESTART|SEC_SOFTRESTART) >> desc=SEC Initialization >> context=SEC_INTERNAL_EVENT >> action=eval %o (require '/wm/lib/perl/WM/SEC/init.pl'; 1) >> >> In our case, we're loading up that init.pl "module" that sets up >> variables, functions, etc. Each time you reload, it could re-evaluate >> this, in which case 'do' may be better than 'require'. This module can >> setup variables, provide function references, etc. Note that this has >> TakeNext so I can have other unrelated startup rules fire after this one >> if needed. On my home server, I've been working on a slightly more >> flexible model: >> >> type=Single >> ptype=RegExp >> continue=TakeNext >> pattern=^SEC_(?:STARTUP|RESTART|SOFTRESTART)$ >> desc=SEC Initialization >> context=SEC_INTERNAL_EVENT >> action=eval %o (do '/usr/local/lib/MySEC.pl'; MySEC::init(); 1) >> >> type=Calendar >> time=*/5 * * * * >> desc=MySEC Reload >> action=eval %o (MySEC::reload(); 1); >> >> The second rule triggers a function periodically that reloads any >> external data needed by the module. Since I use 'do' here, each reload >> will refresh the code as well. >> >> Regards, >> Mark >> > > -- Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP +1 612 626-7884 (desk) ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
