Send and Receive IFS File Parameters

The following table lists all the parameters in alphabetical order for easy reference as well as provides a brief description. Some command parameter fields with brief descriptions are already listed in the Send and Receive File Parameters section. Please see the Send and Receive File Parameters section if the command parameter is not listed here.

Parameter Description
Class Of Service Name Specifies the name of the Class Of Service used in the transfer. Class Of Service is used to set the send and receive buffer sizes of sockets.
  • blank - Default bracket name is used. Parameters SBUFSIZE and RBUFSIZE contained within brackets. Default name values are used.
  • Class Of Service Name - Name entered in bracket name is used. Located in the Class Of Service Table (CFCOS) that is distributed with the MFT Platform Server product. Parameter values for SBUFSIZE and RBUFSIZE contained within the bracket name that was entered are used.
Compression Sets the data compression to be used for this transfer. Valid values are:
  • None – No data compression
  • LZ – LZ provides better compression ratios and compresses a wider variety of different data types than RLE. Choose LZ if you need better compression ratios and can spare CPU cycles. LZ compression uses a lot of CPU cycles. We strongly suggest using ZLIB compression instead of LZ compression. ZLIB compresses better and uses far fewer CPU cycles.
  • RLE – RLE is more data-dependent than LZ. That is, the compression ratio may vary widely based upon the type of data being compressed. Choose RLE if you network bandwidth is not a critical bottleneck for your network and you need to save CPU cycles.
  • ZLIB – ZLIB Data Compression method is used.
CRC Check Specifies whether the CRC check validation method is used in this transfer. CRC check validation adds an extra layer of security and file integrity. The CRC check validation checks the data sent and received over the network between MFT Platform Server Initiator and Responder Programs.
The CRC check defined to MFT Platform Server for the given remote node via the Work With Node Configuration (CFWRKNET) or Global Parameter Update (CFUPDGLB) command is used. Valid values are:
  • Y - CRC check validation method is used.
  • N - CRC check validation method is not used.

If node name is selected in Connection Type, the CRC check value is retrieved from the MFT Platform Server Node Configuration File record based on the node name selected. If the node name does not exist, a default value is used. If IP address or IP name is selected in Connection Type, the CRC check value is retrieved from the MFT Platform Server Global Parameter File record. But you can override any default value by entering the CRC check value selection in any transfer command.

Local File Options
Specifies whether to create a file and add data records or use an existing file and replace data records when an IFS file is received. Valid values are:
  • C - If the local IFS file does not exist, a local IFS file is created with the name specified in the Local IFS File Path parameter. Then add the received remote IFS file data records to the local IFS file. If the local IFS file does not exist, the command ends with an escape message. In addition to the normal validity checks, the following special condition must all be true for the receive IFS file operation to create the local IFS file.
    • To run this command, you must be authorized to add the local IFS file to the specified path name.
  • R - The received remote IFS file data records replaces all existing records in the local IFS file that is used. The local IFS file is cleared before the received remote IFS file data records are added.

    The local IFS file must exist when this command is executed. A local IFS file is not created to receive the remote IFS file data records, the command ends with an escape message.

  • A - The received remote IFS file data records adds all new records at the end of the local IFS file that is used.

    The local IFS file must exist when this command is executed. A local IFS file is not created to receive the remote IFS file data records. the command ends with an escape message.

  • X - If the local IFS file does not exist, a new local IFS file is created and the remote IFS file data records are added to the local IFS file that is used.

    If the local IFS file does exist, replace all existing records in the local IFS file that is used. The to-ifs file is cleared before the received remote IFS file data records are added.

  • Y - If the local IFS file does not exist, a new local IFS file is created and the received remote IFS file data records are added to the local IFS file that is used. If the local IFS file does exist, all new received remote IFS file data records are added at the end of the local IFS file that is used.
  • Z - Whether the local IFS file exists or not, a new local IFS file is created and the received remote IFS file data records are added to the local IFS file that is used.
Local IFS File Path

Specifies the full IFS file path name for the local location where the IFS file is sent or received. Example:

/home/mydir/myfile
Note: To specify a IFS file a leading forward slash is needed.
Remote File Options Specifies whether to create a file and add data records or use an existing file and replace data records when an IFS file is sent. Valid values are:
  • C - If the remote IFS file does not exist, a remote IFS file is created with the name specified in the Remote File Path parameter. Then add the sent local IFS file data records to the remote IFS file. If the remote IFS file does not exist, the command ends with an escape message. In addition to the normal validity checks, the following special condition must all be true for the send IFS file operation to create the remote IFS file.
    • To run this command, you must be authorized to add the remote IFS file to the specified path name.
  • R - The sent local IFS file data records replace all existing records in the remote IFS file that is used. The remote IFS file is cleared before the sent local IFS file data records are added.

    The remote IFS file must exist when this command is executed. A remote IFS file is not created to receive the local IFS file data records, the command ends with an escape message.

  • A - The sent local IFS file data records new records are added at the end of the remote IFS file that is used.

    The remote IFS file must exist when this command is executed. A remote IFS file is not created to receive the local IFS file data records. The command ends with an escape message.

  • X - If the remote IFS file does not exist, a new remote IFS file is created and the local IFS file data records are added to the remote IFS file that is used. If the remote IFS file exists, replace all existing records in the remote IFS file that is used. The to-ifs file is cleared before the sent local IFS file data records are added.
  • Y - If the remote IFS file does not exist, a new remote IFS file is created and the sent local IFS file data records are added to the remote IFS file that is used. If the remote IFS file exists, all new sent local IFS file data records are added at the end of the remote IFS file that is used.
  • Z - Whether the remote IFS file exists or not, a new remote IFS file is created and the sent local IFS file data records are added to the remote IFS file that is used.
Remote File Path Specifies the full file path on the remote location where the IFS file or file must be sent/received. Example:

Sending/Receiving to/from another IBM i system:

/home/mydir/myfile

Sending/Receiving to/from Windows:

c:\temp\mydir\myfile

Sending/Receiving to/from UNIX:

/home/mydir/myfile

Sending/Receiving to/from z/OS:

/home/mydir/myfile

If you specify *LOCALIFS for this parameter, MFT Platform Server tries to place the IFS file path in the same location as Local IFS File Path parameter field. This is valid only for IBM i system to IBM i system transfers only.
Note: To specify a IFS file path with a leading forward slash is needed.
Scan Subdirectories Defines whether subdirectories are transferred for a Directory Send or Directory Receive transfer. Valid values are:
  • Y: Transfers files in subdirectories
  • N: Does not transfer files in subdirectories
Stop On Failure Specifies whether to stop all the directory transfers on the first directory transfer that fails when processing directory transfers. Valid values are:
  • Y - Stops all the directory transfers on the first directory transfer that fails.
  • N - Does not stop directory transfers when a transfer fails.
Test Directory Transfer This parameter is used only for directory transfers. It defines whether transfers are executed (N) or a list of files to be transferred is displayed (Y). Valid values are:
  • Y - Extracts the list of files to be transferred and creates a list report on all test directory file transfers. But the file transfers are not executed.
  • N - Executes the directory file transfers and creates a list report on the status of all the directory file transfers processed.
Transport Layer Security Processes the request transfer using the TCP/IP security protocol. The Transport Layer Security defined to MFT Platform Server for the given remote node via the Work With Node Configuration (CFWRKNET) command is used.

The Transport Layer Security value is retrieved from the MFT Platform Server Node Configuration File by the Remote Location Name or the IP Address command parameter field values, if the remote node record exists. Valid values are:

  • Y - Specifies that the Transport Layer Security is required for this data transfer request transaction job.
  • N - Specifies that the Transport Layer Security is not required for this data transfer request transaction job.
  • T - Specifies that the Transport Layer Security Tunnel is required for this data transfer request transaction job.
ZLIB Comp Level Indicates the ZLIB data compression level from 0 to 9 controlling the level of compression that is used to process all MFT Platform Server outgoing data transfer request transactions for a particular remote node.

The ZLIB compression level defined to MFT Platform Server for a given remote node via the Work With Node Configuration (CFWRKNET) command is used.

You can set the ZLIB data compression level to be used for a transfer. 0 is no ZLIB compression level. 1 is the fastest and produces the least data compression. 9 is the slowest and produces the most data compression.
Note: We suggest using ZLIB2 since this offers a high level of compression and does not use too many CPU cycles.
Valid values are:
  • 0 - No ZLIB data compression level
  • 1 - ZLIB data compression level 1 method
  • 2 - ZLIB data compression level 2 method
  • 3 - ZLIB data compression level 3 method
  • 4 - ZLIB data compression level 4 method
  • 5 - ZLIB data compression level 5 method
  • 6 - ZLIB data compression level 6 method
  • 7 - ZLIB data compression level 7 method
  • 8 - ZLIB data compression level 8 method
  • 9 - ZLIB data compression level 9 method