IBM has just released FixPack 9.0.0.3 for IBM MQ V9.0 LTS
http://www.ibm.com/support/docview.wss?uid=swg24044508
Regards,
Roger Lacroix
Capitalware Inc.
IBM has just released FixPack 9.0.0.3 for IBM MQ V9.0 LTS
http://www.ibm.com/support/docview.wss?uid=swg24044508
Regards,
Roger Lacroix
Capitalware Inc.
IBM has announced IBM MQ V9.0.5 Continuous Delivery:
http://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/4/877/ENUSZP18-0084/index.html
New features and enhancements for clients with MQ Advanced entitlement
– Enhancements to the previously delivered Replicated Data Queue Manager support
– New support for the MQ MFT REST administration interface
– Identification of MQ Advanced installs
– Improved performance for MQ AMS encryption on MQ Advanced for z/OS® VUE
New capabilities for both MQ base and MQ Advanced clients
– Increased security flexibility and updates
– Updates to the MQ Console
– Enhancements to syncpoint performance
IBM MQ (aka WebSphere MQ) homepage
http://www.ibm.com/software/products/en/ibm-mq
Regards,
Roger Lacroix
Capitalware Inc.
Bastien Jansen has written a blog posting called: High performance IBM MQ & JMS applications. If you program in JMS and IBM MQ then you should definitely read the blog posting. You can find it here:
https://bjansen.github.io/java/2018/03/04/high-performance-mq-jms.html
Persistent messages are used by queue managers to guarantee message delivery.
That’s not the correct IBM terminology. It should be “assured message delivery“, otherwise IBM lawyers get their shorts in knots. 🙂
Regards,
Roger Lacroix
Capitalware Inc.
Paul Titheridge has posted a blog item over at developerWorks with the title “What is the default behaviour of the IBM MQ classes for Java method MQMessage.writeString(String)?”:
https://developer.ibm.com/messaging/2018/03/09/mqmessage-writestring-default-behaviour/
Regards,
Roger Lacroix
Capitalware Inc.
IBM has posted a support note regarding the levels of JRE and GSkit bundled with IBM MQ
http://www.ibm.com/support/docview.wss?uid=swg27038676
Regards,
Roger Lacroix
Capitalware Inc.
Yesterday, I wrote about MQ Messages to/from SQLite DB which are a pair of utilities for offloading and loading messages to/from SQLite database.
I thought it would be a good idea to publish what I designed so that other vendors, companies or users can easy use the standard.
First, the SQL to create the table is:
CREATE TABLE IBM_MQ_MESSAGES(Version INT, Report INT, MsgType INT, Expiry INT, Feedback INT, Encoding INT, CodedCharSetId INT, Priority INT, Persistence INT, BackoutCount INT, PutApplType INT, MsgSeqNumber INT, Offset INT, MsgFlags INT, OriginalLength INT, Format CHAR(8), ReplyToQ CHAR(48), ReplyToQMgr CHAR(48), UserIdentifier CHAR(12), ApplIdentityData CHAR(32), PutApplName CHAR(28), PutDate CHAR(8), PutTime CHAR(8), ApplOriginData CHAR(4), MsgId BLOB, CorrelId BLOB, AccountingToken BLOB, GroupId BLOB, Data BLOB );
I like the KISS principle, so the name of the table is “IBM_MQ_MESSAGES”. Clean and obvious. The column names are directly from the MQMD structure in cmqc.h file.
The naming standard for the SQLite database file is based on the queue manager’s name, the queue name and the current day’s date.
I.e.
For a file extension, I decided to create a uniquely identifyible file extension called ‘mqsdb’. Now, I could have gone with a more standard file extension like ‘db’ or ‘sqlite’ but I wanted something more descriptive that would clearly identify the file’s purpose.
Next, reducing the database size or attempting to keep it as small as possible. Hence, any MQMD field that was either all blank or null, I set the table column to null for that record. This is done for all 9 CHAR fields and 5 BLOB fields.
i.e.
/* Is the Format field all blank? */ if (memcmp(pMD->Format, MQFMT_NONE, MQ_FORMAT_LENGTH) == 0) sqlite3_bind_null(hStmt, 16); else sqlite3_bind_text(hStmt, 16, pMD->Format, MQ_FORMAT_LENGTH, SQLITE_STATIC); /* Is the CorrelId field all null? */ if (memcmp(pMD->CorrelId, MQCI_NONE, MQ_CORREL_ID_LENGTH) == 0) sqlite3_bind_null(hStmt, 26); else sqlite3_bind_blob(hStmt, 26, (char *)&(pMD->CorrelId), MQ_CORREL_ID_LENGTH, SQLITE_STATIC);
So, in theory, if the Format field is blank or the CorrelId field is null, then by setting the column field to null, it should save disk space.
Finally, reading the SQLite database where certain columns may or may not be null.
/* Retrieve the Format field, is it null? */ p = (char *)sqlite3_column_text(hStmt, 15); if (p != NULL) memcpy(md.Format, p, MQ_FORMAT_LENGTH); /* Retrieve the CorrelId field, is it null? */ p = (char *)sqlite3_column_blob(hStmt, 25); if (p != NULL) memcpy(md.CorrelId, p, MQ_CORREL_ID_LENGTH);
So there you have it, a new MQ Messages to SQLite database standard that I hope everyone will adopt. 🙂
Now, for those people who REALLY like to read code, please don’t get your shorts in a knot because the column numbers are different between writing and reading the database. It is one of those quirks in SQLite. For sqlite3_bind_* API calls, the column number begin with ‘1’ whereas for sqlite3_column_* API calls, the column number begin with ‘0’. Hence, that is why they differ by 1 and it is something you just need to remember. 🙂
Maybe some time in the near future, I’ll write another blog posting on how to handle this new MQ Messages to SQLite database standard from Java.
Regards,
Roger Lacroix
Capitalware Inc.
Capitalware has an MQ solution called MQ Message Replication (MQMR).
MQ Message Replication will clone messages being written (via MQPUT or MQPUT1 API calls) to an application’s output queue and MQMR will write the exact same messages to ‘n’ target queues (‘n’ can be up to 100). When MQMR replicates a message both the message data and the message’s MQMD structure will be cloned. This means that the fields of the MQMD structure (i.e. PutTime, MessageId, CorrelId, UserId, etc..) will be exactly the same as the original message’s MQMD structure.
I have always left it up to the customer to decide what to do with and/or how to offload replicated messages in the target queue(s). There are probably 100 solutions for extracting messages in a queue and writing the information to a file: Capitalware has solutions, other vendors have products, SupprtPacs and even the new dmpmqmsg program included with IBM MQ. These are all fine tools to get the job done and of course, I prefer my tools which use VEQ format that I created a very long time ago (and is published here).
Over this past weekend, I got the bright idea to create the 101st solution for offloading and loading MQ messages to and from an SQLite database. I will include the solution with MQMR for free – an extra little bonus for customers. 🙂
Why bother? Well, it is nice to have MQ messages as records in a database table. It allows the user to do what ever they want to the MQMD header and/or the message data. There are lots of SQLite tools to manage/interact with an SQLite database. Plus, an SQLite database is a single file. So, a user can quickly compress/zip the file and move it another server without any issues.
I like the KISS (Keep It Simple Stupid) principle. So rather than have 1 program do both loading and unloading of messages, I broke it up into 2 light-weight programs. Ok, light-weight may be a bit of an understatement since they both have MQ and database calls. 🙂
I decided to write these 2 programs in C rather than Java. I like to mix things up. 🙂 I’ll do builds of them on AIX, HP-UX, IBM i, Linux, Solaris and Windows.
Both programs can be run from the command line or as an MQ Service. I would strongly suggest that people run MQ2SDB program as an MQ Service on the same queue manager where MQMR is configured as an MQ API Exit. Hence, when the queue manager is started, MQ2SDB will write MQ messages to the SQLite database right away.
MQ2SDB program will create the database file based on the queue manager’s name, the queue name and the current day’s date.
I.e.
{QMgrName}-{QueueName}-YYYY_MM_DD.mqsdb
When retrieving MQ messages and writing them to an SQLite database, MQ2SDB program will automatically roll to the next file at midnight (or when the next message arrives after midnight).
Here’s a screen-shot of DB Browser for SQLite with an SQLite database table that contains 100 records (messages). Click to see a larger image of it.
By default, when the SDB2MQ program is run, it will load all of the records in the database table as messages into the specified queue. The SDB2MQ program has 2 optional parameters (StartPosition and RowCount) to control where to start the load and how many records to load as messages into the queue.
If you interesting in trying it out, please send an email to support@capitalware.com to request a trial of MQ Message Replication with these new extra tools.
Note: If people are interested in offload/load messages to/from an SQLite database then I will extend this feature into MQ Visual Edit, MQ Visual Browse and MQ Batch Toolkit.
Regards,
Roger Lacroix
Capitalware Inc.
What is GDPR? From Wikipedia:
The General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) is a regulation by which the European Parliament, the Council of the European Union and the European Commission intend to strengthen and unify data protection for all individuals within the European Union (EU). It also addresses the export of personal data outside the EU. The GDPR aims primarily to give control back to citizens and residents over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.[1] When the GDPR takes effect, it will replace the data protection directive (officially Directive 95/46/EC)[2] of 1995. The regulation was adopted on 27 April 2016. It becomes enforceable from 25 May 2018 after a two-year transition period and, unlike a directive, it does not require national governments to pass any enabling legislation, and is thus directly binding and applicable.
May 25th, 2018 is only 3 months away. For those companies in the EU and any company that interacts with EU residences, what have you done to protect IBM MQ messages that contain personal data?
Capitalware has created and sells a variety of MQ solutions that solve the above listed questions:
* MQME does have support for Pub/Sub encryption. Several customers have been testing and using it for about 9 months. I just haven’t made the official announcement.
And if your company’s auditors want to know ‘who is doing what in MQ’, we also have created and sell the following MQ solutions:
Regards,
Roger Lacroix
Capitalware Inc.