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.

Advertisements

IBM MQ and MQ Appliance News – October 2017

On Tuesday October 24th, IBM Hursley announced the next in the series of Continuous Delivery releases for IBM MQ V9.0 and the MQ Appliance. IBM MQ V9.0.4 was made available on November 6th.

Here are the various announcement letters:-

Links of interest:-


We’ll collect up any other links about the new release as we find them and put them all here.

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

IBM MQ and MQ Appliance News – May 2017

On Tuesday May 30th, IBM Hursley made available the next in the series of Continuous Delivery releases for IBM MQ V9.0 and the MQ Appliance. IBM MQ V9.0.3 is now available.

Downloading IBM MQ Version 9.0.3 Continuous Delivery

This was announced on z/OS VUE:-

Links of interest:-


We’ll collect up any other links about the new release as we find them and put them all here.

IBM MQ V9 LTS FixPack 1

IBM recently shipped the first Fix Pack for the V9.0.0 Long Term Support (LTS) release.

Downloading IBM MQ Version 9.0.0.1

Spotted by one of our eagle-eyed followers, this document indicates:-

IBM MQ Version 9.0.0, Fix Pack 1 is released only on AIX, IBMi, Linux, and Windows. It is not released on HP-UX or Solaris.

EDIT: Fix Pack 1 is now available on HP-UX on Itanium, Solaris on SPARC, and Solaris on x86 64 as of 15 June 2017. Download from the above link.

We asked IBM why this was the case, and here is the answer.

9.0.0.1 was not shipped on HP-UX and Solaris due to an ongoing quality issue in the JVM on those platforms. We expect 9.0.0 LTS maintenance to be available on these platforms in the future. For more info [on the JVM quality issue on those platforms], head here: Oracle Bug Report: JDK-8175251 : Failed to load RSA private key from pkcs12.



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 and MQ Appliance News – March 2017

On Firday March 17th, IBM Hursley made available the next in the series of Continuous Delivery releases for IBM MQ V9.0 and the MQ Appliance. IBM MQ V9.0.2 is now available.

Downloading IBM MQ Version 9.0.2 Continuous Delivery

Unlike V9.0.1 there are no announcement letters.

Read about the changes in this blog post by Leif Davidsen.

Other links of interest:-

Or read this IBM InterConnect 2017 conference presentation from David Ware and Pete Siddall.

Or watch this video.


We’ll collect up any other links about the new release as we find them and put them all here.


The next Continuous Delivery (CD) release is now available. Read more about V9.0.3.