| Author |
Message
|
| Sam Uppu |
 Posted: Sun Dec 19, 2010 12:25 pm Post subject: regarding cast function |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
I have a question regarding Cast function. We use CCSID and ENCODING to cast any message.
Somewhere in the forum, I saw only CCSID is used for casting any message.
I would like to know if both CCSID & ENCODING are used for casting a message or CCSID alone is used.
Let me know.
Thanks
Sam |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Sun Dec 19, 2010 12:53 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It depends on what you are casting to what.
If you are casting an INTEGER to a formatted decimal, why would CCSID be involved?
If you are casting a string from one CCSID to another, why would Encoding be involved? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Dec 19, 2010 12:56 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Depending upon the content of your messages, the ENCODING value may have no affect on the outcome of a CAST operation.
Kimbert has explained this a number of times in this forum. I bow down to his greater understanding of this area than myself.
_________________
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 |
|
|
| Sam Uppu |
| Posted: Sun Dec 19, 2010 1:05 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Thank you mqjeff. Pls help me in understanding the below ones.
If I am getting BLOB data to mqinput node
and I want to cast it to char, I should use
only ccsid. Pls confirm.
If I want to cast char data to blob again, I need to use only
ccsid with the cast function.
Pls confirm. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sun Dec 19, 2010 1:43 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
If I am getting BLOB data to mqinput node
and I want to cast it to char, I should use
only ccsid. Pls confirm. |
You *may* need the ENCODING as well. It depends on the code page that you are using.
a) if your CCSID refers to a single-byte code page then you do not need ENCODING
b) if your CCSID refers to a multi-byte code page, AND the code page has an implied byte order then you do not need ENCODING
c) if your CCSID refers to a multi-byte code page AND the code page does not have an implied byte order then you *may* need to specify ENCODING.
The usual example of c) is code page 1200 ( UTF-16, byte order not specified ). If this code page is used, the data will often that with a Unicode byte-order mark ( BOM ), in which case ENCODING will not be required.
| Quote: |
If I want to cast char data to blob again, I need to use only
ccsid with the cast function. |
Not true. The above rules apply in this direction as well. If you want a specific byte order in the output then you must either specify a code page with an implied byte order, or else specify ENCODING.
Having said all of that, you could just specify ENCODING anyway - if it is not required it will simply be ignored. Most people specify InputRoot.Properties.Encoding regardless of whether they need it. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Sun Dec 19, 2010 4:08 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Thank you guys for sharing valuable information.
I have one more question.
We have COBOL data coming to wmb flow.
WMB is running on Aix.
We enabled Ebcdic to ASCII conversion in mqinputnode(ccsid 819, encoding 273).
The COBOL file after coming out of mqinput node has some junk characters.
These junk characters are actually represented as
Lowvalues in mainframe.
I don't understand why we are getting these junk characters when we have
Conversion enabled on the node.
Let me know your thoughts. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sun Dec 19, 2010 4:25 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| We enabled Ebcdic to ASCII conversion in mqinputnode |
That is nearly always the wrong approach. You should make sure that the CCSID in the MQ header is correct ( i.e. it accurately describes the content of the message ) and then let message broker perform any required code page conversion.
As things stand
a) you are double-converting the text data ( EBCDIC->ASCII->Unicode )
and
b) you may well be treating non-text data ( maybe packed decimals or binary integers ) as text. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Sun Dec 19, 2010 4:35 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| kimbert wrote: |
| Quote: |
| We enabled Ebcdic to ASCII conversion in mqinputnode |
That is nearly always the wrong approach. You should make sure that the CCSID in the MQ header is correct ( i.e. it accurately describes the content of the message ) and then let message broker perform any required code page conversion. |
When a message comes from Mainframe program the CCSID is 500. We have enabled convert on MQInput node.
I didn't understand what is wrong with my approach?
[quote="kimbert"]
| Quote: |
As things stand
a) you are double-converting the text data ( EBCDIC->ASCII->Unicode )
and
b) you may well be treating non-text data ( maybe packed decimals or binary integers ) as text. |
We are not doing any conversion via esql.It is broker(MQINPUT node) which is doing the conversion. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Dec 19, 2010 9:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Like Kimbert said, this is the wrong approach.
Your message set is built with a specific set up in mind... and converting your input will change this setup.
There is also the fact that certain characters may not exist in the CCSID you are converting to when using the convert flag on the MQInput node: presumably the default CCSID of the broker's qmgr.
Best practice is to not set any conversion flag (channel, MQInput node etc...) but let the broker convert the original bitstream to Unicode. It also ensures that those pesky characters that you now see with a "?" get converted correctly, at least until the bitstream is serialized again into a CCSID that does not support said pesky characters...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Dec 20, 2010 2:38 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| When a message comes from Mainframe program the CCSID is 500. We have enabled convert on MQInput node. I didn't understand what is wrong with my approach? |
Message broker converts all character data to Unicode when it parses the input message. If you enable conversion on the MQInput node then you are ( at best ) doing message broker's work for it.
You have told the input node to convert to ASCII. ASCII is not Unicode. So message broker is converting from EBCDIC to ASCII in the input node and then converting from ASCII to Unicode in the message flow.
Switch off the conversion in the input node. Message broker will convert directly from CCSID 500 to Unicode when it needs to. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Dec 20, 2010 7:56 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
[quote="kimbert"]
| Quote: |
| Switch off the conversion in the input node. Message broker will convert directly from CCSID 500 to Unicode when it needs to. |
I would switch off the convertion on input node. I am not using messageset. The data from mainframe is coming like blob.
I am wondering will broker take care of conversion from EBCIDIC to ASCII?
If broker takes care of this, why there are so many discussions on EBCIDIC to ASCII convertion?
Why do we have convert option on MQINPUT node? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 20, 2010 8:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| I would switch off the convertion on input node. I am not using messageset. The data from mainframe is coming like blob. |
If the data is in the form of a COBOL copybook, why not use a message set? Why take it as a BLOB, cast it to character and then (presumably) try to do something useful with it?
It does sound (as has been said before) like you're trying to do broker's job for it.
| Sam Uppu wrote: |
| I am wondering will broker take care of conversion from EBCIDIC to ASCII? |
If you ask it to, by telling it to output the message tree in ASCII. Again (as has been said before) the broker uses Unicode not ASCII
| Sam Uppu wrote: |
| If broker takes care of this, why there are so many discussions on EBCIDIC to ASCII convertion? |
Because so many people either don't understand or do it wrong (like having an EBCDIC message with an ASCII CCSID in the MQMD because they're sending it to an ASCII machine.....!).
| Sam Uppu wrote: |
| Why do we have convert option on MQINPUT node? |
Because it's an MQGMO option and the node exposes it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Dec 20, 2010 8:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Vitor is correct. We cannot provide any more help unless you explain what your message flow is trying to do. I was assuming that you were using a message set to parse your COBOL data. I expect there is a reason why you're not doing it that way. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 20, 2010 9:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Back up a step... you first need to understand the nature and type of data the COBOL program is creating.
If the COBOL is running on z/OS, then it is creating 8-bit EBCDIC - which can (but will not likely) use all 256 possible characters in the EBCDIC character set.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 20, 2010 9:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
Back up a step... you first need to understand the nature and type of data the COBOL program is creating.
If the COBOL is running on z/OS, then it is creating 8-bit EBCDIC - which can (but will not likely) use all 256 possible characters in the EBCDIC character set. |
I don't see the point you're making. No matter if the EBCDIC is 7 or 8 bits, all of these will fit into the broker's Unicode and the z/OS data is described by a copybook. So the message set can describe it.
So what understanding of the nature and type of data is required over and above the copybook layout? Or do you mean that some characters in the EBCDIC can't be described as ASCII? That's theoretically true for 7-bit as well, and is a fairly remote chance for business data.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
