| Author |
Message
|
| dosttumhara1810 |
 Posted: Wed Jan 29, 2014 3:31 am Post subject: CCSID in MQGET node |
 |
|
Voyager
Joined: 01 Dec 2010
Posts: 76
|
hi All,
Is there any way to force MQGET node to use the CCSID (1208) instead of the one set by the Sending application into the MQMD header (CCSID 1140) of the input message of MQGET node listening Queue.
What is happening is there are some special characters that the sending application is sending the the XML body but with CCSID set in MQMD as 1140. Hence when MQGET node picks the messge it throws error on Failure terminal saying parsing fail due to some unconvertable character coming in the body of the message and when checked that character is not supported in 1140, but supported in 1208. Now i want MQGET node to forcefully use 1208 as the CCSID while parsing the message, instead of the one sen by the sending application. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Jan 29, 2014 4:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If the sender has mislabelled the data as codepage 1140 when it is really 1208 - then this is a basic programming error that needs fixing.
Otherwise you have little option but to get it without conversion as a Blob and then manipulate the MQMD values.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jan 29, 2014 4:55 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Well, my friend 1810,
you can always create a little helper flow that gets the messages from the queue as BLOB, modifies MQMD.CodedCharacterSetId and puts the messages onto another queue.
Then change the MQGet node to read from that queue instead. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 29, 2014 5:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Better still fix the origin program instead of making a work-around (the latter seems to be the norm in some cultures which means IT is steadily being messed up!).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 29, 2014 5:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| zpat wrote: |
| Better still fix the origin program instead of making a work-around (the latter seems to be the norm in some cultures which means IT is steadily being messed up!). |
totally agree. Otherwise you will end up with a hack for 1140, 51, 437, 923 and every other CCSID in common use in your receiving application.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Jan 29, 2014 5:55 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Esa wrote: |
Well, my friend 1810,
you can always create a little helper flow that gets the messages from the queue as BLOB, modifies MQMD.CodedCharacterSetId and puts the messages onto another queue.
Then change the MQGet node to read from that queue instead. |
No way !!... the solution was already given, and suggesting micky mouse fixes is no good. Fix the problem at source please. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jan 29, 2014 6:19 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
I agree with the others.
My suggestion is just a quick fix that can be used to enable further testing while the sending end keeps fixing the problem.
Because the problem seemed to me something that usually happens when you have started integration or system testing. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 29, 2014 6:27 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Esa wrote: |
I agree with the others.
My suggestion is just a quick fix that can be used to enable further testing while the sending end keeps fixing the problem.
Because the problem seemed to me something that usually happens when you have started integration or system testing. |
The trouble is that 'quick fixes' quickly become impossible to remove.
'Why do we need to change our system when you already have a work around...'
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jan 29, 2014 6:47 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| smdavies99 wrote: |
The trouble is that 'quick fixes' quickly become impossible to remove.
'Why do we need to change our system when you already have a work around...' |
So true.
Hey, listen! Is that water that I hear falling somewhere...  |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Jan 29, 2014 7:01 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Esa wrote: |
I agree with the others.
My suggestion is just a quick fix that can be used to enable further testing while the sending end keeps fixing the problem.
|
In that case, next time please make it clear that it is ONLY a suggestion to enable testing, but not a full solution. |
|
| Back to top |
|
|
|
|
