| Author |
Message
|
| David.Partridge |
 Posted: Tue Jun 03, 2008 7:03 am Post subject: CONVERT(YES) on channels revisited |
 |
|
Master
Joined: 28 Jun 2001
Posts: 249
|
I've always resisted any use of convert(yes) on channels, but my current client has defined quite a number of their channels (mostly cluster channels, but also regular channels) with convert(yes) and I've not managed to persuade them that they should enforce the usual "getter makes good" approach.
Their argument (which is backed by another external consultant) is that doing this means that they can look at a message on z/OS that was sent from (e.g.) AIX using the standard TSO panels, and be able to make sense of it, and that it also provides protection against third party apps that don't do get with convert (e.g. JMS applications that assume the other party is running on a similar platform).
Am I being a reactionary stick in the mud here? I've presented all the usual efficiency arguments, and issues like channels stopping on unconvertable messages.
Your comments gratefully received (either way) ...
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Tue Jun 03, 2008 7:44 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
as you can see there is no wrong or right here "really"...
just opinions, experiences sooo what would I do?
make the case once which you did, listen to the arguments and then decide to leave it for now... (if it ain't broke don't fix it...)
but be prepared when you hit a retrying channel with an unconvertible message in it 
I often run into situations I don't like, but then I would be busy all day fixing things I don't like, sometimes you need to be able to leave things as they are... but always be prepared ...
my 2cts hope it helps
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 03, 2008 11:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| as you can see there is no wrong or right here "really"... just opinions, experiences ... |
But there are best practices. Receiver makes good is a best practice. It is not etched in stone.
You have discovered two things here: 1) the client pays the bills; and 2) some reasons for doing it this way or that, don't make sense. In this case, refer to 1).
_________________
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 |
|
|
| fjb_saper |
| Posted: Tue Jun 03, 2008 11:46 am Post subject: Re: CONVERT(YES) on channels revisited |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| David.Partridge wrote: |
Their argument (which is backed by another external consultant) is that doing this means that they can look at a message on z/OS that was sent from (e.g.) AIX using the standard TSO panels, and be able to make sense of it, and that it also provides protection against third party apps that don't do get with convert (e.g. JMS applications that assume the other party is running on a similar platform).
Am I being a reactionary stick in the mud here? I've presented all the usual efficiency arguments, and issues like channels stopping on unconvertable messages.
Your comments gratefully received (either way) ... |
Where did you hear that piece of crap?
Their external consultant makes no sense because:
The default for a JMS TextMessage is to do a get with convert. A JMS application does not assume any more than you or me that the other party is running on a similar platform. It just has a tendency to automatically add an RFH header. This can be suppressed in V6 by the targetClientMatching = true on the QCF (default in V6) and in earlier version  (out of support) either in the JNDI layer or by adding "?targetClient=1" to the raw queue name URI. 
On top of this the JNDI CCSID attribute allows you to set the CCSID at queue level. The queue manager will then transform any text message to the CCSID in the JNDI before putting it to the queue, achieving exactly the same effect as a channel convert but without setting the convert option on any channel. Very effective for sending an EBCDIC message from a Unix platform to a mainframe with mutlihopping...
Hope this helped a tiny bit to clarify the landscape. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jun 03, 2008 6:36 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
The best practice is to use the default CONVERT(NO) on MQ channels. Applications which require messaging across different platforms must be correctly coded to use automatic conversion (MQPUT with MQFMT_STRING, MQGET with GMO_CONVERT).
If there are channels with CONVERT(YES), application programmers will become lazy and not code GMO_CONVERT. This leads to serious problems when the app is moved to a new environment where CONVERT(NO) is the practice.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 04, 2008 1:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| gbaddeley wrote: |
The best practice is to use the default CONVERT(NO) on MQ channels. Applications which require messaging across different platforms must be correctly coded to use automatic conversion (MQPUT with MQFMT_STRING, MQGET with GMO_CONVERT).
If there are channels with CONVERT(YES), application programmers will become lazy and not code GMO_CONVERT. This leads to serious problems when the app is moved to a new environment where CONVERT(NO) is the practice. |
Convert YES with a conversion exit on the channel can also lead to serious problems when using a multihop route.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Jun 04, 2008 2:10 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I think we all agree convert(no) is best,
what David is facing is an existing situation, so...
do you put your foot down and go and insist on fixing something that clearly has not caused a problem (yet)... ???
I already gave my 2 cents...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| MrSmith |
| Posted: Mon Jun 30, 2008 2:41 am Post subject: |
|
|
Master
Joined: 20 Mar 2008
Posts: 215
|
I was always led to believe that channels should never, unless in last resort situations be used to convert the messages.
For reasons already defined here if you have one message that occasionally or persistently causes the channel to crash because the conversion was unsucessful then you have just made more work for yourself and everybody assocaited with this.
The client although he says his consultant said this or that will be the first person down your throat when potential business critical messages or events didn't happen because the channels was down. Now the client could say well you should have monitoring set up to immediately advise you of said channel situ and thats a good point - don't forgte to adda couple of tens of thousands to the SLA for his shortsigted approach. Its also "lazy gits" approach of if it works then happy days and when it doesn't kick the vendor or support guy. MQ has been around a long time it has been advised by IBM that conversion should take place in your API apps, there are enough articles on this forum to suggest so.
My suggestion to D.Partridge tell you will honour the wishes of his external consultant and please sign this piece of paper as an amendment to your SLA, which states that your comany has advised X they chose Y the hazards of such a choice are Z, the additonal cost to fix, monitor and implement Z is A times as many zeros as you think it needs for him to rethink his situ. You could also ask them to list why the recommendations of thier consultant should be used. Clients never like to think they paid shed loads of dosh to a consultant and then find he ill advised them without good business reason
My rant over. |
|
| Back to top |
|
|
|
|
