I’ve been working on an interesting PMR recently. A customer was using IBM MQ Managed File Transfer for z/OS V9, and wanted to transfer some data from the mainframe to a directory on Windows, where the fully qualified path for the directory contained a space character, by running the BFGTRCRS JCL job.

You might be thinking This should be nice and easy. Modify the BFGTRCRS JCL and put the directory name in quotes, like this:

%BFGCMD TRACE,CMD=fteCreateTransfer +
    -p MFTQM                        +
    -sa ZOSAGENT1                   +
    -da WINDOWSAGENT2               +
    -dm WINDOWSMFTQM                +
    -dd "C:\MFT Output Files"       +
    /u/mftuser/sourceFile.txt

However, when the customer and I tried this, it ended up in a managed transfer containing multiple transfer items being submitted to the agent!

The reason for this is due to the way BFGTRCRS (and other IBM MQ Managed File Transfer for z/OS JCL jobs) work.

When the job is submitted, it runs the REXX script BFGCMD. This script processes the arguments that have been passed in, and then invokes BPXBATSL PGM to call the appropriate IBM MQ Managed File Transfer command within the USS directory IBM MQ Managed File Transfer installation path\bin.

So, when the BFGTRCRS job shown above was run, it ended up making the following call:

bpxbatsl pgm /opt/ibm/wmqfte/bin/fteCreateTransfer -p MFTQM -sa ZOSAGENT1 
    -da WINDOWSAGENT2 -dm WINDOWSMFTQM
    -dd "C:\MFT Output Files"  /u/mftuser/sourceFile.txt 

Now, when BPXBATSL is invoked with the PGM argument, it will split everything after PGM on the space character, regardless of whether the space is enclosed in quotes or not.

This meant that when the BFGTRCRS job was run, the managed transfer request that was submitted to the agent incorrectly contained three transfer items:

<item mode="text" checksumMethod="MD5">
  <source recursive="false" disposition="leave">
    <file>Output</file>
  </source>
  <destination type="directory" exist="overwrite">
    <file>"C:\MFT</file>
  </destination>
</item>
<item mode="text" checksumMethod="MD5">
  <source recursive="false" disposition="leave">
    <file>Files"</file>
  </source>
  <destination type="directory" exist="overwrite">
    <file>"C:\MFT</file>
  </destination>
</item>
<item mode="text" checksumMethod="MD5">
  <source recursive="false" disposition="leave">
    <file>/u/mftuser/sourceFile.txt</file>
  </source>
  <destination type="directory" exist="overwrite">
    <file>"C:\MFT</file>
  </destination>
</item>

In order to get this to work correctly, the JCL had to be modified so that the -dd parameter used the Windows short path for the directory, rather than the full path that included spaces.

To find the short path for the directory, the customer logged onto the Windows system, navigated to the C:\ directory and ran the following command:

dir /x

This returned a directory listing that showed both the long and short names for all of the files in the root directory of the C:\ drive. The entry for the destination directory of the managed transfer (“C:\MFT Output Files”) looked like this:

18/10/2018  15:57    <DIR>          MFTOUT~1     MFT Output Files

The short name for this directory was then put into the BFGTRCRS JCL, like this:

%BFGCMD TRACE,CMD=fteCreateTransfer +  
    -p MFTQM                        +
    -sa ZOSAGENT1                   +  
    -da WINDOWSAGENT2               + 
    -dm WINDOWSMFTQM                +
    -dd C:\MFTOUT~1                 +  
    /u/mftuser/sourceFile.txt                 

the job was resubmitted, and the managed transfer completed successfully.

Easy when you know how!

As always, I hope this helps. If you have any questions on this, let me know and I’ll be happy to answer them.

1 comment on"How can I use BFGTRCRS to transfer to a Windows directory containing spaces in the name?"

  1. You should consider using the MQ REXX interface to format a XML Transfer request message and place it onto the Agests Command queue . If you design this REXX Script with your typical needs in mind you will find that this will not only be more flexible it will also be significantly faster and use much less CPU.

Join The Discussion

Your email address will not be published.