| Author |
Message
|
| cd |
 Posted: Mon Mar 16, 2009 9:58 am Post subject: RFH2 messages from z/OS to AIX. |
 |
|
Novice
Joined: 16 May 2001
Posts: 20
|
Hi Everyone,
I saw a number of posts related to building RFH2 messages but I didn't see exactly what I was looking for. Please let me know if the following has been asked and answered.
The environment:
The sending side:
z/OS 1.9
MQ for z/OS v6.0 at RSU0812
Sending app written in Enterprise PL/I v3.
The receiving side:
AIX 5.3 Tech Level 8 Service Pack 6
MQ for AIX v6.0.2.2 and v6.0.2.4
Receiving app is an MDB deployed to WAS v6
The requirement is for the z/OS app to send an RFH2 message to the MDB. Historically, we have had developers send a structured string message to a WMB app and have the WMB app add the RFH2 header. WMB is also on an AIX server, though a different server than where WAS is installed. Early testing revealed unacceptable performance when going from z/OS to WMB to WAS/MDB. The app team now wants to go from z/OS directly to WAS/MDB.
We have a mock-up message that we were able to capture from using rfhutil. When we send the message through a QRemote on the z/OS side to a QLocal on the AIX side and then try to browse the message on the AIX side, everything converts/displays correctly except the NameValueData component.
If my understanding is correct:
The MQMD.Format field applies to the entire Message Body.
The MQRFH2.Format field applies to whatever is after the entire RFH2 Structure (36-byte RFH2 Header + NameValueLength/NameValueData pairs).
So what describes the NameValueData stuff? I've tried various values for the MQRFH2.NameValueCCSID field but with no success. What is the trick to get everything to convert correctly on the target platform?
Thanks!
Curt Dolny
Northwestern Mutual
Milwaukee, WI USA |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Mar 16, 2009 10:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm very very surprised you found unacceptable performance if all that WMB was doing was creating an RFH2 header. You must have either a very slow, very overloaded, and likely outdated Broker installation - or very very very tight performance constraints.
I'm also surprised that rather than doing the reasonable thing and attempting to performance tune the WMB flow you decided to tightly couple your back and front ends. |
|
| Back to top |
|
|
| cd |
| Posted: Mon Mar 16, 2009 12:14 pm Post subject: |
|
|
Novice
Joined: 16 May 2001
Posts: 20
|
All valid points. We've tried to discourage tightly coupling the apps, but this is something the app team wants to try. I'm not on the app team; I'm the assigned MQ/WMB Admin. We are using WMB v6.0.0.6 on AIX 5.3 servers.
The way we implement most WMB apps is that we have a standardized framework that all apps use. The app teams download their own copy of this framework and then customize certain portions of their use/implementation of the framework to meet their needs. I have suggested the app team create a simple MQInput->Compute->MQOutput type message flow whose sole job is to deal with the RFH2 Header, but so far the app team has not tried this.
Preliminary timings are showing the app team that adding WMB into the mix is adding (I think) around 300-400 milliseconds per message. They have deemed this unacceptable and are looking for alternatives. Even suboptimal alternatives.
Thanks.
Curt |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 16, 2009 12:29 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If they don't want to do MQInput->Compute->MQOutput, then maybe they'll be fine with doing PL/I->Queue->Lightweight JMS app->MDB.
Doing this in PL/I is going to be annoying. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue Mar 17, 2009 2:18 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Doing this in PL/I is annoying - and hard to get right. Going back to your original question I think that RFH2 headers are not fully supported on EBCDIC systems? From memory I think the NameValueCCSID has to be unicode i.e. one of CCSIDs 1200, 13488, and 17584 or UTF-8 (CCSID 1208).
I cannot remember exactly what our PL/I team did, but their messages get tidied up in message broker before going to WAS, and frequently cause 'invalid CCSID' problems with our monitoring tools.
If the apps team has not tried a simple flow to add a header then how have they got preliminary timings?
Good luck with it. |
|
| Back to top |
|
|
| cd |
| Posted: Tue Mar 17, 2009 5:02 am Post subject: |
|
|
Novice
Joined: 16 May 2001
Posts: 20
|
The Application Programming Reference manual mentions that the MQRFH2.NameValueCCSID field can contain only a limited number of values and those values are enumerated in the manual. We've tried those, plus a few others like MQCCSI_Q_MGR, MQCCSI_INHERIT and the CCSID value of the target server/qmgr. None of these options worked. 'Annoying' may turn out to be an understatement, but I have a little patience left and we will keep trying.
Thanks!
Curt |
|
| Back to top |
|
|
| cd |
| Posted: Fri Apr 03, 2009 9:55 am Post subject: |
|
|
Novice
Joined: 16 May 2001
Posts: 20
|
Just to finish this off, IBM confirmed that the NameValueData field(s) are never converted at the target platform. The app developers are now looking at some of the other options.
Thanks everyone for your comments.
Curt |
|
| Back to top |
|
|
|
|
