G'day ric00015,

A few tangential items:

• I use Tk with v5.18.1: it works fine; that's unrelated to your problem.
• The experimental warnings you're seeing were introduced in v5.18.0 - see "perl5180delta: The smartmatch family of features are now experimental" for an explanation and a way to disable them.
• Writing CORE when you mean CG::CORE2 is not helpful to us; doing this on the command line, in a configuration file or as part of your code, may result in a far worse outcome. Paying attention to detail is important! A simple search on CPAN can tell you whether you've chosen an unused namespace: compare search for 'CG::CORE2' (produces: "No matches") with search for 'CORE' (produces pages of matches).
• Embarking on a major upgrade (of anything) and just walking away for three days while it ran was a poor choice. Do you know what happened in that time? Do you have logs? Did the upgrade complete? Were there power outages or other events that may have caused problems? Your feedback mentions none of these things: we're left to make guesses.
• The issue of not performing backups has already been addressed. You said none were done prior to the upgrade; however, do you have no backups at all? Can you restore state as it existed, say, a few days ago?

With the scant information you've provided, my guess is that the environment used by your upgrade differed, in one or more respects, from the environment used for the initial installation. I don't know what the difference(s) might be. Non-exhaustive possibilities include:

• different user/group permissions (whether changed from the original or the result of running as another user)
• different method used for initial install and upgrade (could be different versions of the same program, e.g. /usr/bin/cpan vs. /usr/local/bin/cpan; different programs, e.g. cpan vs. cpanp; entirely different methods, e.g. cpan vs. a customised shell script with wget .../perl Makefile.PL/make/etc.)
• different environment variables controlling the process: there's a lot of these, see ExtUtils::MakeMaker to get an idea of the number and variety.

You say you installed a new version of Perl (5.18.1): did that overwrite the version used by Red Hat? is that a problem?

Thanks for helping. You have a lot of points, so I'll address them in that order.

Perl 5.18.1 works just as well as 5.16.0. Which is to say that it has the same issues I mentioned earlier. The warnings are merely an annoyance.

I edited the actual names of the modules, scripts, etc because the names may have proprietary information. CG::CORE2 gave me no problems. I just shortened it to CORE for this post. I had no idea there was a module actually named CORE before posting here.

We have no logs, records, etc of what happened, or what we had before. 'r' does show a few modules that have not been upgraded, including DynaLoader. The full list is below. I have a new UPS, so a power outage is out. And no more mass updates for me!

Package namespace         installed    latest  in CPAN file
Alien::wxWidgets               0.62      0.64  MDOOTSON/Alien-wxWidget
+s-0.64.tar.gz
DBI                           1.628     1.630  TIMB/DBI-1.630.tar.gz
DateTime::TimeZone             1.62      1.63  DROLSKY/DateTime-TimeZo
+ne-1.63.tar.gz
Devel::Symdump                 2.10      2.11  ANDK/Devel-Symdump-2.11
+.tar.gz
ExtUtils::InstallPaths        0.009     0.010  LEONT/ExtUtils-InstallP
+aths-0.010.tar.gz
HTTP::Tiny                    0.036     0.037  DAGOLDEN/HTTP-Tiny-0.03
+7.tar.gz
Net::Ping                      2.38      2.41  SMPETERS/Net-Ping-2.41.
+tar.gz
Perl::OSType                  1.002     1.006  DAGOLDEN/Perl-OSType-1.
+006.tar.gz
Perl::Tidy                 20120714  20130922  SHANCOCK/Perl-Tidy-2013
+0922.tar.gz
Sub::Exporter::Progressive  0.001010  0.001011  FREW/Sub-Exporter-Prog
+ressive-0.001011.tar.gz
B                              1.34      1.42  RJBS/perl-5.18.0.tar.bz
+2
B::Concise                     0.89      0.95  RJBS/perl-5.18.1.tar.gz
DynaLoader                     1.14      1.15  NWCLARK/perl-5.8.6.tar.
+gz
Grid::Request::DRM::PBS       undef       0.9  VICTORF/Grid-Request-0.
+9.tar.gz
JSON::PP::Boolean             undef   2.27203  MAKAMAKA/JSON-PP-2.2720
+3.tar.gz
JSON::backportPP::Boolean     undef   2.27203  MAKAMAKA/JSON-2.61.tar.
+gz
657 installed modules have no parsable version number
(use 'o conf show_unparsable_versions 1' to show them)
[download]

I'm not sure about some of your non-exhaustive possibilities. Perl was installed before I even got here, so I'm not sure exactly how he did everything. The original installer may not remember either. But perl 5.16.0 did not overwrite the system perl. (We don't have root access at work. Even if we did, I hear that's just bad practice.) And my 5.18.1 was installed right next to his. In fact, right now, I'm installing a fresh copy of 5.16.0, just to see if it'll work as before.

Update! I just finished installing my fresh 5.16.0 install of perl, as well as a few CPAN modules. It still acts the same way as my updated 5.16.0, and 5.18.1. I am partially convinced that either something central to all installs went bork, or an up-to-date module is causing the problem.

This logic module (called CORE)

And this showed me something very interesting: some of the subroutines were being redefined! 9 of them, in fact, were already loaded and defined; the program is now working properly.

The specific error is Undefined subroutine &Module::subroutine called at /home/path/module.pm line 128, <FILE> line 30.

The full package name is CG::CORE2. I didn't even know about Perl's CORE, and it never interfered.

Subroutine sub1 redefined at /home/path/module.pm line 68.
Subroutine sub2 redefined at /home/path/module.pm line 197.
etc.
[download]

where module.pm is used from CG::CORE2.

sub do_something {
    my $var1 = shift;
    my $var2 = shift;
    my %hash = %{module::subroutine($var1, $var2)};
}
[download]

model::subroutine is supposed to return a hash reference, and exists within the code of module.pm. However, it doesn't seem to be loading all the subroutines of module.pm.

One scenario where the message "Subroutine xyz redefined ..." appears for every function in a Module, is when you have the module on a case insensitive filesystem (such as FAT32) and you required/used it with the wrong case. For example:

# script.pl:
use XML::twig; # wrong case, should be XML::Twig
# some Module used by script.pl:
use XML::Twig;
[download]

If you write it with differing upper-/lowercase, then Perl considers them to be different files. As such loading twig.pm and Twig.pm. This works due to the case insensitive filesystem. Since it is however the same file, and it is loaded twice, it will cause all the functions of the package to be redefined. If you 'use' or 'require' the Module with the proper case, then it is only loaded once, and the error will go away.

You say the error message is:

 Undefined subroutine &Module::subroutine called at /home/path/module.
+pm line 128, <FILE> line 30.
[download]

The filename of a Module should typically be the same as the package name (case sensitive!). Check that the package name matches the filename. Also check that the case of &Module::subroutine is correct. &module::subroutine is not the same as &Module::subroutine.

The way you wrote the message suggests otherwise; I hope it was merely the brevity of the message which creates this perception?

This would be one of the many reasons to make sure you have a clean backup so you can roll back.

(and this is also the reason that my place of work has a strict rule of never making updates to a working system after noon on Friday ... you can fix a problem, but no introducing new stuff on Friday afternoon)

As of right now, we only have one Perl environment (2, if you include the different version I just installed). I didn't think mass updating modules would pose a problem, but I asked the one who initially installed Perl to begin with. Apparently, he didn't see any problems either. Boy were we wrong!

This is what is known as 'experience' :-)

--MidLifeXis