How to work with Wildcards in XCOM-transfers
Article ID: 30746
Updated On:
Products
Issue/Introduction
Transferring multiple files using wildcard *
Normally XCOM is used to transfer one single file from one Computer running an Operating System to another Computer running the same or a different Operating System. That Operating System can be for example Windows, different flavors of Unix or z/OS. But XCOM also allows to transfer several files in one transfer. This is realized by using the wildcard character asterisk ‘*’. This document provides you with samples and suggestions for the usage of wildcards in transfers.
How do you use the wildcards? Simply by specifying them in the appropriate fields, commands or jobs!
You can use the GUI and specify the wildcard in the fields “File Name” for the local and remote system as shown below:
<Please see attached file for image>
You specify the wildcards in parameters LOCAL_FILE and REMOTE_FILE of command xcomtcp when starting a transfer using a DOS-Prompt or in a Unix-Shell:
C:\xcomnt>xcomtcp -c1 -f REMOTE_SYSTEM=nnn.nnn.nnn.nnn PORT=8044
USER=user01 PASSWORD=... LOCAL_FILE="c:\temp\windows\*"
REMOTE_FILE=XCOM.TARGET(*) ...
You specify the wildcard in the SYSIN-Statements LFILE and FILE for the XCOM Job on the Mainframe:
//SYSIN01 DD *
IPNAME=nnn.nnn.nnn.nnn
IPPORT=8844
TYPE=SEND
FILETYPE=FILE
FILEOPT=REPLACE
LFILE=XCOM.FILES.SOURCE(D*)
FILE="c:\files\from-zos\*"
CODE=EBCDIC
USERID=pieal01
PASSWORD=...
/*
Here are some examples on how to use the wildcard.
1. * à * or ABC* à *
Using the ‘*’ you specify all members of a Dataset or all files in a directory. If you want to restrict the transfer to files with a specific prefix simply specify that prefix on the sending side of the Transfer. The transfer copies all members/files to the target destination.
This picture shows the possible transfers between the different platforms:
<Please see attached file for image>
The green arrows indicate that there are no problems with this kind of transfer in the specified directions between the Operating systems.
The yellow arrows indicate that the transfer from Windows or Unix to z/OS runs but you need to be aware of the following:
a. The file extension is ignored. File test.txt on Windows is named TEST when transferred to z/OS.
b. If transferring files which have filenames longer than eight characters the names are truncated to the length of eight which is the maximum length for Member names on z/OS. File longfilename.txt appears on the mainframe side as member LONGFILE in the specified Dataset. There is no error or warning message on that truncation.
c. If not using FILEOPT=REPLACE and if there is more than one file with long names and the first eight characters are identical, only the first file will be transferred, then the transfer ends with message
XCOMM0269E LONGFILE DUPLICATE MEMBER ON ADD FUNCTION DSN=AA.BB.CC
Example: If files longfilename1.txt, longfilename2.txt and longfilename3.txt are transferred without OPTION=REPLACE the first file is transferred successfully into member name LONGFILE but the two others (and all others not previously transferred) are not transferred because of the transfer ending with the above error message.
2. * à D* or ABC* à D*
You might want to append a suffix to the filenames during the transfer. This can be accomplished by specifying that suffix on the receiving side of the transfer. Here is what happens on the different platforms:
<Please see attached file for image>
The green arrows indicate that there are no problems with this kind of transfer in the specified directions between the Operating systems. The names of the transferred are getting the specified prefix added.
The yellow arrows indicate that the transfer from Windows or Unix to z/OS runs but you need to be aware of the following:
a. The Prefix is ignored when z/OS is the target of the transfer.
b. If the prefix is longer than eight characters, then the transfer fails with message
XCOMM0132E INVALID DATASET NAME
Example: If files longfilename1.txt, longfilename2.txt and longfilename3.txt are transferred without OPTION=REPLACE the first file is transferred successfully into member name LONGFILE but the two others (and all others not previously transferred) are not transferred because of the transfer ending with the above error message.
3. * à *D or ABC* à *D
You might want to add a suffix to the filename during the transfer. This can be accomplished by specifying that prefix on the receiving side of the transfer. Most common example is to transfer members from the mainframe to Windows or Unix and to provide them with a file extension .txt or .csv during that transfer.
Here is what happens on the different platforms:
<Please see attached file for image>
The green arrows indicate that there are no problems with this kind of transfer in the specified directions between the Operating systems. The names of the transferred are getting the specified suffix added.
The red arrows indicate that there is no suffix accepted when transferring files to z/OS, regardless from which platform. The transfer is not executed and message
XCOMM0226E MEMBER NAME MISSING OR INVALID
is created.
4. Other Options
You can think of more options like using multiple asterisks (D* --> **) in the file name or suffix and prefix (* --> ABC*xyz). You can also try to send all files from a source into one target file (* --> a.txt). These options might work or create errors or unpredictable results, depending on which platforms you are acting on.
We therefore strongly recommend to only use one asterisk to specify the local files and one asterisk to specify the remote files. More than that is not documented in the manuals.
Environment
Component:
Attachments
Feedback
