Controlling general tracing

To control the general trace, enter one of the following:

MODIFY jobname,DEBUG=(option_1,option_2,...,option_n,USERID(filter_name))

MODIFY jobname,DEBUG=(option_1,option_2,...,option_n,IPADDR(filter))

Where options are one of the following:

?

Displays the status of the general traces.

The status of the trace is displayed as a response to all uses of the operator MODIFY DEBUG command. The ? allows you to get the status without making a change.

ACC

Shows the details of the login process.

ALL

Sets all of the trace points.

When the ALL parameter is processed, both the FSC and the SOC trace are set to level 1.

BAS

Sets a select group of traces that offer the best overall details without the copious output generated by certain trace options. Specifying this value is the same as the following:

MODIFY jobname,DEBUG=(CMD,INT,FSC,SOC)

CMD

Shows each command and the parsing of the parameters for the command.

FLO

Shows the flow of control within FTP. It is useful to show which services of FTP are used for an FTP request.

FSC(n)

Shows details of the processing the following file services commands

APPE
STOR
STOU
RETR
DELE
RNFR
RNTO

This trace can be very intense; therefore, it allows you to specify levels of granularity for the trace points. The level 1 tracing that is specified by entering FSC or FSC(1) is the level normally used unless more data is requested by TCP/IP service group. The variable n can be a number in the range 1–8.

Level 1

Covers the major steps of the file services processing, which includes the following:

Entry to a command processor
Determination of the type of file being processed
Choice of allocation method
Choice of open method
Choice of transfer routine
Recognition of end of file or data
Close and deallocation
Call for SMF processing

Level 2

Provides more details for the major steps that are executed. These should be one-time events that enhance the information for the steps of level 1 tracing. An example would be some additional information about the allocation process.

Level 3

Provides trace information of repetitive events that occur during the processing. For example, a trace for each full buffer (180K) of data that is received. Another example is a trace for each restart marker that is sent. The rate of repetition should be low enough that this level does not flood the trace.

Level 4

Provides trace information of repetitive events that occur at a higher rate than those of level 3. For example, a trace for each time data must be moved to the top of a buffer before the next receive_data.

Level 5

Provides trace information of repetitive events that occur at a higher rate than those of level 4. This is the most intense and covers events such as the processing of each block of data.

Tip: This level of tracing produces an extremely large amount of data and should not be used for large file transfers.

INT

The INT trace shows the details of the initialization and termination of the FTP session.

JES

The JES trace shows details of the processing for JES requests, such as when SITE FILETYPE=JES is in effect.

NONE

This value is used to turn off all of the traces.

PAR®

The PAR trace shows details of the FTP command parser. It is useful for debugging problems in the handling of the command parameters.

SEC

The SEC trace shows the processing of security functions such as AT-TLS and GSSAPI negotiations.

SOC(n)

The SOC trace shows details of the processing during the setup of the interface between the FTP application and the network as well as details of the actual amounts of data that is processed. This trace can be very intense; therefore, it allows you to specify levels of granularity for the trace points. The level 1 tracing that is specified by entering SOC or SOC(1) is the level normally used unless more data is requested by the TCP/IP service group. The variable n can be a number from 1 to 8.

Level 1: Covers the major steps of the socket services processing. Connection initiation and closing steps are included.
Level 2: Adds more detail for level 1 events. For example, it traces the three steps that occur when a data connection is closed.
Level 3: The events for this trace are the send() and recv() calls for the data connection.

SQL

Shows details of the processing for SQL requests, such as when SITE FILETYPE=SQL is in effect.

UTL

Shows the processing of utility functions such as CD and SITE.

USERID(filter_name)

Filters the trace for user IDs matching the filter_name pattern.

If the user ID matches the filter at the time the clients log in, their tracing options are set to the current value of the options. Otherwise, tracing options are not set. Clients can use the SITE command to set their options after login if the initial ones are not appropriate. An example for the USERID filter is MODIFY jobname,DEBUG=(CMD,USERID(USER3*)), which activates the CMD trace for a user whose ID starts with USER3.

IPADDR(filter)

This optional parameter filters the trace for IP addresses matching the filter pattern.

If the IP address matches the filter at the time clients connect, its tracing options are set to the current value of the options. Otherwise, tracing options are not be set. Clients can use the SITE command to set their options after connect if the initial ones are not appropriate. An example of the IPADDR filter is MODIFY jobname,DEBUG=(JES,IPADDR(9.67.113.57)), which activates the JES trace for a client whose IP address is 9.67.113.57. Another example is MODIFY jobname,DEBUG=(JES,IPADDR(FEDC:BA98:7654:3210:FEDC:BA98:7654:3210)). This activates the JES trace for a client whose IP address is FEDC:BA98:7654:3210:FEDC:BA98:7654:3210.

If the filter is an IPv4 address, submasking can be indicated by using a slash followed by a dotted decimal submask. For example, 192.48.32/255.255.255.0 allows addresses from 192.48.32.00 to 192.48.32.255.

If the filter is an IPv6 address, network prefixing can be indicated by using a slash followed by a prefix length. For example, FEDC:BA98::0/32 allows all IP addresses from FEDC:BA98::0 to FEDC:BA98:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF.

The specification of the trace on the MODIFY operator command is not additive. That is, the trace setting is that of the last MODIFY operator command. For example:

  MODIFY FTPDJG1,DEBUG=(NONE)
  +EZYFT82I Active traces: NONE
  MODIFY FTPDJG1,DEBUG=(CMD)
  +EZYFT82I Active traces: CMD
  MODIFY FTPDJG1,DEBUG=(FSC,USERID(USER33))
  +EZYFT82I Active traces: FSC(1)
  +EZYFT89I Userid filter: USER33
  MODIFY FTPDJG1,DEBUG=(SOC)
  +EZYFT82I Active traces: SOC(1)

Guidelines: The following are some guidelines to use for migrating from previous versions of the MODIFY operator command :

MODIFY jobname,TRACE
This is still accepted and is equivalent to MODIFY jobname,DEBUG=(BAS). The old response message EZY2704I is replaced by EZYFT82I.
MODIFY jobname,NOTRACE
This is still accepted and is equivalent to MODIFY jobname,DEBUG=(NONE). The old response message EZY2705I is replaced by EZYFT82I.
MODIFY jobname,JTRACE
This is still accepted and is equivalent to MODIFY jobname,DEBUG=(CMD,FSC,JES). The old response message EZY2710I is replaced by EZYFT82I.
MODIFY jobname,NOJTRACE
This is still accepted and is equivalent to MODIFY jobname,DEBUG=(NONE). The old response message EZY2711I is replaced by EZYFT82I.
MODIFY jobname,UTRACE=USER33
This is rejected as an obsolete command. Its function can be replaced with the following pair of commands:
```
  MODIFY jobname,DEBUG=(ALL,USERID(USER33))
  MODIFY jobname,DUMP=(ALL,USERID(USER33))
```
The use of the ALL parameter can produce an extensive amount of trace data and should not be specified on a routine basis.
MODIFY jobname,NOUTRACE
This is rejected as an obsolete command. If complete tracing was activated as suggested in the previous step, then the tracing can be stopped as follows:
```
  MODIFY jobname,DEBUG=(NONE)
  MODIFY jobname,DUMP=(NONE)
```