Use wildcard characters with MFT

We can use wildcard characters when you specify source file names and source file paths for file transfers. This allows you to select multiple files simultaneously.


Multiplatforms

We can use the following wildcard characters on Multiplatforms:

    ?
    Use the question mark (?) to represent exactly one character. All of the other characters specified are required in matching file names.

    For example, ab?d.jpg matches the files abcd.jpg, abed.jpg, and abfd.jpg.

    *
    Use the asterisk character (*) to represent zero or more characters.

    For example *.txt matches the files abc.txt and x.txt.

    The pattern *txt matches the files abc.txt, x.txt, and newtxt because the period (.) in the file names is a required character.

    You must enclose the asterisk character (*) in double quotation marks. If we do not, the character will be interpreted by the command shell and might cause the command to fail.

    On UNIX and Linux , using the asterisk character (*) will not include the pseudo hidden files, for example .bashrc.

If the operating system is case-insensitive for file and path names, for example Windows, the pattern match is case-insensitive. We can use wildcard characters to specify file names only: we cannot use wildcards in directory names.


Protocol bridge agent

If you are using a protocol bridge agent to transfer files from an FTP, FTPS, or SFTP file server, wildcard matching is case sensitive, regardless of the platform that the file server is actually running on.


Connect:Direct bridge

When the source of a transfer is a Connect:Direct® bridge agent that is requesting files from a Connect:Direct node, wildcards are not supported.

IBM i

We can use the following wildcard characters on IBM® i platforms:

    ?
    Use the question mark (?) to represent exactly one character. All of the other characters specified are required in matching file names.

    For example, ab?d.jpg matches the files abcd.jpg, abed.jpg, and abfd.jpg.

    *
    Use the asterisk character (*) to represent zero or more characters.

    For example *.txt matches the files abc.txt and x.txt.

    The pattern *txt matches the files abc.txt, x.txt, and newtxt because the period (.) in the pattern is a required character.

    For additional considerations regarding the use of wildcard characters with save file transfers, see Transferring save files that reside in QSYS.LIB file system on IBM i systems .

z/OS

For z/OS® systems the wildcard character rules for Managed File Transfer follow the standard ISPF wildcard conventions in general. There are specific rules for both sequential and partitioned data sets as follows:

Sequential data sets

When you reference sequential data sets, we can use data set name qualifiers containing asterisks (*) and percent signs (%) as follows:

    *
    Use a single asterisk (*) to represent at least one qualifier. A single asterisk within a qualifier represents zero or more characters.

    **
    Use double asterisks (**) to represent zero or more qualifiers. We cannot use a double asterisk within a qualifier.

    %
    Use a single percent sign (%) to represent one single alphanumeric or national language character.

    %%
    Use between one and eight percent signs to represent zero or more characters.

Partitioned data sets

When you reference partitioned data sets, we can specify wildcard characters for the member names only. We can use data set name qualifiers containing asterisks (*), underscores (_), and question marks (?) as follows:

    *
    Use the asterisk (*) character to represent zero or more characters.

    _
    Use the underscore (_) character to represent exactly one character.

    ?
    Use the question mark (?) character to represent exactly one character. The question mark is an alternative to the underscore character and is provided as an addition to ISPF conventions.


Directories

By default if you create a file transfer with a wildcard pattern that matches subdirectories, the subdirectories are not transferred. We can specify the -r parameter on the fteCreateTransfer command to include subdirectories that match the wildcard pattern. When you transfer a subdirectory, the entire contents and structure of the subdirectory are transferred: including all of its files, subdirectories, and hidden files.

For example, if we have a directory called abc, there is a difference in behavior between specifying a source file path of /opt/abc and /opt/abc/*. In the case of /opt/abc because the directory is transferred, a directory called abc is created at the destination and all of the file contents are transferred. In the case of /opt/abc/*, the contents of abc are transferred into the destination path.


Hidden files

Wildcards do not match hidden files except on UNIX-type platforms when the wildcard pattern starts with a dot character (.). For example: /opt/.* transfers all hidden files in the opt directory.

On Windows if you want to transfer a hidden file, either specify the file name exactly or transfer the directory containing the hidden file.


Symbolic links

Symbolic links are a type of file that contain a pointer to another file or directory and are known as shortcuts on Windows. We can match symbolic link files with wildcard characters. However, when a destination file is created from a source that is a symbolic link, the destination file becomes a hard link (that is, a regular file). We cannot successfully transfer symbolic links to directories because this could potentially create a recursive path.


Transferring files with wildcard characters in their file names

We can transfer a file if the file name itself contains a wildcard character. If you specify that file name exactly, only that file is transferred, and not the set of files that match the wildcard.

For example, if we have a file called /opt/abc*.txt and you create a file transfer for /opt/abc*.txt, the only file transferred is /opt/abc*.txt. But if you create a file transfer for /opt/ab*.txt, all files matching the pattern /opt/ab*.txt are transferred, including the file /opt/abc*.txt.


Transferring directory paths that contain wildcard characters

Enclose any directory path that includes a wildcard character in quotation marks (" ") or single quotation marks (' ') to avoid shell expansion. Shell expansion happens when the operating system expands the wildcard character before the character is passed to the Managed File Transfer command and this might cause unexpected behavior. For example, if you run the following fteCreateTransfer command with the -gt parameter on UNIX, where ${...} is a variable substitution from a resource monitor: 
fteCreateTransfer -p QM_VENUS -sa AGT.QM_JUPITER -sm QM_JUPITER -da AGT.QM_NEPTUNE -dm QM_NEPTUNE -r -sd delete
-t binary -de overwrite -jn MONTASK -gt /home/fteadmin/bin/TransferTask.xml -df "${FilePath}" "${FilePath}"
the shell parses ${FilePath} and does not pass it to the command. The workaround is to enclose ${FilePath} in double quotation marks, that is, ${FilePath}.


Transfer is reported as successful even though wildcard matches zero files

If you attempt to transfer a file that does not exist, Managed File Transfer treats this attempt as a failed transfer. If you specify a file name explicitly (for example, /a/missing/filename.txt) and MFT is unable to find that file, the following error message is reported in the log: 
BFGIO0001E: File "/a/missing/filename.txt" does not exist
As part of this process the source agent, which could not find the file, notifies the destination agent that this file transfer has been canceled (because the source agent cannot find the source file to read). If you had planned to trigger an exit after the transfer at this point, the destination agent triggers its DestinationTransferEndExit with a FileExitResultCode of CANCEL_FILE for that file name. However, if you attempt to transfer a wildcard (for example, /a/missing/*.txt) and the source agent does not find any files that match that wildcard, MFT reports this as a successful transfer. This is because technically the source agent was asked to transfer 0 files. The following error message is reported in the log: 
The transfer request has successfully completed, although no files were transferred.
In this example, because the destination agent was never involved in the transfer, its exit is not called.