What happened to strict and warnings in your code? Also, i recommend that you use Carp. The "English" module also makes your code clearer. Avoid the implicit variable $_ - it is (in my opinion) the spawn of evil and should be avoided at all costs to make code easier to read.

#!/usr/bin/env perl

use strict;
use warnings;
use Carp;
use English;
[download]

open(F0, $ARGV[0]); open(F1, $ARGV1); open(F2, ">$ARGV2");

Urgh, there are so many things wrong with that, it gives me an instant headache. First of all, do not use plain file handles, use variables. Use three-argument open(). Check the return value of open(). Use multiple lines. Put the ARGV stuff into named variables to make the code clearer. Use proper variable names for the filehandle, so you know later in the code which handle does what.

my ($ipfname, $portfname, $resultfname) = @ARGV;

open(my $ipfh, '<', $ipfname) or croak($ERRNO);
open(my $portfh, '<', $portfname) or croak($ERRNO);
open(my $resultfh, '>', $resultfname) or croak($ERRNO);
[download]

I can't really make out what the rest of your code is trying to do. I'll suggest you implement the recommendations by me and the others who have already replied to your question and see if that helps. You can always come back with a new question, but please do at least the following:

1. Explain what your code is trying to do. Adding an example output (can be edited by hand) is very helpful.
2. Implement our recommendations as far as possible. "use strict" and "use warnings" are pretty much a requirement these days.
3. Make your code more readable. One command per line, proper indentation.
4. Add comments. Especially comment on the regular expressions. Yes, we can "decode" them, but it's easier if you already tell us what they are supposed to do. Makes the code easier to understand and allows us to check if the regex actually does what you think it should do.
5. Use variables with names that hint at their intended purpose.
6. Check the return value of open().
7. Show us your error messages (if any).

Most of us have limited time to understand questions and come up with good answers. The best way for us to help you is for you to help us in providing a good question that is easy to read, easy to understand and has readable example code (and example data, if applicable).

I can only speak for this from my own point of view, but say there are three new SoPW questions. Two of them are easy to understand and one would take an hour just to understand what the example code might try to do. I'm not talking about how complicated itis to come up with a solution, just how hard it is to even understand what the problem is. In this case i will probably work on the two easy questions and ignore the confusing one.