How can I use LANSA/Integrator FTPService to send a file to a Windows Server
Posted: Fri Apr 22, 2022 6:25 am
Using LANSA V15 RDMLX installation on IBMi, using FTP Service to transfer a 40MB file to a Windows Server. The Windows Server is actually an Azure cloud running Windows 2019 DataCenter and the FTP Server bundled with IIS10. We control both ftp client and ftp server settings.
I can use ftp command entry to transfer the file successfully but the LANSA/Integrator RDMLX function doing the same steps fails.
The specific issue seems to be the SITE command listed here : https://docs.lansa.com/15/en/lansa093/i ... 7_1290.htm
By default on IBMi ftp, there is a SITE format for client and server. The client format defaults to 0 (meaning library format naming) . SITE NAMEFMT is not a command understood by a Windows Server, so I use LOCSITE NAMEFMT 1 in the ftp command entry to set the client NAMEFMT and avoid a Command Not understood error when I use NAMEFMT 1 which attempts to reset the Name Format for ftp client and ftp server.
I have 2 questions :
1) Should L/I have ignored the SITE command error and continued with the PUT. The L/I trace for PUT after the SITE Command returned an error seems to indicate that it didn't understand where to get the file from, perhaps because the SITE command didn't really work. I couldn't find a L/I FTPService command to check the NAMEFMT setting on FTP Client after running the SITE command
2) How to specify LOCSITE NAMEFMT 1 in the FTPService, which does not return an error when connecting to a Windows FTP Server because it only changes the FTP Client NAMEFMT
I have attached a zip with both logs. removing any customer identification information such as IP addresses and userids
My current workaround is to have LANSA RDXML call a CL driven Batch FTP Script where I manually set LOCSITE NAMEFMT 1 and the ftp works. but it's not ideal in passing in parameters to the script or reading the log programatically to verify that the ftp completed ok
I can use ftp command entry to transfer the file successfully but the LANSA/Integrator RDMLX function doing the same steps fails.
The specific issue seems to be the SITE command listed here : https://docs.lansa.com/15/en/lansa093/i ... 7_1290.htm
By default on IBMi ftp, there is a SITE format for client and server. The client format defaults to 0 (meaning library format naming) . SITE NAMEFMT is not a command understood by a Windows Server, so I use LOCSITE NAMEFMT 1 in the ftp command entry to set the client NAMEFMT and avoid a Command Not understood error when I use NAMEFMT 1 which attempts to reset the Name Format for ftp client and ftp server.
I have 2 questions :
1) Should L/I have ignored the SITE command error and continued with the PUT. The L/I trace for PUT after the SITE Command returned an error seems to indicate that it didn't understand where to get the file from, perhaps because the SITE command didn't really work. I couldn't find a L/I FTPService command to check the NAMEFMT setting on FTP Client after running the SITE command
2) How to specify LOCSITE NAMEFMT 1 in the FTPService, which does not return an error when connecting to a Windows FTP Server because it only changes the FTP Client NAMEFMT
I have attached a zip with both logs. removing any customer identification information such as IP addresses and userids
My current workaround is to have LANSA RDXML call a CL driven Batch FTP Script where I manually set LOCSITE NAMEFMT 1 and the ftp works. but it's not ideal in passing in parameters to the script or reading the log programatically to verify that the ftp completed ok