in reply to Am I missing something here?

"Debugging 101" suggests that a few well-placed print statements might be in order. Before the loop, open a <pre> block. Then, within, the loop, print a few key values, such as the raw date values and $day_diff. That should help you narrow down the problem.

And are you really sure that it's a date difference problem? The following looks suspect to me: 

   $domain = unpack ("A4", $temp1[40]);
   ...
   if (($domain eq "BBA") && ...

[download]
You're extracting a 4 character string, then comparing it to a 3 character string. Is that what you really mean to do?

Replies are listed 'Best First'.
Re: Re: Am I missing something here?
by sifukurt (Hermit) on Nov 07, 2001 at 19:47 UTC
    With regard to the debugging print statements, here's something I do that works very well for me in situations like this. First, at the top of the file, set a debug flag: 
    $debug = 1;

    [download]
    Then I make a debug subroutine: 
    sub Debug {
    if ( $debug ) {
        my $msg = shift;
        print $msg, "\n";
    }
}

    [download]
    Then throughout the code, I drop in things like: 
    Debug( "Entering calculation phase." );
Debug( "Pre-calculation value of \$x: $x" );
...
Debug( "Leaving calculation phase." );
Debug( "Post-calculation value of \$x: $x" );

    [download]
    This allows me to check values of just about anything, at any point in execution. Then when you're done debugging, you just set $debug to zero and you're done. Personally, I usually leave the debug code in place, in case I ever need to come back and fiddle with the program and need to debug it again.

    HTH
    ___________________
    Kurt
[reply]
[d/l]
[select]

      This will allways call the Debug() sub. The overhead may or may not be a problem in your production systems, it all depends on how many times this call is executed.

      Imagine a few thousand times per minute. (Or per second...)

      I propose the alternative solution: 

      $debug=1;
$debug&&print("Debug info...\n");

      [download]

      The above should require less overhead. I've even read somewhere that Perl optimizes this so that the $debug&& doesn't have to evaluated, but unfortunately I can't find back the reference to that text. :-( Maybe some of the well educated Monks may chime in about that?

      If there is no reason to change the value of $debug during execution, the following should be even smarter(?): 
      *DEBUG=\1;
$DEBUG&&print("Debug info...\n");

      [download]


      f--k the world!!!!
      /dev/world has reached maximal mount count, check forced.

[reply]
[d/l]
[select]

        I'm sure your way is more efficient compared to calling a sub all the time, but I would definitely push for "use constant" in this scenario, especially if you're concerned with efficiency

        Suppose the following is in a file called "debug.pl":

        *DEBUG = \1;
use constant CONST_DEBUG => 1;
$DEBUG && print "foo\n";
CONST_DEBUG && print "bar\n";

        [download]

        They look pretty much the same, but you should see the output of perl -MO=Deparse debug.pl

        ## Output of perl -MO=Deparse on my machine with perl 5.6.1:
*DEBUG=\(1);
sub CONST_DEBUG() {
    package constant;
    $scalar;
}
print "foo\n" if $DEBUG; # <- $DEBUG must be evaluated each time
print "bar\n"; # <- there's no evaluation... just straight print()'ing

        [download]

        There you see that the second option gives you a literal print "bar\n" without needing to evaluate another variable.

        This is because of a couple of reasons: 1 - the perl compiler is smart enough to optimize away "real" constants... and 2 - *DEBUG = \1 is NOT a "real" constant. (You can always assign on top of *DEBUG if you so choose to).

[reply]
[d/l]
[select]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom