The ownership of a file is not the same as the userid that the file will execute under. The userid that a file will execute under will generally be the same as the userid of the person/thing running the script (except in the case of setuid scripts and the like).

You have uploaded a file either under your id, or through anonymous FTP, which means the file is either owned by your uid, or whatever uid anonymous ftp uses respectively. You script however will be executed by the webserver which which probably runs under some other uid (probably nobody.) So since only the owner of a file (or root), can change the permissions of that file, your script being run by the webserver will not be able to chmod() your text file.

You have a few options, you can go ahead and change the permissions on the text file via ftp or a shell (this would probably be the best solution), or you can make your script be setuid (NOT RECOMMENDED) by making sure that the owner of the script is correct (meaning being owned by the same person as the text file) and setting the permissions to something like 4755 (setuserid, rwx for owner, rx for group, and rx for world).

Why not to make your script setuid:
In short, its a security risk. Your are allowing this script to be run as your userid (or worse, root), allowing it your level of access to things on the machine.
As if that weren't a good enough reason, in some OS's, it is possible to have the shell go ahead and spawn your script's interpreter (in this case perl) as the uid that owns it (you or root), but for the actual script to be changed before the interpreter gets to it. This means arbitrary code being run as the wrong user.
Given all this, many webservers will not execute a script that is setuid unless set up to do so, and it is not recommended that they be configured to do so.

There is a good thread on the subject of suid scripts that was spawned in response to setuid scripts, how?

Hope this info helps.