Accessing Members in sshftp

[mvsroot]

Hello,

I am trying to edit a member of a data set mounted with sshfs. I doesn't work because all member sizes are set to 0 bytes.
If I connect with a sftp client to our mainframe and list all members of a dataset the list looks like:
BPXBATCH 7 2002/10/31 2006/07/19 15:48:49 AL13808
if I use ls -l BPXBATCH I get the following result:
-rw-rw-rw- 0 0 0 0 Jan 1 1970 BPXBATCH
sshfs shows more or less the same result:
-rw-rw-rw- 1 root root 0 1. Jan 1970 BPXBATCH

Is it possible to get a result like (LRECL=80):
-rw-rw-rw- 1 AL13808 root 560 19. Jul 2006 BPXBATCH ?

Thanks
Dirk

[dovetail]

The Co:Z SFTP server doesn't currently show members sizes in bytes since this information is not in the PDS directory. If there are ISPF statistics, then there would be line counts, but we currently don't use these to estimate byte counts. Your suggestion is to use the ISPF line counts, if they exist, to estimate byte counts. We have considered this, but it doesn't solve the entire problem since we also don't create ISPF statistics when we write a member.

So, support for PDSs in Co:Z SFTP is not as complete as we would like. Much of the work is more difficult than it should be, since we rely on the IBM C Library for dataset I/O and it has poor support for partitioned datasets.

BTW: Co:Z SFTP does estimate dataset sizes, but it is only an estimate since the actual transfer often involves conversion of records into lines, trimming trailing spaces, adding line separators, etc.

[mvsroot]

Thanks for your answer.
Isn't it better to set the size to 1 instead of 0 to avoid the empty file error message? I hope the client reads until eof instead of using the file size.

[dovetail]

Yes, I suppose that we could do this:

- estimate the size when ISPF stats are present
- use 1 instead of 0 otherwise.

Do you think that this would make sshfs work OK? It probably wouldn't be that difficult for us to test.

[mvsroot]

I hope so. I can test it if you send me a changed version. Source of sshfs is available but I think testing is easier than debugging

[dovetail]

I can't promise when we can get to this, but I would hope to be able to get it into the next release since it is a pretty minor change.

[dovetail]

As you might notice, we released a new release last week that didn't address this issue.

Here's why:

What we do now for files that we cannot provide a size estimate (currently including PDS members) is to not return any size. The file size is an optional field in the SFTP packet, and we clear a bit to indicate that a size estimate is not provided.

The issue in this case is that many sftp clients (apparently sshfs included) use "0" if a size is not provided. Perhaps this is a bug that should be reported to the open source sshfs team?

We generally think that it may not be good to provide a "1" as a size estimate rather than what we are doing (not providing any size). What I would prefer to do for PDS members is to actually provide a file size estimate where we can, which is a little more difficult and somewhat unappealing, since the directory doesn't have a member size except in the case where ISPF statistics exist and then only "lines" are available.

Even more frustrating is the fact that the C library, which we use for dataset I/O, has no support for creating or updating user-info (such as ISPF statistics) in the directory, which is also something that we would like to address.

[mvsroot]

Thanks for the answer. I am in St. Louis for vacation at the moment so I haven't noticed that there is a new version. I can take a look into the source of sshfs and/or try to contact the author when I am back in the office after Oct. 12. But I think it would be a better solution to add a shell variable which can change the behavior from your described one the the first proposal of setting it to 1. What do you think about it?