There are several alternative one line changes that do what you ask, such as:

• Declare $glbA and $glbB with our in functions.pl
• Refer to those variables in functions.pl with the fully qualified $main::glbA and $main::glbB
• no strict "vars"

But none of the above is recommended. You would be much better in most scenarios to make functions.pl a package, and pass lexical variables as parameters to its functions.

sub procedureA {
  print $main::glbA;
}

sub procedureB
{
  print $main::glbB;
}
[download]

I had a very similar problem. This thread came up first in search resultes, but it didn't help me to understand the problem better. I'm sharing my experience here so that it may help the next person who finds this page in search results.

The thread that helped me most is Variable Scoping in Perl: the basics

The key is paying attention to the difference between the scope and the package. When you use my, it only declares a variable in the current scope, not in the current package. So, variables in a module that are declared with my in that module aren't accessible using the package name of the module, e.g. $main::var1.

To declare variables in the current package and the current scope, use our.

In my case, I wanted a global $logfile variable that I could reference in my module, but I wasn't able to access the main script's $logfile variable from the module's subroutine even if I used the fully-qualified name.

The solution that worked best for me is to set $ModulePackage::logfile whenever I set the $logfile variable in the main script. I could have as easily declared the our $logfile in the main script, but then I would have had to use the fully-qualified name in the module.

Also see package variable scope in module subroutine @ StackOverflow.

I'm not sure that I understand your question, since in your example the use of globals should be very easy, but if you want to multi-fork(thread?) your package, then possible this will help. In Unix/Linux, I use this technique:

#!/usr/local/bin/perl -w
# Server.plx

use warnings;
use strict;

our $root = "/usr/local";   # This should be a very protected location
+! Different filesystem is even better

our ( $GlobalLock, %HashA, @ArrayA . . . );

## eval
{  require "functions.pl";
   my $ret = Setup(0);   ## Setup subroutine initializes the global va
+riables only once
                         ## I usually put the 'require's in the Setup 
+subroutine
                         ## Then I can test with: perl -e 'require Ser
+ver.plx; my $r = Setup(4);'
                         ## Errors are now run-time errors the (4) is 
+debug level for logging.
}
if ( $@ )
{  ## didn't work, you could retry or whatever
}

# fork childern
while ( 1 )
{  # check on children
}
[download]

And now the child activity after the fork.

#!/usr/local/bin/perl -w
# Server.plx ( really child after fork! )

use warnings;
use strict;

our $root;

{
##  $GlobalLock was opened by parent and is available to children for 
+processing

##  Child is waiting for work ( in my case usually a socket wait )
##  If child needs to work on any global variables, should lock/unlock
+ with fork.
##  And always check the return code from flock!

}
[download]

Obviously, a lot of code is needed to complete this sample, but the general idea is there. One thing that is critical, is to lock the globals when the children use them. For this, I use the $GlobalLock file and use flock to lock/unlock when ever I access a global variable.

The global variables will remain in the parent address space, and may be used by the children. One strange thing that I have observed, is that after you check the syntax of your package ( perl -c -w server.plx ), sometimes I get run-time errors that many global can't be accessed from a subroutine. When I add 'our $root;' to the subroutine, all the run-time errors go away. You may have experienced this, and hence you question!

This may be over-kill for your needs, but you're next step may be to add threads and work in parallel. Some one else on this list will have to coach you on what locking/unlocking requirements are needed for threads. A lot of programmers learn the hard way, myself included! You need to Lock it!

Thank you and Good Luck