But don't be afraid I won't reproduce an excerpt here ... would be too easy for the others to help you then... ;-)

For what it's worth I seem to recall having experienced something similar. Try replacing your Dumper bit with something else that forces Perl to peek inside the hash. Something like this perhaps:

do { my @tmp = keys(%$hashref) };
[download]

(That's right - the results are invisible!)

Further to tobyink's post: Here's one scenario (of many) in which hash data can 'vanish' in certain circumstances, only to magically reappear later:

>perl -wMstrict -le
"my $hr = { 'Node' => 'TestServer' };
 my ($k) = each %$hr;
 print qq{'$k'};
 ;;
 pk($hr);
 ;;
 sub pk { my ($hr) = @_;  my ($k) = each %$hr;  print qq{'$k'} }
"
'Node'
Use of uninitialized value $k in concatenation (.) or string at -e lin
+e 1.
''
[download]

Now try inserting an otherwise-useless keys statement after the first each statement (which exhausts hash iteration in this case):
    my ($k) = each %$hr;
    my $ignore_this = keys %$hr;

>perl -wMstrict -le
"my $hr = { 'Node' => 'TestServer' };
 my ($k) = each %$hr;
 my $ignore_this = keys %$hr;
 print qq{'$k'};
 ;;
 pk($hr);
 ;;
 sub pk { my ($hr) = @_;  my ($k) = each %$hr;  print qq{'$k'} }
"
'Node'
'Node'
[download]

See each and keys (and values) for discussions of hash iteration behavior.

Update: neousr: Others have alluded to the annoying fact that you show no (useful) code. What would really be useful would be a small, standalone, executable code example demonstrating the problem. The effort to produce such code may not be trivial, but the very process of producing it may clarify the problem so far as to answer your own question!

Thanks CountZero

Ok w/o ironies ... why don't you show some code?

Cheers Rolf

( addicted to the Perl Programming Language)