| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ChannelExit & selectively Data Conversion |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQKev |
 Posted: Mon Jan 02, 2006 3:42 am Post subject: ChannelExit & selectively Data Conversion |
 |
|
Newbie
Joined: 07 Nov 2005
Posts: 9
|
A happy new year 
I have to do a little workaround. Before i start coding, i would like to hear youre opinion about this "solution". Maybe i forgot something or didn`t understand every detail.
Today:
We have 3 nodes. Company A (with QMgr qmgrA) has to send Messages to Company B (qmgrB). Due to architectural decisions these messages are forwarded by a third, so called "Gateway Queuemanager" (qmgrC). C is my Company/System. Strange engough, i know
The real problem: The messages of qmgrA (Unix) can have two types. One is sent to C (z/os) on a Channel with activated conversion, the other has to stay in its codepage. On qmgrC both remote queues (XY and XY.KONV) foward the message to qmgrB (queue XY).
Next Month:
We need a direct connection between A and B because C has some performance problems. The Applications won`t be changed, mq has to solve the problem on its own.
My Idea: One Channel between A and B. And a ChannelExit, that activates channel conversion, if the target queue is named XY.KONV. Then the target queue will be renamed in XY.
(A solution with two channels is not wished)
I hope anybody understood that scenario
Now the Question: Is that possible? I`ve found a pointer on the Channel Definition (PMQCD) in a channel exit function, where i should be able to set the conversion. And i should have the "AgentBuffer", where i will find the transmission header for the target queue (which is my conversion criteria). Correct investigation so far?
thx`n greeting
Kev |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Mon Jan 02, 2006 4:33 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
are you sure the application on qmgr b reads without mqgmo-option?
if the application uses mqgmo_convert, then no actions are required.
otherwise i assume from your description, that the application B expects one queue to have messages in unix codepage (ASCII), and one queue to have messages in z/OS codepage (EBCDIC), and now you are looking for a channel exit to convert unix messages to z/OS codepage because qmgr C is no longer involved?!? did i understand that correct?
anyway, i am pretty sure that your exit can not switch on/off channel conversion, because channel conversion takes place when the message is read from the xmitq, and you want to decide afterwards whether to convert or not to convert.
you could either perform the conversion on your own in a message exit (using a channel with CONVERT(NO) or use a program (either on sending or receiving end) that will do the conversion for you. but for the second solution you will need aditional queues.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| MQKev |
| Posted: Mon Jan 02, 2006 4:57 am Post subject: |
|
|
Newbie
Joined: 07 Nov 2005
Posts: 9
|
| Mr Butcher wrote: |
are you sure the application on qmgr b reads without mqgmo-option?
if the application uses mqgmo_convert, then no actions are required.
|
I don`t know about internals of B. I`m glad about it
| Mr Butcher wrote: |
otherwise i assume from your description, that the application B expects one queue to have messages in unix codepage (ASCII), and one queue to have messages in z/OS codepage (EBCDIC), and now you are looking for a channel exit to convert unix messages to z/OS codepage because qmgr C is no longer involved?!? did i understand that correct?
|
Thats nearly correct. B expects two different Messages (even different Codepages) in ONE queue Yeah, thats very strange.
| Mr Butcher wrote: |
anyway, i am pretty sure that your exit can not switch on/off channel conversion, because channel conversion takes place when the message is read from the xmitq, and you want to decide afterwards whether to convert or not to convert.
|
I already read something like that and had a bad feeling about it. But i`m pretty new to mq and i read the manuals like the bible: interpretationable.
So the attribute "DataConversion" in MQCD is readonly? (Page 451 "Intercommunication). Thats not good 
| Mr Butcher wrote: |
you could either perform the conversion on your own in a message exit (using a channel with CONVERT(NO)
|
That would be a usual Data Conversion Exit? I also had a look at them, but i thought they`re supposed to handle multiple Datatypes. Since such an exit has to have the same name than the messages` format (MQSTR in my case), can i overwrite the MQSTR Conversion functionality? Or do we need a new Format definition? (Not possible: Change in Application)
| Mr Butcher wrote: |
or use a program (either on sending or receiving end) that will do the conversion for you. but for the second solution you will need aditional queues. |
Changes in A`s or B`s Systems won`t be possible. (Except of changing Remote Queue Definitons and inserting the Exit in qmgr A).
Thanks a lot for your fast answer |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Jan 02, 2006 5:49 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
the easiest way is to go and ask the application-B-people if they do a get convert. if so, no actions are required.
(i assume they do because they handle different msg encoding in one queue, but this could also be handled in a different way without mqseries conversion).
is qmgr B the same codepage as qmgr C? if so, then the next possible way is to use 2 channels, one with and one without conversion. (you said you dont like to, but its better than coding).
i dont think that conversion exits apply here because they are called when a get-convert is done by the application. if no conversion is requested by the program then the exit is not called. if you want to do the conversion by the channel then you will need a message exit.
anyway, i would prefer a small program in that case on a seperate queue instead. exits are more complicated and the chance to screw up things is high, especially when this is your first exit.
| Quote: |
| Changes in A`s or B`s Systems won`t be possible. (Except of changing Remote Queue Definitons and inserting the Exit in qmgr A). |
well, you should be allowed to do some more changes. this is a special situation, and it requires a special solution. looks like someone has already decided to go with an exit solution without knowing if it is possible?!?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 02, 2006 7:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
An other option:
Assumptions:
a) The application sending stuff to the MF is JMS
b) in JNDI you can distinguish which queue gets posted EBCDIC and which queue gets posted ASCII
Solution define the JNDI CCSID for the EBCDIC queue with the EBCDIC code page (500 | 37). This will cause the message to be translated to that code page on the sending qmgr.
Enjoy  |
|
| Back to top |
|
|
| MQKev |
| Posted: Wed Jan 04, 2006 2:31 am Post subject: |
|
|
Newbie
Joined: 07 Nov 2005
Posts: 9
|
| Mr Butcher wrote: |
| the easiest way is to go and ask the application-B-people if they do a get convert. if so, no actions are required. |
That`s -if possible- the best solution. I`ll check it out.
Thank you so far.
One last question, l don`t get the processing of message exits. If a data conversion is proceed BEFORE a message exit, how can a message be manipulated by this exit?
greetings,
Kev |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Jan 05, 2006 12:02 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| If a data conversion is proceed BEFORE a message exit, how can a message be manipulated by this exit? |
??? the channel message exit gets the message passed, so it has access to all headers and data, no matter if there was a conversion or not before. it just depends whether the exit gets what it expects, e.g. it gets an ascii message or a ebcdic message.
anyway, it is never a good practice to manipulate the message data in an exit.
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
