The OES FTP Server's "remote server" feature allows a FTP client to specify a path involving NCP Servername / volumename by taking a double-slash to mean that what comes afterwards is a server name. For example:

cd //server1/vol1/path

This causes the FTP server to use NCP to contact "server1" and map a drive to NCP volume "vol1" and then access "path" there.

For this to work, the FTP client must allow and preserve the double slash (//) that a user might enter. Most "simple" command-line ftp clients can do this. Many "smart" ftp clients cannot, which is unfortunately but we have lived with that for quite some time.

However, the situation has recently worsened because beginning in SLES 12, SLES no longer ships a "simple" command line client. It now ships "lftp" which arguably is no longer simple, and it doesn't respect double slashes the way that the previous "lukemftp" ftp client did. Lukemftp package was part of SLES 11 and earlier.

As a result, customers moving to OES 2018 on SLES 12 may find that ftp scripts which run there and which rely on remote server syntax (//servername/volumename) no longer work.

I have tested and confirmed this myself. lftp client is not a good companion to the remote server feature of OES FTP.

As such, we really should include a simple FTP client in OES which would be suitable for this use. We could bring back "lukemftp" -- though take note that the lukemftp project in the Linux community is now called "tnftp".

Admittedly, this only helps cases where an OES 2018 machine is the FTP client to a OES <any version> FTP server. It does not necessarily help other scenario. There may still be plenty of machines (SLES or not, Linux or not, etc.) which don't already supply an FTP client that is simple enough to transparently get along with OES FTP's syntax needs. But at the very least, an OES machine itself should have a FTP client that can use this OES FTP feature.