Diagnosing FTP client problems with tracing

You can activate tracing on startup by doing the following:

Coding DEBUG statements in FTP.DATA. See the DEBUG statement in z/OS Communications Server: IP Configuration Reference for more information.
Starting the FTP client with the -d command-line option. See z/OS Communications Server: IP User's Guide and Commands for more information about the FTP environment.

Alternatively, you can activate tracing by toggling tracing on or off during an FTP session with the DEBUG subcommand.

You can activate FTP client extended trace at startup by coding one or more DUMP statements in FTP.DATA. See the DUMP statement in z/OS Communications Server: IP Configuration Reference for more information. Alternatively, you can toggle extended tracing on or off during an FTP session with the DUMP subcommand.

The DEBUG and DUMP subcommands activate the general and the extended levels of tracing. The general tracing shows key events in the processing of a subcommand (for example, the opening of a file) and the extended trace shows data areas that are used during processing. The extended trace produces large amounts of output and should be used at the direction of IBM® service team. The format of DEBUG allows multiple parameters to be specified on one subcommand. See z/OS Communications Server: IP User's Guide and Commands for the syntax and parameters for the DEBUG and DUMP subcommands.

For example, the following sequence of subcommands would set traces:

DEBUG ACC SQL      *Activates the ACC and SQL traces
DEBUG BAS          *Activates the default traces 
                   *CMD, INT, FSC, and SOC in addition 
                   *to the two already set
DEBUG              *Resets all tracing

When running FTP interactively or from a REXX exec, all tracing goes to the terminal unless output is redirected. When running FTP from a TSO batch job, all tracing goes to SYSOUT.

Use the following checklist to diagnosis FTP client problems with tracing:

Ensure that the user has properly allocated the DDNAME being referred to. The TSO LISTALC STAT HIST command can be helpful in debugging allocations. Also, ensure that the allocations are correct. For example, if a file already exists, the disposition should not be new.
Ensure that DDNAMEs are only used to refer to local files. For example, get //DD:FTP01 FILEONE is not valid because it attempts to use a DDNAME to refer to a host file. If you try to use a DDNAME for a remote file name, the name is sent to the remote host for processing as it is. If the remote host actually has a file named //DD:FTP01, then that file would be referred to, but most likely the remote host would reject it as a file name that is not valid.

To find attempts to access files by DDNAME, look for DD: in FTP trace output as shown below:

MF0573 seq_open_file: OSTN -> w,recfm=*,NOSEEK for dd:FTP02                    
MF0663 seq_open_fle: ddname FTP02 has filename USER1.CCPYXLMT                  
MF0669 seq_open_file: set DDNAME characteristics- recfm=90, lrecl=128, blksize=614

Tip: By using DDNAME support, the user is assuming responsibility for correctly allocating and deallocating the DDNAMEs being used.