I agree with perlfan. If you try to run your code with use strict perl complains that the script has "too many errors". This is mainly because you aren't declaring all your variables. For instance, right at the begining change it to

my $popCt = 1;
my $markers = 2;
[download]

This will help, amoung other things, track down typos. In tester() you have $HoHMarer where you almost certainly mean $HoHMarker. Nail down those sort of errors and you are often halfway there.

I find it easier to track down bugs by supplying a sub all the arguments it needs so that it is a self contained script on its own. This means you can test it on its own, it doesn't rely on anything that might be happening a hundred lines further up or further down the script. This way you can test your script with sample known good/bad data and check that it behaves as expected.

Again in tester(), the first three lines are

sub tester {
  my @holder = @{$HoH{$newcounter}{'holder'}};
  my @ind = @{$HoH{$newcounter}{'individual'}};
  my %HoHMarker = %{$HoH{$newcounter}{'marker'}};
[download]

What do you expect $newcounter to be? undef would not be a lot of use here. Strict would force you to declare it and you may need it to be an argument that you pass to the sub.

my $newcounter = 1;
tester($newcounter);
#...
sub tester {
  my ($newcounter) = @_;
  ...
}
[download]

Pass your subs all the args it needs. If it needs a lot construct a hash/hashref.

my $args = {
  arg1 => $arg1,
  arg2 => $arg2,
  arg3 => $arg3,
};
tester($args);
...
sub tester{
  my ($args) = @_;
  ...
}
[download]

You could also debate how useful %HOH is as a name, something more meaningful (but short) might make the code easier to read.

Some more error checking wouldn't go amiss and Data::Dumper is, as you have, a very useful tool. When I'm trying to get some sense out of a script I use the ... or die "somevar is $somevar"; liberally, and when things are really bad on everyother line. :-)

As an example, in tester() again

sub tester {
  my @holder = @{$HoH{$newcounter}{'holder'}};
  die "tester: holder is empty" unless @holder;
[download]

Have all your subs return a value. Even if it is only true on success and false on failure. The "return early, return often" idiom can make your subs logic a lot easier too. It would also assist testing/error checking.

my $success = tester();
die "tester failed" unless $success;
[download]

Finally,

...is there a way to have an array name itself...

With strict and warnings on the answer is "no". Self modifying code is considered a bad idea but there are many alternatives, a hash lookup being popular.

my %user_data_lookup;
...
my $safe_input = validate($user_input);
push @{$user_data_lookup{$safe_input}}, @some_array;
...
[download]

Try to write a script that demonstrates the snag you're having trouble with (not the whole lot!) and we'll see where we go from there.

Good luck! Let us know how you get on.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.