Delivered RFEs in MQ V8
Morag Hughson 110000EQPN Comments (2) Visits (6033)
We've had the Requ
From the announcement letters, you'll have seen we had a number of security features in MQ V8. One of those features was an enhancement to the MQ CHLAUTH rules introduced in MQ V7.1. In MQ V8 you can now use hostnames instead of IP addresses if you wish. This was raised as RFE 21982 and was the most voted for un-delivered RFE, and second highest voted for from all RFEs (closed or not), so we got the message that it was a pretty important thing for us to do! At the same time, we sorted out another issue raised in RFE 34976, about turning off reverse lookup of hostnames, something that was previously only controlled by an undocumented service parameter. We added it as a proper queue manager attribute, on both distributed and z/OS, in MQ V8.
There were quite a few RFEs asking for enhancements around the area of password checking, some requesting supplied exits (like the CSQ4BCX3 exit we have on z/OS) others asking for authentication via LDAP, or PassPhrases on z/OS. The requests were all rather different (so the RFEs couldn't all be closed as duplicates) but ultimately quite a number of them are satisfied by our Connection Authentication line item, where you can have applications supply a user ID and password and have the queue manager make use of those to authenticate the connection, either against the O/S or against an LDAP server. RFEs 22568, 29335, 30709, 31523, 42463 and 44077 were all closed off as delivered.
We've had a single digital certificate to represent the whole queue manager right back from when SSL was first introduced in MQ V5.3. In MQ V8 we have relaxed both the mandated name and the single certificate by giving you a place to provide the label of the certificate you want to use, both overall for the queue manager, and per channel, so now different channels can present a different certificate to the partner. This was most eloquently requested by RFE 26672, and also in RFE 34056. It was also the basic problem described by RFE 28672 which has also been closed as delivered.
You can read more about these security features in MQ V8 in the "IBM
There are a number of z/OS specific features in MQ V8, as there always are. One of the most wished for z/OS features was completed in MQ V8 and that was providing the ability to move your buffer pools above the bar and utilise 64-bit storage for them. This was raised as RFE 22361. Since we were making changes to buffer pools, we also made another change that you, our customers, requested via RFE 22368, to increase the number of buffer pools, so you can now have the same number as you have page sets, making buffer pool management easier.
We've done quite a bit of work on our SMF stats in V8, including supplying stats for the CHINIT address, and the channels which run there, as well as improving the granularity of our stats as requested by RFE 29399. Now you can configure stats per queue, and you can start gathering stats for long running tasks.
There was no V7.5 of MQ on z/OS, so there was a lot of interest about when z/OS customers would be able to get hold of the Split Cluster Transmit queue feature that the distributed platforms supplied in V7.5. I suspect it is no surprise to most that it appears in MQ V8, the next available release on z/OS. It was requested in RFE 24104.
You can read more about these, and other, z/OS specific features in MQ V8 in the "IBM
The IBM i platform was in a similar position to z/OS because there was no V7.5 release there either. There was, of course, a V8 version of it though, and that provided the Advanced Message Security (AMS) feature built into the queue manager, just as for the other distributed platforms in V7.5. This meets requirement 37862 which was raised.
We have a number of very popular SupportPacs for MQ. One of the most popular was MO72, an alternative to runmqsc, that could run on a client (something runmqsc couldn't previously do). In MQ V8, runmqsc is enhanced to allow it to run as a client program, using the -c flag, and also, you can use it to create or edit Client Channel Definition Table (CCDT) files on a client only installation using the -n flag. This means you are no longer forced to create the CCDT on the queue manager box and then move it to the client box. There were a few RFEs that requested this including RFE 26417, and RFE 35525. At the same time as providing this, we have stabilised the CSQUTIL MAKECLNT utility on z/OS which provided the same ability if you only had queue managers on z/OS.
Nothing stays still in the IT world and the MQ SOE is no exception. We do get a lot of requests for updates to the SOE outwith the cycle of a new release, and these are not mentioned here, but of course, some are done in a new release, such as a new level of MS Visual Studio as raised in RFE 30504, or support for Windows Server 2012 as raised in RFE 32936.
Quite a number of the RFEs and line items mentioned above were sizable peices of work. But an RFE doesn't have to be for a big thing, smaller requests are also just fine, for example RFE 30310, which requested the behaviour of the SUBUSER attribute make more sense, and RFE 41015, which got dmpmqcfg to capture all authority records, not just those which has objects associated with them (and also we fixed this via an APAR for earlier releases), were requested and slotted in, in between other big peices of work that had to be done.
This is not a complete list of all the features in MQ V8, just those that were requested through RFEs. If you want a more complete view of MQ V8, check out the