| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| EBCDIC/ASCII Conversion |
« View previous topic :: View next topic » |
| Author |
Message
|
| TopOne |
 Posted: Thu Oct 05, 2006 7:03 pm Post subject: codepage? |
 |
|
Newbie
Joined: 02 Oct 2006
Posts: 4
Location: Chile
|
I have the problem in the past.
solutions:
1) MAINFRAME CODE PAGE IN CP437
LINK EXIST for CCSID XXX in 0
2) Mainframe all Channels in mode autoconverted = no
3) Client plataform channels in mode converted = yes , the distribution software mq with tables of convertion for cp437 and CODEPAGE of plataform = any
Lo único permanente es el Cambio.
only the change is permanent. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Oct 06, 2006 3:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rmpinchback wrote: |
The problem is that unless you control otherwise, the default CCSID for client mode comes from the queue manager. |
That is not correct. A client uses its local CCSID, even if you specify the default QM CCSID when doing the MQPUT. This is documented in the Client manual.
If your app spits out "Hello World", and those bytes are ASCII bytes, and they happen to be on a Windows box, then your message's MQMD better have 437 in the CCSID field. Guess what, it will. If the app is running in bindings mode and asks for the QM's CCSID it will get it, 437. And that's great, since the data is 437 at that point.
Now take a Windows client and connect it to a mainframe QM, whose CCSID is 500. When that app spits out the bytes, they are still CCSID 437 bytes, and when they get placed on the queue, whether that queue is on a z/OS QM, or an AS/400 QM, or a Solaris QM, they better be tagged as 437. And as I stated above IBM thought this out and the client will produce an MQMD that matches the CCSID of the local client, not the QM.
If you call a dog a duck, it will not quack!
If a Windows app put Hello World into a queue and manually codes 500 in the CCSID, those bytes will not automatically convert themselves to EBCIDIC. MQ does not offer Convert_On_Put! In this scenario, you end up with ASCII bytes, tagged as EBCIDIC, and when the next innocent app does a get with convert, MQ treats those ASCII bytes as EBCIDIC when starting the converision, and it turns into a big mess! That dog no longer barks, it doesn't quack, it just pukes!
Bottom line is that when a message is about to be put on a queue, its MQMD_CCSID better match exactly the actually data. Then let an MQ Sender channel or an MQ application's get with convert change that data to the receiver's code page.
Wanna know a CCSID horror story? We bought a mainframe emulation tool. It ran on a windows box, and produced EBCIDIC data. Kewl, its emulating the mainframe. But when that cobol program running in the emulation program on a windows box made a MQ Client call to do an MQPUT, guess what, MQClient worked as designed and tagged those messages as CCSID 437. Working as designed. How the heck were the MQClient libraries supposed to know that a Windows app was not producing 437 messages, but instead was producing CCSID 500 messages!? The solution was to specifically code CCSID 500 prior to the put. The app was putting CCSID 500 messages, so we had to tag them as such. I learned a lot about clients and CCSID that week!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
