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:
EZA1736I get 'SDSD.O31.BUG1215.DMP00023' 'BSSJ1.ABENDX37'
EZA1701I >>> PORT 10,14,0,1,4,54
200 Port request OK.
EZA1701I >>> RETR 'SDSD.O31.BUG1215.DMP00023'
125 Sending data set SDSD.O31.BUG1215.DMP00023
EZA1490I Error writing to data set
EZA1735I Std Return Code = 16426, Error Code = 00020
EZA2606W File I/O error 1001
EZA2805W System completion code and reason: D37-04
EZA2804W Data set is out of space.
EZA1690W Failure attempting to close the local data set
>>>ABOR
426 Connection closed; transfer aborted.
226 Abort successful.
In this case, the FTP client is retrieving a dataset from a z/OS FTP server when the local dataset fills up and the transfer ends with a D37 abend. As required by RFC 959, the client sends an ABOR command to tell the server to abort the transfer. The server closes the data connection and replies 446 to indicate that the transfer is aborted. But look what happens next: on the last line, we see the server replies to the ABOR command with a 226 reply code. Although the transfer failed, the abort operation was a success.
Guess which reply code the server records in the SMF record? The reply code field in the FTP Server Transfer Completion record (SMF Type 119, Subtype 70) is documented to be the “Last reply code to client,” and, in fact, that is just what is recorded in this case: 226.
The confidence of success reported to the FTPOSTPR exit is low. But remember: confidence of success is not recorded in SMF.
Steven St.Jean, head of product development, SDS, Feb. 2012
Free Demo/Trial
We offer individualized product demonstrations by request. Your organization can also try SDS Software on your system for 30 days, free of charge.
Contact SDS
Phone: (800) 443-6183
Phone: (763) 571-9000
200 Village Center Drive, Suite 250
North Oaks, MN 55127
USA