dragonchild,

The significant lines of the script are posted in another reply. Yes, the values in the %app hash are not changed in the &print_application() function. Or, rather, the &print_application() function is seeing values that should be undef when another function tests thoese values and finds them to be unacceptable.

Thank you for your list of possible causes. I checked the hash key spelling, "my (or local) %app" in the &print_application() function, and the IIS error logs say nothing (they never do offer much help). Did I mention I hate IIS today?

"Given the dearth of information". Opps. (Sorry. I was hoping not to clutter the post with noise.)

cog,

I missed the "returned value" == "1" vs. "returned value" == 1 vs. "returned value" eq "1" in your earlier post. Thanks for the suggestion. I'll always aspire to write things more exactly. Unfortunatley the O'Reilly Perl book is slightly larger than my head and is among my first programming attempts. (You've all probably noticed my unusual methods such this cludge (I'll find a better way sometime):

my $first_name_check = &check_name($app{"first_name"});
unless ($first_name_check == 1) {
    undef $app{"first_name"};
    push (@errors, "First Name: ".$first_name_check);
}
[download]

Thanks for catching the regex mistake. :-)

Your comment, "As for returning the warning string, I don't think that's a good idea, because both 1 and "Friendly message..." evaluate to a true value" has made me reconsider that technique. It did cross my mind that both return values were technically true but thought that keeping the failure message with the test function was helpful. What do you think of returing (1, "Test OK") or (0, "Helpful message")? ...another bad idea? My first attempt was:

sub check_name {
    my $name = $_[0];
    if ($name =~ /^[A-Z][A-Za-z\-']+/s) {
        return 1;
    } else {
        return 0;
    }
}

unless (check_name($app{"first_name"}) {
    undef $app{"first_name"};
    push (@errors, "Helpful error message here...");
}
[download]

It seems that seperating the error message from the function would require the error message to be repeated everywhere the test will be preformed and the user notified. This could result in error messages falling out of sync with the current rendition of the regular expression. Either way, I'll stick with your recommendation and keep my return values as true/false only. :-)

Learning Perl is a great book (third edition is much better than the second). The table of contents completely fell out of the binding because of the number of times I fall back on this book.

I'm hoping to develop better habbits with time and practice.