FWIW, there is another eval trick:

use strict;
use warnings;

my %cs101 = ("joe"=>    "80" );

print "Choose which hash\n";
chomp (my $input = <STDIN>);
#my $whichhash=\%cs101;
my $whichhash="$input";

sub hashvalues {
   while( (my $key, my $value) = each (%$whichhash) ) {
       print "$key $value\n";
   }
}

die "Illegal hash name: $input\n" unless $input =~ /^\w\w+$/;
eval '$whichhash = \%'.$input;
die "Input: <$input> is not a hash name: $@\n" if $@;


&hashvalues;
[download]

... however, executing unchecked user input is no good idea. Consider somebody inputs cs101; unlink $0...
So, the approach suggested by toolic above is more secure and also allows for better user interaction, i.e. by presenting the user a menu list created from the HoH.

Update (16:05 CEST): From my point of view, when giving an answer to a SoPW-question, the answer should also include a note about possible drawbacks and limitations. Knowing the pros/cons, helps the reader to decide upon the usefulness of the answer(s) under her/his given circumstances.
Here, unlink $0 is just an example that is not intended to be a useful exploit but as one that should create awareness of a potential drawback. Creating a usefull exploit is left as an exercise for the reader ;-)
Seriously, one should not rely on the pure assumption, that the program will always be executed under the same privileges of the user and without malicious intend. I've seen scrips that were designed to be used as CLI tools and later wrapped and executed by a webserver, however vulnerable to injection attacks. This might be far away from the OPs intention, but who knows? Maybe, I should have made this explicit earlier...