FTP problem

We are attempting to FTP a file from a bank using the FTP command -

FTP RMTSYS('bank.ftpserver.com') PORT(20021) SECCNN(*SSL)

This connects to a Sterling Commerce FTP server on the bank's mainframe. 
Once connected, I can provide user ID and password, move around in 
directories, and pretty much do anything I want to except list contents of 
directories and retrieve files.  When I try to actually retrieve a file, the 
session hangs and eventually gives me a "No response from FTP server" 
message.

The odd thing is, I am already connecting to another bank which uses 
Sterling Commerce and have been retrieving files from them for several 
months.  I have gone back and forth with the bank's (semi-)technical support 
personnel to describe the problem as a firewall configuration issue based on 
many messages here on Midrange-L to no avail.  Today I received this e-mail 
from the (not very) technical support person:

"The problem is that the FTP control data is encrypted as it comes through 
the firewalls, so it cannot be read to do the IP "natting" at the firewall. 
Most third-party clients handle this by storing the original control address 
and using it during the transmission. Native FTP programs such as MSDOS and 
IBM's FTP do not allow for this and uses each control block as it is sent. 
There is also a feature called Clear Control Channel that allows the userid 
and password to be sent encrypted, then all other data exchanged over the 
control channel to be sent as clear text. In our case, this would allow the 
firewall to see the IP address and correctly "nat" it to the proper IP. All 
data sent over the data channel will remain encrypted. According to our 
vendor, this is a feature normally found only in third-party FTP software, 
and they are fairly certain this feature would not be available on the 
default AS/400 operating system FTP software."

This response seems highly incorrect in light of the fact that we are 
already FTPing from another bank using Sterling Software.

Is their response correct?

Thanks,

Steve