I’m deploying SLES in an IBM System Z environment, and need a Linux FTP server which incorporates “structure record” (as opposed to “structure file”, which is the typical default) support in order to facilitate transfers between z/OS and/or z/VM. I already use such a server in Windows, but the vendor does not offer a Unix variant. Googles haven’t turned up anything definitive. Advice, anyone? Thanks.
My answer is next to useless… but I’m just confirming what you may already have found: The 2 FTP servers which are distributed with SLES (pure-ftpd and vsftpd) do not support record structure. Whether any FTP server does, on Linux, I’m not sure.
Thanks dpartrid, the confirmation is appreciated. I’m having a verbal skirmish with IBM who doesn’t yet appear to understand the situation.
Maybe I am missing something but I am running SLES 11 SP3 servers on System z and they all have vsftp installed and configured. I can initiate FTP’s from z/OS or z/VM to Linux and from Linux to z/OS and z/VM. This thread is the first I remember seeing regarding “a Linux FTP server which incorporates “structure record” (as opposed to “structure file”, which is the typical default)”.
The issue appears at the “native” level e.g. when manipulating z/OS datasets outside of the USS environment. “Structure record” was created for this purpose. In my particular instance, I’m transferring z/OS DF/DSS dump datasets to portable media in the Unix environment for offsiting purposes. Without structure record, if such a dataset is transferred back from the portable media as part of a data recovery/restoration operation, DF/DSS does not recognize it.
Ok, I now understand what you’re doing. I’ve had similar issues with DF/DSS not recognizing its datasets when FTPing between z/OS systems.
I did some Google searches and found a workaround but be advised that I haven’t tested it. The workaround is to use the TERSE program (PGM=TRSMAIN,PARM=PACK) to compress the DFDSS file(s) on z/OS prior to FTPing it to *nix. When the file is needed on z/OS, FTP it back and then run the UNTERSE program (PGM=TRSUNPCK,PARM=UNPACK).
Thanks. I am aware of the terse/unterse alternative; unfortunately, it adds considerably to both the overall duration and CPU resource consumption of the backup process. However, I may have to contemplate it further.