Package used to work, no change to code but new environment, fails w/ "Can't locate object method" error

Did you load the MSGStore module first with "use MSGStore;" or "require MSGStore"?

Has the path to this package changed?

Are the permissions on this package set correctly?

"You" don't provide a "use" or "require" statement.    Presumably the perl backend implements/emulates that action.    You simply supply a configuration file which specifies the package name and file path to it to slapd:

slapd.conf :

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include     /usr/local/etc/openldap/schema/core.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral   ldap://root.openldap.org

pidfile     /tmp/slapd.pid
argsfile    /tmp/slapd.args

#######################################################################
# perl database definitions
#######################################################################

database        perl
suffix      "dc=xxx,dc=yyy"
rootdn      "uid=jlw12,dc=xxx,dc=yyy"
rootpw      ZZZ$www

perlModulePath /work/local/scripts/MSGStore.pm
perlModule MSGStore


/work/local/scripts/MSGStore.pm:

package MSGStore;

require v5.8.5;

use Tie::File::AsHash;
    $debug = 3;

sub bind
{
      ...
}
sub modify
{
    return 0;
}

sub add
{
    return 0;
}

sub delete
{
    return 0;
}

sub init
{
    return 0;
}

sub modrdn
{
    return 0;
}

sub search
{
    ...
}

sub compare
{
     return 0;
}

sub new
{
    my $class = shift;
    my $this = {};
    bless $this, $class;
   return $this;
}

sub config
{
    my $this = shift;
    my ( @args ) = @_;
        local $, = " - ";
        print STDERR @args;
        print STDERR "\n";
        return 0;
}

1;

As for path and permissions, there's been no change to these, no.  

I'm not sure, but I would guess the perlModulePath should only contain the path for perl modules, not the actual name.  Give a try like so:
    perlModulePath /work/local/scripts
    perlModule MSGStore
or with a trailing slash on the path:
    perlModulePath /work/local/scripts/
    perlModule MSGStore

In the working version specifies the full path to the file containing the package.   But I'll try it anyway.  Maybe some difference between the Perl's in use (v5.8.5 [working] vs v5.8.8 [failing])

Nope.   No change, same results.    

Aha.    Environmental issue; there's a "use" statement in my Package source file that is causing the Perl compliation to fail.   Apparently there is some issue when the line reading "use Tie::File::AsHash;" is encountered; comment it out (and the code which subsequently uses it) and the failure to find the object method "new" (defined later in the Package source file, of course) ceases.

Unfortunately, I REALLY NEED the code supplied by that Tie::File::AsHash package.   Gotta figure out what's going wrong with that, now.

What's the proper procedure now?   The problem has the same lead-in components, but it's a different problem now.   Should I delete this question and start a new one?  Or leave this one going with a new focus?

I think my previous post addresses that... all perl module paths need to be in the perlModulePath line.  

RE: Adam314:   perl -e 'print join(" ", @INC);'
                          Include the output from the above on the perlModulePath line in addition to the
                          /work/local/scripts directory.

Changed my perlModulePath to include this, no change.

Maybe I'm not getting the correct Perl even though the default is considerably lower than the REQUIRED version, so it isn't seeing the library where Tie::File::AsHash has been installed from CPAN?

OK, took the SampleLDAP.pm that comes with the OpenLDAP code, changed its internal package name so it's the one my configuration is expecting, and replaced my Package source file with that changed version.
Then added to its init code the line "print STDERR join(':',@INC);" and tried running my LDAP server again.

Sure enough, the path printed back bears little resemblence to the one that I get when I run things outside of the OpenLDAP server -- looks like the included path for the Perl v5.8.4 that is the default version on the Zone, not the one I installed to get it up to at least v5.8.5.   Amazing that the "require v5.8.5" statement isn't triggering.    Anyway, time to look at something w/ the paths so we get the right perl interpreter, I guess.

The @INC is not the path to the perl binary used to interpret your perl code.  To view that, use $^X.  
What is the output from this, when run both on the command line, and from within your LDAP server:

#!/usr/bin/perl
print "Binary=$^X\n";
$"=" ";
print "\@INC=@INC\n";

I know that @INC wasn't the path to the Perl executable, but the results that were there were clearly those for the wrong version of Perl, the default version before my installation from Blastwave.   There were several references to directories tied to v5.8.4.

Anyway, and I don't know how this affects things, but I created a symbol PERL=<path to my perl> and
exported this symbol; then REBUILT from the ./configure command the OpenLDAP server.   NOW the
resultant string looks to be right.   So somehow, even though the Blastwave one wasn't there when the
slapd server was built, and the PATH pointed to it for Perl, it took this force feeding to push things thru.
Still some issues, not quite right, but a modicum of progress.

While the "accepted solution" wasn't what was really the problem, it was the hint that identified the problem sufficiently to resolve it.  

For some reason, the build of OpenLDAP was not using the perl intended, resulting in not finding the intended associated CPAN libraries, resulting in a compilation error on the Package and the absence of
a required method when OpenLDAP tried to use the Perl backend code.

In other words, the  path had changed...