The z/OS Communications Server FTP client and server both record FTP transfers in SMF 119 type records. The records contain a wealth of information about the IP partners, the userid, and the datasets or files involved. In many cases, the SMF records will tell you all you need to know about FTP activity in your enterprise.
To rely exclusively on SMF records, however, leaves you exposed to several blind spots.
Not all transfer attempts are recorded.
If a data transfer is not initiated, no SMF record is cut by either the z/OS FTP client or server. For example, a request that fails because of a syntax error, or because a non-existent dataset was requested, will not be recorded. More seriously, a request that is rejected by RACF dataset security because the user tried to transmit a sensitive file or dataset, will not be recorded in SMF as a transfer request.
If the z/OS client is run in batch and the job is canceled before transfer completion, no SMF record is cut by the client. A savvy user who is aware of this loophole could conceivably cover his tracks by transmitting a sensitive file, monitoring the transfer progress, and then canceling the job before the transfer completes.
SMF does not record a transfer’s Confidence of Success
In z/OS Communications Server V1R7, IBM added a new concept to FTP monitoring. A transfer’s “confidence of success” is a measure of the client or server’s confidence that the data was all transferred and stored successfully in the target host’s file system.
A high confidence of success indicates a successful transfer.
A low confidence of success indicates a request that failed, either immediately or in flight.
The infrequently seen NoEOF confidence of success indicates that the data connection was closed gracefully and all received data was stored, but an expected end-of-file marker was not seen by the FTP server.
The confidence of success is given a numeric value and communicated to the FTPOSTPR Post-Processing user exit by the FTP server. If FTPLOGGING is configured, the server will also log message EZYFS86I to syslog showing the confidence of success. The client issues message EZA2108I showing confidence of success.
Confidence of success is not included in SMF 119 transfer records written by either the z/OS FTP client or server.
Reply codes are not enough
Why do I care about “confidence of success” when I can judge a transfer’s success or failure by the reply code, which is included in the SMF 119 record? After all, if the reply code starts with a “4” or “5”, I know the transfer failed, and if it starts with a “1” or “2”, I know it was successful, right?
Not always. Consider the following example: