| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ-CICS Bridge response |
« View previous topic :: View next topic » |
| Author |
Message
|
| pjrmoreira |
 Posted: Wed Jul 09, 2003 12:17 am Post subject: MQ-CICS Bridge response |
 |
|
Novice
Joined: 02 Jul 2003
Posts: 14
|
Hi,
I'm developing a JMS application that is communicating with the MQ-CICS Bridge (for DPL Programs). In the Application Programming Guide I'm able to find the possible request message structure. But I wasn't able to find the message structure of the responses. From some experiences I've made I was able to detect two types of structure:
-MQCIH + ProgramName(char8) + Output Commarea - when the program runs successfully
-MQCIH + Error Message - when the program runs unsuccessfully. I'm not sure if this is the right structure.
Can you please tell me the different message structures for the responses?
I have another question for you. My JMS application is coding the MQCIH fields in ASCII, and the ProgramName+Commarea in EBCDIC. If I try to code both of them in ASCCI or EBCDIC it won't work. Also, if the program runs successfully I'll have the response MQCIH in ASCII and the ProgramName+Output Commares in EBCDIC. If the program runs unsuccessfully, then both MQCIH and the error message will be in ASCII. Is this the correct behavior?
Many thanks
PM |
|
| Back to top |
|
 |
| EddieA |
| Posted: Wed Jul 09, 2003 5:45 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Firstly, here's another thread on using the Bridge with Java. It may help in some areas.
http://www.mqseries.net/phpBB2/viewtopic.php?t=9526
If you're using DPL, then you don't actually need the MQCIH. It will work without.
The 'structures' that are input and output from the Brigde are the COMMAREAs of the program you are calling. When you invoke the CICS program, it is passed, as the COMMAREA, the data you provided. When that program RETURNs, with a COMMAREA, it's that COMMAREA that is returned in the message.
You don't have to muck around with EBCDIC in your JMS program. Just use normal text, and the Bridge will convert on the way in. If the input COMMAREA has fields other than text, then you need to write a Conversion exit. For output, if you have an MQCIH, then you need to turn on Convert in the Sender Channel, and make shure the CHIN JCL has a reference to where the IBM supplied conversion routine/program is located. Again, if the COMMAREA has fields other than character, then a Conversion exit will be needed. It should run at the mainframe end if you have an MQCIH, or, possibly, the receiving application end if just the COMMAREA is returned.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| pjrmoreira |
| Posted: Thu Jul 10, 2003 12:18 am Post subject: |
|
|
Novice
Joined: 02 Jul 2003
Posts: 14
|
Eddie,
First of all thanks for your help. As I told you, I was looking for some documentation about the response message structure. I found the possible request message structures, but not for responses. I know that when the DPL program runs successfully, the response will have a MQCIH+ProgramName+CommArea, but I would like to know any other possible message structures (for example for errors).
I tried to use normal text for the Program Name and for the Commarea, but it didn't work. In order to successfully run the program I have to specify the MQCIH with ASCII and the ProgramName/Commarea in EBCDIC. Do I have to make any additional configuration?
Regards,
Paulo |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Jul 10, 2003 7:01 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Paulo,
The last time I used the Bridge, it was from a Windows box where we were using both the 3270 and DPL modes. For the 3270 we HAD to have the MQCIH, but for the DPL we used the 'simple' option, without the MQCIH.
In neither case did we code anything in EBCDIC. Everything was written as 'native' text. And I'm fairly sure we didn't turn on Convert in the channel going to the mainframe. Have you got the correct DD for CSQXLIB in the CHIN to point to the conversion routines (I know you need it in the CHIN for the outgoing messages. Not sure about incoming that aren't converted by the channel. I'll assume you need the routines in a library for the QMGR as well). Is the Format in the MQCIH set to MQSTR. If not, have a conversion routine to handle that format.
Again, from memory, all the error messages I saw were the same format. They were a native 3270 stream. But they may have only come from the 3270 part. (It was a while ago I did this.  ).
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| R3WARNNO |
| Posted: Fri Jul 11, 2003 7:03 am Post subject: |
|
|
Newbie
Joined: 25 Jun 2003
Posts: 6
Location: New York
|
Good news and bad news. First, the MQCIH is always returned in the "outbound" message. At this point you're probably aware that the direction (inbound versus outbound) is relative to the Bridge Facility and the Bridge client; "inbound" direction corresponds to messages sent from client to Monitor Request queue (or whatever its local representation is). Within the MQCIH structure of the outbound message are various indicators that allow interpretation of the message and use of the data that follow the CIH. 
Next, about the ASCII versus EBCDIC translation. That is also managed using the CIH, however, the MQMD comes into play too. The various structures used in the MQ Bridge, e.g. MQMD, MQCIH, ADS, ADSL, and so forth, are used by different components within the process flow for different purposes. For example, the CICS program (transaction) that is invoked by the Bridge Exit doesn't see the CIH because it's a control structure for MQ Bridge components. 
I might be able to help you further if I can see the MQMD and CIH structures for both the inbound and outbound messages.
_________________
Best Regards,
Norton |
|
| Back to top |
|
|
| R3WARNNO |
| Posted: Fri Jul 11, 2003 7:14 am Post subject: |
|
|
Newbie
Joined: 25 Jun 2003
Posts: 6
Location: New York
|
A little further information that I though that may be helpful after I re-read your questions. The MQ Bridge is documented in the Programmer's Guide, Chapter 17. The data structures are documented in the Programmer's Reference. Additionally, I'd like to suggest that you obtain the CICS External Interfaces Guide (TS1.3), "CICS Transaction Server for OS/390 Version 1 Release 3: Web Support and 3270 Bridge (SG24-5480), and CICS Passthru SupportPack CA1E.
I hope that this helps.
_________________
Best Regards,
Norton |
|
| Back to top |
|
|
| pjrmoreira |
| Posted: Fri Jul 11, 2003 7:25 am Post subject: |
|
|
Novice
Joined: 02 Jul 2003
Posts: 14
|
Hello,
I've found the SupportPac MA1E. It has a very good document where all the possible responses are described. I think IBM should include this information in the Application Programming Guide.
I'm trying to develop a generic JMS application that can execute in different systems (windows, unix, etc.). The application runs DPL programs using the CICS Bridge. Presently, my application (running in a windows system) is using a request with the structure MQCIH+ProgramName+COMMAREA. It writes the MQCIH using the default CCSID, but it has to convert the ProgramName and the COMMAREA to EBCDIC.
The Bridge reply has the same format- the MQCIH is in ASCII, and the COMMAREA in EBCDIC. This is going against the Application Programming Reference, that clearly states "The application message data following the MQCIH structure must be in the same character set and encoding as the MQCIH structure".
I'm afraid that my application won't be portable, although is running perfectly well on my environment.
From the IMS’s Bridge code sample provided by IBM I can see that the application doesn’t have to convert the MQCIH to any other CCSID. Therefore, I suppose (the behavior of the IMS Bridge should be similar to the CICS Bridge) that I shouldn’t convert the ProgramName/COMMAREA to EBCDIC, but it only works with this conversion.
Do you know if anything is going wrong here?
Thanks
Paulo |
|
| Back to top |
|
|
| R3WARNNO |
| Posted: Fri Jul 11, 2003 8:30 am Post subject: |
|
|
Newbie
Joined: 25 Jun 2003
Posts: 6
Location: New York
|
Hello, Paulo. First, I think that MA1E is out-of-date. It was a stop-gap for TS 1.2 because the MQ Bridge hadn't yet been implemented. Study the External Interfaces Guide, SupportPack CA1E ("Passthrough"), and the Redbook. Yes, you're right when you suggest that IBM should include information from different sources into the definitive MQ product documentation.
Secondly, I agree that portability is paramount. Therefore, the approach using a partial character-set conversion is untenable.
By the way, the "Passthru" Supportpack is a mainframe implementation to capture Bridge and client dialogue (messages) whether DPL or 3270.
Is it possible to capture both the Request and (first) Response messages?
By dissecting these a better picture may emerge.
Also, as information, and it's probably not the case here, the CIH is needed for DPL when there are logical unit of work considerations, i.e. syncpointing to coordinate updates to protected resources over the course of a dialogue exchange of several DPL messages, or several concurrent transactions.
I think to get to the root of this we need to analyze the Request/Response messages. At this time, I believe that channel exits are not at issue. I'd bet that some attribute of the MQMD and/or CIH on the Request message is the cause of this behavior.
As further information, the first 28 bytes of the CIH of the first (or only) inbound Request message should be:
C3C9C840 00000002 000000B4 00000311 000001F4 40404040 40404040
where cih.format (CIH+20) is spaces 0x0020
The first (or only) Response message should have in cih.format the name of the Bridge Exit conversion program that was invoked, e.g. CSQCBDCO
Note: in the Response message at CIH+20 will be the name of the Bridge Exit (DFHCKBP) character conversion routine, and not the MQ channel conversion exit.
I hope that this helps.
_________________
Best Regards,
Norton |
|
| Back to top |
|
|
| pjrmoreira |
| Posted: Mon Jul 14, 2003 1:16 am Post subject: |
|
|
Novice
Joined: 02 Jul 2003
Posts: 14
|
Norton,
I tried different configurations, but always with the same result. First, my application was placing requests in the Bridge queue. Then, I tried to place requests in a transmission queue of a Windows Queue Manager. The result was always the same- if I set the MQCIH in ASCII and ProgramName/Commarea in EBCDIC, everything will work ok.
I'm able to access all the message (both requests and responses) fields. So, if you think that there is any field that can provide extra information, please tell me. Each request as CCSID=819 and Encoding=273. Replies from the Bridge have also these values. I don't know what's happening. It seems that the bridge tries to convert the MQCIH, but it doesn't do any conversion with the rest of the message content.
I'm getting very confused because I saw different opinions. The MQ documentation states that both MQCIH and ProgramName/Commarea must use the character set and encoding of the queue manager. I saw some posts about people saying that they are coding all the information in ASCII, and somehow, my system is working in a mix of ASCII and EBCDIC.
Regards
Paulo |
|
| Back to top |
|
|
| pjrmoreira |
| Posted: Mon Jul 14, 2003 4:27 am Post subject: |
|
|
Novice
Joined: 02 Jul 2003
Posts: 14
|
Norton,
You were correct. My problem is related with MQCIH fields. I was defining the MQCIH's format field as MQFT_NONE. If I define it as MQFT_STRING, then I can specify the program name/commarea in ASCII, and the bridge will convert it automatically. Everything will work pretty well, without being dependent on the CCSID.
The reply is not as easy. I'm still dependent on the CCSID. I can define the Reply Format as MQFMT_STRING, but I'm always dependent of the reply queue's platform. I think that the best option is to keep the reply format as MQFMT_NONE, and make the mainframe CCSID as an application parameter. This way, the application will be able to convert the output by itself, without being dependent on the MQ platform.
Regards,
Paulo |
|
| Back to top |
|
|
| R3WARNNO |
| Posted: Mon Jul 14, 2003 7:34 am Post subject: |
|
|
Newbie
Joined: 25 Jun 2003
Posts: 6
Location: New York
|
Hello, Paulo. Let's review. You've identified that the CIH.format attribute affects the character-set conversion of the data payload of the inbound message. This is as I suspected, and I should say, what's been my experience. Are you also taking the CIH defaults for CIH.encoding, too? There doesn't seem to be a good reason why your application should perform any character-set conversion for any part of the message. I'm interpreting your last notes to mean that you are reverting to handling character-set conversion for both inbound (i.e., to Bridge from client) and outbound messages by the client program. I believe that this approach will impair the utility and protability of the client. Before you conclude that the client must do this perhaps you can review the cmqc.h header file, specifically the struct "tagMQCIH" and the #define "MQCIH_DEFAULT". Please note the struct element MQCIH.REPLYTOFORMAT. You'll want to ensure that is MQFMT_STRING.
Please advise.
_________________
Best Regards,
Norton |
|
| Back to top |
|
|
| pjrmoreira |
| Posted: Mon Jul 14, 2003 1:39 pm Post subject: |
|
|
Novice
Joined: 02 Jul 2003
Posts: 14
|
Hello Norton,
I´m not using the CIH.Encoding field because it´s a reserved field. Concerning to formats, I can only play with CIH.Format and CIH.ReplyFormat. By using the CIH.Format field I´m already able to have an application that doesn´t have to do any conversion for the Inbound messages.
My problem is with the outbound messages. Even if I set the CHI.ReplyFormat as MQFMT_STRING, I still have to ask MQ to convert the data. The problem is that, when using JMS, the outbound message is defined as a BytesMessage, and as far as I know,there is no way to ask MQ to convert the message content. Also, if the application is running in a different platform than the one where the Queue Manager is, MQ will convert the data to the QM's platform format. Therefore, I think that I have to use the application to convert outbound´s data.
I´m not seeing any other solution. Please tell me if I´m wrong.
Thanks
Paulo |
|
| 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
|
|
|
|
