Here's the skinny. This is a subset of a subroutine. Yes, I am using use strict and use warnings. Every single print statement in the code is put there solely for debugging purposes.

For being a subset of a subroutine, this is waaay too long. You are giving yourself a clue writing

I have a series of comments in the code that are to help me keep track of brackets more than anything else.

Anything else would be far better. Do you think we are so much smarter than you following the code flow, and spotting the bug?

• Try to break up your long loop into smaller chunks, and put those into subroutines.
• recently there was a discussion about variable naming.

  FASTAKEY:  for my $g (@fastarray){
  [download]

  This one strikes me for it's lousieness. The Thing All The Loop Is About is just named $g! And nobody gets to know what the hell it is, because there is no comment.
• avoid goto. Avoid goto! Avoid nested gotos going back and forth within a loop like the sin! Almost everytime you feel like needing goto, or if you are using excessive calls to next and last, you really need to rethink the logic of your program flow.

Go back. GOTO your starting point:

What I'm trying to do

I have gathered a series of endpoints to a large text file (containing a genome split into FASTA format records). The endpoints are stored in a %HoAoA, where the keys of the hash correspond to the ID lines of each FASTA record, and the values are arrays of arrays. Each (first level) array corresponds to a particular sequence I want to extract from the genome file. Each (second level) array contains three elements: [0] is the starting point, [1] is the ending point, and [2] is the length of DNA contained between them, defined as [1] - [0]. At this point in the script, I am trying to refer to the %HoAoA to find out where each sequence is, and then extract that sequence from the genome file, and place it into a corresponding element in an %HoA.

Start from there. Put this block as a comment into your code. Program what you're stating here. Tweak the formulation of the problem 'til it fits with the code you program for it. Each statement of what I'm trying to do should be followed with the code which is meant doing what is stated, i.e. translate the requirements into perl, and re-formulate the requirements to be translatable. Take care that the outcome of both ways to express the same thing - i.e. comment and code - remain understandable. (In an ideal program a bug would then be obvious, because the description in program code would be a contradiction to what is expressed in words)

Bottom line, rather than debugging, I would rewrite that code.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}