Does SFTP support GDG datasets with relative generation numbers?
I have tried creating a dataset with (+1) and it works the first time but not when I try it again to create another.
I tried to GET using (0) and it didn't work. DEL with (0) also doesn't work.
I just need to know if this is supported.
Jerry Roman
SFTP GDG Support
GDGs are supported. Which version of Co: SFTP are you using? Is this a problem with the client or the server?
- I'm not sure why you are getting an error with get gdg.name(0). Could you post the log messages that you get from the cozsftp client (or the error log from the Co:Z sftp-server, depending on whether you mean the client or the server).
- for put x gdg.name(+1) - it is probably failing because the default disposition for gdg +x allocation is "new catalog", but the default dynamic allocation setting is "nogdgnt". Look at your log messages to be sure. You can use the /+gdgnt setting to cause dynamic allocation to use the latest catalog information, so that +1 is always a new goovoo.
Note: to get the log messages from the Co:Z sftp-server, you can do this from a remote client (in the same session, after doing something that you want to see log messages for).
get /+error.log error.log
Hope this helps. If not, please post your log messages and we'll take a look.
- I'm not sure why you are getting an error with get gdg.name(0). Could you post the log messages that you get from the cozsftp client (or the error log from the Co:Z sftp-server, depending on whether you mean the client or the server).
- for put x gdg.name(+1) - it is probably failing because the default disposition for gdg +x allocation is "new catalog", but the default dynamic allocation setting is "nogdgnt". Look at your log messages to be sure. You can use the /+gdgnt setting to cause dynamic allocation to use the latest catalog information, so that +1 is always a new goovoo.
Note: to get the log messages from the Co:Z sftp-server, you can do this from a remote client (in the same session, after doing something that you want to see log messages for).
get /+error.log error.log
Hope this helps. If not, please post your log messages and we'll take a look.
Sorry for the confusion. This is a question regarding the server. Also, I just found out that it's not a problem with GET or PUT. They are trying a delete command. Here is an example:
del //u163284.ftps.ath016(0)
They get a failure message on their client. If they specify the full dataset name with the g0000v00, then they are able to delete it.
Here are the messages from the server log:
[00039] debug3: request 256: realpath
[00039] realpath "//u163284.ftps.ath016(0)"
CatalogSearch[D]: -> setFilterKey(U163284.FTPS.ATH016)
CatalogSearch[D]: <- setFilterKey()
CatalogSearch[T]: -> search()
CatalogSearch[T]: search: total_length=1024, min_required=0, used=168, num_f\
ields_plus_one=3, resume=
CatalogSearch[T]: <- search()
[00060] debug1: request 256: sent names count 1
[00339] debug3: request 256: remove
[00339] remove name "//U163284.FTPS.ATH016(0)"
ZosUtil[T]: -> zos_remove(//U163284.FTPS.ATH016(0))
CatalogSearch[D]: -> setFilterKey(U163284.FTPS.ATH016)
CatalogSearch[D]: <- setFilterKey()
CatalogSearch[T]: -> search()
CatalogSearch[T]: search: total_length=1024, min_required=0, used=168, num_f\
ields_plus_one=3, resume=
CatalogSearch[T]: <- search()
ZosUtil[E]: Remove failed. "//U163284.FTPS.ATH016(0)" does not exist.
ZosUtil[T]: <- zos_remove(rc=-1)
[00364] debug3: request 256: sent status 4
[00364] sent status Failure
Jerry Roman
del //u163284.ftps.ath016(0)
They get a failure message on their client. If they specify the full dataset name with the g0000v00, then they are able to delete it.
Here are the messages from the server log:
[00039] debug3: request 256: realpath
[00039] realpath "//u163284.ftps.ath016(0)"
CatalogSearch[D]: -> setFilterKey(U163284.FTPS.ATH016)
CatalogSearch[D]: <- setFilterKey()
CatalogSearch[T]: -> search()
CatalogSearch[T]: search: total_length=1024, min_required=0, used=168, num_f\
ields_plus_one=3, resume=
CatalogSearch[T]: <- search()
[00060] debug1: request 256: sent names count 1
[00339] debug3: request 256: remove
[00339] remove name "//U163284.FTPS.ATH016(0)"
ZosUtil[T]: -> zos_remove(//U163284.FTPS.ATH016(0))
CatalogSearch[D]: -> setFilterKey(U163284.FTPS.ATH016)
CatalogSearch[D]: <- setFilterKey()
CatalogSearch[T]: -> search()
CatalogSearch[T]: search: total_length=1024, min_required=0, used=168, num_f\
ields_plus_one=3, resume=
CatalogSearch[T]: <- search()
ZosUtil[E]: Remove failed. "//U163284.FTPS.ATH016(0)" does not exist.
ZosUtil[T]: <- zos_remove(rc=-1)
[00364] debug3: request 256: sent status 4
[00364] sent status Failure
Jerry Roman
Jerry,
Thanks for clarifying. We currently use the IBM C library functions for delete and rename, and these don't seem to support GDG relative references.
We will add this to our wishlist of future improvements, but I can't commit to any timeframe right now (unless you were to sign up as a commercial support customer).
Please contact us if you have any more questions.
Kirk Wolf
636.300.0901
Thanks for clarifying. We currently use the IBM C library functions for delete and rename, and these don't seem to support GDG relative references.
We will add this to our wishlist of future improvements, but I can't commit to any timeframe right now (unless you were to sign up as a commercial support customer).
Please contact us if you have any more questions.
Kirk Wolf
636.300.0901