Perl 5.8.3 is severely old. The system perl (/usr/bin/perl) is probably newer than that. (5.8.8 IIRC, but I don't have an AIX 5 box anymore to check with.) Do you have to use the perl that is inside Oracle for this? I would suggest installing your own perl and using that. I've been regularly building 5.16.0 and 5.17.* ("blead") on AIX 6 and 7 (7 has a minor issue, but I think IBM has fixed it, just waiting to get the fix applied to the system to be sure). Tux has been building on 5.2 and 5.3 fairly regularly as well. This would resolve your first issue. Failing that, you may be able to "install ExtUtils::MakeMaker" - I'm not sure if that will eventually drag in a newer version of perl and then you're back to installing a private perl again anyway as I wouldn't suggest upgrading the perl included with Oracle.
It also looks like you're mixing 32-bit and 64-bit objects. Or at least 32-bit objects when perl might be compiled for 64-bit (which would make sense since the perl that comes with AIX is 32-bit). Again, a recommendation for a private perl: I've had this issue when compiling against the system perl, but never with a private perl.
I'd also be tempted to ask Oracle if they support you installing additional modules to their private perl. I'd somewhat expect a response like "Um, er... what?" which might also give you impetus to use your own perl. I do expect, however, that there should be no problem connecting to Oracle from your own private perl. You shouldn't require Oracle's perl to connect to their db.
| [reply] |
Yes Perl 5.3 is severely old, and yes it is Oracle's private perl in AIX. I am sure they won't support external PMs (except DBD and DBI, or maybe not). I was able to successfully install a couple of external modules like XML::XPath and Net::Stomp to Oracle perl but WWW::Mechanize seems to have a whole lot of dependencies. I can use AIX's perl installation to get Mechanize in, but the problem is the job scheduler we use, uses Perl profile set for Oracle Perl only, so in order to be able to run a program using AIX perl we will end up creating a new profile.
| [reply] |
5.8.3, not 5.3 :-) I'm guessing it already comes with DBI and DBD::Oracle.
Now you're running into a few other issues that take a bit more to resolve. Again, I'll reiterate: install a private perl. And then we can more or less resolve the rest of the issues.
Let's say you install perl 5.16.0. Depending on how your environment is set by the job scheduler, different solutions may present themselves. If, for example, it simply puts Oracle's perl first in the PATH, you can just put your first line to be:
#!/opt/myperl/5.16.0/bin/perl
and everything is fine after that. However, if your code is actually being run directly by a hardcoded-in-the-scheduler perl, that is it's running /u01/oracle/product/10.2.0/perl/bin/perl $yourscript directly, it's a bit more convoluted. My suggestion would be to write a wrapper (in perl 5.8.3 syntax). Roughly something like this:
#! perl
# delete $ENV{...} to clean up the environment if needed
exec {$0} "$0-wrapped", @ARGV;
And then have a -wrapped version of the file with your real code in it that starts with the appropriate line above in it. This will have the job scheduler launching the Oracle perl which then reads this file, and it will then tell the kernel (AIX) to execute another program in its place. The kernel will read the magic number from the new program ("#!") and interpret it as a script that needs interpretation, read the rest of the line for the interpreter, and then run that. So it's a bit of an annoyance, but it should all run quick enough not to be noticed.
And, as a bonus, you'll be able to use the new features in newer perls. Like 5.8.8. :-P | [reply]
[d/l]
[select] |