About Morag

I'm an IBM MQ expert and family history nut. By day I write MQ Technical Education Courses, and in the evening I delve into my family history. I’m from Shetland, in fact from Unst, Britain’s most northerly island, and I am trying to put together a complete Unst family tree.

I can haz error logs?

IBM MQ on IBM Cloud has now reached the Beta phase. See Jen’s latest Blog Post: MQ on IBM Cloud – we’ve hit beta and one of the new things in the beta is the ability to view your queue manager’s error logs.

I Can Haz Error LogsThis is a very important step since one of the first things you should learn is how to discover what your queue manager is trying to tell you when there is an error. In fact this is one of the most important things my MQ training modules also teach you.

Here’s a quick summary of exactly how you can view your IBM Cloud queue manager error logs.

Having created your queue manager, as per Woz Arshad’s YouTube video:

YouTube Introducing MQ on IBM Cloud

you can view your queue manager and get connection information on how to connect to it. From this same view you can also get hold of your queue manager’s error log. Select the “Logs and diagnostics” option.

IBM Cloud MQ Logs and Diagnostics

Select the Logs and diagnostics section

This will show a panel where you have two choices. You can download a smaller zip file which is mainly about obtaining your error logs, or you can go for the full RAS package. For just the error logs click on the “Collect logs” button, and you will then be prompted to supply a password which you will use to unlock the error log files in the zip you download.

IBM Cloud MQ Collect logs

Press the button to collect the queue manager error logs

IBM Cloud MQ Download Log file zip

Download your password protected zip file

After a few moments your zip file will be ready and then you can download it to view the contents.

Inside the zip file there will be three folders:-

  • FDCs
  • QM Logs
  • trace

You’ll be interested in the folder called “QM Logs”. N.B. This is the error logs from the queue manager not the transactional logs.

Inside that folder you will find three files AMQERR0n.LOG – usually you will find all you need in AMQERR01.LOG.

Advertisements

IBM MQ on IBM Cloud – MCA Channels

One of the first things I wanted to do with my new IBM Cloud Queue Manager was to make channels to/from another queue manager on my own machine. Here are some tips that I learned from doing that. Screenshots below show the MQ Console making MQ objects, but of course you can also use all your favourite tools to manage your IBM Cloud queue manager.

Inbound Channel to an IBM Cloud Queue Manager

So I defined a sender channel and transmission queue on the queue manager on my own machine, thus:-

DEFINE CHANNEL(MORAG.TO.MQG1) CHLTYPE(SDR) TRPTYPE(TCP) +
       CONNAME('mqg1-xxxx.qm.beta.mqcloud.ibm.com(nnnnn)') +
       XMITQ(MQG1)
DEFINE QLOCAL(MQG1) USAGE(XMITQ)

And defined a receiver channel on my IBM Cloud queue manager, thus:-

IBM Cloud MQ Console Create Receiver

Create a Receiver channel using the MQ Console

Starting the sender channel on my own machine, targeting my IBM Cloud queue manager failed with:-

AMQ9558: The remote channel 'MORAG.TO.MQG1' .. is not currently available.

Turns out you also need to allow this receiver channel through CHLAUTH. IBM Cloud queue managers come with a back-stop rule already in place, unlike any queue manager you have created yourself using crtmqm. Once you know this, it is a simple matter to get the channel running.

I created a CHLAUTH rule on my IBM Cloud queue manager. I chose to make a Queue Manager Map and not to put an Address filter on it because of all the network translation that goes on between you and your IBM Cloud queue manager. Perhaps later I’ll look into the address the queue manager thinks I’m connecting in from to add an Address filter to my inbound check.

IBM Cloud MQ Console Create CHLAUTH

Create a CHLAUTH rule to allow my receiver in

And then my inbound channel was able to run successfully

IBM Cloud MQ Console Running Channel

And now my receiver is running

Outbound channel from an IBM Cloud Queue Manager

If you have an external IP address for your own machine then you should be able to just plug it into the CONNAME of a sender channel on your IBM Cloud queue manager and get going as you might expect.

If you’re trying this out from home, you may well be behind a router, and using the ipconfig command (or equivalent) will only tell you the IP address assigned to your machine internally, e.g. if it’s a 192.168.* address it’s an internal private address and external connections such as the channels coming out from your IBM Cloud queue manager cannot see it.

One way around this is to use a VPN – if you have one for dialing into work when you are working from home that may well be enough. If you run it and then try the ipconfig command (or equivalent) again, you’ll see that you now have an external IP address. It’s likely that your IBM Cloud queue manager can see that address.

Without a VPN

One of the reasons I decided to write this part of the blog post, is that I think IBM Cloud queue managers may mean that more people are trying to connect between them and a ‘home’ address. Trying out MQ in the cloud is free at the moment, and may well encourage lots of people to try it out.

If you don’t have a VPN, and you are behind a router with a 192.168.* address, you do still have an external IP address, and you can find out what it is by asking google (or using a variety of other websites that will also be listed by this search).

If using your external IP address and queue manager’s port number still don’t work, this is likely because you are behind a router that doesn’t know what to do with this inbound connection. It doesn’t know to send it to your computer rather than any other computer on the internal private network.

You’re better off to have a static IP address for your machine when doing the following to save you having to continually make changes to this configuration every time the DHCP server gives you a new IP address, but it is not absolutely essential. My internal IP address in the following examples is 192.168.1.113. You need to configure your router to tell it where to send connections that come in on the port in question, in the following examples, my queue manager is listening on port 2222.

All routers are different, but you’ll find some kind of section, probably in an advanced setup section, that mentions NAT Forwarding. In that section look for something like Virtual Servers, and then add in configuration that tells the router when it sees traffic on your external IP address and the port your queue manager is listening (2222 in my example), to send that on to the machine with internal IP address 192.168.1.113. You can change the port number at the same time, but I’ve kept it simple and used the same port internally and externally.

IBM Cloud Router config

Configuring my router to pass on connections targeted for my queue manager

Now when I start my sender channel from my IBM Cloud queue manager to the queue manager on my own machine, it connects successfully.

IBM Cloud MQ Console Two Running Channels

Now both my channels, inbound and outbound, are able to run

Since you’ve opened up a port to the outside world to get your channel running into your own machine from the IBM Cloud, you’ll now be able to see the IP address it comes in from. You may want to add an IP address filter with a CHLAUTH rule so that only your cloud queue manager can make that connection.

The next thing I’d like to see from the MQ on IBM Cloud team is how to use SSL/TLS on my channels.

Getting going with MQ on IBM Cloud

I’d seen Jen’s Blog Post: Experimental service for MQ on IBM Cloud is here and watched the YouTube video: YouTube Introducing MQ on IBM Cloud and thought I would have a go. Anything that allows me to try out an MQ queue manager in a different way, I’m interested in trying.

I’m new to Bluemix and IBM Cloud but I had an IBM ID already, so I signed up with my IBM ID and got an IBM Cloud account. Then I went to the catalog page for the new Experimental IBM MQ service and it told me I needed to upgrade my account before I could use it. Upgrading my account required a Credit Card. I was initially dubious about this – the catalog description clearly stated this was free!

I asked on Twitter and Woz kindly answered:-

So I bit the bullet and added my Credit Card details. Now I’d be able to make a queue manager!

Unfortunately not. Now the catalog page had another error:-

You don’t have access to any organizations or spaces in this region. Check that you have the appropriate access with your account owner or administrator.

IBM Cloud Region Access Error

I emailed for help to the address in Jen’s blog post, and was told this was caused by not having a Cloud Foundry Org and Space set up in the “US south” region. Here’s how you fix that:-

  • Assuming you’re logged into IBM Cloud look for the Manage menu in the top right of your screen. Choose Manage -> Account -> Cloud Foundry Orgs
  • There will probably be one entry in the list named after your email address. If there’s nothing listed there, click on the big blue button “Add a new Cloud Foundry Org” and give it a name. If you have an entry on the list, click on View Details on the existing entry.
  • The details shown will show the region your Cloud Foundry spaces are in. If the region is not “US SOUTH” then that is why you see the above error. Click on “Add a Cloud Foundry Space” and ensure you choose the region as “US South”, give it a name and add it.
  • Now go back to the MQ catalog entry and the error should have gone away.

Now you can follow along with the steps in the YouTube video: YouTube Introducing MQ on IBM Cloud.


I’m told the MQ on IBM Cloud documentation here is going to be updated to include something similar to the above.


UPDATE: I hit one further problem later on. My API Key password that I was trying to use to log into the MQ Console never worked. I tried lots of different things, and had a few emails with IBM Hursley, before it was found that there was an intermittent authorization problem in IBM Cloud. This was fixed and after that my password worked exactly as the instructions said it should. This was an intermittent problem but I wasn’t the only person to hit it (see question in dWAnswers). If you also hit this problem, I suggest to go back and try it again now that this has been fixed.

Behaviour changes in MQ V9.0.4 – CONNAUTH/CHLAUTH

UserID and PasswordIBM recently released it’s latest Continuous Delivery release (MQ V9.0.4). This has made some changes to the default behaviours for CONNAUTH and CHLAUTH. You can read all the new changes in V9.0.4 here, but I wanted to highlight a few I thought were very important.

Adopt Context is YES by default

From the introduction of Connection Authentication in IBM MQ V8, the default value of ADOPTCTX was NO. I am delighted to see that the default has now been changed to YES. This is probably the most common configuration problem we help customers with around the use of Connection Authentication. It’ll take a while to percolate through, because there are plenty of existing queue managers out there with ADOPTCTX(NO) but it will definitely improve things.

qm.ini ChlauthEarlyAdopt=Y is now the default

The qm.ini ChlauthEarlyAdopt attribute was added in IBM MQ V8 FixPack 5 to allow users to revert the behaviour back to the way it was prior to another change that was made – i.e. back to the designed IBM MQ V8 GA behaviour. I am very happy to see that IBM has now reverted this behaviour to be there by default for everyone.

Java clients use user ID and password in the same way as ‘C’ clients

Due to the historical use by the Java client of the FAP flow to send a user ID and password (as described in this blog post) a compatibility setting had to be provided at MQ V8 GA in case any Java Client connections into queue managers were relying on this behaviour for their security exits. This meant that Java clients and ‘C’ Clients operated differently by default. Now, as of V9.0.4, the Java client uses the MQCSP to send its user ID and password just as the ‘C’ client does and they both work the same way. This is very good news.

Running the Trigger Monitor as a SERVICE

There was a recent update to MO71 that allowed multiple SERVICE objects to be edited at once.

The example used in the screenshot was of the trigger monitor being run as a service, and is straight out of Knowledge Center (with the exception of a more meaningful object name).

It uses the provided amqsstop program as recommended too. The parameters that amqsstop expects are provided in the STOPARG which include the +MQ_SERVER_PID+ which is a token representing the process id of the process started by the STARTCMD and STARTARG arguments.

I was playing around with this SERVICE object a little more today and discovered that the STOP SERVICE command doesn’t work. This post covers what I discovered and how to fix it.

You’ll note from the screen shot that I’m running a 64-bit Windows queue manager – you can tell that from the path of the amqsstop program which is in the bin64 directory. However, I used the runmqtrm program from the bin directory. This is no doubt a migratory aid for those users that had scripts etc starting the trigger monitor from that location prior to the Windows queue manager becoming a 64-bit entity.

Having started my trigger monitor with the above definition, I can see it’s status using the DISPLAY SVSTATUS command.

AMQ8632: Display service status details.
   SERVICE(TRIGGER.MONITOR)                STATUS(RUNNING)
   PID(3384)                               SERVTYPE(SERVER)
   STARTDA(2017-06-17)                     STARTTI(11.40.55)
   CONTROL(QMGR)                           STARTCMD(C:\mqm8004\bin/runmqtrm)
   STARTARG(-m MQG1 -q ACCOUNTS.INITQ)     STOPCMD(C:\mqm8004\bin64/amqsstop)
   STOPARG(-m MQG1 -p 3384)             
   DESCR(Trigger Monitor Service Auto Started with QMgr)
   STDOUT( )                               STDERR( )

Part of this display is the process ID of the trigger monitor, and you can also see that the replaceable insert +MQ_PROCESS_ID+ in the STOPARG attribute has been replaced with the same PID.

When you issue the MQ command STOP SERVICE(TRIGGER.MONITOR) it issues a PCF Inquire Connections command with a WHERE clause asking for all those connections where the PID is 3384. You can see in the MQ trace that the answer which comes back is MQRCCF_NONE_FOUND.

Now I know the trigger monitor is running so I find it myself in a DISPLAY CONN command and I see this:-

AMQ8276: Display Connection details.
   CONN(876C445920002201)                
   EXTCONN(414D51434D5147312020202020202020)
   TYPE(*)                               
   PID(4604)                               TID(1) 
   APPLDESC(WebSphere MQ Trigger Monitor)
   APPLTAG(:\mqm8004\bin64\runmqtrm.exe)   APPLTYPE(SYSTEM)
   ASTATE(NONE)                            CHANNEL( )
   CLIENTID( )                             CONNAME( )
   CONNOPTS(MQCNO_SHARED_BINDING)          USERID(MUSR_MQADMIN)
   UOWLOG( )                               UOWSTDA(2017-06-17)
   UOWSTTI(11.40.55)                       UOWLOGDA( )
   UOWLOGTI( )                             URTYPE(QMGR)
   EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   QMURID(0.20482)                         UOWSTATE(ACTIVE)

So there are two interesting things in this output. Firstly the PID is different. Secondly, it’s the bin64 version of runmqtrm. There’s no sign of the bin version of runmqtrm with PID(3384) anywhere in DISPLAY CONN. So I guess it didn’t make a connection to the queue manager.

Next thing to check out is the processes that the Windows OS thinks are running. I look for and find both PID(3384) and PID(4604).

runmqtrm processes

Two processes running called runmqtrm

So it seems that the runmqtrm in the bin directory is not a copy of the one in the bin64 directory, but something else that starts the bin64 version of runmqtrm. This means that amqsstop doesn’t work because it is trying to find the first process which never connected to the queue manager.

The fix to get your Trigger Monitor Service definition to work again with a STOP SERVICE command is to use the bin64 version of runmqtrm directly in the STARTCMD and avoid this double hop which leaves you with two processes running unnecessarily.

DEFINE SERVICE(TRIGGER.MONITOR) +
       SERVTYPE(SERVER) CONTROL(QMGR) +
       DESCR('Trigger Monitor Service Auto Started with QMgr') +
       STARTCMD('+MQ_INSTALL_PATH+bin64\runmqtrm') +
       STARTARG('-m +QMNAME+ -q ACCOUNTS.INITQ') +
       STOPCMD('+MQ_INSTALL_PATH+bin64\amqsstop') +
       STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+')

You don’t have the same problem on Unixes, because there aren’t the two bin directories on those platforms. So this is very specific to Windows.

Really it’s a shame that there isn’t a replaceable insert something like +MQ_BIN_DIR_PATH+ so that these platform differences would be completely removed from the SERVICE object definition. But I suppose you could make one yourself and put it into the service.env file.


IBM Certified SpecialistIBM Champion 2017 Cloud

Morag Hughson
IBM Champion 2017 – Cloud
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson Twitter: https://twitter.com/MoragHughson SlideShare: http://www.slideshare.net/moraghughson developerWorks: https://www.ibm.com/developerworks/community/profiles/html/profileView.do?userid=110000EQPN

What’s in Command Levels 90x

MQ90x StairsIBM MQ released Long Term Support release V9.0.0 back in June 2016 which had a Command Level of 900. The subsequent Continuous Delivery releases, V9.0.1, V9.0.2, V9.0.3 and V9.0.4 have each introduced their own Command Levels, 901, 902, 903 and 904 respectively.

This post captures the changes that are available in each of those Command Levels.

Release Command Level Features protected by Command Level – details below
V9.0.0.0 900 AMS Protection Policy enhancement – Confidentiality Policy
LDAP Authorization on Windows
V9.0.1 901 No changes protected by Command Level
V9.0.2 902 Log management features
V9.0.3 903 No changes protected by Command Level
V9.0.4 904 z/OS only Advanced Capability attribute on the queue manager object

AMS Protection Policy enhancement – Confidentiality Policy

With the introduction of Confidentiality Policies in Command Level 900, there is a new attribute on the Set Policy command. A confidentiality policy has no signature algorithm, but does have a encryption algorithm. The Key Reuse feature is applicable to this type of policy. Jon Rumsey has a great write-up of this IBM MQ V9 feature on the MQDev blog, MQ V9 Fast encrypted messages with MQ – Introducing AMS Confidentiality Policies.

AMS Policy

New Attribute MQSC name
See SET POLICY
Look for KC 9000 indicator
PCF constant and values
See Set Policy
Look for KC 9000 indicator
Key Reuse

KEYREUSE

  • DISABLED
  • UNLIMITED
  • 1 – 9999999

MQIA_KEY_REUSE_COUNT (267)

  • MQKEY_REUSE_DISABLED (0)
  • MQKEY_REUSE_UNLIMITED (-1)
  • 1 – 9999999

LDAP Authorization on Windows

Introduced in Command Level 801 on Unix, this feature extended the V8.0.0 Connection Authentication feature which checked your user ID and password, to allow LDAP authorization as well. The fields now available on Windows are the same as those noted in the earlier post for Command Level 801, and are not repeated here.

Log management

With the introduction of Automatic management of linear log extents, and Automatic writing of media images, in Command Level 902, there are new attributes on the queue manager object, queue manager status, and one on queue objects. Mark Whitlock has written about this in an MQDev Blog Post: Logger enhancements for MQ v9.0.2.

Queue Manager Object

New Attribute MQSC name
See ALTER QMGR
Look for KC 902 indicator
PCF constant and values
See Change Queue Manager
Look for KC 902 indicator
Image Schedule

IMGSCHED

  • AUTO
  • MANUAL

MQIA_MEDIA_IMAGE_SCHEDULING (268)

  • MQMEDIMGSCHED_AUTO (1)
  • MQMEDIMGSCHED_MANUAL (0)
Image Interval

IMGINTVL

  • 1 – 999 999 999
  • OFF

MQIA_MEDIA_IMAGE_INTERVAL (269)

  • 1 – 999 999 999
  • MQMEDIMGINTVL_OFF (0)
Image Log Length

IMGLOGLN

  • 1 – 999 999 999
  • OFF

MQIA_MEDIA_IMAGE_LOG_LENGTH (270)

  • 1 – 999 999 999
  • MQMEDIMGLOGLN_OFF (0)
Image Recover Object

IMGRCOVO

  • NO
  • YES

MQIA_MEDIA_IMAGE_RECOVER_OBJ (271)

  • MQIMGRCOV_NO (0)
  • MQIMGRCOV_YES (1)
Image Recover Queue

IMGRCOVQ

  • NO
  • YES

MQIA_MEDIA_IMAGE_RECOVER_Q (272)

  • MQIMGRCOV_NO (0)
  • MQIMGRCOV_YES (1)

Queue Manager Status

New Attribute MQSC name
See DISPLAY QMSTATUS
Look for KC 902 indicator
PCF constant and values
See Inquire Queue Manager Status
Look for KC 902 indicator
Archive Log Extent Name

ARCHLOG

MQCACF_ARCHIVE_LOG_EXTENT_NAME (3208)

  • String of length MQ_LOG_EXTENT_NAME_LENGTH (24)
Archive Log Size

ARCHSZ

MQIACF_ARCHIVE_LOG_SIZE (1416)

Media Log Size

MEDIASZ

MQIACF_MEDIA_LOG_SIZE (1417)

Restart Log Size

RECSZ

MQIACF_RESTART_LOG_SIZE (1418)

Reusable Log Size

REUSESZ

MQIACF_REUSABLE_LOG_SIZE (1419)

Archive Log In Use

LOGINUSE

MQIACF_LOG_IN_USE (1420)

Archive Log Utilization

LOGUTIL

MQIACF_LOG_UTILIZATION (1421)

Reset QMgr command

Updated attribute MQSC name
See RESET QMGR
Look for KC 902 indicator
PCF constant and values
See Reset Queue Manager
Look for KC 902 indicator
Action

TYPE

  • REDUCELOG
  • ARCHLOG

MQIACF_ACTION (1086)

  • MQACT_REDUCE_LOG (10)
  • MQACT_ARCHIVE_LOG (11)
Archived Log

ARCHIVED

MQCACF_ARCHIVE_LOG_EXTENT_NAME (3208)

  • String of length MQ_LOG_EXTENT_NAME_LENGTH (24)
Log Reduction

REDUCE

  • AUTO
  • ONE
  • MAX

MQIACF_LOG_REDUCTION (1422)

  • MQLR_AUTO (-1)
  • MQLR_ONE (1)
  • MQLR_MAX (-2)

Queue Local and Queue Model

New Attribute MQSC name
See DEFINE queues
Look for KC 902 indicator
PCF constant and values
See Change, Copy, and Create Queue
Look for KC 902 indicator
Image Recover Queue

IMGRCOVQ

  • NO
  • YES
  • QMGR

MQIA_MEDIA_IMAGE_RECOVER_Q (272)

  • MQIMGRCOV_NO (0)
  • MQIMGRCOV_YES (1)
  • MQIMGRCOV_AS_Q_MGR (2)

Advanced Capability

To allow monitoring tools to discover whether advanced VUE capabilities are available on this queue manager, an attribute has been added to the display of the queue manager object.

Queue Manager Object

New Attribute MQSC name
See ALTER QMGR
Look for KC 904 indicator
PCF constant and values
See Change Queue Manager
Look for KC 904 indicator
Advanced Capability

ADVCAP

  • DISABLED
  • ENABLED

MQIA_ADVANCED_CAPABILITY (273)

  • MQCAP_NOT_SUPPORTED (0)
  • MQCAP_SUPPORTED (1)

You can get the equivalent information for earlier Command Levels from these posts.

IBM MQ Blogosphere in 2016

The IBM MQ Blogosphere is the set of blogs that cover content about the IBM MQ product. I wrote about the MQ Blogosphere at the end of 2015. This post is an update showing the new bloggers we’ve gained in 2016, and the existing bloggers that have continued to post great articles for you to read. I hope you’re following all these great blogs to get a feed of interesting an informative MQ blog posts.

No PhotoAlamelu Nagarajan started blogging in 2016. He blogs on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Andy OwenAndy Owen dipped a toe into the MQ Blogosphere this year – see his first post on the MQDev blog. developerWorks Logo
MQDev Logo
Ant BeardsmoreAnthony Beardsmore has been blogging for several years, often about Queue Manager Clustering, but now he has turned his attention to blogging about the MQ Appliance. He blogs on the MQDev blog – see his posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
Anil SahuAnil Sahu has rekindled his blogged career in 2016 after writing a little back in 2014. He blogs on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Twitter Logo
Arthur BarrArthur Barr started blogging about MQ in 2015 and it’s great to see more posts from him in 2016. He blogs on the MQDev blog – see his posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
Chris MatthewsonChris Matthewson snuck in his first blog post on MQDev right at the end of the year. Is this a sign of things to come? developerWorks Logo
MQDev Logo
Chuck MisuracaChuck Misuraca works for an MQ ISV, Perficient, and he occasionally blogs over on the Perficient blog – see his posts. LinkedIn Logo
Colin PaiceColin Paice has his own blog, Colin Paice Blog, where he writes stories about the things he discovers about MQ on z/OS. Colin has been stressing the performance and usability of MQ on z/OS for as long as I can remember, and gets changes made to the product for the benefit of its customers as a result of the things he discovers. He also makes regular appearances on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Gwydion TudurA brand new blogger in late 2015, Gwydion Tudur has continued his blogging on MQDev throughout 2016 – see his posts. I am very happy to see him continue to post. LinkedIn Logo
developerWorks Logo
MQDev Logo
No PhotoJames Robertson snuck in his first blog post on MQDev right at the end of the year. Is this a sign of things to come? developerWorks Logo
MQDev Logo
Jamie SquibbA brand new blogger in 2016, Jamie Squibb blogs on MQDev – see his posts. Jamie has worked in the IBM MQ for z/OS area for many years, and I am glad to see he’s now also turning his hand to blogging. I hope to see many more posts from Jamie in 2017! LinkedIn Logo
developerWorks Logo
MQDev Logo
John ColgraveA new member of the IBM MQ Blogosphere in late 2015, John Colgrave has continued blogging throughout 2016 – see his posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
Jon RumseyThose of you lucky enough to have met Jon Rumsey will soon realise the breadth and depth of his knowledge of the IBM MQ product is incredible. Most recently he’s majored in security, being extremely knowledgeable about Advanced Message Security and also channel security. He’s also a big fan of the IBM i platform. He’s been blogging for a couple of years now. You can read his posts over on the MQDev blog. LinkedIn Logo
developerWorks Logo
MQDev Logo
Leif DavidsenLeif Davidsen has his own blog, Leifdavidsen’s Blog, where he writes about Messaging, Connectivity and more. It’s a wordpress blog just like this one, and so is very easy to follow, and well worth it! He also comes up with some of the best titles for blog posts! LinkedIn Logo
Twitter Logo
Lyn ElkinsLyn Elkins has her own blog, Lyns Random Thoughts, where she writes about MQ on her favourite platform, z/OS. After going offline last year, Lyn’s now got her domain back up and running with a new blog. LinkedIn Logo
Mark BluemelMark Bluemel is an occasional blogger, writing on subjects he is very knowledgeable about, namely the Java and JMS support in IBM MQ – see his posts on the MQDev blog. developerWorks Logo
MQDev Logo
Mark CampbellMark Campbell snuck in his first blog post on MQDev right at the end of the year. Is this a sign of things to come? developerWorks Logo
MQDev Logo
Mark TaylorMark Taylor started blogging on MQDev in late 2015, and has written a fair few posts this year too. See his posts. You’ll also find lots of MQ videos featuring Mark. LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
No PhotoMark Whitlock dipped a toe into the MQ Blogosphere this year – see his first post on the MQDev blog. developerWorks Logo
MQDev Logo
Mark WilsonMark Wilson has been blogging since 2014, and has written on the AIM Support Blog, the IBM Messaging blog and the MQDev blog. Mark started his MQ career on the z/OS platform, but has been expanding his knowledge to cover the distributed platforms too. LinkedIn Logo
developerWorks Logo
MQDev Logo
Mark WomackMark Womack has been blogging over on the AIM Support Blog for a number of years, always with a perspective to help MQ customers, his ‘tracking technical trends’ posts are always interesting – see his posts. LinkedIn Logo
developerWorks Logo
Matt LemingMatt Leming has been blogging about MQ since 2014. He writes about the MQ on z/OS product over on the MQDev blog – see his posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
Matt WhiteheadMatt Whitehead has been blogging for a year or two now. He writes about MQLight and Bluemix, over on the MQDev blog – see his posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
Mayur RajaMayur Raja has worked on IBM MQ for z/OS for many years and is a very experienced z/OS developer. He has started blogging about MQ this year. He blogs on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Twitter Logo
Miguel RodriguezMiguel Rodriguez works in IBM in the L2 Service team for IBM MQ, and he blogs over on the AIM Support Blog – see his posts. developerWorks Logo
Morag HughsonMorag started her blogging career in IBM. After leaving IBM she joined MQGem Software, an MQ ISV that produces tools to assist with your MQ system, and she now blogs on the MQGem Software blog, and also over on the IBM MiddleWare User Community. You’ll also see her regularly answering questions on StackOverflow. LinkedIn Logo
developerWorks Logo
Twitter Logo
Nathan WilsonNathan Wilson works for an MQ ISV, W3Partnership, and he occasionally blogs over on the W3Partnership blog – see his posts. LinkedIn Logo
Twitter Logo
Paul TitheridgePaul Titheridge started blogging at the start of 2016, although he’s been a successful IBM MQ writer through many IBM Technotes in the past. He writes up problems seen in his day job in Level 3 service that are useful for all users to see. It’s a great way to get the word out about common problems. He blogs on the MQDev blog – see his posts. Paul can also be found on the IBM MQ Service YouTube channel. LinkedIn Logo
developerWorks Logo
MQDev Logo
Pete SiddallAnyone who’s met Pete Siddall, the STSM for MQ on z/OS, knows how passionate he is about the platform and the MQ product that runs on it. Pete helps MQ on z/OS customers in a million different ways, and still has found time to write the occasional blog post over on MQDev – see his posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
Richard PilotHaving started his blogging career in 2015, Richard Pilot continued with a few posts this year too – see his posts. Looking forward to more in 2017! LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
Rob ParkerRob Parker has been blogging for a year or two now. You can read his posts over on the MQDev blog. LinkedIn Logo
developerWorks Logo
MQDev Logo
Twitter Logo
Roger LacroixRoger Lacroix has his own blog, Roger’s Blog on MQ, Java, C, etc…, where he writes about MQ as well as a variety of other subjects. Roger works for Capitalware, an MQ ISV that produces exits and tools for your MQ system, and runs the annual MQTC Conference. LinkedIn Logo
Sajina Puthalath KandySajina Puhtalath Kandy started blogging in 2016. She blogs on the MQDev blog – see her posts. LinkedIn Logo
developerWorks Logo
MQDev Logo
No PhotoSam Goulden started blogging about the MQ Appliance this year. He blogs on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Twitter Logo
Sam MasseySam Massey works in the performance team for Distributed MQ, and has entered the MQ Blogosphere this year with a few performance related posts – see his posts on the MQDev blog. LinkedIn Logo
developerWorks Logo
MQDev Logo
ShashiShashikanth Thambrahalli has been blogging for as long as I can remember. I think he might have been one of the founding members of the MQDev blog! Shashi is passionate about the service of our product, and the go to man for .NET and XMS too. This years he’s also been blogging about MFT. See his posts on the MQDev blog. You’ll also see him regularly answering questions on StackOverflow. LinkedIn Logo
developerWorks Logo
MQDev Logo
No PhotoSimon Davitt started his blogging career in 2016 with a couple of posts on MQDev. Hope to see more in 2017. developerWorks Logo
MQDev Logo
No PhotoSridhar Ravindra started blogging in 2016. He blogs on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Thomas LeendTom started blogging at the start of 2016, writing up problems seen in his day job in Level 3 service, that are useful for all users to see. It’s a great way to get the word out about common problems. He blogs on the MQDev blog – see his posts. Tom can also be found on the IBM MQ Service YouTube channel. LinkedIn Logo
developerWorks Logo
MQDev Logo
T.RobT.Rob Wyatt has his own blog, Store and Forward – A blog about securing and using WebSphere MQ, where he writes about MQ, and then he also writes over on the IBM MiddleWare User Community. T.Rob has looked at MQ from every angle, he’s been a customer, an IBMer and now, a consultant offering his incredible knowledge about MQ, to get your MQ system running smoothly. You’ll also see him regularly answering questions on StackOverflow. LinkedIn Logo
developerWorks Logo
Twitter Logo
Tony SharkeyTony Sharkey is an IBM MQ for z/OS Performance expert. If you’ve got any interest in MQ on z/OS, you’ve probably read at lot of Tony’s writing over the years as he’s contributed hugely to the Performance Reports you get for every release. Now he’s blogging as well. He blogs on the MQDev blog – see his posts. developerWorks Logo
MQDev Logo
Twitter Logo

It is so great to see so many IBM MQ experts taking the time to write blog posts for you all to read. If you don’t follow one or more of these blogs, you should. Clicking on the “Follow” button is easy! I look forward to reading many more blog posts in 2017, and sharing them in our Monthly Newsletter. Thanks to all our MQ bloggers!


Footnote: If you’ve blogged about IBM MQ in 2016 and you’re not in the above list, let me know in the comments and I’ll add you to the list, and your blog to our IBM MQ Resources Page if it’s not already there.