| Author |
Message
|
| PeterPotkay |
 Posted: Fri Jun 14, 2013 12:09 pm Post subject: DataPower to IMS via the OTMA Bridge - MQMD Encoding issue |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
We have an issue where an MQ message being sent thru the OTMA Bridge was causing IMS to abend. DataPower was producing the message including the IIH header. IMS kept complaining about the lenght of some fields.
Eventually we started comparing the MQMD, MQIIH and data payload between what DataPower was producing and what a Java app was producing. The Java app was producing request messages that were not causing an issue.
We noticed that the MQMD's Encoding field was different between the DataPower message that abended and the Java message that worked. Also, when viewed in Hex the MQIIH's Version field and StrucLength field were different.
DataPower produced messages:
MQMD CCSID = 819
MQMD Encoding = 546
MQIIH Version Field (in hex) = 01000000
MQIIH StrucLength Field (in hex) = 54000000
Java Client produced messages:
MQMD CCSID = 819
MQMD Encoding = 273
MQIIH Version Field (in hex) = 00000001
MQIIH StrucLength Field (in hex) = 00000054
So, we asked the DataPower dude what he was setting the MQMD Encoding to inside DataPower. He was not setting it to anything at all. He then coded in DataPower to set the MQMD Encoding value to 273. The next message he put now looked like the Java produced one - it had 273 for the MQMD Encoding and the MQIIH Version and StrucLength hex bytes flipped themselves around.
We let the message go into the OTMA bridge and success - no abend on the mainframe and the reply came back. High fives all around! But wait a minute, did we fix the root cause, or did we implement a work around that's gonna break when the real problem is fixed?
Why does the mainframe deal with this OK:
MQMD Encoding = 273
MQIIH Version Field (in hex) = 00000001
MQIIH StrucLength Field (in hex) = 00000054
But abends on this:
MQMD Encoding = 546
MQIIH Version Field (in hex) = 01000000
MQIIH StrucLength Field (in hex) = 54000000
Does 546 correctly describe 01000000 and 54000000 in the MQIIH?
If yes, shouldn't the mainframe be able to deal with it correctly? If it can't is there a bug on the mainframe side?
If 546 does not correctly describe the data, why does DataPower produce a 546 message by default - is that the bug?
This is the first time we are using DataPower to send to the IMS Bridge. But more importantly, I bet this is the first time we are using DataPower to send MQ messages with something other than plain character data in it, and thus the first time that the MQMD Encoding field is relevant.
Not sure if this was more appropriate for the Mainframe Forum or the DataPower Forum. Since it was the mainframe that was abending I still the thread here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| rekarm01 |
| Posted: Sat Jun 15, 2013 3:29 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| PeterPotkay wrote: |
| Does 546 correctly describe 01000000 and 54000000 in the MQIIH? |
Yes.
| PeterPotkay wrote: |
| If yes, shouldn't the mainframe be able to deal with it correctly? If it can't is there a bug on the mainframe side? |
Whether it's a bug or not, it is documented:
| Quote: |
Character set and encoding: Special conditions apply to the character set and encoding used for the MQIIH structure and application message data:- Applications that connect to the queue manager that owns the IMS bridge queue must provide an MQIIH structure that is in the character set and encoding of the queue manager. This is because data conversion of the MQIIH structure is not performed in this case.
|
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jun 15, 2013 5:36 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| rekarm01 wrote: |
| Quote: |
Character set and encoding: Special conditions apply to the character set and encoding used for the MQIIH structure and application message data:- Applications that connect to the queue manager that owns the IMS bridge queue must provide an MQIIH structure that is in the character set and encoding of the queue manager. This is because data conversion of the MQIIH structure is not performed in this case.
|
|
In our case the DataPower application is not client connected to the z/OS QM, it is connected to a Linux QM that forwards the message to the z/OS QM.
Fine you say, the next bullet point then applies.
| Quote: |
Applications that connect to other queue managers can provide an MQIIH structure that is in any of the supported character sets and encodings; the receiving message channel agent connected to the queue manager that owns the IMS bridge queue converts the MQIIH.
Note: There is one exception to this. If the queue manager that owns the IMS bridge queue is using CICS® for distributed queuing, the MQIIH must be in the character set and encoding of the queue manager that owns the IMS bridge queue. |
So the RCVR MCA on z/OS is smart enough to convert messages with an IIH header, but does not convert messages without an IIH header? Really?
Even if true, its not working as advertised. The messages are put with a CCSID of 819 and apparently that part is getting converted fine but the Encoding parts are not? 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Jun 15, 2013 11:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The obvious question...
Did you verify your mainframe can convert encoding 546 properly... ? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jun 15, 2013 12:32 pm Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding iss |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| We have an issue where an MQ message being sent thru the OTMA Bridge was causing IMS to abend. |
What type of abend? Have you pursued the abend code and related dump with IBM? I'm surprised that something as simple as code-pages would cause IMS to abend.
Is IMS version current? Current maintenance applied?
_________________
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 |
|
|
| rekarm01 |
| Posted: Sun Jun 16, 2013 5:46 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| PeterPotkay wrote: |
| In our case the DataPower application is not client connected to the z/OS QM, it is connected to a Linux QM that forwards the message to the z/OS QM. |
Oh? Please describe the path from DataPower to IMS in more detail. What are the qmgr ccsids and native encodings for the Linux and z/OS qmgrs? How does the Linux QM forward the message to z/OS? Do any other components or applications perform other conversions along the way?
| PeterPotkay wrote: |
| The messages are put with a CCSID of 819 and apparently that part is getting converted fine but the Encoding parts are not? |
It would be unusual for an MCA or other WMQ component to convert the CCSID but not the Encoding, at least not without generating a warning somewhere. It might be useful to view the message in hex at each hop, and take a closer look at the Format, CCSID, and Encoding fields in each of the MQ headers, and the message data, to determine what else might be trying to convert the message. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 17, 2013 6:38 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding iss |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| bruce2359 wrote: |
| PeterPotkay wrote: |
| We have an issue where an MQ message being sent thru the OTMA Bridge was causing IMS to abend. |
What type of abend? Have you pursued the abend code and related dump with IBM? I'm surprised that something as simple as code-pages would cause IMS to abend.
Is IMS version current? Current maintenance applied? |
With a 546 encoding the program pulling the messages of the IMS queue abends complaining about missing or incomplete segments. I think because the LL portion of the LLZZ, that describes the length, is not interpreted correctly with an MQMD.Encoding of 546.
We are at IMS 11 on z/OS 1.12 with MQ 7.0.1.
| mqjeff wrote: |
The obvious question...
Did you verify your mainframe can convert encoding 546 properly... ? |
I did not verify this. It was ASSumed on my part. I just figuered we are dealing with basic common CCSIDs and Encodings. A current IBM product (DataPower) sending to another current IBM product (IMS on z/OS) via a current IBM product (MQ) all built and executing in the U.S.A. But I'll explore this to see if I can find reference that says 546 is an acceptable incoming encoding.
| rekarm01 wrote: |
Oh? Please describe the path from DataPower to IMS in more detail. What are the qmgr ccsids and native encodings for the Linux and z/OS qmgrs? How does the Linux QM forward the message to z/OS? Do any other components or applications perform other conversions along the way?
|
The request message originates from a Datapower XI50 appliance running firmware 4.0.2 which has MQ Client 7.0.1.1. The MQIIH.Format is being set to MQFMT_IMS_VAR_STRING. The MQMD.CCSID is being set to 819. The MQMD.Encoding was not being set and was defaulting to 546 (causing issues). Now it is being explicitly set to 273 (and working).
The Datapower client connects to a Queue Manager at MQ version 7.0.1.6 running on a Red Hat Linux server. This queue manager's CCSID is set to 1208.
There is a SNDR/RCVR pair of channels between the Red Hat Linux queue manager and the z/OS queue manager. The SNDR channel does not convert.
The mainframe queue manager is at MQ 7.0.1 on z/OS 1.12. The CCSID for this queue manager is set to 500.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg15970_.htm
| Quote: |
“The data conversion is performed by either the distributed queuing facility ( which may call any necessary exits ) or by the intra group queuing agent ( which does not support the use of exits ) when it puts a message to a destination queue that has XCF information defined for its storage class.”
“Because the WebSphere MQ-IMS bridge does not convert messages when it gets a message….” |
I guess this is saying the RCVR MCA on a z/OS queue manager is slick enough to know that it must do some conversion if an incoming message bound for an MQ queue defined as an OTMA Bridge queue. And apparently it is not doing it correctly or at all for an encoding of 546 but since the 273 encoding is mainframe friendly (assumption on my part) it works. Further assumption is that it has no issues converting the character data from CCSID 819 of the request message to the CCSID 500 of our mainframe QM.
From the link you posted rekarm01.....
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.amqwak.doc/ir11680_.htm
| Quote: |
“•Applications that connect to other queue managers can provide an MQIIH structure that is in any of the supported character sets and encodings; conversion of the MQIIH is performed by the receiving message channel agent connected to the queue manager that owns the IMS bridge queue.
Note: There is one exception to this. If the queue manager that owns the IMS bridge queue is using CICS® for distributed queuing, the MQIIH must be in the character set and encoding of the queue manager that owns the IMS bridge queue.” |
Further evidence that the RCVR MCA should be doing this. Guess the question on the table is if 546 is a “supported encoding”.
I don’t know what “If the queue manager that owns the IMS bridge queue is using CICS® for distributed queuing” means. We do have CICS attached to this mainframe queue manager and unrelated incoming MQ messages do trigger some CICS transactions. But I’m going to guess this is not an issue because the character portion of the messages that we send to the bridge queue is in an 819 CCSID and it is being dealt with.
Comments on the assumption that the RCVR MCA on our 7.0.1 z/OS Queue Manager is not dealing with a 546 encoding correctly?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 17, 2013 6:52 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding iss |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| With a 546 encoding the program pulling the messages of the IMS queue abends complaining about missing or incomplete segments. |
Can you be more precise as to the abend code(s). S0c4? S0c7?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon Jun 17, 2013 8:20 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding iss |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| bruce2359 wrote: |
| PeterPotkay wrote: |
| With a 546 encoding the program pulling the messages of the IMS queue abends complaining about missing or incomplete segments. |
Can you be more precise as to the abend code(s). S0c4? S0c7? |
I'm getting the info second hand as I don't have direct access to check myself.
When I asked for some more info I learned:
| Quote: |
| U4000 - when the program goes to get a segment and it is the first segment and there is nothing there, it calls the abend routine. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 17, 2013 9:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Boy, they are dribbling out the symptoms, aren't they.
Unnn abends codes are from applications (sub-systems), and do not (usually) abend IMS or any other subsystem.
Where did this U4000 user abend code appear? Which address space? IMS has multiples? Was it a DL1 address space? Batch job?
_________________
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 |
|
|
| rekarm01 |
| Posted: Mon Jun 17, 2013 3:12 pm Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| PeterPotkay wrote: |
| Further evidence that the RCVR MCA should be doing this. Guess the question on the table is if 546 is a "supported encoding". |
If it's possible to look at the message in hex, before and after the RCVR MCA, then it's much easier to see what the MCA itself is doing.
There are a relatively small number of possible Encodings; it would be surprising if z/OS didn't support converting to/from 546. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 18, 2013 5:22 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| PeterPotkay wrote: |
| Further evidence that the RCVR MCA should be doing this. Guess the question on the table is if 546 is a "supported encoding". |
If it's possible to look at the message in hex, before and after the RCVR MCA, then it's much easier to see what the MCA itself is doing.
There are a relatively small number of possible Encodings; it would be surprising if z/OS didn't support converting to/from 546. |
Yes, I've reviewed that further since my comment. Not the kind of detail I deal with regularly, so I don't keep that kind of thing in near-term cache, just backed up to the Info Center.
Another thing to try is to have the Java application send the message with the datapower encoding, and see if that also fails. It could be something with the svrconn from DP to the initial qmgr, rather than the qmgr->qmgr channel. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 18, 2013 10:35 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| rekarm01 wrote: |
| There are a relatively small number of possible Encodings; it would be surprising if z/OS didn't support converting to/from 546. |
I've done some more testing and analysis and will report results soon. I think I see what's happening and am waiting for the DataPower team to do a couple of tests to prove my theory.
For the list of Encodings at the link rekarm01 provided, I would like to know which ones are big endian and which are little endian. Is there good IBM online reference? I haven't been able to find one. I did find this:
http://en.wikipedia.org/wiki/Endianness#Endianness_and_hardware
To me that says mainframe and unix are Big Endian, so 273 and 785 are Big, while x86 is Little Endian, so 546 is Little. Is this true?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 18, 2013 10:43 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| rekarm01 wrote: |
| There are a relatively small number of possible Encodings; it would be surprising if z/OS didn't support converting to/from 546. |
I've done some more testing and analysis and will report results soon. I think I see what's happening and am waiting for the DataPower team to do a couple of tests to prove my theory.
For the list of Encodings at the link rekarm01 provided, I would like to know which ones are big endian and which are little endian. Is there good IBM online reference? I haven't been able to find one. I did find this:
http://en.wikipedia.org/wiki/Endianness#Endianness_and_hardware
To me that says mainframe and unix are Big Endian, so 273 and 785 are Big, while x86 is Little Endian, so 546 is Little. Is this true? |
There's a slightly different view on the thing here
But it's really kind of cpu/os specific. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Jun 19, 2013 12:55 am Post subject: Re: DataPower to IMS via the OTMA Bridge - MQMD Encoding |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| PeterPotkay wrote: |
| I would like to know which ones are big endian and which are little endian. Is there good IBM online reference? |
The "NORMAL" Encodings are big-endian, and the "REVERSE" Encodings are little-endian. Starting with the link that mqjeff provided, the pages that follow describe the integer, decimal, and float encodings in greater detail. See also here. |
|
| Back to top |
|
|
|
|
