Couple of issues, I hope you don't mind that I put these in a single post:
With CZCHKCMD:
I uncommented:
export SFTP_ZOS_INITIAL_DIR=//
In sftp-server.rc. When I do my initial connect to the sftp server I can issue the command pwd and it has //userid as my current working directory. However, when CZCHKCMD is invoked the filetype/directory is set to HFS. If I issue the command:
cd //userid
When I issue the command pwd it still shows my current directory as //userid. However, when CZCHKCMD is invoked the filetype/directory is set to MVS.
Am I missing something? Since uncommenting the SFTP_ZOS_INITIAL_DIR=// and issuing the command cd //USERID results in the same working directory, why is the filetype/directory not the same.
Second issue is with CZPOSTPR:
It does not seem to be invoked if the transfer has a error. Example: If I issue the command:
put localfile.txt //!USERID.ENV.ZZZZZZZZZZZZZ
It will fail (as it should), but the CZPOSTPR does not seem to be invoked. I have CZPOSTPR setup to issue a WTO that says "success" or "fail". For transfers that work, I get my WTO. A success is if PTRCREA is zero or PTRRCODE is equal to 250. A failure is if PTRCREA is non-zero and PTRRCODE is not equal to 250.
Couple of issues with exits CZPOSTPR and CZCHKCMD
For the first problem (SFTP_ZOS_INITIAL_DIR) -
The SFTP protocol really doesn't have "current directory" as a state. We simulate this in our exit. In the case of SFTP_ZOS_INITIAL_DIR, this is set prior to initialization, so a CHKCMD exit isn't driven for it, which is why it isn't remembered as the "pretend" current directory. This is unfortunate, and we will probably look to change this. It really isn't a severe problem, however, IMO, since we always send full path names or dataset names to exits in Co:Z (see the Co:Z SFTP Exits Guide).... so the pretend current directory is never relevant anyway. From an exit security/completeness point of view, the current directory shouldn't be used to control security, since the user can always use full path names and avoid changing the current directory.
For the second issue (no CZPOSTPR for bad DSN) -
Are you sure that IBM FTP will call this exit in this case? Our testing showed that IBM FTP will not write an SMF record or call the POSTPR exit for situations where the dataset could not be opened. This includes "GETs" for non-existent datasets, and I believe your case. Our goal was to be compatible with IBM FTP.
The SFTP protocol really doesn't have "current directory" as a state. We simulate this in our exit. In the case of SFTP_ZOS_INITIAL_DIR, this is set prior to initialization, so a CHKCMD exit isn't driven for it, which is why it isn't remembered as the "pretend" current directory. This is unfortunate, and we will probably look to change this. It really isn't a severe problem, however, IMO, since we always send full path names or dataset names to exits in Co:Z (see the Co:Z SFTP Exits Guide).... so the pretend current directory is never relevant anyway. From an exit security/completeness point of view, the current directory shouldn't be used to control security, since the user can always use full path names and avoid changing the current directory.
For the second issue (no CZPOSTPR for bad DSN) -
Are you sure that IBM FTP will call this exit in this case? Our testing showed that IBM FTP will not write an SMF record or call the POSTPR exit for situations where the dataset could not be opened. This includes "GETs" for non-existent datasets, and I believe your case. Our goal was to be compatible with IBM FTP.
Couple of issues with exits CZPOSTPR and CZCHKCMD
We use CZCHKCMD to do processing if the file is a MVS file, if it is a HFS I just exit. Since you always pass the full file name> I can change my code is that if it is HFS I will still check the 1st position of the file name for a quote. If there is a quote, I process if no quote I exit.
Today we don't use FTPOSTPR, we use the FTPSMFEX. I was 99% sure that when I was originally testing my FTPSMFEX exit that I sent to a invalid file name and it was invoked. However, I just tired using a invalid file name and the exit was NOT invoked. So I will find another way to force a failure on the transfer.
Thanks for all of the help.
Today we don't use FTPOSTPR, we use the FTPSMFEX. I was 99% sure that when I was originally testing my FTPSMFEX exit that I sent to a invalid file name and it was invoked. However, I just tired using a invalid file name and the exit was NOT invoked. So I will find another way to force a failure on the transfer.
Thanks for all of the help.
Your exit should follow the logic outlined in this post to work properly in all cases:
http://dovetail.com/forum/viewtopic.php?t=963
http://dovetail.com/forum/viewtopic.php?t=963