>>> On 3/19/2018 at 03:03 PM, "Will, Chris" <[email protected]> wrote: > I ran the upgrade and everything seemed ok until I ran a perl job (in this > case smt-agent). It seems the @INC variable is still pointing to the older > 5.10 version and not 5.18 that comes with SLES 12. Is there any way to > refresh this or reinstall perl to correct this? > > # smt-agent > Can't locate strict.pm in @INC (@INC contains: > /usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 > /usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi > /usr/lib/perl5/site_perl/5.10.0 > /usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at > /usr/sbin/smt-agent line 2. > BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.
SMT is written entirely in perl. As others have said, that looks like at least pieces of the older perl have been left on the system. -snip- > # perl -V > Can't locate Config.pm in @INC (@INC contains: > /usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 -snip0 > Another file that seems identical gives the following which is correct. > > # perl5.18.2 -V > Summary of my perl5 (revision 5 version 18 subversion 2) configuration: > > Platform: > osname=linux, osvers=3.12.61-52.101-default, > archname=s390x-linux-thread-multi -snip- The fact that these two binaries give different results tells us that they are _not_ identical. Running ls -li /usr/bin/perl* will show whether or not the perl name is hard-linked to perl5.18.2 or not. Running md5sum /usr/bin/perl /usr/sbin/perl5.18.2 will show whether or not the contents are identical. Running rpm -V perl will show if anything else is wrong with the package. Just for "fun," running which -a perl show all the executable binaries named perl that are in your $PATH. I would expect to see something like this: # which -a perl /usr/bin/perl /usr/bin/X11/perl Those are actually the same file, since /usr/bin/X11 is a symbolic link to /usr/bin (or should be). I don't think having DB2 on the system would be the cause of this sort of problem, unless the IBM package is doing something _really_ stupid. (Not impossible, but not likely either.) Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
