Re: FTP suddenly stopped working

On 16-Oct-2014 07:13 -0500, Pam Gutowski wrote:

We have a nightly process that has been running for 10+ years and
suddenly it stopped working.
The process builds a file called AIRRES on our local iSeries and
saves it to the IFS in /QDLS/MESSAGES, then FTP's it overseas to our
Bangkok server. The file is being successfully created on our local
IFS but FTP fails.

Here is the log:

≥ NAMEFMT 1
500 'SITE NAMEFMT 1': command not understood
Client NAMEFMT is 1.
Enter an FTP subcommand.
≥ LCD /QDLS
Error occurred when resolving a path name.
Enter an FTP subcommand.
≥ LCD MESSAGES
Unknown extension in database file name.
Enter an FTP subcommand.
≥ PUT AIRRES.TXT
Unknown extension in database file name.
Enter an FTP subcommand.
≥ QUIT
221

The first thing I would do [although mostly cosmetic] is change the first subcommand request [from the "NAMEFMT 1"] to the following request, to prevent the FTP server from issuing an error [manifest as the FTP500 "command not understood" shown]; saves the client ever sending a request to the server for something expected to fail:
LOCSITE NAMEFMT 1

The error msg TCP10A5 "Error occurred when resolving a path name" is somewhat generic [for possible origins], but the FTP client joblog should show the error that gave origin to that condition being diagnosed; the "Recovery" of that message should even suggest something like "Refer to any previous messages in the joblog; correct the condition, and try the failing operation again."

The error msg TCP12C7 "Unknown extension in database file name", shown twice after the first failed LCD, are merely a side effect of the prior failure with the first LCD request; they can be ignored. However I will explain further: That error for the second LCD and the PUT requests are a side effect of the FTP client starting with both the NAMEFMT=1 established and having a Current Directory of *CURLIB. Both the LCD and LOCSTAT subcommands, if issued without any parameters and issued after the first failed LCD, would indicate that the client FTP session had not modified the Local CD of the job since the default of /QSYS.LIB/CurLib.LIB [where "CurLib" is the resolved value of the special value *CURLIB for the client FTP job] was established for NAMEFMT=0. Because the IFS naming is in effect [per NAMEFMT=1], because the second LCD to somewhere other than a within a /QSYS.LIB library (*LIB) object had failed, and because the Local Current Directory remains within the /QSYS.LIB file system, a valid "extension" must be specified on various subcommands [such as LCD and PUT] in order for those requests to pass syntax-checking rules; the TCP12C7 message further describes the extension requirements. Unfortunately the possibly confusing syntax message is issued to the user, instead of what might seemingly be a more obvious error [from the perspective of that user] being reported to the user within that failing script; e.g. "Cannot change directory to MESSAGES.FILE" might make the situation seem clearer [to some users, yet possibly just as confusing to others].?

FWiW: If there is no restriction for which establishing the local directory must be done with two separate requests, the two LCD requests could be combined; setting of the Local CD, effected with solely the one subcommand request:
LCD /QDLS/MESSAGES

The most common cause that I recall for error messages with the /QDLS file system is the error msg CPF9006 "User not enrolled in system distribution directory." If that is\was the cause of the above issue, then the joblog of the job running as the IBM i FTP client would show that error message being sent from the program QOKGETD [symptom kwd F/QOKGETD]. The expected result for the FTP client error would be for that feature to manifest the access failure with the msg TCP10A5 "Error occurred when resolving a path name", _just as shown_ transpired, in the quoted script\session output included above. If CPF9006 was the error in the joblog, then best to verify that the client FTP request was running under the expected user profile, and that the user profile being used for the job is properly registered\enrolled in the System Distribution Directory; Add Distribution Directory Entry (ADDDIRE) to add an entry if they are not enrolled, though typically reviewed first with the Work With Directory Entries (WRKDIRE). After enrollment is verified, verify that the specific user can access both the directory and the named document, outside of the FTP. Any errors for access outside the FTP probably more directly diagnose the issue(s), thus eliminating the FTP client from the scenario\investigation. If CPF9006 was not the error in the joblog of the FTP client, then review instead, how to resolve whatever was the error msg logged in the FTP client joblog.

Note: I replied to the original\improper newsgroup and to the appropriate forum [cross-posted], with /followup/ set to the latter group\forum.