JMS/MQRFH2 Message Properties in “other” Folder

January 17, 2020 Roger Lacroix

On StackOverflow, someone asked about having an “other” folder (not “usr”) with an MQRFH2 (aka JMS) message.

That day, I played around with a MQ/Java program that created various folders in an MQRFH2 message.
i.e.

MQMessage sendmsg = new MQMessage();
MQRFH2 rfh2 = new MQRFH2();
rfh2.setEncoding(CMQC.MQENC_NATIVE);
rfh2.setCodedCharSetId(CMQC.MQCCSI_INHERIT);
rfh2.setFormat(CMQC.MQFMT_STRING);
rfh2.setFlags(0);
rfh2.setNameValueCCSID(1208);
// type of JMS message
rfh2.setFieldValue("mcd", "Msd", "jms_text");
rfh2.setFieldValue("jms", "Dst", "queue:///"+outputQName);
// set named properties in the "usr" folder
rfh2.setFieldValue("usr", "SomeNum", 123);
rfh2.setFieldValue("usr", "SomeText", "TEST");
// set named properties in the "other" folder
rfh2.setFieldValue("other", "thingA", 789);
rfh2.setFieldValue("other", "thingB", "XYZ");
// Set the MQRFH2 structure to the message
rfh2.write(sendmsg);
sendmsg.writeString("This is a test message.");
// IMPORTANT: Set the format to MQRFH2 aka JMS Message.
sendmsg.format = CMQC.MQFMT_RF_HEADER_2;
// put the message on the queue
queue.put(sendmsg, pmo);

When I ran a MQ/JMS program to retrieve the messages, the MQ/JMS programs simply ignore all folders outside of ‘mcd’, ‘jms’ and ‘usr’.

QueueReceiver receiver = session.createReceiver(myQ);
Message inMessage = receiver.receive();
String thing = inMessage.getStringProperty("other.thingB");
System.out.println("   thing="+thing);

Enumeration<String> props = inMessage.getPropertyNames();
if (props != null)
{
   while (props.hasMoreElements())
   {
      String propName = props.nextElement();
      Object o = inMessage.getObjectProperty(propName);
      System.out.println("   Name="+propName+" : Value="+o);
   }
}

Any named properties in the “other” folder are simply ignored by the JMS framework.

If you are wondering about C programs, yes, they can get access named properties in the “other” folder. When using the MQINQMP API call, there is no parameter for the folder name, so you code it as a qualifier to the name keyword. i.e. “other.thingB”

MQCHARV  inqname = {(MQPTR)(char*)"other.thingB", 0, 0, 12, MQCCSI_APPL};
impo.Options = MQIMPO_INQ_NEXT;
impo.ReturnedName.VSPtr = name;
impo.ReturnedName.VSBufSize = sizeof(name)-1;
type = MQTYPE_STRING;
MQINQMP(Hcon, Hmsg, &impo, &inqname, &pd, &type, sizeof(value)-1, value, &datalen, &CompCode, &Reason );
printf("property name <%s> value <%s>\n", name, value);

So, if you want to use a folder called “other”, that is fine, so long as you don’t want the information to be used by a JMS/MQ program, otherwise, you need to put the name/value properties in the ‘usr’ folder.

Regards,
Roger Lacroix
Capitalware Inc.

C, IBM i (OS/400), IBM MQ, Java, JMS, Linux, macOS (Mac OS X), Programming, Unix, Windows, z/OS Comments Off on JMS/MQRFH2 Message Properties in “other” Folder

Merry Christmas and Happy New Year

December 19, 2019 Roger Lacroix

I would like to wish everyone a Merry Christmas, Happy Hanukkah, Happy Kwanzaa, etc… and a Happy New Year. 🙂

Regards,
Roger Lacroix
Capitalware Inc.

General 1 Comment

Windows Print Screen

December 12, 2019 Roger Lacroix

Ok. Here’s something not related to MQ or programming. 🙂

Everyday, someone sends Capitalware a support request with an image or two. Its not a problem. I review what they asking and send back a reply.

Most of the images I receive are some sort of cropped image of the whole desktop. Sometimes the image is tightly cropped to whatever they are sending and sometimes I’m getting too much information about their desktop.

A far better way of sending Capitalware a screen shot of information is to use one of the following 2 options:

(1) Bring the window to the foreground (so that it is active) then press ALT-PrtScn. i.e. Hold the ALT key then press the PrtScn (Print Screen) key. Windows will capture an image of ONLY the active window and place it in the clipboard and then the user can paste it into an email.

(2) Use the Snipping Tool that has been available since Windows Vista. Start it, select the Mode (i.e. Rectangular Snip), click New button and select whatever you want then paste it into the email.

Note: None of the images are shared with anyone or other companies but it is far, far better for people to only send Capitalware information that I need to see.

Regards,
Roger Lacroix
Capitalware Inc.

Capitalware, Windows Comments Off on Windows Print Screen

MQ Internals Explained (a little bit)

December 10, 2019 Roger Lacroix

IBM likes to market IBM MQ (aka WebSphere MQ, MQSeries) as a simple and complete solution for business’s messaging needs. Going with the KISS approach is wise (very wise in some cases).

IBM talks about the 2 different messaging models that IBM MQ supports: Point-to-Point (P2P) and Publish/Subscribe (Pub/Sub).

    IBM will:

  • show you how to put messages to local/alias/cluster/remote queues (P2P) or get messages from local/alias/cluster queues (P2P).
  • show you how to publish messages to a topic string or object (Pub/Sub) or subscribe to a subscription (or topic) to retrieve messages from a topic string or object (Pub/Sub).
  • show you how to create an alias queue that can point to (1) a local queue (P2P) or (2) a topic (Pub/Sub) and if you use a topic, how to cross messages from the P2P model to the Pub/Sub model.
  • show you how to create a subscription that can point to (1) a local queue (P2P) or (2) a topic (Pub/Sub) and if you use a local or alias queue, how to cross messages from the Pub/Sub model to the P2P model.

IBM likes to show the world that IBM MQ use of Point-to-Point and Publish/Subscribe is a single messaging model. While IBM markets IBM MQ as a single messaging model is fine (aka the KISS approach), it sometimes makes my life a little difficult when explaining either MQ Message Encryption or MQ Auditor to customers (although, less so with MQ Auditor, because by default, it collects information from both messaging models).

Here’s an example: A customer recently sent me a picture of a setup they were trying to implement with MQ Message Encryption (MQME) and they were confused why MQME did not do its job of encrypting messages when the messages were put/published at different points in the setup.

Here’s the picture of their setup:

For those who prefer MQSC definitions, here they are:

DEFINE QALIAS('TEST_ALIAS') TARGET('TEST_TOPIC') TARGTYPE(TOPIC)
DEFINE QREMOTE('TEST_QUEUE_REM') RQMNAME('QMGR2') RNAME('TEST_QUEUE') XMITQ('QMGR2')
DEFINE QLOCAL('TEST_QUEUE_LOC')
DEFINE TOPIC('TEST_TOPIC') TOPICSTR('MQME/TEST')
DEFINE SUB('TEST_SUB_1') TOPICSTR('') TOPICOBJ('TEST_TOPIC') DEST('TEST_QUEUE_REM')
DEFINE SUB('TEST_SUB_2') TOPICSTR('') TOPICOBJ('TEST_TOPIC') DEST('TEST_QUEUE_LOC')

When they put a message to the alias queue, everything was fine but when they published a message to the topic ‘MQME/TEST’ then the message was not encrypted.

In the user’s MQME IniFile, they only had set the protected queue(s) of ‘TEST*’. They did NOT have any protected topic definitions.

There are many things I need to explain that goes on under the covers with MQ. I will do my best to explain it in a logical order but I know that I’m about to confuse many people.

Things to remember:

(1) When messages flow through P2P model/environment, the message can be a plain message, JMS message (aka MQRFH2), CICS message, IMS message, SAP message, etc.

Layout for 5 example messages for P2P:

{message payload}
{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}
{CICS header}{message payload}
{IMS header}{message payload}
{SAP header}{message payload}

(2) When messages flow through Pub/Sub model/environment, the message MUST be a JMS message (aka MQRFH2) formatted message. Now a JMS message can contain a CICS message, IMS message, SAP message, etc.

Layout for 4 example messages for Pub/Sub:

{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}
{RFH2 header}{mcd folder}{jms folder}{usr folder}{CICS header}{message payload}
{RFH2 header}{mcd folder}{jms folder}{usr folder}{IMS header}{message payload}
{RFH2 header}{mcd folder}{jms folder}{usr folder}{SAP header}{message payload}

Note: The user can change the queue’s property attribute (PROPCTL) or subscription’s property attribute (PSPROP) to ‘NONE’, so that MQ removes the message properties (aka named properties) and folders when the message is retrieved by the application.

Item #1:
When an application opens an alias queue, internally that object type is called MQOT_Q. Hence, MQ is operating in the P2P model. Since, it is the P2P model, MQME will check its protect queue definitions for the a match. If MQME finds a match then all messages put to or retrieved from that object handle (aka opened queue) will be encrypted or decrypted (assuming permissions are correct).

When the user ran an application to publish a message to topic ‘MQME/TEST’, the topic was opened and the object type was MQOT_TOPIC. Since, it is the Pub/Sub model, MQME will check its protect topic definitions for the a match. In this particular case, MQME did not find a match, so it will not encrypt the messages or decrypt the messages for subscribers.

Now if the user adds a protect topic definition to the MQME IniFile with something like ‘MQME/TEST’ or ‘MQME/*’ or ‘MQME/TEST*’ then MQME would find a match and encrypt or decrypt messages of that particular topic.

Here’s the analogy that I like to use with customers, think of IBM MQ as a brain (human brain if you will). Each person has a single brain. IBM MQ provides a single messaging infrastructure. But if you look closely at the brain, you will see that it is made up of 2 hemispheres and if you look closely, you will see that IBM MQ is made up of 2 different messaging models: Point-to-Point and Publish/Subscribe.

So, how an application opens a queue or topic will dictate which side of the brain (aka messaging system) MQ will use to handle the getting or putting of messages. And if companies have a configuration where messages flow back and forth between the 2 messaging systems then the users of MQME need to beware of the point of contact with the MQ (aka the brain).

Item #2:
Did you know that when a message hops between P2P and Pub/Sub that the message actually changes! Also, for those of you that are using MQ’s Pub/Sub for message replication, did you know that not all MQMD fields of the original message are replicated to the copied messages!

Example:

Using the above customer setup, if you start MQ Explorer and put a test message to the alias queue ‘TEST_ALIAS’ then the following is what happens to the message:

– Putting a plain message to an alias queue

{message payload}

– When MQ transfers the message to a topic object or subscription then the message becomes

{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}

– When the message is put to the XMITQ queue it looks like

{XMIT header}{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}

– When it is put to the local queue of the local queue manager, it is still in the format:

{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}

– When it is put to the local queue of the remote queue manager, it is still in the format:

{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}

Note: For those newbies out there, MQRFH2 is the internal name for a JMS message. Also, yes, I know on the subscription, the user can change the Property attribute (PSPROP) to ‘NONE’, so that MQ removes the message properties (aka named properties) which in theory turns the message back to a regular message.

Users of MQ should really be aware of what goes on under the covers with MQ, so that they don’t blame MQ when they don’t get the results they want.

Also, there are far simpler solutions for handling message replication. i.e. MQ Message Replication

If you want, you can sub-title this blog posting as ‘your brain on MQ!’ 🙂

Regards,
Roger Lacroix
Capitalware Inc.

.NET, Assembler, C, C#, C++, HPE NonStop, IBM i (OS/400), IBM MQ, Java, JMS, Linux, macOS (Mac OS X), MQ Auditor, MQ Message Encryption, Programming, Unix, Windows, z/OS 2 Comments

MQME Issue with ExcludeQueue keyword on an MQPUT1 API Call

December 9, 2019 Roger Lacroix

Late last week, a customer discovered an obscure issue in MQ Message Encryption (MQME) with the ExcludeQueue keyword on an MQPUT1 API call.

I have since fixed it but here is what I mean by obscure:

– If the user has wild-carded their protected queue setup i.e. ‘TEST.*’
– And then set the ExcludeQueue keyword value to ‘TEST.FRED’ because they want all ‘TEST.*’ queues to have their messages encrypted EXCEPT for queue ‘TEST.FRED’
– There was a bug in MQME that it did not successfully handle the values for ExcludeQueue keyword on an MQPUT1 API call.
– Hence, the messages for queue ‘TEST.FRED’ would be encrypted.
– And this only happened for MQPUT1 API calls – MQPUT API calls were correctly handled.

This is an obscure but supported setup. Most customers either explicitly set the queue name for a protect queue (i.e. ‘TEST.BARNEY’) or they wildcard it (i.e. TEST.*) but they generally don’t wildcard the protected queues then exclude a single queue. Note: The user could actually exclude queues with a wildcard.

This too is a supported setup:
– Have protect queues of ‘TEST.*’
– And exclude queues of ‘TEST.FRED.*’
– Or the user could exclude queues for ‘TEST.FRED.*’ and ‘TEST.WILMA.*’

Hence, any queue listed in the ExcludeQueue would NOT have their messages encrypted.

If anyone would like to test out the latest release then send the email to support@capitalware.com

Regards,
Roger Lacroix
Capitalware Inc.

Capitalware, IBM i (OS/400), IBM MQ, Linux, MQ Message Encryption, Security, Unix, Windows Comments Off on MQME Issue with ExcludeQueue keyword on an MQPUT1 API Call

wc3270 and IBM RDP Issue

December 9, 2019 Roger Lacroix

I use IBM’s Remote Development Program (RDP) to host my z/OS and Linux for System z LPARs. I installed the latest release of wc3270 of the x3270 project on my new Windows 10 PC and copied my settings from my old Windows 7 PC. Hence, I should be good to go but no.

I have been getting the following error and at first I thought maybe IBM was re-configuring their Dallas data center (which they do from time to time):

SSL: InitializeSecurityContext: error 0x80090322 (The target principal name is incorrect.)

I checked the online documentation for IBM’s RDP and the IP address (requires TLS/SSL tunnel) for the master VM is still the same. I checked my wc320 session file for corruption and it was fine. I compared the old release of wc3270 wizard with the current release and I noticed a new option called “10. Verify host certificates”. It is set to “Yes” by default. I decided set it to “No” and try the connection again. Surprise, I got a successful connection.

I don’t know when the option “Verify host certificates” was added to wc3270 but if you upgrade wc3270 and start getting the above error messages then set “Verify host certificates” to “No”.

Or you can edit your wc3270 session file(s) and add the following line:

wc3270.verifyHostCert: false

Regards,
Roger Lacroix
Capitalware Inc.

Capitalware, Open Source, Security, Windows, z/OS Comments Off on wc3270 and IBM RDP Issue

IBM MQ Fix Pack 9.1.0.4 Released

December 6, 2019 Roger Lacroix

IBM has just released Fix Pack 9.1.0.4 for IBM MQ V9.1 LTS:
https://www.ibm.com/support/pages/node/1119051

Regards,
Roger Lacroix
Capitalware Inc.

Fix Packs for MQ, IBM MQ, Linux, Unix, Windows Comments Off on IBM MQ Fix Pack 9.1.0.4 Released

IBM MQ V9.1.4 Announced

December 3, 2019 Roger Lacroix

IBM has announced IBM MQ V9.1.4 for Multiplatforms:
https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS219-487/index.html
Planned availability for IBM MQ V9.1.4 is December 5, 2019 for Electronic software delivery.

IBM MQ (aka WebSphere MQ) homepage
https://www.ibm.com/products/mq

Regards,
Roger Lacroix
Capitalware Inc.

Fix Packs for MQ, IBM MQ, IBM MQ Appliance, Linux, Unix, Windows, z/OS Comments Off on IBM MQ V9.1.4 Announced

MQ Batch Toolkit v3.2.0 Released

December 3, 2019 Roger Lacroix

Capitalware Inc. would like to announce the official release of MQ Batch Toolkit v3.2.0. This is a FREE upgrade for ALL licensed users of MQ Batch Toolkit. MQ Batch Toolkit allows users to manipulate, monitor and manage messages in a queue of an IBM MQ (formally WebSphere MQ & MQSeries) queue manager from a command-line or shell scripting environment.

For more information about MQ Batch Toolkit go to:
https://www.capitalware.com/mqbt_overview.html

    Changes for MQ Batch Toolkit v3.2.0:

  • Updated the QList and TopicList function to have ‘-S’ parameter that will allow SYSTEM queues or topics to be included in the output list
  • Fixed an issue with parsing event (PCF) messages and displaying them.
  • Updated SSL/TLS support
  • Enhanced the error message regarding an expired license key
  • Added warning message that the trial-only release cannot be registered.
  • Updated docs (English only)

Regards,
Roger Lacroix
Capitalware Inc.

Capitalware, IBM MQ, Linux, macOS (Mac OS X), MQ Batch Toolkit, Windows Comments Off on MQ Batch Toolkit v3.2.0 Released

Java on Windows 10 Issue: “Could not open/create prefs root node”

November 22, 2019 Roger Lacroix

I was getting the following error message when I would run a Java application on my new Windows 10 Pro PC:

Nov 21, 2019 3:57:37 PM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.

I searched the internet regarding the error message, people say it is a known bug and you need to manually create the following Windows registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs

When I opened the RegEdit, I found that the key already exists.

After a little more searching on the internet, I came across another comment that says you also need the following Windows registry key: 

HKEY_LOCAL_MACHINE\Software\WOW6432Node\JavaSoft\Prefs

So, I opened the RegEdit and found the key did not exist. I created it and then the error message went away.

Hence, for future users who encounter this error message, create a text file called javasoft_prefs.reg and put the following in it:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs]

[HKEY_LOCAL_MACHINE\Software\WOW6432Node\JavaSoft\Prefs]

Now start RegEdit and click File – > Import and select the javasoft_prefs.reg file and the error message will go away.

Or you can run RegEdit from the Command Line and pass the file name as a parameter:

regedit  javasoft_prefs.reg

Regards,
Roger Lacroix
Capitalware Inc.

Java, Programming, Windows Comments Off on Java on Windows 10 Issue: “Could not open/create prefs root node”