This reminds me of COBOL programming on IBM mainframes in the early 1980's - if you did not initialise numeric values before using them in a condtional, you would get a program abend and a dump (the good old OC7 abends, for any other OS/370 programmers out there). So the standard way we woudl declare our variables was something like:

WORKING-STORAGE SECTION.

05  SOME-VARIABLE       PIC 9(10) USAGE COMP VALUE 0.
[download]

That solves one problem. Now the other issue to resolve is "why is an unitialised variable being referenced in your code"? There are probably two causes:

1. The value is optional - say from a HTML form. So then the corresponding value in the %param hash will be undefined. Several solutions:
   1. set a default value on the HTML form itself;
   2. have a loop early in your form processing program that iterates across every element in %param and, if undefined, defines it to some value; or
   3. use the if (defined $param{some_param}) { construct.
2. You have a bug in your program, or in the program calling the routine. A good practice to get into is to have a "preprocessing" validation section first in a program - did we get all the information we need, are the values sensible, and so on. If the input fails the validation - including mandatory values that were not supplied (and hence undefined), your routine should fail - with suitable diagnostic messages.

The bottom line is, there is probably no universal, safe "catch all" to prevent the uninitialised value message. As part of your code design, you need to consider what it means if a variable is undefined - is it merely an optional value, and if it is undefined, we can ignore that (and skip some processing), or is there a deeper problem in the program?