| Author |
Message
|
| BBuff |
 Posted: Wed Apr 12, 2006 6:08 am Post subject: |
 |
|
Novice
Joined: 11 Apr 2006
Posts: 10
|
True. I've been totally impressed with the response on the forum.
I do have a little more information. If PutApplType = MQAT_IMS_BRIDGE then the message never arrives in the queue. If it is set to PutApplType = MQAT_WINDOWS_NT the message shows up in the queue just fine. I know I have some sort of disconnect somewhere, but not sure where it is at this time. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 12, 2006 6:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBuff wrote: |
True. I've been totally impressed with the response on the forum.
I do have a little more information. If PutApplType = MQAT_IMS_BRIDGE then the message never arrives in the queue. If it is set to PutApplType = MQAT_WINDOWS_NT the message shows up in the queue just fine. I know I have some sort of disconnect somewhere, but not sure where it is at this time. |
Well this would make sense. If you're claiming that the putting application for a message intended for the bridge is the bridge, it'll disappear up itself in a puff of logic. 
I never set putting application & let it default. Lazy but seems to work. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| BBuff |
| Posted: Wed Apr 12, 2006 6:45 am Post subject: |
|
|
Novice
Joined: 11 Apr 2006
Posts: 10
|
| Well I lied. If the Message Descriptor Format property that's killing me somehow. If it's set to MQFMT_IMS the message never goes in the queue, but if it is set to MQFMT_STRING it's fine. Sorry for any confusion. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 12, 2006 6:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBuff wrote: |
| Well I lied. If the Message Descriptor Format property that's killing me somehow. If it's set to MQFMT_IMS the message never goes in the queue, but if it is set to MQFMT_STRING it's fine. Sorry for any confusion. |
Bizarre. Can't think of a reason why the format would cause the put to fail, but clearly your system can. Interested to know what the reason code is when you set MQFMT_IMS, but it's just morbid curiosity.
The IT world is full of bizarre things, and I've learned to just let them slide unless they actually stop you getting someplace.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| BBuff |
| Posted: Wed Apr 12, 2006 6:59 am Post subject: |
|
|
Novice
Joined: 11 Apr 2006
Posts: 10
|
The weird thing is that when I debug and step over the MQPUT line the reason code is 0.
Is this correct for building the header:
Private Function BuildBridgeHeader() As Variant
Dim header As String
header = "IIH " ' MQIIH_STRUCT_ID
header = header & Hex$("1") ' MQIIH_VERSION_1
header = header & Hex$("84") ' MQIIH_LENGTH_1
header = header & Hex$("0") ' 4 byte reserved
header = header & Hex$("0") ' 4 byte reserved
header = header & "MQIMSVS " ' MQFMT_IMS_VAR_STRING
header = header & Hex$("0") ' MQIIH_NONE
header = header & "MASTER " ' 8 byte ltermoverride
header = header & "MODU03 " ' 8 byte mfsmapname
header = header & "MQIMSVS " ' MQFMT_IMS_VAR_STRING
header = header & Left(g_user_id & Space( , ' 8 byte authenticator
header = header & "0000000000000000" ' 16 byte transid
header = header & " " ' MQITS_NOT_IN_CONVERSATION
header = header & "1" ' MQICM_SEND_THEN_COMMIT
header = header & "C" ' MQIIS_CHECK
header = header & " " ' 1 byte reserved
BuildBridgeHeader = header
End Function
| Vitor wrote: |
| BBuff wrote: |
| Well I lied. If the Message Descriptor Format property that's killing me somehow. If it's set to MQFMT_IMS the message never goes in the queue, but if it is set to MQFMT_STRING it's fine. Sorry for any confusion. |
Bizarre. Can't think of a reason why the format would cause the put to fail, but clearly your system can. Interested to know what the reason code is when you set MQFMT_IMS, but it's just morbid curiosity.
The IT world is full of bizarre things, and I've learned to just let them slide unless they actually stop you getting someplace.... |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 12, 2006 7:27 am Post subject: Re: MQIIH In VB6 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I would have stuck with
| BBuff wrote: |
Dim iih As MQIIH
MQIIH_DEFAULTS iih
|
etc - more maintainable.
No message & a reason code of 0? Again, bizarre. Clearly getting itself routed someplace. Hands up anyone who cares.....? 
Unless of course, as JT points out, the reason it's not there is because IMS has consumed it....? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| DryHeatDave |
| Posted: Wed Apr 12, 2006 8:12 am Post subject: |
|
|
Apprentice
Joined: 21 Mar 2006
Posts: 28
Location: Phoenix, AZ
|
NOt sure how much it helps (if at all). But here's a captured example - I have sanitised the replyto info & userid. As you can see on the last line, we did explicitly include the LLZZTRANNAME before the payload (we use a SOAP-compliant envelope).
[ 364 bytes] Message Descriptor (MQMD)
StrucId :'MD '
Version :2
Report :0
Message Type :8
Expiry :-1
Feedback :0
MQEncoding :0x'311'
CCSID :37
Format :'MQIMS '
Priority :0
Persistence :0 (Not Persistent)
Message Id :. ( . . . . & . . . . . . . . . . . . . . . . .
414D512053445058585131312020202043DAE1DA208F4402
Correl. Id :. . . . . . . . . . . . . . . . . . . . . . . .
000000000000000000000000000000000000000000000000
Backout Cnt. :0
ReplyToQ :'reply.to.queue.name '
ReplyToQMgr :'reply.to.queue.manager.name '
UserId :'usersid '
AccountingTkn:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0000000000000000000000000000000000000000000000000000000000000000
ApplIndentity:' '
PutApplType :28
PutApplName :' '
Put Date :'20060214'
Put Time :'10200396'
ApplOriginDat:' '
Group Id :. . . . . . . . . . . . . . . . . . . . . . . .
000000000000000000000000000000000000000000000000
Msg Seq No. :1
Offset :0
MsgFlags :0
Original Len.:-1
+00000000 C9C9C840 00000001 00000054 00000000 00000000 IIH ................
+00000014 D4D8C9D4 E2404040 00000000 40404040 40404040 MQIMS ....
+00000028 40404040 40404040 D4D8C9D4 E2E5E240 40404040 MQIMSVS
+0000003C 40404040 00000000 00000000 00000000 00000000 ................
+00000050 40F0C340 0AA40000 D3E5D3E2 E3404040 4CC595A5 0C .u..LVLST <Env
_________________
SCJP2
IBM Cert. Solutions Designer for Websphere MQ 5.3
Not a certified mainframer - just been doing it a real long time. |
|
| Back to top |
|
|
| DryHeatDave |
| Posted: Wed Apr 12, 2006 8:19 am Post subject: |
|
|
Apprentice
Joined: 21 Mar 2006
Posts: 28
Location: Phoenix, AZ
|
Regarding the Format in the descriptor - I think it has to be MQIMS, to tell MQ to look for (and parse) the IIH.
Q. Does anyone know - does this apply when sending a message with RFH2 (or other) headers ? i.e. do you have to set the appropriate MD format, to get MQ to parse the additional header/s ?
If changing the format to MQIMS in the descriptor causes an error - betting it's a problem in the IIH, which was not being parsed by MQ before (if you don't tell it to expect an IIH, I guess it'll be treated as payload)
_________________
SCJP2
IBM Cert. Solutions Designer for Websphere MQ 5.3
Not a certified mainframer - just been doing it a real long time. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 12, 2006 8:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The format of the MQMD has to always be set to the format of the next section of the message.
Sometimes this section is another header, sometimes it is the message body.
In general, if a particular section of a message has a Format field, then the format field will indicate the format of the NEXT section of the message.
so if you have a message that is
MQMD
MQIIH
MQRFH2
Body
Then the MQMD Format will be MQIIH, the MQIIH Format will be MQHRF2 and the format of the MQRFH2 will be, perhaps, MQFMT_STRING.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
