not finding <file> the 2nd time it's called

Does ./final_drc exist?  Are there any files matching *.log in this directory?  Do you chdir() anywhere in the rest of the script between the first and second call to the process_file sub?

Also, "./final_erc/*.log" would be expected to return a list of results (all the files matching *.log).  Is there a reason you're populating a scalar with this, rather than, say, an array?

The files exists.  If I swap the order, the 2nd one still fails.

I do not use chdir.  The main reason is that I couldn't get the equivalent of cd .. to work and had to move on to the next problem.  

Only one log file exists in each directory.  
I  have the array checking code rem'ed out for now, until I get the basic functions to work.  

I put   sleep 5 ;
at the end of the sub and it still fails on the 2nd time thourgh.

That works.
What is it doing and why do you need it?

In scalar context, glob iterates through
               such filename expansions, returning undef when the list is
               exhausted.
($fileIn) =
puts it in array context

      If what's within the angle brackets is neither a filehandle nor a sim-
       ple scalar variable containing a filehandle name, typeglob, or typeglob
       reference, it is interpreted as a filename pattern to be globbed, and
       either a list of filenames or the next filename in the list is
       returned, depending on context.  This distinction is determined on syn-
       tactic grounds alone.  That means "<$x>" is always a readline() from an
       indirect handle, but "<$hash{key}>" is always a glob().  That's because
       $x is a simple scalar variable, but $hash{key} is not--it's a hash ele-
       ment.

       One level of double-quote interpretation is done first, but you can't
       say "<$foo>" because that's an indirect filehandle as explained in the
       previous paragraph.  (In older versions of Perl, programmers would
       insert curly brackets to force interpretation as a filename glob:
       "<${foo}>".  These days, it's considered cleaner to call the internal
       function directly as "glob($foo)", which is probably the right way to
       have done it in the first place.)  For example:

           while (<*.c>) {
               chmod 0644, $_;
           }

       is roughly equivalent to:

           open(FOO, "echo *.c | tr -s ' \t\r\f' '\\012\\012\\012\\012'|");
           while (<FOO>) {
               chomp;
               chmod 0644, $_;
           }

       except that the globbing is actually done internally using the standard
       "File::Glob" extension.  Of course, the shortest way to do the above
       is:

           chmod 0644, <*.c>;

       A (file)glob evaluates its (embedded) argument only when it is starting
       a new list.  All values must be read before it will start over.  In
       list context, this isn't important because you automatically get them
       all anyway.  However, in scalar context the operator returns the next
       value each time it's called, or "undef" when the list has run out.  As
       with filehandle reads, an automatic "defined" is generated when the
       glob occurs in the test part of a "while", because legal glob returns
       (e.g. a file called 0) would otherwise terminate the loop.  Again,
       "undef" is returned only once.  So if you're expecting a single value
       from a glob, it is much better to say

           ($file) = <blurch*>;

       than

           $file = <blurch*>;

       because the latter will alternate between returning a filename and
       returning false.

       If you're trying to do variable interpolation, it's definitely better
       to use the glob() function, because the older notation can cause people
       to become confused with the indirect filehandle notation.

           @files = glob("$dir/*.[ch]");
           @files = glob($files[$i]);

Which is why I was asking whether you should really wanted to be reading it into @fileIn rather than $fileIn...