What is correct with global variables really depends on the larger picture of what you are trying to do. Generally you want to try as much as possible to return values rather than set global variables. Perl lets you return lists of variables so you aren't limited to a single return value.

sub myFunc { return (1,2,3); }

my @aReturnValues = myFunc();
[download]

Second best is passing in an array or reference as a parameter and stuffing generated values into the array or hash parameter. Although this isn't as easy to maintain as a return value, a parameter at least keeps the data and the thing that changes it closely related. As long as you document that the parameter will be modified, you shouldn't have problems from this. But keep in mind, it is easy to forget to read documentation and also not so easy to keep documentation and code in sync. A return value is better.

The only read/write things that should go into global variables are configuration data that your whole program needs. If possible these should be gathered into larger data structures, e.g. a configuration hash or an application object. You should try to keep the number of read/write global variables very small. You should also carefully limit the functions that can change the global data and give the setter functions names that are easy to search for. If you don't, your code will become hard to maintain because you won't be able to keep track of what functions change which variables.

A final closing question: do you have lots of variables ending in $stringN or $messageN where N is some number? If so, perhaps you should consider putting them into an array of arrays (see perldsc). They would be much easier to keep track of and work with that way:

my @strings;
my @messages;

#process first 65 strings

# loop through the numbers 0 thru 64 inclusive
for my $i (0..64) {

  if(substr($strings[$i][$count],0,2) eq "MY") {
    $messages[$i] = substr($strings[$i][$count],2);
  }

}
[download]

For whatever it may be worth ... when any project that I am working with starts to grow to encompass “multiple .PM files,” I try to start thinking in terms of “Perl objects.”

If I construct my “Perl module” in terms of “it creates and defines a Perl object,” I know that I will get a whole lot of advantages, all at once ...

• I have “a very easy means to get my hands on a very convenient handle” (namely, the object instance...) which gives me simultaneous access both to operative code and an associated, per-instance, block of data.   Every sub that I define now becomes “a method of an object,” which will automagically be given a reference to that object-instance as its first parameter.   This gives tremendous flexibility with regard to how you manage storage, and it also greatly reduces the coupling, or unwanted interference, between the various modules.
• I virtually eliminate the need to mess with “globals,” which of course are probably (IMHO) the single biggest source of “coupling.”   In this scenario, every object has its own private play-pen.   From a purely pragmatic, bug-reducing perspective, that is huge.
• I can coin just as many instances of a particular object as I want, and every one of them will be distinct.