| Author |
Message
|
| zpat |
 Posted: Tue Sep 21, 2004 1:36 am Post subject: Default CCSID results? |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Suppose an application is putting a string message to MQ, without explicitly setting any MQMD fields (except perhaps format as MQSTR).
What will be the CCSID value found in the message? Where does this value come from?
Assume Windows MQ 5.3 client connected to a Windows MQ 5.3 Queue manager.
Then what happens if the same MQ client is now directly connected to a mainframe queue manager instead - does this change the CCSID that is defaulted? Will it now be correct? Assuming that the message data is always standard Windows ASCII.
The issue - is it necessary to explicitly set the CCSID on a message put in order to make the MQ client program work with different queue manager platforms or is it safe to allow it to default? |
|
| Back to top |
|
 |
| Tibor |
| Posted: Tue Sep 21, 2004 2:53 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
I think so you have to change / set MQCCSID when translation not found in CCSID.TBL , e.g.
- ASCII - EBCDIC or
- Latin-1 - EBCDIC is correct, but
- Latin-2 - EBCDIC isn't
Tibor
PS: It is absolutly theoretical, because I have never worked on mainframe... |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 21, 2004 7:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Not I am not asking about conversion, just what CCSID value appears in the MQMD.
I think the answer is the QM one, and this means changing to a mainframe QM will break the client application.
Syncpoint defaults also vary - IBM have managed to provide a cross-platform product that does not result in portable client code unless you change the default options on the MQI calls.
Not easy to do when the developers work somewhere else! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 21, 2004 9:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We had TONS of fun with this one.
The MQClient gets the CCSID of the machine the CLIENT is running, NOT the QM it is connected to. This is documented in the Clients Manual. You can override that behaviour by manually setting the CCSID prior to the MQ call, or by setting an environment variable on some platforms.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Sep 22, 2004 1:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
OK that's actually what I would prefer to have happen.
Defaults are very important because I have found that most developers allow them to happen due to inexperience with MQ.
The one that really bugs me is that the MQMD.FORMAT defaults to NONE when 99.99% of messages (in sites like ours) are string data! Which prevents data conversion taking place and makes MQGET with CONVERT start failing! |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Sep 28, 2004 3:26 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| The purpose of the defaults is to provide a structure which des not contain any errors, not to make unwarranted assumptions about the data being passed. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 28, 2004 5:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
zspat:
We have hit a similar problem. We have messages from WAS (Websphere & ATG) going to the mainframe. Yes they are Text and we are setting the MQSTR as we are using JMS MQ ver=5.3.07. However the Mainframe still has difficulties doing a get with convert. (we got tons of error codes...) but the version here is still 2.1 ...
The way we solved it is to change the CCSID of the remote queue sending the message to the MF to the CCSID (500) of the MF qmgr. This change is done in the JMS JNDI setup of the queue. Works pretty good for us. This way it does not impact any coding...
This way the translation works fine even if the get does not specify with convert. It even works when we browse the MF queue in a client connection.
Enjoy  |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 28, 2004 11:30 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Nigelg wrote: |
| The purpose of the defaults is to provide a structure which des not contain any errors, not to make unwarranted assumptions about the data being passed. |
It is equally unwarranted to assume MQFMT_NONE and statistically wrong to do so in 99.99% of cases in sites that I have worked at.
Maybe you could have a QM setting to decide what format should be defaulted to if not specified. I would bet most customers would prefer MQSTR.
I would also prefer the default on MQGET to be CONVERT, although this would be more contentious.
These two values default to a non-cross platform compatible setting which defeats the purpose of MQSeries being cross-platform (with say XML data). It is, but only when every program sets the right options - not at all easy to enforce especially if you don't control the source code. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Sep 29, 2004 1:14 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
MQFMT_NONE cannot cause any errors. That is the point of the default.
You need to take responsibility for coding your apps properly according to your own requirements, not expect the middleware out of the box to be set up for you. If you have a particular requirement, you could modify MQMD_DEFAULT and other structures in cmqc.h to have the defaults in force at your site. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Sep 29, 2004 3:37 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It may not cause MQ errors but it may also result in applications becoming non-portable.
With respect, your response is a typical Lab one - you don't take into account the complex real-world situation of customers that have to integrate vendor packages, in-house code and object code delivered (without source code) by outsourced and offshore suppliers.
As you can tell by the sort of questions asked on this site, many programmers in India and elsewhere are "having a go" at developing MQ applications without training, or really understanding these issues.
Therefore the solution is not as simple as you state. Being able to control the defaults (at run-time) would be one resolution. Especially with the trend towards XML, it would seem sensible to do so. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 29, 2004 8:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
zspat:
We have hit a similar problem. We have messages from WAS (Websphere & ATG) going to the mainframe. Yes they are Text and we are setting the MQSTR as we are using JMS MQ ver=5.3.07. However the Mainframe still has difficulties doing a get with convert. (we got tons of error codes...) but the version here is still 2.1 ...
The way we solved it is to change the CCSID of the remote queue sending the message to the MF to the CCSID (500) of the MF qmgr. This change is done in the JMS JNDI setup of the queue. Works pretty good for us. This way it does not impact any coding...
This way the translation works fine even if the get does not specify with convert. It even works when we browse the MF queue in a client connection.
Enjoy |
I dunno. Maybe JMS is different. But regular MQ does not work this way.
If you take a dog and call it a duck, it is not going to quack!
If your app produces a message in ASCII, say code page 437, (the dog) and you put CCSID 500 in the MQMD (call it a duck), that is not going to make the message buffer magically change to EBCIDIC 500! (There was no conversion exit executed just because you changed the CCID of the MQMD) Instead, you will have a buffer in 437 tagged as 500, and the next app down the line will try to convert all the 437 data to XXX, but will use the 500 to XXX table, and of course, a big mess will follow.
But maybe JMS is different.
By the way, I agree with zpat, but understand Nigelg's point.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 29, 2004 5:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter
I do not presume to understand exactly how it works. I seem to remember having read somewhere that it will take ccsid 500 to be the default setting for the queue and convert the message from its original ccsid (819 Unix) before putting it to the queue.
We did send TextMessage (JMS) to the Mainframe. With this type of JMS message the format is automatically set to MQSTR. For whatever reason the MainFrame qmgr was giving us errors doing a get with convert option and of course not translating on a get. (I believe the error was something like could not translate .... even though the translation tables were there...)
Now with the ccsid in place in JNDI the MF just does a get (without the convert option) and the message is translated fine. Remember we are talking about MQ 2.1 on the MF and not 5.3... Some things might work a little bit differently there. We do not have any problems with text messages sent by the MF. If was decided it was easier to solve it that way than to change any settings on the MF or check into any translation tables and setup there....
The advantage here is that you do not have to set the channel to translate and the message is fine when you receive it on the target. On top of it as the ccsid we set in jndi is the ccsid of the target, the target does not have to use the get with convert option...
This keeps the application portable. No programming change is involved. The setup is purely in the JNDI. (We are not even touching the queue's definition in the Unix qmgr!
Yes this may well be restricted to JMS but that's what we are using on this end of the MF connection.
F.J. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 30, 2004 12:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Some of the earlier releases of MQ on the mainframe did not support UNICODE translation - so that CONVERT would not work properly with JMS applications. Upgrading MQ sorts it out, or changing the message data to ASCII. |
|
| Back to top |
|
|
|
|
