CHGFTPA NAMEFMT(*PATH) CURDIR(*HOMEDIR)
Much like doing FTP from command line and then use NAMEFMT 1 to switch from the library/file format on a put to doing a /qsys.lib/mkslib.lib/xyz.savf format.
When trying to distribute to a system set up like this failure is the end result.
Please do not try to workaround this by using
in the MKS ftp scripts. Why? Because our target system is also using GoAnywhere and it's setup to keep you in the namefmt 1 situation and if you try the command namefmt 0 it will tell you unpleasant things.
Implementer currently only supports the use of the built-in IBM i FTP server.
We do not have an integration with GoAnywhere but wonder if there is a setting in that configuration that will accept switching to NAMEFMT 0 ?
Thanks for your cooperation.
Can I get a copy of a sample script so that I may run it by GoAnywhere to see how we can do this?
Since this is specific to your systems, we will be logging a case and working with you individually.
I've talked to GoAnywhere.
Let's say that Implementer uses a sample script like:
QUOTE SITE NAMEFMT 0
QUOTE RCMD CRTLIB RMTLIB
QUOTE RCMD CRTSAVF RMTLIB/RMTFILE
QUOTE RCMD CLRSAVF RMTLIB/RMTFILE
PUT LOCLIB/LOCFILE RMTLIB/RMTFILE
GoAnywhere will not allow that and has no plans to ever allow commands like this. They view this as a security breach. Their recommended technique is to drop a file and trigger a process to run based on that file being dropped. I seriously doubt that PTC is interested in coming up with such a process and I can't say as I blame them.
An alternative is to configure an alternative IP address for use by PTC. And do not have GoAnywhere monitor that IP address.
The third alternative is to no longer have PTC propagate to this lpar. We may choose to go that route.
Implementer's file transfer mechanism is certified to work with the IBM i stock FTP server.