Nothing listed in FTP half of comparison

I'm doing a compare of a PC directory with an FTP'd directory on z/VM. The PC half populates correctly, but the FTP half remains empty.

I can see the FTP commands being passed and the results, and everything looks normal, except that FEAT is rejected and between "125 List started OK" and 250 "List completed successfully" nothing is shown. I've tried both Indy9 and SmartFTP. Using SmartFTP I can see that the LIST command causes exactly the same number of bytes (on the 250 message) to be transferred as doing an ls of the same directory using Windows ftp command, so it looks like BC is somehow losing what is sent.

Any suggestions?

I've figured out what was wrong with that. I need to tell z/VM's FTP to use UNIX instead of VM format for LIST. Having done so, BC is listing the initial directory, but it cannot list directories or files in it. I've found the reason for this too, but don't know if there's anything can be done about it.

Because z/VM uses three entirely different filesystems, it's behaviour isn't completely normal. The default filesystem is the least UNIX-like, and looks to ftp like a single directory of files. The other two use a trigger in the path name to determine which to use. This is where it gets messy.

The most UNIX-like file system (called Byte File System, or BFS) has the most peculiar trigger, with a general format of /../VMBFS:filepoolid:filespace/. When a valid filepoolid and filespace are specified, this on its own specifies the root of the particular filesystem. In theory, you should be able to use cd to move around from this point, and in fact from a shell command line, you can. In ftp however, you can't.

Instead, if I want to get the file /../VMBFS:POOL1:SPACE1/mydir/myfile, then from the "root" of this BFS, in ftp it is necessary to specify at least get /mydir/myfile. BC just does get myfile, which would normally work, but just says file not found here.

Is there any way I can make this work? I.e. can I make BC fully qualify each directory and file name? The trigger on the front is always valid, so if BC could always send the full path name, it should work.

Graham.