| Author |
Message
|
| chris boehnke |
 Posted: Wed Oct 06, 2010 7:46 am Post subject: regarding CCSID's |
 |
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
Hi Guys,
I have my BROKER on AIX system. In Request flow, I need to send a request COBOL message to mainframe application. Later, in Response flow, I receive the response message from Mainframe application.
My questions are
In Request flow, do I need to change the CCSID from ASCII to EBCDIC before dropping the message to Mainframe application?
In response flow, I receive message from Mainframe application, Do I need to change the CCSID from EBCDIC to ASCII?
Pls suggest. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 06, 2010 7:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
CCSID should always reflect the coding of the message.
Does the mainframe app do a get with convert reading the message?
Does your response flow have convert switched on in the MQInpt node?
Do the channels to or from the mainframe have conversion switched on?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Wed Oct 06, 2010 8:14 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| Vitor wrote: |
CCSID should always reflect the coding of the message.
Does the mainframe app do a get with convert reading the message?
Does your response flow have convert switched on in the MQInpt node?
Do the channels to or from the mainframe have conversion switched on? |
If nothing is done from Mainframe application or MQ
In Request flow, do I just need to change the CCSID and Encdoing on message Properties to EBCDIC and send to Mainframe application while putting the mesage to queue?
In Response flow , Do I need to just change the CCSID to ASCII on message Properties or do I need to do any thing else for processing the message.
Pls suggest. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Wed Oct 06, 2010 9:41 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
Guys,
In my response flow, I am getting message from Mainframe application. This message is received as BLOB on my input queue. Late I would send this message as one input to WTX map.
I would like to know if I need to do any CCSID change from ASCII to EBCDIC?
Pls let me know. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 06, 2010 1:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chris boehnke wrote: |
Guys,
In my response flow, I am getting message from Mainframe application. This message is received as BLOB on my input queue. Late I would send this message as one input to WTX map.
I would like to know if I need to do any CCSID change from ASCII to EBCDIC?
Pls let me know. |
Don't know about WTX... but
- It will not hurt on the output to the MF to set the CCSID in the properties to say 37 or 500 depending on what you use on the MF.
- on the reply, if you need to translate make sure you use CCSID and ENCODING from InputRoot.Properties.... as those will define the ccsid and encoding the received BLOB is in...
- In short the Properties should always describe the ccsid and encoding your message payload is in.
I would not set the translation flag on the MQInput node.
Now all depends on what CCSID your WTX map is expecting and whether it expects a single byte or multibyte charset. This will effect the way the BLOB is parsed and transformed.
And this was the short version....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Wed Oct 06, 2010 7:18 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
fjb,
Thanks for your inputs.
If the Mainframe application uses MQGMO_CONVERT , is it ok if we donot change the CCSID and encoding when we drop message to Mainframe queue? Pls clarify.
I would contact the WTX team and find out if they are using CCSID and Encding while doing transformation.
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 06, 2010 7:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chris boehnke wrote: |
fjb,
Thanks for your inputs.
If the Mainframe application uses MQGMO_CONVERT , is it ok if we donot change the CCSID and encoding when we drop message to Mainframe queue? Pls clarify.
I would contact the WTX team and find out if they are using CCSID and Encding while doing transformation.
Thanks |
It might well be. But if you do set it on the broker before putting to the MF it will not matter either way.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Thu Oct 07, 2010 11:42 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| Vitor wrote: |
CCSID should always reflect the coding of the message.
Does the mainframe app do a get with convert reading the message?
Does your response flow have convert switched on in the MQInpt node?
Do the channels to or from the mainframe have conversion switched on? |
WTX maps take only ASCII data. So, I am thinking to check the convert property on MQINPUT node and use Encoing and CCSID of AIX QMGR.
and convert it to ASCII.
Is only the convert property on MQINPUT node enough for conversion?
Anything else is also required from MQ?
Pls clarify |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 07, 2010 12:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chris boehnke wrote: |
WTX maps take only ASCII data. So, I am thinking to check the convert property on MQINPUT node and use Encoing and CCSID of AIX QMGR.
and convert it to ASCII.
Is only the convert property on MQINPUT node enough for conversion?
Anything else is also required from MQ?
Pls clarify |
Well the problem I have is the meaning of ASCII in correlation with the WTX map. If you could relate it to a CCSID it would be better.
Some character that can be mapped in ccsid 500 or 37, may have no equivalent in ccsid 437 or 819... but be available in ccsid 1208... also it would be the "odd one out".
Try it the way you suggested. I'm sure it will work 90 to 99% of the time. However if the format of the messages is not MQFMT_STRING you'll still have to convert the CCSID of the message and BLOB in a compute node.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Thu Oct 07, 2010 5:03 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| fjb_saper wrote: |
| chris boehnke wrote: |
WTX maps take only ASCII data. So, I am thinking to check the convert property on MQINPUT node and use Encoing and CCSID of AIX QMGR.
and convert it to ASCII.
Is only the convert property on MQINPUT node enough for conversion?
Anything else is also required from MQ?
Pls clarify |
Well the problem I have is the meaning of ASCII in correlation with the WTX map. If you could relate it to a CCSID it would be better.
Some character that can be mapped in ccsid 500 or 37, may have no equivalent in ccsid 437 or 819... but be available in ccsid 1208... also it would be the "odd one out".
Try it the way you suggested. I'm sure it will work 90 to 99% of the time. However if the format of the messages is not MQFMT_STRING you'll still have to convert the CCSID of the message and BLOB in a compute node. |
I am getting reply message from Mainframe. My message flow is running on AIX system.
So the CCSID coversion is from 500 to 819.
As you said some characters have no equivalent in 437 or 819, Can I convert CCSID 500 to 1208 instead of 819?
Pls suggest |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 07, 2010 6:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sure you can.
- Do not set the convert flag on the MQInput node
- Use an MQ compute node for
- convert from ccsid 500 to char
cast (blob as character ccsid InputRoot.Properties.CodedCharSetId);
- Convert char to blob ccsid 1208:
SET OutputRoot.Properties.CodedCharSetId = 1208;
CAST (charvar AS BLOB CCSID OutputRoot.Properties.CodedCharSetId);
Important: You need to set the outputroot.properties' ccsid before doing the conversion (cast). If you set it after your MQ message will be all messed up and in the wrong ccsid!
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Fri Oct 08, 2010 4:51 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
fjb,
I made changes as you have suggested. It is working. Thanks a lot. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 08, 2010 6:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chris boehnke wrote: |
fjb,
I made changes as you have suggested. It is working. Thanks a lot. |
Bitte Sehr, gern geschehen.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Oct 10, 2010 3:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It is a basic principle of decoupled design not to code for the target. Today it might be a mainframe, tomorrow it might be Linux.
Convert on receipt. It's always the correct approach to take. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Oct 10, 2010 12:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
It is a basic principle of decoupled design not to code for the target. Today it might be a mainframe, tomorrow it might be Linux.
Convert on receipt. It's always the correct approach to take. |
 However reality is sometimes in the way. There still exists some MF centric environments where the programs are not always coded with the convert option... and getting them to change is sometimes more of a battle than it's worth. We've all learned to choose our battles... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
