| Author |
Message
|
| vijsam |
 Posted: Thu Dec 15, 2011 5:00 am Post subject: MQGet node Exception-Error creating converter |
 |
|
Apprentice
Joined: 01 Jun 2011
Posts: 46
|
Hi All,
Iam adding MQIIH headers before hitting Mainframe application,Iam using MQGet node which ll receive the message from Mainframe appliation,Iam setting Message Domain as BLOB,in MQGet node iam getting the exceptiona as :MQGet node Exception-Error creating converter,Please suggest .
Thanks in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 15, 2011 5:54 am Post subject: Re: MQGet node Exception-Error creating converter |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vijsam wrote: |
| Iam adding MQIIH headers before hitting Mainframe application |
As you describe here?
How (in light of the advice given) are you now adding the headers?
| vijsam wrote: |
| Iam setting Message Domain as BLOB |
Why?,
| vijsam wrote: |
| in MQGet node iam getting the exceptiona as :MQGet node Exception-Error creating converter |
Almost certainly the MQGet is in a tangle trying to manipulate the flow message (with or without IIH headers) and the message arriving via MQGet into an output message tree.
Check your MQGet settings, especially tree locations.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vijsam |
| Posted: Thu Dec 15, 2011 6:20 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2011
Posts: 46
|
I was able to set the headers as explained by you in previous link .Iam setting the messageDomain as blob to accept the headers and actual data.
I have set the properties in MQGet settings as :
Input MQMD location : blank . Did not specify any thing
and check Include message contents in output assembly.Do i need specifically mention any other properties?  |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 15, 2011 6:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vijsam wrote: |
| I was able to set the headers as explained by you in previous link |
Just attempting to clarify which method you'd selected from those offered in the thread.
| vijsam wrote: |
| Iam setting the messageDomain as blob to accept the headers and actual data. |
I don't understand your point. What headers? The MQIIH, MQMD, etc don't form part of the BLOB.
| vijsam wrote: |
I have set the properties in MQGet settings as :
Input MQMD location : blank . Did not specify any thing
and check Include message contents in output assembly.Do i need specifically mention any other properties? |
Well I'd have expected more than that to be specified. Perhaps if you gave a little background here? From what you've said you're picking up a message via MQGet, adding an MQIIH & pushing it to a mainframe by some undisclosed means, but what triggers your flow? Is that message incorporated into what the mainframe gets? How are you merging the trees? Certainly that's a first place to look for your issue IMHO.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vijsam |
| Posted: Thu Dec 15, 2011 6:55 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2011
Posts: 46
|
This is used for setting MQIIH headers at the begging
| Quote: |
| All you need is ESQL which adds the MQIIH header but specifies where in the tree it should be positioned; either before the data or after the MQMD |
flow looks like MQINput-->MQoutputNode-->MQGet node.
| Quote: |
| I don't understand your point. What headers? The MQIIH, |
after MQinptnode Iam appending MQIIH headers to the message and framing it as cobol structure and pushing it to MQoutput node and I can see the MQIIH headers added to the actual message in MQoutput node.
So vitor when the data is coming from Mainframe application does the MQIIH headers doesnot come with cobol structure? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 15, 2011 7:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
[quote="vijsam"]This is used for setting MQIIH headers at the begging
| Quote: |
| All you need is ESQL which adds the MQIIH header but specifies where in the tree it should be positioned; either before the data or after the MQMD |
Yes, but which of the 2 suggested methods did you end up using? 
| vijsam wrote: |
| flow looks like MQINput-->MQoutputNode-->MQGet node. |
So you're getting a message from someplace, passing it to the manframe and processing the response? With a few Compute nodes not shown?
| vijsam wrote: |
| So vitor when the data is coming from Mainframe application does the MQIIH headers doesnot come with cobol structure? |
Maybe, probably and what has that got to do with anything? Is that why you're using BLOB? Why? I don't see what you're trying to do & certainly don't see why the MQGet is not configured to process a response as that seems to be what you're doing.
This lies at the heart of your problem I think. Basically your flow is set up badly and it's breaking. From the details you've given it's hard to be specific but you don't seem to have set a lot of things I'd expect to be set, but maybe you've just not drip fed that information into this thread.
I also feel you may have a design or knowledge gap that beyond the scope of the help you can get here.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 15, 2011 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vitor wrote: |
| I also feel you may have a design or knowledge gap that beyond the scope of the help you can get here.... |
Or of course a broken MQGet node. What version of WMB are you using? If it's v6.1 not at current maintenance that could explain a lot.
WMBv7.0.0.0 may not be doing you any favours either.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| paintpot |
| Posted: Thu Dec 15, 2011 7:09 am Post subject: |
|
|
Centurion
Joined: 19 Sep 2005
Posts: 112
Location: UK
|
Break this problem into bits.
Look at the message created for the mainframe by using RFHUtil - does it look correct?
Does the mainframe transaction work correctly?
Look at the response from the mainframe using RFHUtil - does the message look correct?
Why use an MQGet? Just have another flow with an MQInput node - then see if that works - it's less easy to muck it up
 |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 15, 2011 7:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| paintpot wrote: |
| Why use an MQGet? Just have another flow with an MQInput node - then see if that works - it's less easy to muck it up |
Potentially valid as a diagnostic technique (if as subtle as a brick through a window) but not recommended if this really is a request/reply model.
Note the use of the word "if".
I mention this purely for the benefit of less experienced readers who may encounter this thread in the years to come. I'm sure you knew this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| paintpot |
| Posted: Thu Dec 15, 2011 7:45 am Post subject: |
|
|
Centurion
Joined: 19 Sep 2005
Posts: 112
Location: UK
|
| Vitor wrote: |
but not recommended if this really is a request/reply model.
|
Have to disagree here - much better design to have two separate flows - which would preserve broker resources better. Obviously you often need to preserve some context information, which can be hidden in an MQRFH2 with IMS transactions. Aggregations also work.
I suspect if the mainframe responds in a temperamental fashion, the broker flow could suffer the equivalent of a denial of service with the MQGet pattern suggested.
The OP may have his reasons for this design, but it can be wrong |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 15, 2011 8:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| paintpot wrote: |
| Obviously you often need to preserve some context information, which can be hidden in an MQRFH2 with IMS transactions. |
Relies on the mainframe application playing it's part which can be tricky if it's a legacy application "which can't be changed" but I take the point.
| paintpot wrote: |
| I suspect if the mainframe responds in a temperamental fashion, the broker flow could suffer the equivalent of a denial of service with the MQGet pattern suggested. |
So how would you handle the failure reposnse to the original requestor in this segregated scenario?
How would the flow be impacted as you suggest?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
