As usual error messages tell you something. Read them instead of just acknowledging them. If you don't understand them directly, google them or find them in the documentation.

In this case probably the error message told you that the evaluation of parameter.pm resulted in a false value, which should not be (although I don't have the slightest idea why this was built into the module system). Just add as a last statement anything that results to true, usually everyone just adds

1;
[download]

as the last line of a .pm file

Sorry for incomplete message, jethro.
In fact I did add the last statement 1; The error message says: Global symbol "%module" requires explicit package name at ... How should I name a hash from the module?
As to:
I don't have the slightest idea why this was built into the module system
I simply cannot figure out how can I get it otherwise. One way is simply to let the hash in the main file, but as already said the hash grows huge and the main file will be confusing.
Thanks.
VE

my %hash = do q{path/parameter.pl};
[download]

Thank you very much wfsp, it works this way!
VE

Having said that, you could create a pointer to the hash, and share the pointer - accessing the hash through the pointer. Or you replace my with our, and access the hash as you'd access any other package variable.

Thank you tospo!
You mean the parameter could by saved in csv-file which could look like:

shorthand;title;indicator;name;yskala;legend
THIS;This Evaluation;01;First;[:100];bottom
THIS;This Evaluation;02;Second;[:100];bottom
THIS;This Evaluation;15;Fifteen;[0:];top
[download]

and be read into the hash?
Of course it would simplify the build-up. I will try to accomplish this, though I have read some threads on this subject, as converting a text into a hash datastructure or Building an arbitrary-depth, multi-level hash and did not see "The Light" yet :-)
I'll try.
Thanks!
VE

Definitely OT but I could not stop myself: I made a funny typo today: "sue strict; sue warnings;". Well, Perl did not do it :-)
VE

not really. The crucial point is that the entire content of that csv file can be auto-generated in a few linew unless I'm missing something important here.
Take this as a simple example:

my @combinations = ( "1,1","1,2","2,1","2,2")
[download]

vs.

my @combinations;
for my $i (1..2){
  for my $j (1..2) {
    push @combinations, "$i,$j";
  }
}
[download]

I'm generating an array in this case with strings that are combinations of elements, in this case simply the number 1 and 2 but you can easily substitute that with "THIS", "THAT" and "This Evaluation", "That Evalutation" etc, which is what you have (if I remember your other thread correctly).
In the first example, I harcode the array by typing all the combinations in my script. I could also save them to a file in csv format, as dump of the array (using Data::Dumper), or whatever format you can think of - the problem remains: I'm hardcoding all possible but entirely predictabe and therefore scriptable combinations of elements.
In the second example, I generate all possible combinations on the fly. Again, if I remember correctly, you only need to do that to generate a file name. For that reason you don't even need to save the data to an array or a hash - you just generate the string as a combination of all the elements and then use that to open your file - job done.
Of course, in my simple example, the second version is longer than the first, but you can easily see how that changes quickly with more elements and more combinations.
So, if the data can be generated on the fly, do it - that's the whole point of scripting. If not, i.e. sometimes you want the scale for a "THIS" plot to be "0:" and sometimes ":100" and tehre is no way to predict it, then you have to resort to a config file (for which you can use a number of options, such as YAML or simple config format - have a look around on the CPAN).
Hope this helps.

I used to know a girl called sue strict. shudders

Yes and no. If the logic gets torturous I find it better just to create a table even if it is almost wholly repetitive. If it is large (or small), if most entries are the same or even empty. Perl doesn’t mind tedious.

As soon as there are nots, ors and ands and they start nesting and cascading all over the place I’m certain, nay, guaranteed, to get it wrong. I find it hard to write, the bugs hard to find and they are most often the sort of bugs that appear six months down the line. Did I mention my boolean algebra is weak?

If it is appropriate and I can fit the logic into a table I get on much better, it is all reduced to a lookup. If it is not appropriate then yours is the way to go. What is appropriate, of course, is a matter of taste. :-)

well, Perl doesn't mind tedious but you might and you are likely to get nice little errors in the long table that will be difficult to find. Why risk it? It's like wanting to print out a multiplication table by hardcoding all the results instead of calculating them. Yes, you can do it and Perl doesn't mind but it would defeat the purpose, wouldn't it?