Upon upgrade to 5.13, from 5.11 in my case, PUTs to Tectia SSH zOS server fail, "ftadv" problem
PUT -resumesupport=off -nopreservetime "C:\Ambros\br14.txt" "/ftadv:P=BIN,lrecl=128,recfm=fb/___TS72TMA.WS513.TEST(mob100im)"
Using this "Advice string" directive to Tectia no longer works, real path is obtained twice
Before the PUT is encountered - behavior as before
. 2018-04-10 14:08:59.774 Getting real path for '.'
> 2018-04-10 14:08:59.774 Type: SSH_FXP_REALPATH, Size: 10, Number: 16
. 2018-04-10 14:08:59.941 Real path is '/u/ts72tma'
Then this
> 2018-04-10 14:08:59.944 Script: PUT -resumesupport=off -nopreservetime "C:\Ambros\br14.txt" "/ftadv:P=BIN,lrecl=128,recfm=fb/___TS72TMA.WS513.TEST(mob100im)"
Then this
. 2018-04-10 14:08:59.947 Getting real path for '/ftadv:P=BIN,lrecl=128,recfm=fb/'
> 2018-04-10 14:08:59.948 Type: SSH_FXP_REALPATH, Size: 41, Number: 272
Then this
. 2018-04-10 14:09:00.255 Real path is '/FTADV:P=BIN,lrecl=128,recfm=fb/_u/ts72tma'
The construct like that with Tectia is to have a string that looks like a valid directory and file path but the ftadv is a keyword that causes Tectia to strip and affect the eventual dataset attributes. What results is that the transfer goes into the home directory of the userid on the zOS side instead of to the dataset as before.
Is there a syntax change that we are not up to date on as to how we code that advice string and maybe need to escape something or look at an alternate form of coding that Tectia provides for it... can you point us to what is causing this to happen?
Unfortunately this is hitting some of our apps as they automated uploads from their machines and the rollout was widespread today...
UPDATE: We found a workaround...
Changing the PUT to this format:
PUT -resumesupport=off -nopreservetime "C:\Ambros\WinSCP3.txt" /ftadv:P=BIN,lrecl=128,recfm=fb/_//TS72TMA.WS513.TEST(mob100im)
doesn't avoid the extra SSH_FXP_REALPATH but it fools the partners into working with the right output dataset name.
What changed? I didn't see anything in the release notes that would lead me to this...
Using this "Advice string" directive to Tectia no longer works, real path is obtained twice
Before the PUT is encountered - behavior as before
. 2018-04-10 14:08:59.774 Getting real path for '.'
> 2018-04-10 14:08:59.774 Type: SSH_FXP_REALPATH, Size: 10, Number: 16
. 2018-04-10 14:08:59.941 Real path is '/u/ts72tma'
Then this
> 2018-04-10 14:08:59.944 Script: PUT -resumesupport=off -nopreservetime "C:\Ambros\br14.txt" "/ftadv:P=BIN,lrecl=128,recfm=fb/___TS72TMA.WS513.TEST(mob100im)"
Then this
. 2018-04-10 14:08:59.947 Getting real path for '/ftadv:P=BIN,lrecl=128,recfm=fb/'
> 2018-04-10 14:08:59.948 Type: SSH_FXP_REALPATH, Size: 41, Number: 272
Then this
. 2018-04-10 14:09:00.255 Real path is '/FTADV:P=BIN,lrecl=128,recfm=fb/_u/ts72tma'
The construct like that with Tectia is to have a string that looks like a valid directory and file path but the ftadv is a keyword that causes Tectia to strip and affect the eventual dataset attributes. What results is that the transfer goes into the home directory of the userid on the zOS side instead of to the dataset as before.
Is there a syntax change that we are not up to date on as to how we code that advice string and maybe need to escape something or look at an alternate form of coding that Tectia provides for it... can you point us to what is causing this to happen?
Unfortunately this is hitting some of our apps as they automated uploads from their machines and the rollout was widespread today...
UPDATE: We found a workaround...
Changing the PUT to this format:
PUT -resumesupport=off -nopreservetime "C:\Ambros\WinSCP3.txt" /ftadv:P=BIN,lrecl=128,recfm=fb/_//TS72TMA.WS513.TEST(mob100im)
doesn't avoid the extra SSH_FXP_REALPATH but it fools the partners into working with the right output dataset name.
What changed? I didn't see anything in the release notes that would lead me to this...
