"Yeah, I apologize I'm a noob ..."

None of us left the womb with knowledge of Perl. We all had to learn and practice it. This is not something for which you need to apologise.

"... and still getting better at optimizing ..."

Code optimisation is the last thing you should be doing. Don't even concern yourself with it at this stage. The most important thing is to get the program to run correctly; i.e. produces expected results without errors or warnings.

If, when running correctly, you find it is running exceptionally slowly, or chewing up vast amounts of memory, or something similar, that's the time to look at optimisation. There are hints in "perlperf - Perl Performance and Optimization Techniques" but, as I said, this is the last thing to address. You can ask us about optimisation, in a separate question, if you're having problems in this area.

"... and minimizing my code, wasn't really sure how else to cut it down."

Perl doesn't care how long or short your code is. As a general rule, aim for readability, not brevity. There are benefits to following the DRY principle; however, at this stage, getting your code to work correctly is more important.

I don't know how you managed to end up with the code you posted in "Re^4: bug or curly bracket hell?". Instead of reaching for a search engine to fix problems, you should calmly and carefully look at what you've written. I'm pretty sure that if you'd done that, the 'print "' at the start would have alerted you to a problem.

Perl's diagnostic messages are described in perldiag. This is the place to look for an explanation of error and warning messages. Search for key phrases in the messages; specifics are typically replaced with '%s'; so, as an example, you'd need to look for 'Argument "%s" isn't numeric%s'. Until you're familiar with this, such a search can be tricky; while learning, I suggest you use the diagnostics pragma BUT do remove this from production code (it's only intended to be used as a developer tool).

I recommend that you take a step back and read "perlintro - a brief introduction and overview of Perl". This will take you through the basics: it explains not just what to do but also why you should do it. Every section here is peppered with links to more detailed information: you won't need to follow all of these now, but you'll find them useful over time; bookmark this link for future reference, it's an excellent resource.

I don't intend to provide a full code review; however, you're I/O handling has many problems. Here's some guidelines:

• Read the documentation for the open() function.
• Use lexical filehandles (e.g. my $conf_fh) not package variables (e.g. 'conf' and FH).
• Always use the 3-argument form of open().
• Use the autodie pragma and let Perl handle your I/O exceptions. Hand-crafting your own messages is tedious and error-prone; and things like "... or die;" are pretty much useless.

Putting all of that advice together, your typical script might start something like this:

#!/usr/bin/env perl

use strict;
use warnings;
use diagnostics; # TODO - remove in production
use autodie;
[download]

When posting questions, please remove all of the unnecessary parts. For instance, can you show the problem using a spreadsheet with two columns (e.g. first and last name); does address, post code, phone number, etc. add anything useful in terms of describing the problem. See SSCCE for a discussion of this. When presented with screenfuls of code, many monks (who could potentially provide you with excellent advice) may decide that that do not have time to deal with something so large: this is your loss.