Okay, first one possible answer. Let me rephrase the situation, to see if I got it:

You want to create colored links near the top of the page, and these links will point into a big table that comes afterwards on the same page, and you won't really know where the link targets will be in that table until you actually process the big hash array(s) of table data -- but you would prefer to process all that data only once. Right? I agree with that.

The answer: create a server-side include statement at the spot where you want to include the colored links, and open an output file that can be included at that point; e.g. something like this:

    print $outhandle "<!--#include virtual=\"my_link.incl\"-->\n";
    open( LINKER, ">my_link.incl" );
[download]

Now, once you go into that grotty part about actually writing the table based on the hash data, just figure out what points need to be link targets, and how the colorized link tag should be written, then write that link tag to the LINKER file handle.

When you close the page, close the linker file. You're done.

Now about that code... Naturally, many folks here will say you should be using CGI.pm, and they're probably right. but it looks like you're creating static html content here, so nevermind that.

You said: # yes, I am using strict But I couldn't find the declarations for the crucial data hashes ("%alljobs"? "%classname"? "%classHash"?) Well, nevermind that.

Try to think how you would refactor some of the logic into a subroutine; instead of a chain of "if ... elsif ... elsif ... elsif ...", where the blocks are all pretty much the same activity, just use one subroutine call, like

     printTableRow( $outhandle, $status, $class );
# and maybe this is where you do your linkage, too:
     print LINKER $linkstring if ( $need_to_link_here );
[download]

and put hashes in the sub that map the varying strings and colors to $status, since that is all that differs:

sub printTableRow {
   my ($handle,$status,$class) = @_;
   my %colors = ( active => "#c1ffc1",
                  failed => "#ff0000",
                  queued => "#b23aee",
                  partial => "#ffcc00",
                  success => "#33cc33", );
# and a similar hash (%title) for "Active Jobs", etc...

   print $handle <<ROW;
  <tr>
    <td colspan="12" align="left" valign="center" bgcolor="$colors{$st
+atus}">
       <b><font size="+2">$class: $title{$status}</b></font>
    </td>
  </tr>
ROW
}
[download]

Notice that no "if ... elsif ... elsif ..." is needed this way, and the "ROW" heredoc only needs to be typed once. Makes things easier to maintain later. Also, I think you want this bit:

 print "\n<table border=1 width=\"100%\">\n";
[download]

to be outside the double loop, rather than inside, and you'll then want something like this after the loops:

 print "\n</table>\n";
[download]

And maybe you could work on using proper indentation. Everybody likes that.

update: I'm sure you'll realize that you would actually need four separate linker files, since you are creating four different html files. This level of the structure is probably another case where you may be better off by refactoring into a subroutine that you call four times, to do one page/include.file at a time -- this should not require changing the underlying data hashes.