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.
midrange.com
