More great news. Mark Taylor of IBM and Morag Hughson of IBM will be speaking at Capitalware’s MQ Technical Conference v2.0.1.3 (MQTC).
The information for Mark Taylor and Morag Hughson’s sessions will be posted in the near future.
For more information about MQTC, please go to:
http://www.mqtechconference.com
Regards,
Roger Lacroix
Capitalware Inc.
D. Richard Hipp has just released SQLite v3.7.17.
http://www.sqlite.org/news.html
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain.
Regards,
Roger Lacroix
Capitalware Inc.
Mozilla Firefox has just released Mozilla Firefox v21.0.
http://www.mozilla.com/firefox/
Mozilla Firefox is a free and open source web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation. To display web pages, Firefox uses the Gecko layout engine, which implements most current web standards in addition to several features that are intended to anticipate likely additions to the standards
Regards,
Roger Lacroix
Capitalware Inc.
In the previous blog posting, “File Transfer to 3rd Party Application using Universal File Mover (How To #7)”, I showed how to do file transfers from UFM to a 3rd party application.
In this blog posting, I will show how to use UFM to receive files from a 3rd party application. UFM will connect to the remote queue manager in “client mode”.
In this example, the following servers are used but they only have WebSphere MQ (WMQ) Client installed (no queue managers):
- aix002 is an AIX server with WMQ Client and UFM software installed
- linux002 is a Linux server with WMQ Client and UFM software installed
In this example, the following queue managers are used:
- MQA1 is a queue manager residing on a AIX (aix001) server (sender)
- MQL1 is a queue manager residing on a Linux (linux001) server (receiver)
- TEST.LINUX.QL and TEST.LINUX.QL.BK are local queues defined in queue manager MQL1 (receiver)
- TEST.LINUX.QR is a remote queue defined in queue manager MQA1 (sender)
If you do not know how to define/setup communication between 2 queue managers then follow the instructions in this blog posting:
http://www.capitalware.biz/rl_blog/?p=509
Step #1: On the linux002 server, create a file in the mq directory called mql1.xml and copy the following into the file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE UFM_MQ SYSTEM "UFM_MQ.dtd">
<UFM_MQ>
<QMgrName>MQL1</QMgrName>
<QueueName>TEST.LINUX.QL</QueueName>
<Hostname>linux001</Hostname>
<ChannelName>SYSTEM.DEF.SVRCONN</ChannelName>
<Port>1414</Port>
<UserID>tester</UserID>
</UFM_MQ>
The mql1.xml (UFM_MQ XML) file describes how to connect to the remote MQL1 queue manager on server linux001. The connection will use UserID of tester. If you do not have that UserID defined on the linux001 server then use a UserID that is defined.
Step #2: On the linux002 server, in the UFM install directory, create a file called ufm_receive_test_8.xml and copy the following into the file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE UFM_Workflow SYSTEM "UFM_Workflow.dtd">
<UFM_Workflow>
<Actions>
<MQReceive getwithconvert="Y" run="D">
<MQ>
<MQFile>mql1.xml</MQFile>
<BackOutQName>TEST.LINUX.QL.BK</BackOutQName>
</MQ>
<Default>
<Directory override="Y">/home/roger/UFM/</Directory>
<FileName override="Y">Test_${INDEX}.msg</FileName>
</Default>
</MQReceive>
</Actions>
</UFM_Workflow>
When UFM is started, it will run as a daemon (run=”D”) and use a backout queue called TEST.LINUX.QL.BK just in case there is an issue with a message. UFM will use ‘get with convert’ option when retrieving the messages.
Note: The messages will not have the standard UFM information in the MQMD or UFM_Msg XML (in the message data) because the messages originated from a 3rd party application. Therefore, we MUST override both the directory and filename information. In the Default element, I have set both Directory and FileName elements to override the incoming message’s values. Hence, UFM will override the message’s specified directory and use the one provided. Either create /home/roger/UFM/ directory on your Linux server or use a directory that already exist on your Linux server. UFM will also override the filename with the value in FileName element. The INDEX token will start at 1 and be automatically incremented as UFM receives a new message.
Step #3: On the linux002 server, start UFM to receive the file transfers:
./ufm.sh ufm_receive_test_8.xml &
Step #4: On the aix002 server, start the 3rd party application to send the messages to the queue.
Step #5: On the linux002 server, verify that the file(s) was/were put into the /home/roger/UFM/ directory or whatever directory you specified in the ufm_receive_test_8.xml file.
Step #6: Finally, we need to stop UFM daemon that is running on the linux002 server. In the UFM install directory, create a file called ufm_putquit_test_8.xml and copy the following into the file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE UFM_Workflow SYSTEM "UFM_Workflow.dtd">
<UFM_Workflow>
<Actions>
<MQPutQuit>
<MQ>
<MQFile>mql1.xml</MQFile>
</MQ>
</MQPutQuit>
</Actions>
</UFM_Workflow>
Step #7: On the linux002 server, run UFM with the MQPutQuit action:
./ufm.sh ufm_putquit_test_8.xml
This blog demonstrates how to use UFM to receive messages via MQ that originated from a 3rd party application.
Regards,
Roger Lacroix
Capitalware Inc.
I sometimes get a question like “can UFM be used to send files as MQ messages to a 3rd party application”. The answer is yes. In this blog posting, I will show how to do a file transfer in “client mode” when UFM connects to the queue manager.
Things to note: UFM stores the directory name, file name and job name in the MQMD if the following is true:
If any field exceeds these length values then UFM will create UFM_Msg XML and insert it into the message data. Hence, this will be a problem for the 3rd party application as they will not expect it.
Therefore, the sample below will explicitly set the directory name and file name using the Remote element to make sure the field sizes are small and that the UFM_Msg XML is not created.
In this example, the following servers are used but they only have WebSphere MQ (WMQ) Client installed (no queue managers):
- aix002 is an AIX server with WMQ Client and UFM software installed
- linux002 is a Linux server with WMQ Client and UFM software installed
In this example, the following queue managers are used:
- MQA1 is a queue manager residing on a AIX (aix001) server (sender)
- MQL1 is a queue manager residing on a Linux (linux001) server (receiver)
- TEST.LINUX.QL is a local queue defined in queue manager MQL1 (receiver)
- TEST.LINUX.QR is a remote queue defined in queue manager MQA1 (sender)
If you do not know how to define/setup communication between 2 queue managers then follow the instructions in this blog posting:
http://www.capitalware.biz/rl_blog/?p=509
Step #1: On the aix002 server, create a file in the mq directory called mqa1.xml and copy the following into the file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE UFM_MQ SYSTEM "UFM_MQ.dtd">
<UFM_MQ>
<QMgrName>MQA1</QMgrName>
<QueueName>TEST.LINUX.QR</QueueName>
<Hostname>aix001</Hostname>
<ChannelName>SYSTEM.DEF.SVRCONN</ChannelName>
<Port>1414</Port>
<UserID>tester</UserID>
</UFM_MQ>
The mqa1.xml (UFM_MQ XML) file describes how to connect to the remote MQA1 queue manager on server aix001. The connection will use UserID of tester. If you do not have that UserID defined on the aix001 server then use a UserID that is defined.
Step #2: On the aix002 server, create a file in the data directory called test.txt and put a simple text message in the file (i.e. This is a test message.)
Step #3: On the AIX server, in the UFM install directory, create a file called ufm_send_test_7.xml and copy the following into the file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE UFM_Workflow SYSTEM "UFM_Workflow.dtd">
<UFM_Workflow>
<Actions>
<MQSend delete="N" format="S">
<File>data/test.txt</File>
<MQ>
<MQFile>mqa1.xml</MQFile>
</MQ>
<Remote>
<Directory>/junk/</Directory>
<FileName>short.txt</FileName>
</Remote>
</MQSend>
</Actions>
</UFM_Workflow>
When UFM is started, it will send the specified file and mark the message’s MQMD format as ‘string’.
Step #4: On the aix002 server, start UFM to send the file:
./ufm.sh ufm_send_test_7.xml
UFM will start and put the file as a message to the specified queue then terminate.
Step #5: On the linux002 server, run the 3rd party application to retrieve the messages from the queue.
This blog demonstrates how to use UFM to send files via MQ to a 3rd party application.
Regards,
Roger Lacroix
Capitalware Inc.
IBM has just released FixPack 7.0.1.10 for WebSphere MQ.
http://www.ibm.com/support/docview.wss?uid=swg21636042
Regards,
Roger Lacroix
Capitalware Inc.
Using MQAUSX and MQCE together is only a little more complex than uses a single MQ exit. The same software is installed on the server regardless if it is acting as a “server” or “client”. So, let’s go through a setup and test of MQAUSX and MQCE on 2 Solaris servers where 1 Solaris server is the “server-side” and the other Solaris server is the “client-side” of the test which will use a client-side encrypted file.
Information:
- Server 1 is running Solaris SPARC v9 (64-bit) with a queue manager called BIZI.QM.TST on WMQ v7.0.1.0
- Server 2 is running Solaris SPARC v10 (64-bit) and will run the MQ client application with WMQ v7.1.0.0.
Step #1: Install the MQAUSX and MQCE on both servers. Please follow instructions in the manual, the following is the short form:
On Solaris 9, use mqausx_solaris64.tar and mqce_solaris64.tar files and then run setausx.sh and setmqce.sh shell scripts as root.
On Solaris 10, use mqausx_solaris10_64.tar and mqce_solaris10_64.tar files and then run setausx.sh and setmqce.sh shell scripts as root.
Step #2: On Solaris 9 server, copy the Capitalware supplied License files (mqausx_licenses.ini and mqce_licenses.ini) for both MQAUSX and MQCE to the install directory. i.e. /var/mqm/exits64/
Note: The client-side MQAUSX and MQCE components do NOT require a License file.
Step #3: On Solaris 9 server, by default, MQAUSX will authenticate against the Local OS. If you want to authenticate against a different target then update the IniFile to reflect it (please follow the instructions as per the manual). For MQCE, the AES default key size is 128 bits. You can update the IniFile to use 128 or 192 or 256 bit.
Step #4: On Solaris 9 server, define a SVRCONN channel (‘LIOR.CHL’) in queue manager ‘BIZI.QM.TST’ to use both MQAUSX and MQCE:
DEFINE CHANNEL ('LIOR.CHL') CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
SCYEXIT('/var/mqm/exits64/mqausx(SecExit)') +
SCYDATA('mqausx.ini') +
RCVEXIT('/var/mqm/exits64/mqce(CE)') +
RCVDATA('mqce.ini') +
SENDEXIT('/var/mqm/exits64/mqce(CE)') +
SENDDATA('mqce.ini') +
REPLACE
Note: Because I did not specify the path for SCYDATA, RCVDATA and SENDDATA attributes of the channel, MQAUSX and MQCE will look for the specified IniFile in the install directory.
Step #5: On Solaris 10 server, I will create a client-side encrypted file for the client application to use.
enc_clnt -u tester -p abc123 -f /export/home/tester/secure/tester.enc
Note: The client-side encrypted filename can be called anything so long as it has a file extension of “enc”.
I purposely made the path and filename of the client-side encrypted file very long. It is 37 characters long. For MQ channel exits, IBM has restricted the “Data” fields (security/send/receive) to a maximum of 32 characters.
This IBM 32 character restriction for the “Data” field is the number 1 reason why people have problems when dealing with channel exits.
Step #6: On a Windows PC, create the CCDT (Client Channel Definition Table) file using the CCDTE program. I like to call the CCDT file by the name of the queue manager. For this example, the queue manager is called BIZI.QM.TST, so the CCDT file will be called ‘BIZI.QM.TST.TAB’.
Now input the channel name, connection name and queue manager name then select the Unix version of the security and Send/Receive exits from the dropdown.
Please review the “Security Exit Data” field in the above screen-shot. The full path and filename is “/export/home/tester/secure/tester.enc” but it is longer than 32 characters. Therefore, I will just inputted the filename of “tester.enc” and will use the MQAUSXCLNT_HOME environment variable to specify the path to the client-side encrypted file.
Step #7: Now copy the CCDT file (‘BIZI.QM.TST.TAB’) from the Windows PC to the Solaris 10 server. Make sure you copy the file as ‘binary’. In this example, I will copy the CCDT to /export/home/tester/ directory on the Solaris 10 server.
Step #8: On Solaris 10 server, we need set some MQ environment variables:
unset MQSERVER export MQCHLLIB=/export/home/tester export MQCHLTAB=BIZI.QM.TST.TAB
Note: MQCHLLIB environment has 2 “L”s so be care when typing it.
Unset MQAUSX environment variables from the previous test and then set the MQAUSXCLNT_HOME environment variable:
unset MQAUSX_UID unset MQAUSX_PWD export MQAUSXCLNT_HOME=/export/home/tester/secure/
Step #9: On Solaris 10 server, now that the environment variables are set, time to do a test. I will use the amqsputc and amqsgetc MQ sample programs:
Let’s put 1 message on the queue:
/opt/mqm/samp/bin/amqsputc TST1 BIZI.QM.TST Sample AMQSPUT0 start target queue is TST1 this is a test message #2 Sample AMQSPUT0 end
Now, let’s retrieve that message:
/opt/mqm/samp/bin/amqsgetc TST1 BIZI.QM.TST Sample AMQSGET0 start message <this is a test message #2> no more messages Sample AMQSGET0 end
That’s it – pretty straightforward. It is very easy to have both channel authentication and message encryption over the channel.
I strongly recommend that people use client-side encrypted file and place the file in a directory that only the appropriate user has permission to access the client-side encrypted file.
Regards,
Roger Lacroix
Capitalware Inc.
Using MQAUSX and MQCE together is only a little more complex than uses a single MQ exit. The same software is installed on the server regardless if it is acting as a “server” or “client”. So, let’s go through a setup and test of MQAUSX and MQCE on 2 Solaris servers where 1 Solaris server is the “server-side” and the other Solaris server is the “client-side” of the test.
Information:
- Server 1 is running Solaris SPARC v9 (64-bit) with a queue manager called BIZI.QM.TST on WMQ v7.0.1.0
- Server 2 is running Solaris SPARC v10 (64-bit) and will run the MQ client application with WMQ v7.1.0.0.
Step #1: Install the MQAUSX and MQCE on both servers. Please follow instructions in the manual, the following is the short form:
On Solaris 9, use mqausx_solaris64.tar and mqce_solaris64.tar files and then run setausx.sh and setmqce.sh shell scripts as root.
On Solaris 10, use mqausx_solaris10_64.tar and mqce_solaris10_64.tar files and then run setausx.sh and setmqce.sh shell scripts as root.
Step #2: On Solaris 9 server, copy the Capitalware supplied License files (mqausx_licenses.ini and mqce_licenses.ini) for both MQAUSX and MQCE to the install directory. i.e. /var/mqm/exits64/
Note: The client-side MQAUSX and MQCE components do NOT require a License file.
Step #3: On Solaris 9 server, by default, MQAUSX will authenticate against the Local OS. If you want to authenticate against a different target then update the IniFile to reflect it (please follow the instructions as per the manual). For MQCE, the AES default key size is 128 bits. You can update the IniFile to use 128 or 192 or 256 bit.
Step #4: On Solaris 9 server, define a SVRCONN channel (‘LIOR.CHL’) in queue manager ‘BIZI.QM.TST’ to use both MQAUSX and MQCE:
DEFINE CHANNEL ('LIOR.CHL') CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
SCYEXIT('/var/mqm/exits64/mqausx(SecExit)') +
SCYDATA('mqausx.ini') +
RCVEXIT('/var/mqm/exits64/mqce(CE)') +
RCVDATA('mqce.ini') +
SENDEXIT('/var/mqm/exits64/mqce(CE)') +
SENDDATA('mqce.ini') +
REPLACE
Note: Because I did not specify the path for SCYDATA, RCVDATA and SENDDATA attributes of the channel, MQAUSX and MQCE will look for the specified IniFile in the install directory.
Step #5: On a Windows PC, create the CCDT (Client Channel Definition Table) file using the CCDTE program. I like to call the CCDT file by the name of the queue manager. For this example, the queue manager is called BIZI.QM.TST, so the CCDT file will be called ‘BIZI.QM.TST.TAB’.
Now input the channel name, connection name and queue manager name then select the Unix version of the security and Send/Receive exits from the dropdown.
As you can see, I did not set any values for Security Exit Data, Send Exit Data or Receive Exit Data. This means that the default values (client-side) for MQAUSX and MQCE will be used.
Note: For MQAUSX client-side on Windows, the user will be presented with a popup window to input their user credentials, if the Security Exit Data field is empty. On Unix/Linux, there is no popup window hence if the Security Exit Data field is empty then the user must set the MQAUSX_UID and MQAUSX_PWD environment variables.
It would be far better to use the enc_clnt program to create the encrypted user credentials in a client-side encrypted IniFile and then set the location of the client-side encrypted IniFile in the Security Exit Data field.
Step #6: Now copy the CCDT file (‘BIZI.QM.TST.TAB’) from the Windows PC to the Solaris 10 server. Make sure you copy the file as ‘binary’. In this example, I will copy the CCDT to /export/home/tester/ directory on the Solaris 10 server.
Step #7: On Solaris 10 server, we need set some MQ environment variables:
unset MQSERVER export MQCHLLIB=/export/home/tester export MQCHLTAB=BIZI.QM.TST.TAB
Note: MQCHLLIB environment has 2 “L”s so be care when typing it.
And now set MQAUSX environment variables for the User Credentials:
export MQAUSX_UID=tester export MQAUSX_PWD=abc123
Step #8: On Solaris 10 server, now that the environment variables are set, time to do a test. I will use the amqsputc and amqsgetc MQ sample programs:
Let’s put 1 message on the queue:
/opt/mqm/samp/bin/amqsputc TST1 BIZI.QM.TST Sample AMQSPUT0 start target queue is TST1 this is a test message Sample AMQSPUT0 end
Now, let’s retrieve that message:
/opt/mqm/samp/bin/amqsgetc TST1 BIZI.QM.TST Sample AMQSGET0 start message <this is a test message> no more messages Sample AMQSGET0 end
That’s it – pretty straightforward. It is very easy to have both channel authentication and message encryption over the channel.
I strongly recommend that people not use MQAUSX_UID and MQAUSX_PWD environment variables but rather use the client-side encrypted file created by the enc_clnt program (see the next blog posting for an example).
Regards,
Roger Lacroix
Capitalware Inc.
WebSphere MQ developerWorks: Blogs T.Rob’s Store and Forward StackOverflow MQ Questions