MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2013

Re: IFS, not quite Integrated Was: Unix??? was: ftp: mget specifying path names



fixed

On 01 Feb 2013 13:09, rob@xxxxxxxxx wrote:
On 01 Feb 2013 12:16, CRPence wrote:
The ".savf" file extension for the /qsys.lib file system is an
extension of the IBM i FTP server.
Pre-create the save file and replace the ".savf" with ".file" on
the name specification.

Sounds a lot like
<snip>
Doing all that BS we used to have to do with namefmt 0, like making
sure the save file already exists and whatnot doesn't help.
</snip>

But maybe I misheard you.

Early in the second sentence I was just confirming that "all that BS ... with namefmt 0" would probably be required. That is because an FTP server that is not the IBM i FTP server would likely have no concept of the special meaning of the private file-extension ".savf", as alluded in the first sentence.

Later in the second sentence I was suggesting to abandon that special i-specific file-extension of ".savf", and try using ".file" instead.

The idea being, that a WRKLNK '/qsys.lib/rob.lib/rob*' will show "ROB.FILE" as type=FILE and attribute=SAVF. An "extension of the IBM i FTP server" for its capability to recognize the ".SAVF" as a special file-extension is not something one should expect to see supported outside the IBM i FTP server [and the IBM i FTP client]. That the "ROB.FILE" will not be a "directory", whereas a file with attribute PF would be a "directory", we might expect we could write to "ROB.FILE" just as we should be able to write to a "ROB.USRSPC" given we know a write method is supported for each; e.g. the CPY command happily moves the data between them.

So I verified I used .file instead of .savf

cd /qsys.lib/rob.lib
250 Directory changed to /qsys.lib/rob.lib
locsite namefmt 1
Client NAMEFMT is 1.
lcd /qsys.lib/rob.lib
Local working directory is /QSYS.LIB/ROB.LIB
bin
200 Command TYPE okay.
put rob.file
229 Entering Passive Mode (|||24356|)
150 File status okay; about to open data connection.
Unable to send data to server.
551 /qsys.lib/rob.lib/rob: Error on output file.
501 Invalid character in command

Yes, but the above use of ".file" [instead of ".savf"] was only done for the client file name. The interest was not in the client naming, but the naming for the file at the server; i.e. the "output file" naming for which an error is diagnosed.

While one could assume that the "put rob.file" request had the server receiving the name "rob.file" for the target, that is difficult to know. The "/qsys.lib/rob.lib/rob:" in the FTP551 seems improbable to have been caused by the ":" as an invalid character passed from the client; we are left to assume that the colon *may* represent a position of the first invalid character and thus presume was the period from "rob.file", or that the colon is just a separator character used in the message.? Seems improbable also that the complete name "rob" was passed by the client and then used by the server, because then the more likely error would seem to be for an incomplete name specification rather than for an invalid character in that name.? No matter, presumably a name error is what is being diagnosed by the FTP501 "Invalid character in" the PUT subcommand request; perhaps clarified by the prior FTP551 that the issue is the target "output file" name. The actual documentation for the FTP server being utilized might be helpful too, to clarify the conditions for which the "501 Invalid character in command" is issued and clarify the text returned with the 551 error; and perhaps clarify about the two 5xx messages instead of just one.

What I had shown instead, as what I thought should be tried, was that the server should be told explicitly that the extension for the target of the PUT is .file; i.e. as in the following request from my earlier reply:


put /mypcdir/downloaded.savf /qsys.lib/mylib.lib/downloaded.file


Thus for the above quoted FTP script showing the two 5xx errors, rather than having made the request "put rob.file", the equivalent for what I had suggested to request would be the first of the following examples, although the additional two examples also explicitly name the target "output file"; and together the three show how the IBM i FTP client accepts alternate namings to locate the data in the save file:
put rob.savf rob.file
put rob.file rob.file
put rob.file/anything.mbr rob.file

FWiW: I think somewhat telling might be what the server returns for requests of LS and DIR [may be the same; but just the details for the ROB file rather than everything in ROB lib], each having been performed since the current directory got established as /qsys.lib/rob.lib Does that appear as ROB.FILE like with WRKLNK, or something else? Does the server indicate that file is not a directory but a PF is; e.g. something like this:
≥ -rwx------ 1 ROB 0 1609728 Dec 21 08:07 ROB.FILE ≤
≥ drwx------ 1 ROB 0 24576 Feb 01 23:09 MYPF.FILE ≤

FWiW: The FTP server may have a debugging feature that would hopefully produce output showing more details about the requests versus just the error messages returned. For sure the IBM i FTP client has the DEBUG subcommand, but that might not be as helpful as what the server might reveal if it could and would. I know some other FTP clients that I have used have been more verbose than the IBM i FTP client when using their debug features.

FWiW: While I harbor a suspicion that the request might just fail eventually for another reason, there is a chance that given the proper invocation, the request could function. Given the server actually gets to the point that writing data can start, writing to the save file will require that the stream write activity is managed as effective fixed-length records. While that is not something a generic stream write of binary data would negotiate in advance [like an FTP server specific to the IBM i might], I suspect that the data management could accomplish that implicitly; e.g. if the stream data gets written repeatedly as a large amount of data but the writer is informed that each write has accepted only 528 bytes, the writer may repeat writing the remainder of the large amount of data until done, and that would look to the LIC Dump component the same as if each write had been for a fixed-length record. We have no idea what might happen, because getting past the FTP501 is required, in order to get to that.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact