I already told you why you are having the problem. Delete your initializations of $TT{1000001}[1] and you will eliminate this bug when you try to access $TT{1000001}[1]. If you want to remember that what you are dealing with is named 'mname' (and yes, I consider it good to keep this kind of textual context around) then you can use a hash of hashes of arrays rather than a hash of arrays of arrays. Accessing that would be written as $TT{1000001}{mname}[1], and again it is important not to initialize $TT{1000001}{mname} or else you can get into the same error.

Furthermore if you want to avoid the possibility of this bug or any of a number of other common bugs happening, you can use strict, and declare each of %INPUT, %STUDQT, @sorted, and every other variable with my. If going through and putting in the declarations is too much work for you, you can just catch this bug with adding the line:

no strict 'refs';
[download]

at the top of your program. Note that for any program over 20 lines, my experience is that the time saved in tracking down typos amply pays for the effort of declaring everything with my. My experience seems to be par for the course among experienced Perl programmers.

So if you want a quick fix, remove the dangerous initializations, check for strict references using the line I showed you above, and continue on.

But a piece of advice from much painful experience. One of the biggest things every programmer needs to learn is how easily you can think that you are just about to finish when you are not going to finish any time soon. The mantra, "There is just going to be one more bug, this one is it!" can go on for months. Or for larger projects, for years. It is, in fact, quite common for a year long project to appear to be on schedule until 2 weeks before the deadline. Then it starts to slip, and the estimate stays at about 2 more weeks. It can then easily continue to slip couple of years of developing and bug fixing, always seeming to be about 2 weeks off before it is finally cancelled, unfinished.

Based on the code sample that you have shown, the length of what you claim the code to be, and your inexperience, I strongly suspect that you are about to get a milder form of this lesson first hand. Please don't take my saying that personally. I am saying this based on memories of my own learning curve, how difficult I think that code organized that way would be for me to work with, and knowledge of how virtually all programmers tend to chronically underestimate how much work is really left.

That said, unless you can find a mentor who can really work with you on the design of your code, I don't think you are likely to do much better by trying to rewrite from scratch right now. But make a point of redoing this project from scratch when you have some more experience. If you have only been programming Perl for 2 months, and don't have a lot of programming experience, then you should be on a pretty steep part of your learning curve. When you have learned a little more, you should find that you would do things rather differently, and doing them differently will really make a difference. It is worthwhile sometimes to remind yourself of how much you have learned.

And to help that learning curve along, I would suggest the following:

1. As soon as you can, read tye's article, strict.pm. It will tell you a lot about how Perl can make your life easier for you.
2. Read Coping With Scoping, by Dominus, because that will help you to use strict.pm effectively.
3. Read use CGI or die; for the quick demonstration of how to use the param() and header() functions from the classic CGI module. When you know how to use those, you should not want to hand-roll that code again.
4. For more on what symbolic references (the thing that is biting you) are, and why they are so dangerous, read avoid symbolic references by Dominus. Read all three parts, largely because it has a wonderful explanation of why modularization of code matters so much.
5. To gain a better understanding of references, read references quick reference carefully. Also figure out how to use Data::Dumper, and start using it to create debugging dumps of your data structures. That will allow you to see how what you have in there compares with what you think is in there.
6. As soon as you can, pick up some good books about general programming. The usual one I like to recommend is Code Complete.

Good luck.