| Author |
Message
|
| RogerLacroix |
 Posted: Fri Mar 20, 2015 9:05 am Post subject: MQ Properties via Java application |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
All,
I have a very weird problem. I have a MQ Java application that is setting MQ properties and it works fine on MQ v7.5.0.2 and v8.0.0.0. It only fails with Reason Code of 2142 (MQRC_HEADER_ERROR) on a Windows running MQ v7.5.0.3. Yes, a PMR was opened with IBM but so far they are not very helpful.
The MQ Java application is running on Windows MQ v7.5.0.3 (I have verified that the MQ JAR are in fact v7.5.0.3) and is connecting to a queue manager running on Linux. Here is what the code looks like:
| Code: |
MQPutMessageOptions pmo = new MQPutMessageOptions();
pmo.options = CMQC.MQPMO_FAIL_IF_QUIESCING;
MQMessage sendMsg = new MQMessage();
sendMsg.messageId = CMQC.MQMI_NONE;
sendMsg.correlationId= CMQC.MQCI_NONE;
sendMsg.messageType = CMQC.MQMT_DATAGRAM;
sendMsg.format = CMQC.MQFMT_NONE;
sendMsg.setStringProperty("UFM_Directory", "/home/roger/upload/");
sendMsg.setStringProperty("UFM_FileName", "test1.txt");
sendMsg.write("This is a test message".getBytes());
outQ.put(sendMsg, pmo); |
The MQ Knowledge Center does not have a lot of information for RC of 2142 although it says not to set CCSID to MQCCSI_Q_MGR, so I removed that line of code but the problem persist.
No matter what other server I run the code on it works just fine. Has anybody ever had issues with setting MQ properties?
I'm trying to figure out if it is the MQ Client that is generating the RC of 2142 or if it is the MQ Server. Does anyone know how to figure that out? I need to give IBM Support as much information as possible (they have MQ trace files but getting them to look at the files is difficult).
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Mar 20, 2015 11:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Using 7.5.0.3 AMS and bindings connection, no problem with your code...
Tried it as well with a client connection (setting up MQEnvironment).
Worked just fine... for both cases...
Used the MQ provided JVM.
Are you using the MQ provided JVM or a non IBM JVM?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Mar 20, 2015 8:26 pm Post subject: Re: MQ Properties via Java application |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
| RogerLacroix wrote: |
The MQ Knowledge Center does not have a lot of information for RC of 2142 although it says not to set CCSID to MQCCSI_Q_MGR, so I removed that line of code but the problem persist.
|
I don't follow the documentation in the 2142 error in the manual about not setting the CodedCharSetId on a PUT or PUT1 to zero.
| Quote: |
2142 (085E) (RC2142): MQRC_HEADER_ERROR
Explanation
An MQPUT or MQPUT1 call was issued, but the message data contains an MQ header structure that is not valid. Possible errors include the following:
The StrucId field is not valid.
The Version field is not valid.
The StrucLength field specifies a value that is too small.
The CodedCharSetId field is zero, or a negative value that is not valid.
The BufferLength parameter of the call has a value that is too small to accommodate the structure (the structure extends beyond the end of the message).
|
I thought that was one of the recommended approaches for doing a PUT from the IBM documentation, which is to set the CodedCharSetId to MQCCSI_Q_MGR or zero on a PUT. I am pretty sure MQCCSI_Q_MGR is the default value for the CodedCharSetId on the MD, and the amsput sample programs would have that field set to zero on the PUTs, as well.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Mar 21, 2015 5:24 am Post subject: Re: MQ Properties via Java application |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| tczielke wrote: |
| I thought that was one of the recommended approaches for doing a PUT from the IBM documentation, which is to set the CodedCharSetId to MQCCSI_Q_MGR or zero on a PUT. I am pretty sure MQCCSI_Q_MGR is the default value for the CodedCharSetId on the MD, and the amsput sample programs would have that field set to zero on the PUTs, as well. |
It's more like the default approach. The recommended approach, I believe, is to set the CCSID on the message according to it's content. So if you set the content as text in UTF-8 you want to set the format to MQFMT_STRING and the CCSID to 1208....
If Roger did not set a CCSID on the MQEnvironment, or qmgr, his code is correct as he will use the default CCSID of the platform to write the content.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Mar 21, 2015 5:57 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
I have seen IBM documentation (it was some support doc about code pages) where the recommended approach was to let the CodedCharSetId be the default of zero on the PUT. But whether you want to explicitly set that field on the PUT or allow it to default (with zero), it is a moot point in regards to that 2142 error text:
| Quote: |
| The CodedCharSetId field is zero, or a negative value that is not valid. |
When I read that comment, I would naturally infer that having a CodedCharSetId of zero is illegal on a PUT, which is not correct. Maybe it is speaking to something else, that I am not aware of.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Mar 21, 2015 10:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Maybe it is referring to a change of CCSID on the queue manager without a bounce?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon Mar 23, 2015 6:14 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
FYI - This is the IBM support doc where it recommends setting the MQ.CodedCharSetId to MQCCSI_Q_MGR (or zero) on the MQPUT.
http://www-01.ibm.com/support/docview.wss?uid=swg27005729&aid=1
| Quote: |
Common Procedures when doing the MQPUT
Regardless of whether the message is character, numeric, or a mixture of both, in the application that is doing the initial MQPUT of the message, you should:
Set MQMD.CodedCharSetId to MQCCSI_Q_MGR. This will ensure that WebSphereMQ will pick up the default CCSID of the Queue Manager you are doing the MQPUTfrom. The reason for this is that the CodedCharSetId field in the Message Descriptor isboth an input and an output field. This means that if the application is using the sameMQMD structure for both MQPUTs and MQGETs, WebSphere MQ will be putting theCCSID of every message that it MQGETs into this field. If one of these messages was notusing the same CCSID as that of the Queue Manager, and you did not convert it, then thisfield will have been changed to an unanticipated value when the time comes to do thenext MQPUT. Even if you specified that you wished to convert the message on theMQGET, but the MQGET had an unexpected return code (such asMQRC_TRUNCATED_MSG_ACCEPTED) then the message will remain unconverted,and the CodedCharSetId field will be set to the CCSID of the unconverted message.
Note: In a client application, MQCCSI_Q_MGR refers to the CCSID of the applicationlocale, not the CCSID of the remote queue manager. In all cases, when settingMQMD.CodedCharSetId to MQCCSI_Q_MGR, it is the responsibility of the applicationto ensure that the implied CCSID correctly represents the string data in the message.
|
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon Mar 23, 2015 6:46 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
An invalid MD is a 2026. A 2142 looks like it is probably for the other MQ API data structures (i.e. MQDH, MQMDE, MQRFH, etc.) that have both a StrucLength and CodedCharSetId in their structure. Some of these must have a requirement where the CodedCharSetId can not be zero.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 23, 2015 9:43 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
All,
For completeness, I figured out what the problem was and this is what I sent to IBM Support:
| Sent_To_IBM wrote: |
I have identified the issue. The MQ application has been working for a number of years with the following 5 MQ JAR files in its CLASSPATH: connector.jar
com.ibm.mq.jar
com.ibm.mq.commonservices.jar
com.ibm.mq.headers.jar
com.ibm.mq.jmqi.jar
When I added the code to use MQ Properties that is when the MQ application received Reason Code of 2142. After a lot of trial and error, I discovered that if I added the 'com.ibm.mq.pcf.jar' JAR file then the everything would work.
MQ throwing an MQ Reason Code of 2142 is incorrect and totally misleading. MQ should be throwing a 'java.lang.NoClassDefFoundError: com/ibm/mq/pcf/***' for whatever class it was looking for. Also, why would an MQ application need to have the PCF jar file in its CLASSPATH when using MQ Properties?
This needs to be corrected, so that other MQ Java developers do not waste their time because Reason Code 2142 references issues with CodedCharSetId (CCSID) when the issue is clearly a missing class. |
So, if you get RC of 2142 from using MQ Properties, ignore the Reason Code and check your CLASSPATH for missing MQ JAR files - in particular the 'com.ibm.mq.pcf.jar' JAR file.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 23, 2015 10:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Now I see why I never get those errors... For my stand alone applications I always put all the jars in %MQ_INSTALL%\java on the classpath. Well maybe not the postcard one, but all the others, sure...
As to your question: did you look at the content of the pcf.jar? It contains the header's exception wrapper and the context class....
OK it's stuff I would have expected to be in the header.jar. Guess it didn't make it in there...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 23, 2015 10:35 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| fjb_saper wrote: |
| It contains the header's exception wrapper and the context class. |
Actually, if you look in the pcf JAR under com/ibm/mq/pcf you will see a class called CCSID. I bet that was the class it was looking for when it threw the RC of 2142. Of course, why in the world is a CCSID class in the pcf JAR file when it should be in the header JAR file.
| fjb_saper wrote: |
| OK it's stuff I would have expected to be in the header.jar. Guess it didn't make it in there. |
Exactly. This definitely falls on the plate of the MQ Java Architect and should have been caught in a code walk-thru.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 23, 2015 12:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
at first glance, packages com.ibm.mq.headers.pcf in the mqheaders.jar and com.ibm.mq.pcf in the pcf.jar seem to be quite identical... at least in class name ... perhaps not so much in class content?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Mar 24, 2015 10:21 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Over on the MQ ListServer, Ian Alderson posted his thoughts and I thought it would be good to put my reply to his comments here too (for future people doing searches).
| Ian_Alderson wrote: |
| But I did notice that you seemed to be using CMQC from the com.ibm.mq.headers, which is now deprecated. |
Nope. I am using 'com.ibm.mq.constants.CMQC' class. IBM has made a total mess of the CMQC class and totally confuses most Java developers. There are 4 CMQC class and 3 of the 4 are deprecated. Seriously, there are 4 CMQC classes for MQ Java developers can use.
Developers should only be using 'com.ibm.mq.constants.CMQC' class.
These 3 CMQC classes are deprecated:
- com.ibm.mq.headers.CMQC
- com.ibm.mq.headers.pcf.CMQC
- com.ibm.mq.pcf.CMQC
| Ian_Alderson wrote: |
| This has been superseded by the MQConstants class in com.ibm.mq.constants , with CMQC as an interface in the same jar. |
Yes, a developer can use the 'com.ibm.mq.constants.MQConstants' as it implements the 'com.ibm.mq.constants.CMQC' class. It is a massive catch-all class and it has implemented the 'com.ibm.mq.constants.CMQC' interface. I prefer to import only the class that I will be using. When a JVM has to load massive classes it means it will be using more memory in the JVM and I hate the 'out of memory' exception.
| Ian_Alderson wrote: |
| and was surprised to find that MQFMT_NONE does not in fact exist in CMQC from the headers jar |
Again, this is IBM and their duplication. In fact, I was using MQFMT_NONE from 'com.ibm.mq.constants.CMQC'.
| Ian_Alderson wrote: |
| This may or may not help, but I posted anyway as I think your problem would be also resolved by using constants jar rather than the pcf jar, which as you say doesn’t seem related. |
Nope. I tried it and it didn't make any difference.
| Ian_Alderson wrote: |
| To make things more confusing, these constants used to be in MQC, where MQFMT_NONE was deprecated previously. |
Actually, IBM deprecated MQC class in MQ v7.0.0.0 then undeprecated it. Seriously. See the tech note: http://www-01.ibm.com/support/docview.wss?uid=swg21423244
| IBM wrote: |
| In the WebSphere MQ V6 classes for Java, constants were contained in an interface called com.ibm.mq.MQC. This entire interface was deprecated in error at V7. The technote clarifies what aspects of the interface is still deprecated. |
If you check the Knowledge Center for MQ v7.5 or v8.0, you will see that MQC class (com.ibm.mq.MQC) is not deprecated. About 2/3 of the fields in MQC class are deprecated.
So, for those of us doing MQ Java development (non-JMS), IBM sure has made it difficult to know which classes to use and which to not use and of course the 'now it is deprecated, oops, no it is not' just drives you crazy.
Oh what fun. I wish IBM would hire me as the MQ Java Architect (part-time of course). First I would put in some hard and fast rules about the architecture and start doing proper code walk-thrus. Next pull a Microsoft, release MQ v10.0 and every duplicate Java and/or JMS class would be removed. Of course, it would come with clear warning that somethings will be broken but in the long run, it would make the MQ Java developers life easier (because isn't MQ supposed to be around for another 20 years!!).
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 24, 2015 12:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Used to only use WMQConstants and JmsConstants but not all the values I needed were there, so in some cases I had to use MQConstants...
Dropped all the others. Figure being deprecated will mean they might drop at the next release... Anyways it looks like you're just replacing the class name in front of the fieldname...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Mar 24, 2015 2:52 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| fjb_saper wrote: |
| Anyways it looks like you're just replacing the class name in front of the fieldname. |
If you are referring to using com.ibm.mq.constants.CMQC class rather than the massively large com.ibm.mq.constants.MQConstants class then yes.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
