1

Faced a problem. I need to place an RFH2 message into MQ with Properties in the header. If using the MQ API:

MQCRTMH MQSETMP MQPUT

then everything works as long as the name Property does not contain a prefix (for example, 'Property1') - WRKMQMQ shows that the message is in RFH2 format, shows that it contains Properties, shows the correct list of properties...

But as soon as I try add a prefix like 'ctx.Property1', everything stops working... However, none of the above functions return an error. The message will be placed in MQ, but without RFH2 header and without properties.

The question is, how do I correctly prefix the property name?

Victor Pomortseff
  • 158
  • 1
  • 8
  • 1
    OK I have seen the same behaviour when testing using the IBM supplied sample amqsstm.exe - I have also seen that if I put two properties into the message Handle and the second one has no dot in the name, then BOTH properties are added to the message. This sounds very much like a defect. Suggest you contact IBM and open a case. – Morag Hughson Sep 21 '21 at 10:00
  • Morag, thank you so much for paying attention to my question (I really hoped for it - last time you helped a lot) It will be difficult to bring all the code here. Here are the key points: – Victor Pomortseff Sep 21 '21 at 10:12
  • `dsPropName.VCHRP = %addr(PropName);` `dsPropName.VCHRL = PropNameLen;` `MQSETMP(hConn : hMsg : dsMQSMPO : dsPropName : dsMQPD : PropType : PropValLen : %addr(PropVal) : OC : RC);` – Victor Pomortseff Sep 21 '21 at 10:12
  • ` dsMQPMO.PMOPT = %bitor(PMFIQ : PMNSYP : PMNCID);` `dsMQPMO.PMVER = PMVERC;` ` dsMQPMO.PMOMH = hMsg;` ` dsMQMD.MDFMT = FMNONE;` ` MQPUT(hConn : hObj : dsMQMD : dsMQPMO : BuffLen : %addr(Buffer) : OC : RC);` – Victor Pomortseff Sep 21 '21 at 10:15
  • if PropName = 'Property001' I see in WRKMQMQ: GMT GMT Opt Date Time Type UserId Format Size 20210921 10050820 DATAGRAM Y2KU MQHRF2 123 – Victor Pomortseff Sep 21 '21 at 10:18
  • But if PropName = 'ctx.Property001' I see this: GMT GMT Opt Date Time Type UserId Format Size 20210921 10023188 DATAGRAM Y2KU 27 – Victor Pomortseff Sep 21 '21 at 10:19
  • Morag, You are right! I tried add two properties with names: 'ctx.Property001' and 'Property002'. The both of them was added to message and it put to MQ in RFH2 format. It's really looks like defect - 'ctx.Property001' and 'Property002' - success, only 'Property002' - success but only 'ctx.Property001' - fail... – Victor Pomortseff Sep 21 '21 at 10:26
  • @MoragHughson, I found a solution. The fact is that by default, unless otherwise specified, the namespace 'usr' is used. Those. 'PropertyName' will [laced into namespace 'usr' But 'ctx.PropertyName' - into namspace 'ctx' Apparently, RFH2 header is not generated when namespace 'usr' is empty. And if you specify 'usr.ctx.PropertyName', everything works correctly – Victor Pomortseff Sep 21 '21 at 11:56
  • @VictorPomortseff in the future, update your question with the code rather than putting it in the comments - too hard to read code in comments. Also, MQRFH2 messages have folders. The default folders are: mcd & jms. The first qualifier of your property will indicate which folder the property should be put into . All user properties should be put into the usr folder as you have discovered. In MQ/Java, if you use the set***Property methods with just the single property name (no qualifiers) i.e. XYZ then MQ will place the property in the usr folder by default. – Roger Sep 21 '21 at 18:46
  • @Roger, there are a couple of important points missing from the IBM documentation. – Victor Pomortseff Sep 22 '21 at 04:57
  • First, if the folder is not explicitly specified, MQSETMP places the property in the usr folder (i.e. PropertyName is completely identical to usr.PropertyName). But if the folder is explicitly specified, then the property is placed in it and ctx.PropertyName is not equal to usr.ctx.PropertyName (in the first case, the property is placed in the ctx folder outside of usr, in the second - in ctx inside usr) - so that the property is placed in the folder ctx inside the usr folder, you must explicitly specify usr.ctx. This undescribed, ambivalent behavior can be confusing. – Victor Pomortseff Sep 22 '21 at 04:57
  • Secondly (and this is the main thing) - nowhere is it described that MQPUT does not create an RFH2 message header if the usr folder is empty, even if there is another, not empty, folder outside usr. But at the same time, if there are other properties in the usr folder, the header will be created and it will contain both the usr folder and other forlders outside of it. It was this fact that turned out to be a stumbling block for me yesterday. – Victor Pomortseff Sep 22 '21 at 04:57
  • I suspect the "described, ambivalent behaviour" is defective. Rather than asking IBM to describe it, I suggest you ask them to fix it! :-) As noted in my earlier response, I believe your next step should be to raise a case with IBM. Glad to see you have lots of data to give them though. You could write a answer for others, and then update it with anything you get back from IBM in way of an APAR later – Morag Hughson Sep 22 '21 at 05:16
  • @MoragHughson, unfortunately, I work for a company that is a "premium client" of IBM and cannot directly contact IBM over the head of the technical management. I described the situation to the chief architect of the company, I hope that the decision will be made at his level. The main problem, in my opinion, is the insufficient quality of the documentation. I have not found anywhere a mention of the fact that MQPUT does not form the RFH2 message header in the case when the usr folder does not contain any property, even if there is another, not empty, folder. – Victor Pomortseff Sep 22 '21 at 06:24
  • I suspect that is not documented because it is not meant to be that way. And frankly, you wouldn't want it to be that way either. To get code or doc updated you still need to open a case with IBM. – Morag Hughson Sep 22 '21 at 22:14
  • @MoragHughson, I agree that this behavior - when a property in a folder other than usr is placed in the header only when there are other properties in the usr folder - is rather strange. And I will try to convince our technical management to create a case on behalf of the company. – Victor Pomortseff Sep 23 '21 at 04:30
  • I am happy to hear you hope to raise a case with IBM. It would be a shame if a premium client was unable to do that. – Morag Hughson Sep 23 '21 at 09:34

1 Answers1

0

There are a couple of important points missing from the IBM documentation:

  1. If the folder is not explicitly specified, MQSETMP places the property in the usr folder (i.e. PropertyName is completely identical to usr.PropertyName). But if the folder is explicitly specified, then the property is placed in it and ctx.PropertyName is not equal to usr.ctx.PropertyName (in the first case, the property is placed in the ctx folder outside of usr, in the second - in ctx inside usr) - so that the property is placed in the folder ctx inside the usr folder, you must explicitly specify usr.ctx. This undescribed behavior can be confusing.
  2. (and this is the main thing) - nowhere is it described that MQPUT does not create an RFH2 message header if the usr folder is empty, even if there is another, not empty, folder outside usr. But at the same time, if there are other properties in the usr folder, the header will be created and it will contain both the usr folder and other forlders outside of it.

Thus, in my case, it is correct to name the property not ctx.PropertyName, but usr.ctx.PropertyName.

It should be borne in mind (which is also not reflected in the documentation) that if PropertyName or usr.PropertyName is passed to MQSETMP, the MQINQMP call after receiving the message will return the property name in the form PropertyName without usr. But if usr.ctx.PropertyName is passed to MQSETMP, then MQINQMP will return the full name usr.ctx.PropertyName.

Victor Pomortseff
  • 158
  • 1
  • 8