Your problem is with the line that says:

@val3=grep(/\d{1,2}$comparison/,@complex);
[download]

Since $comparison is passed in as the second argument to the subroutine, grep may not find any matches (which will happen when the second argument is a not a single lower-case letter from 'a' to 'x'). When no matches are found, @val3 is still undefined - in otherwords, it is empty. Therefore, any further actions using it, such as:

chop($val3[0]);
$val4=$val1[0]+24-$val3[0];
[download]

will cause perl to complain (if -w is set) about "use of uninitalized value", which is perl's way of saying: "Hey - how I can do anything with this value if you haven't even told me what it is yet?!"

Let me show you one way to track down errors like these, to help you out next time. (This is roughly what I did). First, I ran the script with a -w. This seems to work, as it did for c-era, but only because we have defined a subroutine but not actually *used* it. So, next I added a

&Get_Calibrator_Filename();
[download]

to the top, and got a lot of unitialized value errors. Fair enough, after all, the subroutine does require some input. Instead of using:

$calib1=$_[0];
$comparison=$_[1];
[download]

you should use something like this, which is not only cleaner, but enforces that at least two arguemnts are sent to the subroutine:

$calib1 = shift or die "Missing first argument to sub GCF!\n";
$comparison = shift or die "Missing second argument to sub GCF!\n";
[download]

So, I plugged in two random variables:

&Get_Calibrator_Filename("foo", "bar");
[download]

When ran, it produced far fewer errors, about the same as the number you reported. I then looked at the very first error reported, in other words, the first place in the script that the unititalized value appeared. In this case, it was the line:

chop($val1[0]);chop($val2[0]);chop($val3[0]);
[download]

Breaking it into three lines revealed that it was the final statement that was causing the problem. Then I looked back to find where @val3 was set, and it was in the grep statement above. The grep statement used two variables, $comparison and @complete. The latter is hard coded, but the former is based on the input to the subroutine - bingo! Then, after looking at @complete, I changed the second argument to the subroutine to "f" instead of "foo" - no more errors. Having some minor error checking throughout the program would prevent problems like this. Check to see whether or not grep returned anything, for example. I'll leave that as the proverbial "exercise for the reader", since this post has gone on long enough. :)