I'd write it like this:

use strict;

open my $in, '<', "G203.xml" || die "Cannot open file: $!\n";
open my $out,'>' "_G203.xml" || die "Cannot open file: $!\n";

while (my $string1 = <$in>) {
  $string1 =~ s/XXXGASPOINTIDXXX/656563/gi;
  $string1 =~ s/XXXMMREFXXX/62394732472856563/gi;
  print $out $string1;
}

close $in;
close $out;
[download]

Notes:

• I use the 3 argument form of 'open'.
• I read from the file one line at a time, using 'while', process each line, then write it out. No need to hold all the lines in memory (in an array).
• There's no need to sleep.
• There's no need to loop over the entire file twice: you can do both regex's inside a single loop. Two passes might be necessary if the patterns somehow overlapped, but these don't seem to do so).

Nice concise code and nice concise explanation.

however it does not have time to write to second file

What do you mean? What do you observe, an why do you think whatever you observe is connected to how much time it has? How is the time limited? Is the script killed after a certain period of time?

# ...
close IN;
close OUT;
open (IN2, "+<_G203.xml");
# etc.
[download]

If the problem is buffering and closing the filehandle doesn't solve your problem, try making the filehandle hot. A frequently referenced article on the subject is Suffering from Buffering?

select OUT;
$| = 1;
print OUT '';
[download]

use Modern::Perl;
use File::Slurp;

my $text = read_file( '_G203.xml' );
$text =~ s/XXXGASPOINTIDXXX/656563/gi;
$text =~ s/XXXMMREFXXX/62394732472856563/gi;
write_file( '_G203.xml', $text );
[download]

As others have said, it is never necessary to sleep() to cause file operations to work consistently.   You should write to the file, using an exclusive mode (because you do not want readers to see incomplete results).   Then, you should close the file and reopen it for reading.   This will assure consistency, both to your own program and to any other one(s).   If both of these processes are being done in the same program, the same file-handle can simply continue to be used.

If you are attempting to read from a file that is concurrently open for writing, unpredictable results (called dirty reads) may result.

On another note ... “call me an old COBOL hound, but” ... I do come from a day when main-memory was quite small in relation to the quantity of data that you need to process, so I always do such things using intermediate “spill files,” not in-memory stashes.   For one thing, I know that “memory” is really a disk-file, and for another, I know that many (esp. desktop-sized even-if rack-mounted) systems really don’t handle memory-pressure very well at all:   they start to “thrash” at the drop of a hat.   (Especially when dealing with programs that are using in-memory stashes, which are inherently thrash prone.)   But their operating systems handle file-buffering quite sensibly:   they’ll give “unused” memory over to file buffers without being told to do so, and they’ll handle reductions in the amount of memory that is available for that purpose much more graciously than they will handle any application that has suddenly become a million-pound elephant.   So, I’ll read the data from one file and copy it into another.   When asked to sort information, I’ll do on-disk sorts instead of in-memory ones.   I have plenty of experience to tell me that such programs really don’t run slower in the small case (thanks to the buffering), and that they degrade much more gracefully (linearly ...) as the data load grows large.   I basically get to have my cake and eat it too.