X-no-Archive:yes
Assuming that FTPSCR is an ASCII file, redirection might be doing something
unwanted, or there could be a problem with the file itself. What if you run
FTP.ARPA.SYS;INFO="172.21.1.1";STDIN=FTPSCR (and remove the open from your
command file)? In fact, you can use a host name, and hide the username and
password in a netrc, so they do not show up in your script (and you can
secure the dickens out of the netrc).

Turn DEBUG on. Does the remote host show anything in the error log? Does it
take a while to see the SOCKERR 64? Is it a timeout, or is it immediately in
response to the get? We used to get a lot of these SOCKERR 64s after a
timeout, before someone tended to deficiencies on our WAN, and then we
increased our inbound buffer pool on the 3000. It may not be MPE's fault,
here. Do you get good, consistent response time, pinging with larger
packets? Poor response time, or wild swings in ftp times, indicate
performance problems. Does any get work, maybe a very small ASCII file, or a
dir (which is a small ASCII transfer)? A misconfigured firewall can be hard
on ftp. These are both 3000s, right? Why is there a "200 Type set to I"
message, before the "200 Type set to L"? Is the command file setting binary,
and then setting to bytestream? That's strange. If so, try just setting
bytestream.

BTW, if you have Apache on your 3000, you already have the apache_pb.gif in
/APACHE/PUB/htdocs.

The SAMBA suggestion is a good one as well, if you have it on both boxes.