ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » CONVERT option on SENDER channels

Post new topic  Reply to topic
 CONVERT option on SENDER channels « View previous topic :: View next topic » 
Author Message
ydsk
PostPosted: Mon Mar 12, 2007 9:49 am    Post subject: CONVERT option on SENDER channels Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

Hi,

My scenario:
C++ client appl <-->AIX 5.3 qmgr <--> z/OS MQ v6 qmgr <-->IMS bridge <--> IMS

It's a request response.
We are using point-2-point connections, and no clusters.

Now do I need to set the CONVERT property to 'YES' on both the sender channel definitions between AIX and z/OS qmgrs for the data to be understood by either systems correctly ?

I am using the same MQMD options as specified in the program in this link:

http://www-304.ibm.com/jct09002c/isv/tech/sample_code/mq/imsbridge.cpp

Please post any suggestions.

thank you for your time.
ydsk.
Back to top
View user's profile Send private message
Michael Dag
PostPosted: Mon Mar 12, 2007 10:15 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)



what makes you think you have to put the CONVERT on the Sender channels?

normally the get does the convert...

suppose the following scenario where the z/OS is an intermediate QueueMgr...

AIX QMgr -*> z/OS QMgr -*> AIX QMgr -> Windows Qmgr...

that would result in 2 (see *) unnecessary converts...
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
ydsk
PostPosted: Mon Mar 12, 2007 10:33 am    Post subject: Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

But my data is going from C++ appl ( on Windows) to AIX and then onto mainframe finally for processing by IMS.

Then it comes back on the same path.

I was told by an experienced mainframe MQ guy that I need to change the property from 'No' to 'Yes'.

I thought I'd ask for a second opinion.

Thanks.
ydsk.
Back to top
View user's profile Send private message
Michael Dag
PostPosted: Mon Mar 12, 2007 10:38 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

it doesn't matter were it came from or where it is going...

convert on channels is only necessary if the GETing Application is NOT doing the conversion on the MQGET...
if that is the case for the IMS Bridge... I just don't know.
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Toronto_MQ
PostPosted: Mon Mar 12, 2007 11:43 am    Post subject: Reply with quote

Master

Joined: 10 Jul 2002
Posts: 263
Location: read my name

The IMS Bridge does not do any conversion on the get.

Quote:
Data conversion
The data conversion (including calling any necessary exits) is performed by the distributed queuing facility when it puts a message to a destination queue that has XCF information defined for its storage class. Any exits needed must be available to the distributed queuing facility in the data set referenced by the CSQXLIB DD statement. This means that you can send messages to an IMS application using the WebSphere MQ-IMS bridge from any WebSphere MQ platform.

Note:
Because the WebSphere MQ-IMS bridge does not convert messages when it gets a message, messages arriving through the CICS(R) distributed queuing facility are not converted.
If there are conversion errors, the message is put to the queue unconverted; this results eventually in it being treated as an error by the WebSphere MQ-IMS bridge, because the bridge cannot recognize the header format. If a conversion error occurs, an error message is sent to the z/OS console.

See Writing data-conversion exits for detailed information about data conversion in general.


So, either set CONVERT(YES) on the channel, or write a data-conversion exit.

Steve
Back to top
View user's profile Send private message
ydsk
PostPosted: Tue Mar 13, 2007 1:34 pm    Post subject: Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

Thanks TorontoMQ.

But I think changing the CONVERT property from NO to YES shouldn't adversely affect anything because it only converts if the data isn't already in the right CCSID.

Am I right ?

Pls correct me if I am wrong.

thnx.
ydsk.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Mar 13, 2007 1:55 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

ydsk wrote:
Thanks TorontoMQ.

But I think changing the CONVERT property from NO to YES shouldn't adversely affect anything because it only converts if the data isn't already in the right CCSID.

Am I right ?

Pls correct me if I am wrong.

thnx.
ydsk.

No there is definitely an adverse effect if the channel is used in multi hopping.

You want the channel on the default path to the MF not to have Convert turned on and create a specific channel to the MF for the messages to the IMS bridge that has Convert turned on.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » CONVERT option on SENDER channels
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.