Hello,
I am new to the Co:Z Sftp software and right out of the box my first attempt at using involves an OpenVMS server with an sftp client from Process Software that does not allow specifying a target data set name on the PUT command.
Any suggestions for creative ways around this?
Tried straight put of OpenVMS filename clpb - sftp> put clpb
Also tried - sftp> put clpb.
because the OpenVMS client requires an extension on the filename even if we don't specify one (note the dot after clpb)
Getting some interesting results when trying to do the put after a cd:
sftp> cd /-/SYSLANT.A0CMSPF.CMSINP.VAXEVEN
/-/SYSLANT.A0CMSPF.CMSINP.VAXEVEN
sftp> put clpb
clpb: Unable to stat raw source (no such file)
File does not exist
sftp> put clpb.
/-/SYSLANT.A0CMSPF.CMSINP.VAXEVEN/clpb.: Unable to open destination (permission denied)
Permission denied
Co;Z sftp log:
Co:Z sftp-server version: 1.7.2 (5.0p1) 2010-07-23
Copyright (C) Dovetailed Technologies, LLC. 2008. All rights reserved.
ZosDataset[E]: Open flags not supported: /-/SYSLANT.A0CMSPF.CMSINP/./vaxeven.clpb 0x0093, 0x30001A0
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP..ZOS_CATALOG rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP..ZOS_CATALOG.** rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP..ZOS_CATALOG rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP..ZOS_CATALOG.** rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB. rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB..** rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB. rc=4 ret=122 reas=30
ZosDataset[E]: Open flags not supported: /-/SYSLANT.A0CMSPF.CMSINP.VAXEVEN/./clpb. 0x0093, 0x30001A0
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP.VAXEVEN..ZOS_CATALOG rc=4 ret=122 reas=30
CatalogSearch[W]: CatalogSearchExcepion: IGGCSI00 failed dsn=SYSLANT.A0CMSPF.CMSINP.VAXEVEN..ZOS_CATALOG.** rc=4 ret=122 reas=30
Co:Z Sftp vs Process Software SSH for OpenVMS put cmd
The issue here seems to be that if you set the current directory to a dataset level and then try to upload a file that ends with a period, then that will be an invalid dataset name.
With the SFTP protocol, it is the client that creates the fully qualified target file name, and your client is not creating a name that is a valid dataset name.
Is it possible to upload a file that has an extension?
like:
cd /-/SYSLANT.FOO
put clpb.bar
This should cause your client to create a dataset:
/-/SYSLANT.FOO.clpb.bar
which is a valid dataset name.
I'm also concerned about this message:
ZosDataset[E]: Open flags not supported: /-/SYSLANT.A0CMSPF.CMSINP.VAXEVEN/./clpb. 0x0093, 0x30001A0
This indicates that your sftp client is trying to upen the file with open flags O_RDWR. As with the SSH File transfer spec, we only support O_RDONLY or O_WRONLY.
With the SFTP protocol, it is the client that creates the fully qualified target file name, and your client is not creating a name that is a valid dataset name.
Is it possible to upload a file that has an extension?
like:
cd /-/SYSLANT.FOO
put clpb.bar
This should cause your client to create a dataset:
/-/SYSLANT.FOO.clpb.bar
which is a valid dataset name.
I'm also concerned about this message:
ZosDataset[E]: Open flags not supported: /-/SYSLANT.A0CMSPF.CMSINP.VAXEVEN/./clpb. 0x0093, 0x30001A0
This indicates that your sftp client is trying to upen the file with open flags O_RDWR. As with the SSH File transfer spec, we only support O_RDONLY or O_WRONLY.
It might be possible to make some changes to our SFTP product that would tolerate the behavior of your OpenVMS SFTP client:
- ignore trailing periods on dataset names
- treat O_RDWR open flags as O_WRONLY, and then emit an error if a read is attempted to a write-mode dataset.
Please contact us via email at info@dovetail.com to discuss options.
- ignore trailing periods on dataset names
- treat O_RDWR open flags as O_WRONLY, and then emit an error if a read is attempted to a write-mode dataset.
Please contact us via email at info@dovetail.com to discuss options.
Tried PUT cmd with an extension...
cd /-/syslant.a0cmspf.cmsinp
put vaxeven.clpb
Results from Co:Z log:
Co:Z sftp-server version: 1.7.2 (5.0p1) 2010-07-23
Copyright (C) Dovetailed Technologies, LLC. 2008. All rights reserved.
ZosDataset[E]: Open flags not supported: /-/SYSLANT.A0CMSPF.CMSINP/./vaxeven.clpb 0x0093, 0x30001A0
So I don't think we need to worry about the trailing dot (.) issue... that was just us trying different things to get this to work. Altho, not sure why the log shows /./ in the middle of the data set (OpenVMS client problem perhaps?). When I try this with my PuTTY client the Co:Z log looks like what you would think it should look like:
Co:Z sftp-server version: 1.7.2 (5.0p1) 2010-07-23
Copyright (C) Dovetailed Technologies, LLC. 2008. All rights reserved.
ZosDataset: Opening dataset SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB for write with options: old
ZosDataset: Closing dataset //SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB - 246 bytes received, 2 records written
Discussed OpenVMS sftp client sending O_RDWR with the Process Software vendor. They are checking with their development team. Will update this thread if we hear anything.
Will contact info@dovetail.com on your offer if Process Software can't do anything for us.
Thanks!
cd /-/syslant.a0cmspf.cmsinp
put vaxeven.clpb
Results from Co:Z log:
Co:Z sftp-server version: 1.7.2 (5.0p1) 2010-07-23
Copyright (C) Dovetailed Technologies, LLC. 2008. All rights reserved.
ZosDataset[E]: Open flags not supported: /-/SYSLANT.A0CMSPF.CMSINP/./vaxeven.clpb 0x0093, 0x30001A0
So I don't think we need to worry about the trailing dot (.) issue... that was just us trying different things to get this to work. Altho, not sure why the log shows /./ in the middle of the data set (OpenVMS client problem perhaps?). When I try this with my PuTTY client the Co:Z log looks like what you would think it should look like:
Co:Z sftp-server version: 1.7.2 (5.0p1) 2010-07-23
Copyright (C) Dovetailed Technologies, LLC. 2008. All rights reserved.
ZosDataset: Opening dataset SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB for write with options: old
ZosDataset: Closing dataset //SYSLANT.A0CMSPF.CMSINP.VAXEVEN.CLPB - 246 bytes received, 2 records written
Discussed OpenVMS sftp client sending O_RDWR with the Process Software vendor. They are checking with their development team. Will update this thread if we hear anything.
Will contact info@dovetail.com on your offer if Process Software can't do anything for us.
Thanks!
Reply from the Process Software vendor:
I sent the information you sent to the developer responsible for SFTP. He said that our SFTP client is based upon the F-Secure code.
While we have modified it to run on VMS and provide some VMS specific functionality, it is largely unchanged. The F-Secure implementation does not allow for the specification of a destination file in the user command line interface.
The various SFTP drafts all specified file specifications as Unix-like.
The inclusion of the "-" character in the examples below seems to not fit with the specification. Should it be ".."?
What version of the SFTP draft specification have they implemented? The latest that we implement is version 4, though we recognize the "supported2" and "vendor-id" extension data that are specified in version
6 of the SFTP draft. If they aren't sure what version the server on the IBM system has implemented, they can type
Sftp> status
For information about what version of SFTP has been negotiated and if any vendor information is available.
He just looked through a number of the drafts and could not find anything that specified O_RDONLY or O_WRONLY and stating that O_RDWR might be prohibited. What version of SFTP are they implementing and where are they referring to that some flag combinations may not be allowed?
I sent the information you sent to the developer responsible for SFTP. He said that our SFTP client is based upon the F-Secure code.
While we have modified it to run on VMS and provide some VMS specific functionality, it is largely unchanged. The F-Secure implementation does not allow for the specification of a destination file in the user command line interface.
The various SFTP drafts all specified file specifications as Unix-like.
The inclusion of the "-" character in the examples below seems to not fit with the specification. Should it be ".."?
What version of the SFTP draft specification have they implemented? The latest that we implement is version 4, though we recognize the "supported2" and "vendor-id" extension data that are specified in version
6 of the SFTP draft. If they aren't sure what version the server on the IBM system has implemented, they can type
Sftp> status
For information about what version of SFTP has been negotiated and if any vendor information is available.
He just looked through a number of the drafts and could not find anything that specified O_RDONLY or O_WRONLY and stating that O_RDWR might be prohibited. What version of SFTP are they implementing and where are they referring to that some flag combinations may not be allowed?
The "/./" in the middle of the file name won't be a problem, since this would get eliminated as part of converting a path name to a dataset name.
Assuming that you can deal with file name limitations of this client, the only problem that I see is that the Process Software client is opening a file in O_RDWR (READ+WRITE) mode for a PUT command. We only support z/OS datasets in either READ or WRITE, but not both. Also, it simply seems to me like a misinterpretation of the spec to open a file READ+WRITE for "PUT".
Nevertheless, in theory we could modify our server to accept this flag, yet treat it like WRITE mode (and reject and subsequent read requests). I would be more inclined to do this if I thought that this was a common practice by SFTP clients, but this is the first case that we have seen.
Please contact us offline at info@dovetail.com to discuss options.
Assuming that you can deal with file name limitations of this client, the only problem that I see is that the Process Software client is opening a file in O_RDWR (READ+WRITE) mode for a PUT command. We only support z/OS datasets in either READ or WRITE, but not both. Also, it simply seems to me like a misinterpretation of the spec to open a file READ+WRITE for "PUT".
Nevertheless, in theory we could modify our server to accept this flag, yet treat it like WRITE mode (and reject and subsequent read requests). I would be more inclined to do this if I thought that this was a common practice by SFTP clients, but this is the first case that we have seen.
Please contact us offline at info@dovetail.com to discuss options.