public.dhe.ibm.compublic.dhe.ibm.com/.../wmq/docs/V8.0/PDFs/mq80.mft.pdf · Contents. IBM MQ Managed File Transfer...............................................................................5.

Managed File TransferIBM
Note
Before using this information and the product it supports, read the information in “Notices” on page 1183.
This edition applies to version 8 release 0 of IBM® MQ and to all subsequent releases and modifications until otherwise indicated in new editions.
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. © Copyright International Business Machines Corporation 2007, 2020. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
setup................................................................................................................................................96 Configuring multiple WebSphere MQ Managed File Transfer agents in a IBM 4690 controller
setup................................................................................................................................................96 Starting an agent on an IBM 4690 system.......................................................................................... 97 Restrictions when running on a 4690 OS system............................................................................. 100 File distribution attributes................................................................................................................. 102 Working in a sandbox on IBM 4690...................................................................................................104 Commands in a retail environment................................................................................................... 104 Troubleshooting the IBM 4690 system.............................................................................................116
IBM MQ Managed File Transfer introduction
IBM MQ Managed File Transfer transfers files between systems in a managed and auditable way, regardless of file size or the operating systems used.
You can use IBM MQ Managed File Transfer to build a customized, scalable, and automated solution that enables you to manage, trust, and secure file transfers. IBM MQ Managed File Transfer eliminates costly redundancies, lowers maintenance costs, and maximizes your existing IT investments.
The diagram shows a simple IBM MQ Managed File Transfer topology. There are two agents, each connect to their own agent queue manager in an IBM MQ network. A file is transferred from the agent on the one side of the diagram, through the IBM MQ network, to the agent on the other side of the diagram. Also in the IBM MQ network are the coordination queue manager and a command queue manager. Applications and tools connect to these queue managers to configure, administer, operate, and log IBM MQ Managed File Transfer activity in the IBM MQ network.
IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools. For more information, see “IBM MQ Managed File Transfer product options” on page 23.
You can use IBM MQ Managed File Transfer to perform the following tasks:
• Create managed file transfers
– Create new file transfers from IBM MQ Explorer on Linux® or Windows platforms. – Create new file transfers from the command line on all supported platforms. – Integrate file transfer function into the Apache Ant tool.
© Copyright IBM Corp. 2007, 2020 5
– Write applications that control IBM MQ Managed File Transfer by putting messages on agent command queues.
– Schedule file transfers to take place at a later time. You can also trigger scheduled file transfers based on a range of file system events, for example a new file being created.
– Continually monitor a resource, for example a directory, and when the contents of that resource meet some predefined condition, start a task. This task can be a file transfer, an Ant script, or a JCL job.
– Use the RESTful API provided by the IBM MQ Managed File Transfer Web Gateway to transfer files. – Transfer files to and from IBM MQ queues. – Transfer files to and from FTP, FTPS, or SFTP servers. – Transfer files to and from Connect:Direct® nodes. – Transfer both text and binary files. Text files are automatically converted between the code pages
and end-of-line conventions of the source and destination systems. – Transfers can be secured, using the industry standards for Secure Socket Layer (SSL) based
connections. • View transfers in progress and log information about all transfers in your network
– View the status of transfers in progress from IBM MQ Explorer on Linux or Windows platforms. – Check the status of completed transfers by using the IBM MQ Explorer on Linux or Windows
platforms. – Use the IBM MQ Managed File Transfer database logger feature to save log messages to a Db2® or
Oracle database. – Use the RESTful API provided by the IBM MQ Managed File Transfer Web Gateway to see information
about all transfers in your network.
IBM MQ Managed File Transfer is built on IBM MQ, which provides assured, once-only delivery of messages between applications. You can take advantage of various features of IBM MQ. For example, you can use channel compression to compress the data that you send between agents over IBM MQ channels and use SSL channels to secure the data that you send between agents. Files are transferred reliably and can tolerate the failure of the infrastructure over which the file transfer is carried out. If you experience a network outage, the file transfer restarts from where it left off when connectivity is restored.
By consolidating file transfer with your existing IBM MQ network, you can avoid spending the resources required to maintain two separate infrastructures. If you are not already an IBM MQ customer, by creating an IBM MQ network to support IBM MQ Managed File Transfer you are building the backbone for a future SOA implementation. If you are already an IBM MQ customer, IBM MQ Managed File Transfer can take advantage of your existing IBM MQ infrastructure including IBM MQ internet pass-thru and IBM Integration Bus.
IBM MQ Managed File Transfer integrates with a number of other IBM products: IBM MQ Advanced Message Security
Use IBM MQ Advanced Message Security to provide enhanced security for message traffic in IBM MQ Managed File Transfer, in particular for data on queues. For more information, see “Using IBM MQ Advanced Message Security with IBM MQ Managed File Transfer” on page 128.
IBM Integration Bus
Process files that have been transferred by IBM MQ Managed File Transfer as part of an IBM Integration Bus flow. For more information, see “Working with IBM Integration Bus” on page 358.
IBM Sterling Connect:Direct
Transfer files to and from an existing Connect:Direct network by using the IBM MQ Managed File Transfer Connect:Direct bridge. For more information, see “The Connect:Direct bridge” on page 342.
IBM Tivoli® Composite Application Manager
IBM Tivoli Composite Application Manager provides an agent that you can use to monitor information that is published to the coordination queue manager.
6 Managed File Transfer
Related concepts “IBM MQ Managed File Transfer product options” on page 23 IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools. “IBM MQ Managed File Transfer topology overview” on page 28 Related reference “How does IBM MQ Managed File Transfer work?” on page 500 IBM MQ Managed File Transfer interacts in a number of ways with IBM MQ. This topic describes how the two products interact.
Entities for MQTT clients
MQTT names for client pack, clients, and client sample apps
machine-to-machine (M2M) Mobile Messaging and M2M Mobile Messaging and M2M Client Pack IBM Messaging Telemetry Clients IBM Messaging Telemetry Clients SupportPac MQTT client for Java™
MQTT messaging client for JavaScript MQTT client for C MQTT client sample Java app MQTT client sample Java app for Android MQTT messaging client sample JavaScript pages MQTT client sample C app
MQTT phrases, xrefs, filepaths
The examples are MQTTV3ASample.c and MQTTV3ASSample.c in sdkroot\SDK\clients\c \samples. MQTT build options for different platforms Install a C development environment on the platform on which you are building. System requirements for IBM Messaging Telemetry Clients SupportPac The client identifier must be unique across all clients that connect to the server, and must not be the same as the queue manager name on the server. The configuration gives everyone permission to publish and subscribe to any topic. The configuration of security and access control is minimal and is intended only for a queue manager that is on a secure network with restricted access. To run IBM WebSphere® MQ and MQTT in an insecure environment, you must configure security. To configure security for IBM WebSphere MQ and MQTT, see the related links at the end of this task. If you use the default MqttConnectOptions, or set MqttConnectOptions.cleanSession to true before connecting the client, any old subscriptions for the client are removed when the client connects. Any new subscriptions the client makes during the session are removed when it disconnects. If you set MqttConnectOptions.cleanSession to false before connecting, any subscriptions the client creates are added to all the subscriptions that existed for the client before it connected. All the subscriptions remain active when the client disconnects. Another way of understanding the way the cleanSession attribute affects subscriptions is to think of it as a modal attribute. In its default mode, cleanSession=true, the client creates subscriptions and receives publications only within the scope of the session. In the alternative mode, cleanSession=false, subscriptions are durable. The client can connect and disconnect and its subscriptions remain active. When the client reconnects, it receives any undelivered publications. While it is connected, it can modify the set of subscriptions that are active on its behalf. You must set the cleanSession mode before connecting; the mode lasts for the whole session. To
IBM MQ Managed File Transfer introduction 7
lipo -create [email protected] [email protected] [email protected] -output $@ ${MQTTLIB_DARWIN_A}: ${SOURCE_FILES_A} -mkdir darwin_x86_64 ${CC_armv7} ${CCFLAGS_SO_ARM} -c ${SOURCE_FILES_A} -DMQTT_ASYNC - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -o [email protected] *.o rm *.o ${CC_armv7s} ${CCFLAGS_SO_ARM} -c ${SOURCE_FILES_A} -DMQTT_ASYNC - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -o [email protected] *.o rm *.o ${CC_i386} ${CCFLAGS_SO_i386} -c ${SOURCE_FILES_A} -DMQTT_ASYNC - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_i386} -o [email protected] *.o rm *.o lipo -create [email protected] [email protected] [email protected] -output $@ ${MQTTLIB_DARWIN_S}: ${SOURCE_FILES_S} -mkdir darwin_x86_64 ${CC_armv7} ${CCFLAGS_SO_ARM} -c ${SOURCE_FILES_S} -DOPENSSL - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -L${OPENSSL_DIR}/armv7 -lssl -lcrypto -o [email protected] *.o rm *.o ${CC_armv7s} ${CCFLAGS_SO_ARM} -c ${SOURCE_FILES_S} -DOPENSSL - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -L${OPENSSL_DIR}/armv7s -lssl -lcrypto -o [email protected] *.o rm *.o ${CC_i386} ${CCFLAGS_SO_i386} -c ${SOURCE_FILES_S} -DOPENSSL -DUSE_NAMED_SEMAPHORES - DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -L${OPENSSL_DIR}/i386 -lssl -lcrypto -o [email protected] *.o rm *.o lipo -create [email protected] [email protected] [email protected] -output $@ ${MQTTLIB_DARWIN_AS}: ${SOURCE_FILES_AS} -mkdir darwin_x86_64 ${CC_armv7} ${CCFLAGS_SO_ARM} -c ${SOURCE_FILES_AS} -DMQTT_ASYNC -DOPENSSL - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -L${OPENSSL_DIR}/armv7 -lssl -lcrypto -o [email protected] *.o rm *.o ${CC_armv7s} ${CCFLAGS_SO_ARM} -c ${SOURCE_FILES_AS} -DMQTT_ASYNC -DOPENSSL - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -L${OPENSSL_DIR}/armv7s -lssl -lcrypto -o [email protected] *.o rm *.o ${CC_i386} ${CCFLAGS_SO_i386} -c ${SOURCE_FILES_AS} -DMQTT_ASYNC -DOPENSSL - DUSE_NAMED_SEMAPHORES -DNOSIGPIPE libtool -static -syslibroot ${SDK_ARM} -L${OPENSSL_DIR}/i386 -lssl -lcrypto -o [email protected] *.o rm *.o lipo -create [email protected] [email protected] [email protected] -output $@ .PHONY : clean clean: -rm -f *.obj -rm -f -r darwin_x86_64 Download and install the iOS development tools. For links to client API documentation for the MQTT client libraries, see MQTT client programming reference. You can run an MQTT client for Java app on any platform with JSE 1.5 or above that is "Java Compatible" Log on with a user ID that has administrative authority to IBM WebSphere MQ. The server is now ready for you to test your MQTT V3.1 app. You must have access to an MQTT Version 3.1 server that supports the MQTT protocol over SSL. If there is a firewall between your client and the server, check that it does not block MQTT traffic.
-mkdir windows_ia32 -rm ${CURDIR}/MQTTAsync.obj ${CC} ${CPPFLAGS} ${CFLAGS} ${INC} /Fo ${SOURCE_FILES} ${LD} ${LINKFLAGS} ${IMP} ${LIBPDB} ${LIBMAP} ${WINLIBS} *.obj /out:${MQTTDLL} ${MANIFEST} ${MQTTDLL_A}: ${SOURCE_FILES_A} -mkdir windows_ia32 -rm ${CURDIR}/MQTTClient.obj ${CC} ${CPPFLAGS} ${CFLAGS} ${INC} /Fo ${SOURCE_FILES_A} ${LD} ${LINKFLAGS} ${IMP} ${LIBPDB} ${LIBMAP} ${WINLIBS} *.obj /out:${MQTTDLL_A} ${MANIFEST_A} ${MQTTDLL_S}: ${SOURCE_FILES_S} -mkdir windows_ia32 -rm ${CURDIR}/MQTTAsync.obj ${CC} ${CPPFLAGS_S} ${CFLAGS} ${INC_S} /Fo ${SOURCE_FILES} ${LD} ${LINKFLAGS} ${IMP} ${LIBPDB} ${LIBMAP} ${WINLIBS_S} ${LIBPATH_S} *.obj /out:$ {MQTTDLL_S} ${MANIFEST_S} ${MQTTDLL_AS}: ${SOURCE_FILES_AS} -rm ${CURDIR}/MQTTClient.obj ${CC} ${CPPFLAGS_S} ${CFLAGS} ${INC_S} /Fo ${SOURCE_FILES_AS} ${LD} ${LINKFLAGS} ${IMP} ${LIBPDB} ${LIBMAP} ${WINLIBS_S} ${LIBPATH_S} *.obj /out:$ (MQTTDLL_AS} $(MANIFEST_AS} all: ${MQTTDLL} ${MQTTDLL_A} ${MQTTDLL_AS} ${MQTTDLL_S} .PHONY : clean clean: -rm -f *.obj -rm -f -r windows_ia32 This step is optional on Windows because you can administer IBM WebSphere MQ as a Windows administrator. Set the location of the MQTT source code. Run the makefile in the same directory as the MQTT source files, or set the MQTTCLIENT_DIR command- line parameter: make -f makefile MQTTCLIENT_DIR=sdkroot/SDK/clients/c/mqttv3c/src Add the following lines to the makefile: The example sets VPATH to the directory where make searches for source files that are not explicitly identified; for example all the header files that are required in the build. Set the location of the OpenSSL libraries. This step is required to build the SSL versions of the MQTT client for C libraries. Set the default path to the OpenSSL libraries to same directory as you expanded the MQTT SDK. Otherwise, set OPENSSL_DIR as a command-line parameter. OpenSSL is the OpenSSL directory that contains all the OpenSSL subdirectories. You might have to move the directory tree from where you expanded it, because it contains unnecessary empty parent directories. Select all the source files that are required to build each MQTT library. Also, set the name and location of the MQTT library to build. The source files depend on whether you are building a synchronous or asynchronous library, and whether the library includes SSL or not. Add the following line to the makefile to list all the MQTT source files:
Set the keystore location and attributes with MQ Explorer, or with the DEFINE CHANNEL command; see DEFINE CHANNEL (MQTT). Multiple channels can share a keystore.
MQTT non-phrases
SampleAsyncCallBack SampleAsyncCallBack is in the org.eclipse.paho.client.mqttv3 package. It calls the asynchronous MQTT API. The asynchronous API does not wait for MQTT to complete processing a call; it returns to the application. The application carries on with other tasks, then waits for the next event to arrive for it to process. MQTT posts an event notification back to the application when it completes processing. The event driven MQTT interface is suited to the service and activity programming model of Android and other event driven operating systems. As an example, look at how the mqttExerciser sample integrates MQTT into Android using the service and activity programming model.
SampleAsyncWait SampleAsyncWait is in the org.eclipse.paho.client.mqttv3 package. It uses the asynchronous MQTT API; it waits on a different thread until an action completes. The main thread can do other work until it synchronizes on the thread that is waiting for the MQTT action to complete.
The example command files create the certificates and certificate stores as described in the steps in the task. In addition, the example sets up the MQTT client queue manager to use the server certificate store. The example deletes and re-creates the queue manager by calling the SampleMQM.bat script that is provided with IBM WebSphere MQ.
initcert.bat initcert.bat sets the names and paths to certificates and other parameters that are required by the keytool and openSSL commands. The settings are described in comments in the script.
@echo off @rem Set the path where you installed the MQTT SDK @rem and short cuts to the samples directories. set SDKRoot=C:\MQTT set jsamppath=%SDKRoot%\sdk\clients\java\samples set csamppath=%SDKRoot%\sdk\clients\c\samples
@rem Set the paths to Version 7 of the JDK @rem and to the directory where you built the openSSL package. @rem Set short cuts to the tools. set javapath=C:\Program Files\IBM\Java70 set keytool="%javapath%\jre\bin\keytool.exe" set ikeyman="%javapath%\jre\bin\ikeyman.exe" set openssl=%SDKRoot%\openSSL set runopenssl="%openssl%\bin\openssl"
@rem Set the path to where certificates are to be stored, @rem and set global security parameters. @rem Omit set password, and the security tools prompt you for passwords. @rem Validity is the expiry time of the certificates in days. set certpath=%SDKRoot%\Certificates set password=password set validity=5000 set algorithm=RSA
@rem Set the certificate authority (CA) jks keystore and certificate parameters. @rem Omit this step, unless you are defining your own certificate authority. @rem The CA keystore contains the key-pair for your own certificate authority. @rem You must protect the CA keystore. @rem The CA certificate is the self-signed certificate authority public certificate. @rem It is commonly known as the CA root certificate. set caalias=caalias set cadname="CN=mqttca.ibm.id.com, OU=ID, O=IBM, L=Hursley, S=Hants, C=GB" set cakeypass=%password% @rem ca key store set cajkskeystore=%certpath%\cakeystore.jks set cajkskeystorepass=%password% @rem ca certificate (root certificate) set cacert=%certpath%\cacert.cer
@rem Set the server jks keystore and certificate parameters. @rem The server keystore contains the key-pair for the server. @rem You must protect the server keystore. @rem If you then export the server certificate it is self-signed. @rem Alternatively, if you export a certificate signing request (CSR) @rem from the server keystore for the server key, @rem and import the signed certificate back into the same keystore, @rem it forms a certificate chain. @rem The certificate chain links the server certificate to the CA. @rem When you now export the server certificate, @rem the exported certificate includes the certificate chain. set srvalias=srvalias set srvdname="CN=mqttserver.ibm.id.com, OU=ID, O=IBM, L=Hursley, S=Hants, C=GB" set srvkeypass=%password% @rem server key stores set srvjkskeystore=%certpath%\srvkeystore.jks set srvjkskeystorepass=%password% @rem server certificates set srvcertreq=%certpath%\srvcertreq.csr set srvcertcasigned=%certpath%\srvcertcasigned.cer set srvcertselfsigned=%certpath%\srvcertselfsigned.cer
@rem Set the client jks keystore and certificate parameters @rem Omit this step, unless you are authenticating clients. @rem The client keystore contains the key-pair for the client. @rem You must protect the client keystore. @rem If you then export the client certificate it is self-signed. @rem Alternatively, if you export a certificate signing request (CSR) @rem from the client keystore for the client key, @rem and import the signed certificate back into the same keystore, @rem it forms a certificate chain. @rem The certificate chain links the client certificate to the CA. @rem When you now export the client certificate, @rem the exported certificate includes the certificate chain. set cltalias=cltalias set cltdname="CN=mqttclient.ibm.id.com, OU=ID, O=IBM, L=Hursley, S=Hants, C=GB" set cltkeypass=%password% @rem client key stores set cltjkskeystore=%certpath%\cltkeystore.jks set cltjkskeystorepass=%password% set cltcertreq=%certpath%\cltcertreq.csr set cltcertcasigned=%certpath%\cltcacertsigned.cer set cltcertselfsigned=%certpath%\cltcertselfsigned.cer
@rem Set the paths to the client truststores signed by CA and signed by server key. @rem You only need to define one of the trust stores. @rem A trust store holds certificates that you trust, @rem which are used to authenticate untrusted certificates. @rem In this example, when the client authenticates the MQTT server it connects to, @rem it authenticates the certificate it is sent by the server @rem with the certificates in its trust store. @rem For example, the MQTT server sends its server certificate, @rem and the client authenticates it with either the same server certificate @rem that you have stored in the cltsrvtruststore.jks trust store, @rem or against the CA certificate, if the server certificate is signed by the CA. set cltcajkstruststore=%certpath%\cltcatruststore.jks set cltcajkstruststorepass=%password% set cltsrvjkstruststore=%certpath%\cltsrvtruststore.jks set cltsrvjkstruststorepass=%password%
@rem Set the paths to the client PKCS12 and PEM key and trust stores. @rem Omit this step, unless you are configuring a C or iOS client. @rem You only need to define either one of the trust stores for storing CA @rem or server signed server certificates. set cltp12keystore=%certpath%\cltkeystore.p12 set cltp12keystorepass=%password% set cltpemkeystore=%certpath%\cltkeystore.pem set cltpemkeystorepass=%password% set cltcap12truststore=%certpath%\cltcatruststore.p12 set cltcap12truststorepass=%password% set cltcapemtruststore=%certpath%\cltcatruststore.pem set cltcapemtruststorepass=%password% set cltsrvp12truststore=%certpath%\cltsrvtruststore.p12 set cltsrvp12truststorepass=%password% set cltsrvpemtruststore=%certpath%\cltsrvtruststore.pem set cltsrvpemtruststorepass=%password%
@rem set WMQ Variables set authopt=NEVER set authreq=REQUIRED set qm=MQXR_SAMPLE_QM set host=localhost set mcauser='Guest' set portsslopt=8884 set chlopt=SSLOPT set portsslreq=8885 set chlreq=SSLREQ set portws=1886 set chlws=PLAINWS set chlssloptws=SSLOPTWS set portssloptws=8886 set chlsslreqws=SSLREQWS set portsslreqws=8887 set mqlog=%certpath%\wmq.log
Figure 1. initcert.bat
cleancert.bat The commands in the cleancert.bat script delete the MQTT client queue manager to ensure that the server certificate store is not locked, and then delete all the keystores and certificates that are created by the sample security scripts.
@rem Delete the MQTT sample queue manager, MQXR_SAMPLE_QM call "%MQ_FILE_PATH%\bin\setmqenv" -s endmqm -i %qm% dltmqm %qm%
@rem Erase all the certificates and key stores created by the sample scripts. erase %cajkskeystore% erase %cacert% erase %srvjkskeystore% erase %srvcertreq% erase %srvcertcasigned% erase %srvcertselfsigned% erase %cltjkskeystore% erase %cltp12keystore% erase %cltpemkeystore% erase %cltcertreq% erase %cltcertcasigned% erase %cltcertselfsigned% erase %cltcajkstruststore% erase %cltcap12truststore% erase %cltcapemtruststore% erase %cltsrvjkstruststore% erase %cltsrvp12truststore% erase %cltsrvpemtruststore% erase %mqlog% @echo Cleared all certificates dir %certpath%\*.* /b
Figure 2. cleancert.bat
genkeys.bat The commands in the genkeys.bat script create key-pairs for your private certificate authority, the server, and a client.
@rem @echo ________________________________________________________________________________ @echo Generate %caalias%, %srvalias%, and %cltalias% key-pairs in %cajkskeystore%, %srvjkskeystore%, and %cltjkskeystore% @rem @rem -- Generate a client certificate and a private key pair @rem Omit this step, unless you are authenticating clients. %keytool% -genkeypair -noprompt -alias %cltalias% -dname %cltdname% -keystore %cltjkskeystore% -storepass %cltjkskeystorepass% -keypass %cltkeypass% -keyalg %algorithm% - validity %validity%
@rem -- Generate a server certificate and private key pair %keytool% -genkeypair -noprompt -alias %srvalias% -dname %srvdname% -keystore %srvjkskeystore% -storepass %srvjkskeystorepass% -keypass %srvkeypass% -keyalg %algorithm% - validity %validity%
@rem Create CA, client and server key-pairs @rem -- Generate a CA certificate and private key pair - The extension asserts this is a certificate authority certificate, which is required to import into firefox %keytool% -genkeypair -noprompt -ext bc=ca:true -alias %caalias% -dname %cadname% - keystore %cajkskeystore% -storepass %cajkskeystorepass% -keypass %cakeypass% -keyalg %algorithm% -validity %validity%
Figure 3. genkeys.bat
sscerts.bat The commands in the sscerts.bat script export the client and server self-signed certificates from their keystores, and import the server certificate into the client truststore, and the client certificate
into the server keystore. The server does not have a truststore. The commands create a client truststore in PEM format from the client JKS truststore.
@rem @echo ________________________________________________________________________________ @echo Export self-signed certificates: %srvcertselfsigned% and %cltcertselfsigned% @rem Export Server public certificate %keytool% -exportcert -noprompt -rfc -alias %srvalias% -keystore %srvjkskeystore% - storepass %srvjkskeystorepass% -file %srvcertselfsigned% @rem Export Client public certificate @rem Omit this step, unless you are authenticating clients. %keytool% -exportcert -noprompt -rfc -alias %cltalias% -keystore %cltjkskeystore% - storepass %cltjkskeystorepass% -file %cltcertselfsigned%
@rem @echo ________________________________________________________________________________ @echo Add selfsigned server certificate %srvcertselfsigned% to client trust store: %cltsrvjkstruststore% @rem Import the server certificate into the client-server trust store (for server self- signed authentication) %keytool% -import -noprompt -alias %srvalias% -file %srvcertselfsigned% -keystore %cltsrvjkstruststore% -storepass %cltsrvjkstruststorepass%
@rem @echo ________________________________________________________________________________ @echo Add selfsigned client certificate %cltcertselfsigned% to server trust store: %srvjkskeystore% @rem Import the client certificate into the server trust store (for client self-signed authentication) @rem Omit this step, unless you are authenticating clients. %keytool% -import -noprompt -alias %cltalias% -file %cltcertselfsigned% -keystore %srvjkskeystore% -storepass %srvjkskeystorepass%
@rem @echo ________________________________________________________________________________ @echo Create a pem client-server trust store from the jks client-server trust store: %cltsrvpemtruststore% @rem %keytool% -importkeystore -noprompt -srckeystore %cltsrvjkstruststore% -destkeystore %cltsrvp12truststore% -srcstoretype jks -deststoretype pkcs12 -srcstorepass %cltsrvjkstruststorepass% -deststorepass %cltsrvp12truststorepass% %openssl%\bin\openssl pkcs12 -in %cltsrvp12truststore% -out %cltsrvpemtruststore% -passin pass:%cltsrvp12truststorepass% -passout pass:%cltsrvpemtruststorepass%@rem @rem @echo ________________________________________________________________________________ @echo Create a pem client key store from the jks client keystore @rem Omit this step, unless you are configuring a C or iOS client. @rem %keytool% -importkeystore -noprompt -srckeystore %cltjkskeystore% -destkeystore %cltp12keystore% -srcstoretype jks -deststoretype pkcs12 -srcstorepass %cltjkskeystorepass% -deststorepass %cltp12keystorepass% %openssl%\bin\openssl pkcs12 -in %cltp12keystore% -out %cltpemkeystore% -passin pass:%cltp12keystorepass% -passout pass:%cltpemkeystorepass%
Figure 4. sscerts.bat
cacerts.bat The script imports the certificate authority root certificate into the private keystores. The CA root certificate is needed to create the keychain between the root certificate and the signed certificate. The cacerts.bat script exports the client and server certificate requests from their keystores. The script signs the certificate requests with the key of the private certificate authority in the cajkskeystore.jks keystore, then imports the signed certificates back into the same keystores from which the requests came. The import creates the certificate chain with the CA root certificate. The script creates a client truststore in PEM format from the client JKS truststore.
@rem @echo ________________________________________________________________________________ @echo Export self-signed certificates: %cacert% @rem @rem Export CA public certificate %keytool% -exportcert -noprompt -rfc -alias %caalias% -keystore %cajkskeystore% -storepass %cajkskeystorepass% -file %cacert%
@rem @echo ________________________________________________________________________________ @echo Add CA to server key and client key and trust stores: %srvjkskeystore%, %cltjkskeystore%, %cltcajkstruststore%, @rem The CA certificate is necessary to create key chains in the client and server key stores, @rem and to certify key chains in the server key store and the client trust store @rem @rem Import the CA root certificate into the server key store %keytool% -import -noprompt -alias %caalias% -file %cacert% -keystore %srvjkskeystore% - storepass %srvjkskeystorepass% @rem Import the CA root certificate into the client key store @rem Omit this step, unless you are authenticating clients. %keytool% -import -noprompt -alias %caalias% -file %cacert% -keystore %cltjkskeystore% - storepass %cltjkskeystorepass% @rem Import the CA root certificate into the client ca-trust store (for ca chained authentication) %keytool% -import -noprompt -alias %caalias% -file %cacert% -keystore %cltcajkstruststore% - storepass %cltcajkstruststorepass%
@rem @echo ________________________________________________________________________________ @echo Create certificate signing requests: %srvcertreq% and %cltcertreq% @rem @rem Create a certificate signing request (CSR) for the server key %keytool% -certreq -alias %srvalias% -file %srvcertreq% -keypass %srvkeypass% -keystore %srvjkskeystore% -storepass %srvjkskeystorepass% @rem Create a certificate signing request (CSR) for the client key %keytool% -certreq -alias %cltalias% -file %cltcertreq% -keypass %cltkeypass% -keystore %cltjkskeystore% -storepass %cltjkskeystorepass%
@rem @echo ________________________________________________________________________________ @echo Sign certificate requests: %srvcertcasigned% and %cltcertcasigned% @rem The requests are signed with the ca key in the cajkskeystore.jks keystore @rem @rem Sign server certificate request %keytool% -gencert -infile %srvcertreq% -outfile %srvcertcasigned% -alias %caalias% - keystore %cajkskeystore% -storepass %cajkskeystorepass% -keypass %cakeypass% @rem Sign client certificate request @rem Omit this step, unless you are authenticating clients. %keytool% -gencert -infile %cltcertreq% -outfile %cltcertcasigned% -alias %caalias% - keystore %cajkskeystore% -storepass %cajkskeystorepass% -keypass %cakeypass%
@rem @echo ________________________________________________________________________________ @echo Import the signed certificates back into the key stores to create the key chain: %srvjkskeystore% and %cltjkskeystore% @rem @rem Import the signed server certificate %keytool% -import -noprompt -alias %srvalias% -file %srvcertcasigned% -keypass %srvkeypass% -keystore %srvjkskeystore% -storepass %srvjkskeystorepass% @rem Import the signed client certificate and key chain back into the client keystore %keytool% -import -noprompt -alias %cltalias% -file %cltcertcasigned% -keypass %cltkeypass% -keystore %cltjkskeystore% -storepass %cltjkskeystorepass% @rem @rem The CA certificate is needed in the server key store, and the client trust store @rem to verify the key chain sent from the client or server @echo Delete the CA certificate from %cltjkskeystore%: it causes a problem in converting keystore to pem @rem Omit this step, unless you are authenticating clients. %keytool% -delete -alias %caalias% -keystore %cltjkskeystore% -storepass %cltjkskeystorepass %
@rem @echo ________________________________________________________________________________ @echo Create a pem client-ca trust store from the jks client-ca trust store: %cltcapemtruststore% @rem Omit this step, unless you are configuring a C or iOS client. @rem %keytool% -importkeystore -noprompt -srckeystore %cltcajkstruststore% -destkeystore %cltcap12truststore% -srcstoretype jks -deststoretype pkcs12 -srcstorepass %cltcajkstruststorepass% -deststorepass %cltcap12truststorepass% %openssl%\bin\openssl pkcs12 -in %cltcap12truststore% -out %cltcapemtruststore% -passin pass:%cltcap12truststorepass% -passout pass:%cltpemtruststorepass%
@rem @echo ________________________________________________________________________________ @echo Create a pem client key store from the jks client keystore @rem Omit this step, unless you are configuring a C or iOS client. @rem %keytool% -importkeystore -noprompt -srckeystore %cltjkskeystore% -destkeystore %cltp12keystore% -srcstoretype jks -deststoretype pkcs12 -srcstorepass %cltjkskeystorepass% -deststorepass %cltp12keystorepass% %openssl%\bin\openssl pkcs12 -in %cltp12keystore% -out %cltpemkeystore% -passin pass:%cltp12keystorepass% -passout pass:%cltpemkeystorepass%
Figure 5. cacerts.bat
mqcerts.bat The script lists the keystores and certificates in the certificate directory. It then creates the MQTT sample queue manager and configures the secure telemetry channels.
@echo ________________________________________________________________________________ @echo List keystores and certificates dir %certpath%\*.* /b
@rem @echo Create queue manager and define mqtt channels and certificate stores call "%MQ_FILE_PATH%\mqxr\Samples\SampleMQM" >> %mqlog% echo DEFINE CHANNEL(%chlreq%) CHLTYPE(MQTT) TRPTYPE(TCP) PORT(%portsslreq%) SSLCAUTH(%authreq%) SSLKEYR('%srvjkskeystore%') SSLKEYP('%srvjkskeystorepass%') MCAUSER(%mcauser%) | runmqsc %qm% >> %mqlog% echo DEFINE CHANNEL(%chlopt%) CHLTYPE(MQTT) TRPTYPE(TCP) PORT(%portsslopt%) SSLCAUTH(%authopt%) SSLKEYR('%srvjkskeystore%') SSLKEYP('%srvjkskeystorepass%') MCAUSER(%mcauser%) | runmqsc %qm% >> %mqlog% echo DEFINE CHANNEL(%chlsslreqws%) CHLTYPE(MQTT) TRPTYPE(TCP) PORT(%portsslreqws%) SSLCAUTH(%authreq%) SSLKEYR('%srvjkskeystore%') SSLKEYP('%srvjkskeystorepass%') MCAUSER(%mcauser%) PROTOCOL(HTTP) | runmqsc %qm% >> %mqlog% echo DEFINE CHANNEL(%chlssloptws%) CHLTYPE(MQTT) TRPTYPE(TCP) PORT(%portssloptws%) SSLCAUTH(%authopt%) SSLKEYR('%srvjkskeystore%') SSLKEYP('%srvjkskeystorepass%') MCAUSER(%mcauser%) PROTOCOL(HTTP) | runmqsc %qm% >> %mqlog% echo DEFINE CHANNEL(%chlws%) CHLTYPE(MQTT) TRPTYPE(TCP) PORT(%portws%) MCAUSER(%mcauser%) PROTOCOL(HTTP) | runmqsc %qm% >> %mqlog% @echo MQ logs saved in %mqlog%echo
Figure 6. mqcerts.bat
Get a copy of the IBM WebSphere MQ installation materials and a license in one of the following ways:
1. Ask your IBM WebSphere MQ administrator for the installation materials, and to confirm you can accept the license agreement.
2. Get a 90-day evaluation copy of IBM WebSphere MQ. See Evaluate: IBM WebSphere MQ. 3. Buy IBM WebSphere MQ. See IBM WebSphere MQ product page.
Secure the SSL channel with either certificate authority signed keys, or self-signed keys.
There is no installation program, you just expand the downloaded file.
1. Download the IBM Messaging Telemetry Clients SupportPac. 2. Create a folder where you are going to install the SDK.
You might want to name the folder MQTT. The path to this folder is referred to here as sdkroot. 3. Expand the compressed IBM Messaging Telemetry Clients SupportPac file contents into sdkroot. The
expansion creates a directory tree that starts at sdkroot\SDK.
There is a similar limitation for the MQTT client for Java. If the client code is running on a Java 1.6 JRE from IBM, the required SHA-2 cipher suites must be explicitly enabled. In order to use these suites, the client must also set the SSL context to a value that supports Version 1.2 of the Transport Layer Security (TLS) protocol. For example:
MqttConnectOptions mqttConnectOptions = new MqttConnectOptions(); java.util.Properties sslClientProps = new java.util.Properties(); sslClientProps.setProperty("com.ibm.ssl.keyStore", sslKeys.clientKeyStore); sslClientProps.setProperty("com.ibm.ssl.keyStorePassword", sslKeys.clientStorePassword); sslClientProps.setProperty("com.ibm.ssl.trustStore", sslKeys.clientKeyStore); sslClientProps.setProperty("com.ibm.ssl.trustStorePassword", sslKeys.clientStorePassword); sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2"); sslClientProps.setProperty("com.ibm.ssl.enabledCipherSuites", "SSL_RSA_WITH_AES_256_CBC_SHA256" ); mqttConnectOptions.setSSLProperties(sslClientProps);
On IBM WebSphere MQ, type the following command into a command window:
• echo DISPLAY CHSTATUS(SSL*) CHLTYPE(MQTT) ALL | runmqsc MQXR_SAMPLE_QM echo DISPLAY CHANNEL(SSL*) CHLTYPE(MQTT) ALL | runmqsc MQXR_SAMPLE_QM
When you request a personal certificate, you specify a key size for the public and private key pair. The key size that is used during the SSL handshake can depend on the size stored in the certificate and on the CipherSpec:
• On z/OS, Windows, UNIX and Linux systems, when a CipherSpec name includes _EXPORT, the maximum handshake key size is 512 bits. If either of the certificates exchanged during the SSL handshake has a key size greater than 512 bits, a temporary 512-bit key is generated for use during the handshake.
• On Windows, UNIX and Linux systems, when a CipherSpec name includes _EXPORT1024, the handshake key size is 1024 bits.
• Otherwise the handshake key size is the size stored in the certificate.
Product overview This section provides introductory information that you can use to get started with IBM MQ Managed File Transfer.
• “IBM MQ Managed File Transfer introduction” on page 5 • “IBM MQ Managed File Transfer product options” on page 23 • “IBM MQ Managed File Transfer topology overview” on page 28 • “Scenario overview” on page 29 • “What's new and changed in Version 8.0.0.0?” on page 29
IBM MQ Managed File Transfer introduction IBM MQ Managed File Transfer transfers files between systems in a managed and auditable way, regardless of file size or the operating systems used.
You can use IBM MQ Managed File Transfer to build a customized, scalable, and automated solution that enables you to manage, trust, and secure file transfers. IBM MQ Managed File Transfer eliminates costly redundancies, lowers maintenance costs, and maximizes your existing IT investments.
The diagram shows a simple IBM MQ Managed File Transfer topology. There are two agents, each connect to their own agent queue manager in an IBM MQ network. A file is transferred from the agent on the one side of the diagram, through the IBM MQ network, to the agent on the other side of the diagram. Also in the IBM MQ network are the coordination queue manager and a command queue manager. Applications and tools connect to these queue managers to configure, administer, operate, and log IBM MQ Managed File Transfer activity in the IBM MQ network.
IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools. For more information, see “IBM MQ Managed File Transfer product options” on page 23.
You can use IBM MQ Managed File Transfer to perform the following tasks:
• Create managed file transfers
– Create new file transfers from IBM MQ Explorer on Linux or Windows platforms. – Create new file transfers from the command line on all supported platforms. – Integrate file transfer function into the Apache Ant tool. – Write applications that control IBM MQ Managed File Transfer by putting messages on agent
command queues. – Schedule file transfers to take place at a later time. You can also trigger scheduled file transfers
based on a range of file system events, for example a new file being created. – Continually monitor a resource, for example a directory, and when the contents of that resource meet
some predefined condition, start a task. This task can be a file transfer, an Ant script, or a JCL job. – Use the RESTful API provided by the IBM MQ Managed File Transfer Web Gateway to transfer files. – Transfer files to and from IBM MQ queues. – Transfer files to and from FTP, FTPS, or SFTP servers.
– Transfer files to and from Connect:Direct nodes. – Transfer both text and binary files. Text files are automatically converted between the code pages
and end-of-line conventions of the source and destination systems. – Transfers can be secured, using the industry standards for Secure Socket Layer (SSL) based
connections. • View transfers in progress and log information about all transfers in your network
– View the status of transfers in progress from IBM MQ Explorer on Linux or Windows platforms. – Check the status of completed transfers by using the IBM MQ Explorer on Linux or Windows
platforms. – Use the IBM MQ Managed File Transfer database logger feature to save log messages to a Db2 or
Oracle database. – Use the RESTful API provided by the IBM MQ Managed File Transfer Web Gateway to see information
about all transfers in your network.
IBM MQ Managed File Transfer is built on IBM MQ, which provides assured, once-only delivery of messages between applications. You can take advantage of various features of IBM MQ. For example, you can use channel compression to compress the data that you send between agents over IBM MQ channels and use SSL channels to secure the data that you send between agents. Files are transferred reliably and can tolerate the failure of the infrastructure over which the file transfer is carried out. If you experience a network outage, the file transfer restarts from where it left off when connectivity is restored.
By consolidating file transfer with your existing IBM MQ network, you can avoid spending the resources required to maintain two separate infrastructures. If you are not already an IBM MQ customer, by creating an IBM MQ network to support IBM MQ Managed File Transfer you are building the backbone for a future SOA implementation. If you are already an IBM MQ customer, IBM MQ Managed File Transfer can take advantage of your existing IBM MQ infrastructure including IBM MQ internet pass-thru and IBM Integration Bus.
IBM MQ Managed File Transfer integrates with a number of other IBM products: IBM MQ Advanced Message Security
Use IBM MQ Advanced Message Security to provide enhanced security for message traffic in IBM MQ Managed File Transfer, in particular for data on queues. For more information, see “Using IBM MQ Advanced Message Security with IBM MQ Managed File Transfer” on page 128.
IBM Integration Bus
Process files that have been transferred by IBM MQ Managed File Transfer as part of an IBM Integration Bus flow. For more information, see “Working with IBM Integration Bus” on page 358.
IBM Sterling Connect:Direct
Transfer files to and from an existing Connect:Direct network by using the IBM MQ Managed File Transfer Connect:Direct bridge. For more information, see “The Connect:Direct bridge” on page 342.
IBM Tivoli Composite Application Manager
IBM Tivoli Composite Application Manager provides an agent that you can use to monitor information that is published to the coordination queue manager.
Related concepts “IBM MQ Managed File Transfer product options” on page 23 IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools. “IBM MQ Managed File Transfer topology overview” on page 28 Related reference “How does IBM MQ Managed File Transfer work?” on page 500
IBM MQ Managed File Transfer interacts in a number of ways with IBM MQ. This topic describes how the two products interact.
IBM MQ Managed File Transfer product options IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools.
IBM MQ Managed File Transfer Agent The IBM MQ Managed File Transfer Agent install option installs a file transfer agent. A file transfer agent connects to an IBM MQ queue manager and transfers file data, as messages, to other file transfer agents. These must be installed either as part of the IBM MQ Managed File Transfer Agent or IBM MQ Managed File Transfer Service install options.
The IBM MQ Managed File Transfer Agent install option can be installed on systems without the IBM MQ Server install option being present on the system. Some capabilities of the file transfer agent, installed as part of the IBM MQ Managed File Transfer Agent install are only available when the IBM MQ Managed File Transfer Agent install is installed on a system where the IBM MQ Server install option is installed. For example, the capability to perform protocol bridge configurations and operations.
IBM MQ Managed File Transfer Logger The IBM MQ Managed File Transfer Logger install option installs a file transfer logger. The file transfer logger connects to an IBM MQ queue manager, often the queue manager designated as the coordination queue manager, and logs file transfer audit related data to either a database or a file.
The IBM MQ Managed File Transfer Logger install option must be installed on systems where the IBM MQ Server install option is already installed.
IBM MQ Managed File Transfer Service The IBM MQ Managed File Transfer Service install option installs a file transfer agent that has additional capabilities beyond those provided by the file transfer agent installed via the IBM MQ Managed File Transfer Agent install option. These additional capabilities are:
• Create protocol bridge agents which are used to send and receive files with legacy FTP, FTPS or SFTP servers
• Deploy the Web Gateway feature which provides RESTful interfaces for building web applications that transfer files
The IBM MQ Managed File Transfer Service install option must be installed on systems where the IBM MQ Server install option is already installed.
IBM MQ Managed File Transfer Tools The IBM MQ Managed File Transfer Tools install option installs command line tools that are used to interact with file transfer agents. The tools allow you to start file transfers, schedule file transfers and create resource monitors from the command line.
The IBM MQ Managed File Transfer Tools install option can be installed and used on either a system where file transfer agents are installed or on a system where no file transfer agents are installed.
On UNIX platforms there is an additional IBM MQ Managed File Transfer Base install component. This component contains files common to all of the installation options. You must install the IBM MQ Managed File Transfer Base component before installing any of the Agent, Logger, Service, or Tools components.
For more information on the IBM MQ components required for each product option on UNIX platforms, see the following topics:
• “Components required for each IBM MQ Managed File Transfer product option on HP-UX Systems” on page 24
• “Components required for each IBM MQ Managed File Transfer product option on Linux systems” on page 25
• “Components required for each IBM MQ Managed File Transfer product option on Solaris systems” on page 26
• “Components required for each IBM MQ Managed File Transfer product option on AIX systems” on page 27
Capabilities provided by the Service and Agent options
IBM MQ Managed File Transfer Service
• Make client or bindings mode connections to queue managers. When the file transfer agent and the queue manager are located on the same system, we recommend that you use the bindings mode connections.
• Transfer files to and from other IBM MQ Managed File Transfer agents. • Transfer files to and from SFTP, FTP, or FTPS protocol servers. • Transfer files to and from Connect:Direct nodes. • Transfer files from HTTP clients through the Web Gateway.
Some capabilities are available on only a subset of supported platforms. For more information, see IBM MQ System Requirements.
IBM MQ Managed File Transfer Agent
• Make client or bindings mode connections to queue managers. When the file transfer agent and queue manager are located on the same system, we recommend that you use the bindings mode connections.
• Transfer files to and from other IBM MQ Managed File Transfer agents. • Transfer files to and from Connect:Direct nodes.
Using an MQMFT Agent without a queue manager
In the situation where you are going to have hosts without queue managers, but you want to have MQMFT agents, you might want to install the SupportPac MQC8 with the IBM MQ Client Version 8.0.
Note that this SupportPac does not include the MQMFT code.
Therefore, in order to install MFT agents in a host where only the IBM MQ Version 8.0 client is installed, you need to copy the following file sets from the host where you downloaded the IBM MQ server file sets.
For example, on AIX:
• mqm.ft.agent • mqm.ft.base
After copying those file sets, proceed to install them as user root.
Related concepts “IBM MQ Managed File Transfer introduction” on page 5 IBM MQ Managed File Transfer transfers files between systems in a managed and auditable way, regardless of file size or the operating systems used. “IBM MQ Managed File Transfer topology overview” on page 28
Components required for each IBM MQ Managed File Transfer product option on HP-UX Systems IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. On HP-UX systems, these options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, and IBM MQ Managed File Transfer Tools, and each require specific components.
MQSERIES.MQM-RUNTIME
MQSERIES.MQM-SERVER
MQSERIES.MQM-JAVA
MQSERIES.MQM-JAVAJRE
MQSERIES.MQM-FTBASE
MQSERIES.MQM-FTLOGGER
MQSERIES.MQM-SERVER
MQSERIES.MQM-JAVA
MQSERIES.MQM-FTBASE
MQSERIES.MQM-FTAGENT
MQSERIES.MQM-FTSERVICE
MQSERIES.MQM-JAVA
MQSERIES.MQM-FTBASE
MQSERIES.MQM-FTTOOLS
Components required for each IBM MQ Managed File Transfer product option on Linux systems IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. On Linux systems, these options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, and IBM MQ Managed File Transfer Tools, and each require specific components.
MQSeriesRuntime
MQSeriesJava
MQSeriesJRE
MQSeriesFTBase
MQSeriesFTAgent
IBM MQ Managed File Transfer Logger
MQSeriesRuntime
MQSeriesServer
MQSeriesJava
MQSeriesJRE
MQSeriesFTBase
MQSeriesFTLogger
MQSeriesRuntime
MQSeriesServer
MQSeriesJava
MQSeriesJRE
MQSeriesFTBase
MQSeriesFTAgent
MQSeriesFTService
MQSeriesRuntime
MQSeriesJava
MQSeriesJRE
MQSeriesFTBase
MQSeriesFTTools
Components required for each IBM MQ Managed File Transfer product option on Solaris systems IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. On Solaris systems, these options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, and IBM MQ Managed File Transfer Tools, and each require specific components.
runtime
java
jre
ftbase
ftagent
runtime
server
java
jre
ftbase
runtime
server
java
jre
ftbase
ftagent
ftservice
runtime
java
jre
ftbase
fttools
Components required for each IBM MQ Managed File Transfer product option on AIX systems IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. On AIX systems, these options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, and IBM MQ Managed File Transfer Tools, and each require specific components.
mqm.base.runtime
mqm.java.rte
mqm.jre.rte
mqm.ft.base
mqm.ft.agent
mqm.base.runtime
mqm.server.rte
mqm.java.rte
mqm.jre.rte
mqm.ft.base
mqm.ft.logger
mqm.base.runtime
mqm.server.rte
mqm.java.rte
mqm.jre.rte
mqm.ft.base
mqm.ft.agent
mqm.ft.service
mqm.base.runtime
mqm.java.rte
mqm.jre.rte
mqm.ft.base
mqm.ft.tools
IBM MQ Managed File Transfer topology overview IBM MQ Managed File Transfer agents send and receive the files that are transferred. Each agent has its own set of queues on its associated queue manager and the agent is attached to its queue manager in either bindings or client mode. An agent can also use the coordination queue manager as its queue manager.
The coordination queue manager broadcasts audit and file transfer information. The coordination queue manager represents a single point for the collection of agent, transfer status, and transfer audit information. The coordination queue manager is not required to be available in order for transfers to take place. If the coordination queue manager temporarily becomes unavailable, transfers continue as normal. Audit and status messages are stored in the agent queue managers until the coordination queue manager became available, and can then be processed as normal.
Agents register with the coordination queue manager and publish their details to that queue manager. This agent information is used by the IBM MQ Managed File Transfer plug-in to enable the start of transfers from the IBM MQ Explorer. The agent information collected on the coordination queue manager is also used by the commands to display agent information and agent status.
Transfer status and transfer audit information is published on the coordination queue manager. The transfer status and transfer audit information is used by the IBM MQ Managed File Transfer plug-in to monitor the progress of transfers from the IBM MQ Explorer. The transfer audit information stored on the coordination queue manager can be retained to provide auditability.
The command queue manager is used to connect to the IBM MQ network and is the queue manager connected to when you issue IBM MQ Managed File Transfer commands.
Related concepts “IBM MQ Managed File Transfer introduction” on page 5 IBM MQ Managed File Transfer transfers files between systems in a managed and auditable way, regardless of file size or the operating systems used. “Scenario overview” on page 29 This section lists common IBM MQ Managed File Transfer topologies together with a scenario that sets up the system and transfers a test message. Related reference “How does IBM MQ Managed File Transfer work?” on page 500 IBM MQ Managed File Transfer interacts in a number of ways with IBM MQ. This topic describes how the two products interact.
What's new and changed in Version 8.0.0.0? Learn about the main new and changed functions in IBM MQ Managed File Transfer Version 8.0.
For information about what's new, see What's new in IBM MQ Version 8.0.
For information about what's changed, see What's changed in IBM MQ Version 8.0.
Scenario overview This section lists common IBM MQ Managed File Transfer topologies together with a scenario that sets up the system and transfers a test message.
• Common topologies • Configuring the base server
Common topologies This section lists common IBM MQ Managed File Transfer topologies. The double-sided arrows in each diagram represent connections to the queue manager.
See “Connectivity considerations” on page 32 for more information on queue manager connection options.
Base topology with one queue manager
Figure 7. Base topology with one queue manager
A base topology represents a complete configuration which includes the coordination queue manager. The configuration name is the same as the name of the coordination queue manager. If the coordination queue manager name is MFT1, the configuration name is MFT1.
The base topology is the first IBM MQ Managed File Transfer configuration that you complete. After the base configuration is completed, partner agents from remote servers are added to the base configuration to exchange files.
The base topology does not exchange files outside the base topology server. However, the base topology enables you to move files to different locations in the same server and could be used for development purposes.
Base topology with one partner agent
Figure 8. Base topology with one partner agent
This topology can exchange files between the two agents. Extra partner agents can be added in a similar way to the first added agent.
You can use a single queue manager for all three IBM MQ Managed File Transfer queue manager roles, or you can use dedicated queue managers for specific roles.
For example, you could have one queue manager dedicated to the coordination queue manager role, and the command and agent roles might share a second queue manager.
The connection between a remote agent queue manager in a separate server from the base configuration, and the base configuration coordination queue manager must be configured as an IBM MQ client, or MQI channel.
The connection to the coordination queue manager is established by the fteSetupCoordination command. If the coordination queue manager connection is not configured as an IBM MQ client channel, at the partner server, commands such as fteListAgents fail when issued from the partner agent server.
Base topology with separate coordination queue manager and one partner agent
Figure 9. Base topology with separate coordination queue manager and one partner agent
In the base topology in Figure 3, on the base server, queue manager MFT4 is shared for the command and agent roles, and queue manager MFT5 is dedicated to the coordination queue manager role.
Connectivity must exist across all queue managers in the topology, including queue managers in the base topology, MFT4 and MFT5.
On the partner server queue manager, queue manager CSM1 has the roles of agent and commands queue manager.
This topology can exchange files between the two agents. Each partner agent must connect to a queue manager, as shown in the diagram. Extra partner agents can be added in a similar way, to the way that the first partner agent was added.
Base topology with IBM MQ Managed File Transfer agent partner
Figure 10. Base topology with IBM MQ Managed File Transfer agent partner
This topology can exchange files between the two agents.
The server in the partner agent, depicted as MQCLAGT1 in the diagram, does not have IBM MQ server installed.
The partner agent is configured by using the same commands as the IBM MQ installed server, with some exceptions:
• The configuration for this partner agent must use IBM MQ client connections to base queue manager or queue managers.
• There is no need to run the coordination queue manager role IBM MQ definitions created by the configuration commands in the partner agent server. The coordination queue manager definitions already exist in the base server.
However, you must:
– Copy the agent object definitions generated when the agent is created in the partner server – Transfer the definition file to the base configuration server, and – Create the definitions in the queue manager identified as the agent queue manager in the base
server.
In this case, MFT1 is serving all three roles, and you create the objects for agent MQCLAGT1 in the MFT1 queue manager.
As an alternative to copying the object definitions to the base server, you can run the fteDefine command for agent MQCLAGT1 on the base server where the agent queue manager is located. Use the definitions generated by the fteDefine command to create the required agent definitions on the agent queue manager.
For example, in the diagram shown, you would copy file MQCLAGT1_create.mqsc from the agent directory in the partner server, to the base configuration server, and create the required agent definitions in the MFT1 queue manager.
The configuration you complete on the partner agent server creates the IBM MQ Managed File Transfer configuration directory and required property files.
Connectivity considerations
In the preceding diagrams, each line across the agents and queue managers represents a connection to a queue manager.
This connection might be:
• A bindings or message channel connection, or • An IBM MQ client or MQI connection.
The type of connection you select in your configuration depends on the parameters you specify
• When you specify the queue manager name parameter without other connection parameters, you specify a bindings connection.
If the queue manager used is local to the IBM MQ Managed File Transfer configuration, it also represents a local connection, when used in the base configuration server.
• If you specify the queue manager name parameter, along with the corresponding host, port, and channel name parameters, you specify an IBM MQ client connection.
When agents are located on the same host as the agent queue manager, a bindings type specification, which results in a local connection, is more efficient.
Configuring the base server How you set up the base server with a separate configuration queue manager.
Before you begin
The following example assumes that you have:
• Reviewed the section “Connectivity considerations” on page 32 and understand how to influence the type of connection to queue managers in the configuration.
• A working IBM MQ infrastructure. See Configuring IBM MQ queue managers for information on setting up queue managers.
• IBM MQ security tasks are completed.
All system resources, such as access to files, are configured with adequate security.
For IBM MQ Managed File Transfer security configuration, refer to Security overview for IBM MQ Managed File Transfer and User authorities on IBM MQ Managed File Transfer actions.
• All IBM MQ connections are tested after IBM MQ is configured by either using a sample program to send and receive messages, or using sample amqscnxc to test IBM MQ client type connections.
The amqscnxc sample connects to a queue manager by defining the channel connection in the sample code, which is similar to the way that IBM MQ Managed File Transfer connects, when it uses an MQI or IBM MQ client type connection.
• The instructions assume that the server you use for the base configuration has one IBM MQ version installed. If you have multiple IBM MQ installations in the base server, you must be careful to use the correct file path for the version of IBM MQ you want to use.
• The queue managers used in these instructions do not require connection authentication.
While it might be simpler to complete your first configuration without connection authentication required, if your enterprise requires immediate use of connection authentication, see IBM MQ Managed File Transfer and IBM MQ connection authentication for instructions on how to configure an MQMFTCredentials.xml credentials file
Figure 11. Base topology with separate coordination queue manager and one partner agent
About this task
• Base server
– Queue manager MFT5 is the coordination queue manager – Queue manager MFT4 is used as the agent queue manager for agent MFT4AGT1, and also serves as
the command queue manager for the MFT5 configuration on the base server. • Partner server
– Queue manager CSM1 doubles as the agent queue manager for agent CSM1AGT1, and as the command queue manager for the MFT5 configuration on the partner server.
– Queue manager MFT5, on the base server, is the coordination queue manager.
Procedure
1. Configure the coordination queue manager 2. Configure the command queue manager 3. Set up the agent 4. Set up the logger 5. Configure a partner server
What to do next
Set up the MQExplorer with MQMFT so that you can test your example setup.
Configuring the coordination queue manager How you configure the Coordination queue manager to coordinate file transfers.
Before you begin
Ensure that you have full connectivity between the queue managers you set up for this scenario.
About this task
This task sets up the coordination queue manager MFT5, and the instructions in this section assume that you are working with one IBM MQ installation.
If you have multiple installations, you must set the IBM MQ path to the version of IBM MQ required, by using the setmqenv command, before you start any of the configuration tasks.
Procedure
1. Log in as the IBM MQ administrator. 2. Issue the following command to identify the coordination queue manager and set up the configuration
directory structure:
coordination.properties file C:\<data>\mqft\config\MFT5\coordination.properties
The command also produces an MQSC command file that you must run against your coordination queue manager C:\<data>\mqft\config\MFT5\MFT5.mqsc:
3. Change to the C:\<data>\mqft\config\MFT5 directory. 4. Configure the queue manager, to act as the coordination queue manager, by running the following
command. You need to provide the MQSC command file, produced by the command you issued in Step “2” on page 35:
runmqsc MFT5 < MFT5.mqsc > mft5.txt
5. Open the mft5.txt results file with your preferred editor. and ensure that the definitions have been created successfully.
What to do next
Set up the command queue manager.
Configuring the commands queue manager How you configure the commands queue manager.
Before you begin
Ensure that you have configured the coordination queue manager. See “Configuring the coordination queue manager” on page 34 for more information.
About this task
Procedure
fteSetupCommands -connectionQMgr MFT4
You obtain the following message BFGCL0245I: The file C:\<data>\mqft\config \MFT4\command.properties has been created successfully.
The command queue manager does not require extra IBM MQ definitions. After you run fteSetupCommands, the command.properties file is created in the MFT5 configuration directory.
What to do next
Set up the agent.
Setting up the agent How you prepare a file transfer agent MFT4AGT1, including MQSC scripts that you must run.
Before you begin
You should have set up the command queue manager. See “Configuring the commands queue manager” on page 35 for more information.
About this task
Procedure
1. Issue the following command:
fteCreateAgent -agentName MFT4AGT1 -agentQMgr MFT4
After you create the agent with the fteCreateAgent command, the agents directory, and a subdirectory for the agent, MFT4AGT1, are added to the MFT5 directory.
In the <data>\MFT5\agents\MFT4AGT1 directory you find the:
• agent.properties file • MFT4AGT1_create.mqsc file, which containsIBM MQ definitions required by the agent.
2. Change to the <data>\MFT5\agents\MFT4AGT1 directory, and create the required agent queue manager definitions by issuing the following command:
runmqsc MFT4 < MFT4AGT1_create.mqsc > mft4.txt
3. Open the mft4.txt results file with your preferred editor and ensure that the definitions have been created successfully.
4. Start the agent by typing the following command: fteStartAgent MFT4AGT1. 5. Display the agent by typing the following command: fteListAgents.
You should see output similar to the following:
5655-MFT, 5724-H72 Copyright IBM Corp. 2008, 2020. ALL RIGHTS RESERVED BFGPR0127W: No credentials file has been specified to connect to IBM MQ. Therefore, the assumption is that IBM MQ authentication has been disabled. Agent Name: Queue Manager Name: Status: MFT4AGT1 MFT4 READY
Note: if you have not enabled connection authentication in your IBM MQ Managed File Transfer environment, you can ignore the BFGPR0127W message.
If you issue the ftelistAgents command and receive the following message, BFGCL0014W: No agents exist that match the current selection criteria., see “What to do if your agent is not listed by the fteListAgents command” on page 442 for further information.
What to do next
Set up the logger.
Setting up the logger A file or database logger is required to keep history and audit information about transfer activity for the configuration. In this example you create a file logger.
Before you begin
• Configuration queue manager • Command queue manager • Agent
Procedure
fteCreateLogger -loggerQMgr MFT5 -loggerType FILE -fileLoggerMode CIRCULAR -fileSize 5MB -fileCount 3 MFT5lgr1
After you run the fteCreateLogger command, the <data>\mqft\config\MFT5\loggers directory is crated, with an MFT5LGR1 subdirectory.
The MFT5LGR1 subdirectory holds the logger.properties file. Also in the directory is a file called MFT5LGR1_create.mqsc with IBM MQ definitions required by the logger.
2. Change to the directory <data>\mqft\config\MFT5\loggers\MFT5LGR1. 3. Run the associated MQSC command file.
runmqsc MFT5 < MFT5_create.mqsc
to create the definitions required by the logger. a) Review the results of the object definitions to confirm that the required objects have been created
successfully. 4. Start the logger by issuing the following command fteStartLogger MFT5LGR1. 5. Review the contents of file output0.log at <data>\mqft\logs\MFT5\loggers \MFT5LGR1\logs. After some information about the logger, the last statement should contain message: BFGDB0023I: The logger has completed startup activities and is now running.
Occasionally, log information might not be written to the output0.log the first time the logger starts. If the output0.log file is empty, restart the logger by typing fteStopLogger MFT5LGR1 and pressing the Enter key.
Restart the logger by typing fteStartLogger MFTULGR1 and pressing the Enter key. File output0.log now shows data.
The same behavior extends to the agent version of the output0.log file the first time an agent is started.
Stop and start the agent by using fteStopAgent and fteStartAgent commands. You then see log data written to the agent output0.log file.
Results
You have configured the base server, which includes the coordination queue manager for this configuration.
What to do next
You now do similar work for the partner server, which contains a remote agent.
Configuring a partner server How you configure a partner server, when the base server has a separate coordination queue manager
Before you begin
Ensure that you have fully completed all the tasks to set up a base server, that includes a configuration queue manager.
About this task
The same assumptions made about IBM MQ and the security configuration, as well as the IBM MQ path also apply to the partner server.
Start by setting up the MFT5 configuration directory, and identifying the coordination queue manager by using the fteSetupCoordination command.
Procedure
1. Create the partner server configuration directory by issuing the following command:
fteSetupCoordination -coordinationQMgr MFT5 -coordinationQMgrHost 177.16.20.15 -coordinationQMgrPort 1771 -coordinationQMgrChannel MQMFT.MFT5.SVRCONN
Notes:
a. When the coordination queue manager is on a different server from the partner server, the connection to the base server coordination queue manager must be defined as a client connection.
Failure to define the coordination queue manager connection as an IBM MQ client connection, on the partner server, causes any IBM MQ Managed File Transfer command, that connects to the coordination queue manager, to fail.
An example of a command that connects to the coordination queue manager is fteListAgents. b. You do not need to create the IBM MQ definitions as the definitions required by the coordination
queue manager were completed when you configured the base server. 2. Identify the commands queue manager by issuing the following command:
fteSetupCommands -connectionQMgr CSM1
The commands queue manager does not require any extra IBM MQ definitions. 3. Identify the partner agent queue manager, and create the partner agent queue manager, by issuing
the following command:
fteCreateAgent -agentName CSM1AGT1 -agentQMgr CSM1
4. Change to the CSM1AGT1 directory. 5. Create the IBM MQ definitions required by the agent, by issuing the following command:
runmqsc CSM1 < CSM1AGT1_create.mqsc > csm1.txt
a) Open file csm1.txt with your preferred editor to confirm that all agent required definitions have been created successfully.
6. Start the agent, by issuing the following command:
fteStartAgent CSRMAGT1
7. Display the agent by typing fteListAgents You should see output similar to the following:
C:\>fteListAgents 5655-MFT, 5724-H72 Copyright IBM Corp. 2008, 2020. ALL RIGHTS RESERVED BFGPR0127W: No credentials file has been specified to connect to IBM MQ. Therefo re, the assumption is that IBM MQ authentication has been disabled. Agent Name: Queue Manager Name: Status: CSM1AGT1 CSM1 READY MFT4AGT1 MFT4 READY
Note: if you have not enabled connection authentication in your IBM MQ Managed File Transfer environment, you can ignore the BFGPR0127W message.
If you issue the ftelistAgents command and receive the following message, BFGCL0014W: No agents exist that match the current selection criteria., see “What to do if your agent is not listed by the fteListAgents command” on page 442 for further information.
If the status of one of the agents is UNREACHABLE, see “What to do if the fteListAgents command shows an agent status of UNREACHABLE” on page 444 for further information.
Setting up the MQ Explorer with MQMFT This task helps you connect IBM MQ Explorer to the IBM MQ Managed File Transfer configuration.
Procedure
1. Start MQ Explorer. 2. In the left Navigator panel, scroll down and expand the folder: Managed File Transfer.
You see the entry for the Coordination queue manager: MFT5 3. Right click on MFT5 and select Connect.
a) Select Agents in the drop down menu that appears and ensure that both agents, MFT4AGT1 and CSMAGT1, are in the Ready state.
What to do next
Test your example setup with MQ Explorer.
Using the MQ Explorer to test a file transfer This task gives an example of how you use IBM MQ Explorer with IBM MQ Managed File Transfer, to test a file transfer, after you have set up the MQ Explorer as described in the previous topic.
Before you begin
Ensure that you have a working system, that the agents are READY and MQ Explorer is working. See “Setting up the MQ Explorer with MQMFT” on page 39 for more information.
About this task
Determine the file to use to test the transfer, and a directory to copy it to. For this example, it is assumed that file test-file.txt out of directory C:\temp\mft is used.
C:\temp\mft> dir * <Date stamp> 61 test-file.txt 1 File(s) 61 bytes
Procedure
1. Start the MQ Explorer in Windows 2. In the left Navigator panel, expand the folder: Managed File Transfer.
You see the entry for the Coordination queue manager: MFT5 3. Right click on MFT5 and select Connect. 4. Once connected, right click on MFT5 and select New Transfer
a) Use the pull down menu to select MFT4AGT1 for the Source agent and CSMAGT1 for the Destination agent.
b) Click Next. c) Click Add on the next window.
A wide dialog appears. The left side is for Source and the right side for Destination. 5. On the Source panel:
a) Select Text transfer as the file is text. b) Select Browse to locate the file.
In this case, the file is C:\temp\mft\test-file.txt.
Attention: Do not click OK as you need to complete the Destination panel.
6. On the Destination panel: a) Enter the name that you are giving the file at the destination, for example, test-file.txt.
The use of relative paths is supported. The top portion of the full path is the home directory of the user ID who starts the destination agent.
b) Select Overwrite files if present if you require this option. c) Click OK.
The file you selected appears in the New Transfers panel. 7. If the MFT5 configuration menu is closed, and shows +MFT5, expand the menu by clicking the + sign. 8. Stay at the MQMFT configuration selected.
Next, you check the status of the transfer by carrying out the following procedure. 9. Click Transfer Log under the coordination queue manager MFT5.
10. Look at the status in Managed File Transfer - Current Transfer progress panel, immediately below the Transfer Log top panel and wait for the transfer to complete. If the transfer shows successful and with a green background, you have successfully completed the test of your configuration. If the transfer failed with a red background, an error occurred.
In most cases, you can use the scroll bar below the top Transfer Log panel and view a summary of the reasons for failure.
a) If you cannot determine why the transfer failed, double-click the entry for the transfer in the top Transfer Log panel.
b) Select XML in the left pane of the pop-up panel that appears. c) Scroll through the information to determine the cause of the error. d) Make the corrections needed and test the transfer again.
Installing IBM MQ Managed File Transfer This topic summarizes what you must do to install IBM MQ Managed File Transfer.
From Version 7.5, or later, IBM MQ Managed File Transfer is installed as a component of IBM MQ on UNIX platforms and Windows and is no longer installed as a separate product.
IBM MQ Managed File Transfer remains as a separate product on IBM i and z/OS.
Configuration data to back up
You should back up all the queue managers involved with the topology.
Additionally there are text files, that are not inside queue managers, which you need to back up concurrently with the queue manager data. These are the MQ_DATA_PATH/mqft files, where MQ_DATA_PATH is, on: Windows
C:\Program Files (x86)\IBM\WebSphere MQ\mqft UNIX platforms
/var/mqm/mqft
Product options
IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools.
To decide which components to install, review the product options and topology information in the following topics:
• “IBM MQ Managed File Transfer product options” on page 23 • “IBM MQ Managed File Transfer topology overview” on page 28
How to install For an overview of IBM MQ installation on UNIX platforms and Windows, see Installing and uninstalling.
For information on installing IBM MQ Managed File Transfer on IBM i, see Installing on IBM i.
For information on installing IBM MQ Managed File Transfer on z/OS, see Installing on z/OS.
For information about which specific Managed File Transfer components to install for your platform, see Choosing what to install.
Note: You must update database logger instances before other parts of the Managed File Transfer network so that these instances can correctly process the latest versions of the transfer log messages that they receive.
Related concepts “IBM MQ Managed File Transfer product options” on page 23 IBM MQ Managed File Transfer can be installed as four different options, depending on your operating system and overall setup. These options are IBM MQ Managed File Transfer Agent, IBM MQ Managed File Transfer Logger, IBM MQ Managed File Transfer Service, or IBM MQ Managed File Transfer Tools. “IBM MQ Managed File Transfer topology overview” on page 28 Related reference “Installed command sets” on page 502 The following table shows which commands are installed with each component.
Changes between WebSphere MQ File Transfer Edition V7.0.4 or earlier and IBM WebSphere MQ V7.5, or later
If you are planning to move from WebSphere MQ File Transfer Edition V7.0.4, or earlier to IBM WebSphere MQ V7.5, or later, review the following information that summarizes the changes between versions.
Configuration changes
The configuration layout directly after installation in V7.5, or later is different from the configuration layout directly after installation in WebSphere MQ File Transfer Edition V7.0.4, or earlier.
For example, the diagram shows the configuration layout directly after installation firstly as it was in WebSphere MQ File Transfer Edition V7.0.4.1 and then as it is in WebSphere MQ V7.5, or later.
WebSphere MQ File Transfer Edition V7.0.4, or earlier file name and default location
V7.5, or later equivalent file name and default location
Default configuration directory location (wmqfte_configuration_directory):
• UNIX systems: /var/IBM/WMQFTE/config • Linux systems: /var/ibm/WMQFTE/config • Windows: C:\Documents and Settings \All Users\Application Data\IBM \WMQFTE\config
Default configuration directory location and content:
Information that was previously in the WebSphere MQ File Transfer Edition configuration directory is split over four separate subdirectories: config, installations, ipc, and logs.
The default product root directories (MQ_DATA_PATH) are as follows:
• UNIX systems: /var/mqm • Linux systems: /var/mqm • Windows: the location of the configuration
directory depends on the location of your primary IBM MQ installation. The default locations for primary installations are as follows:
WebSphere MQ File Transfer Edition V7.0.4, or earlier file name and default location
V7.5, or later equivalent file name and default location
– 32-bit: C:\Program Files (x86)\WebSphere MQ
– 64-bit: C:\Program Files\IBM \WebSphere MQ
The configuration subdirectories are as follows:
• The MQ_DATA_PATH/mqft/config directory contains the parts of the configuration that are read-only for Managed File Transfer processes. For example, agent.properties and command.properties.
• The MQ_DATA_PATH/mqft/installations directory contains configuration information for each installation. The content of this directory is equivalent to the content of the wmqfte.properties file.
• The MQ_DATA_PATH/mqft/ipc directory contains IPC resources used internally to communicate between the Managed File Transfer components. Applicable to UNIX and Linux systems only.
• The MQ_DATA_PATH/mqft/logs directory contains the parts of the configuration that are written by Managed File Transfer processes. For example, trace information and log files.
wmqfte.properties
The wmqfte.properties file sets properties that apply to the entire WebSphere MQ File Transfer Edition installation.
The default location is wmqfte_configuration_directory
installation.properties
The installation.properties file is a renamed and relocated equivalent of the wmqfte.properties file.
On UNIX and Linux systems, the default location is MQ_DATA_PATH/mqft/installations/ installation_name
On Windows, the default location is MQ_DATA_PATH\mqft\installations \installation_name
databaselogger.properties.
This file contains property information for the stand-alone database logger.
The default location is wmqfte_configuration_directory/ coordination_qmgr_name
logger.properties
This file now incorporates property information for stand-alone file loggers, stand-alone database loggers, and JEEE database loggers.
The default location is MQ_DATA_PATH/mqft/ config/coordination_qmgr_name/loggers/ logger_name.
Security changes
For IBM WebSphere MQ V7.5, or later, only users who are administrators (members of the mqm group) can run the following list of fte commands:
• “fteChangeDefaultConfigurationOpti