| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Segment issue with IMS Bridge/OTMA? |
« View previous topic :: View next topic » |
| Author |
Message
|
| mswerve |
 Posted: Fri Feb 16, 2024 5:52 pm Post subject: Segment issue with IMS Bridge/OTMA? |
 |
|
Newbie
Joined: 16 Feb 2024
Posts: 3
|
I'm having an issue with the mainframe at the organisation I work at and wondering if the experts here can make sense of what's going on. Admittedly I know very little about the mainframe as I am a Java developer but here's the background.
We have a Java application which is supposed to send an MQ message to the mainframe via the MQ-IMS bridge in order to execute a transaction via OTMA.
On the Java side, we construct a message (using Spring's JmsTemplate) and do the following:
- Set the MQ headers (MQMD) to indicate the format is MQFMT_IMS and flag to the bridge that we have an MQIIH struct in the MQ message
- Set the character set in the MQ headers (MQMD) to indicate we are using code page 1208 (UTF8 encoding)
- Set the Reply to Q (MQMD) to our desired queue destination to receive the response from mainframe
- Ensure that we specify the target client is non-JMS
- We then construct the actual MQIIH using defaults and set the following fields:
| Code: |
Format = MQFMT_IMS_VAR_STRING
ReplyToFormat = MQFMT_IMS_VAR_STRING
Encoding = 0x311
CodedCharSetId = 1208
CommitMode = MQICM_SEND_THEN_COMMIT
LTermOverride = <constant> |
Now this is where things get weird. For many other uses in our organisation (which are working and live in production), we always follow the MQIIH with LLZZ where LL (as a 2-byte short) is:
| Code: |
| = the length of the application data (encoded in UTF8) plus 4 (LLZZ?) + 8 (for the transaction name) |
ZZ is just filled with 00 00 (reserved). And after this we specify the transaction name (8-bytes) and all the remaining application data and this works perfectly fine.
But for one particular transaction name (ie. "AB123 ", it doesn't work unless we explicitly do not include an LLZZ at all! That is, we are writing the MQIIH and directly following by transaction name and remaining application data. This seems to contradict all the things I've read online and seen work previously before. When we include LLZZ, we are getting this error from OTMA:
| Code: |
| APPLICATION ERROR - SENSE CODE=001A001E |
The above appears to be some security violation.
Another quirk we have discovered is that if you omit LLZZ and provide around ~7kb of application data, it's all working fine, but when we try the same with ~9kb of string data, we are getting this error from OTMA:
| Code: |
| APPLICATION ERROR - SENSE CODE=001A0022 |
Which points us to DFS1290E stating that the destination only accepts single segment messages.
I'll also add that, although we encode using UTF-8 on the Java side, none of the data falls outside the standard ASCII character range (ie. there are no multi-byte characters in the data).
Can anyone make sense of this? This issue has been going on for weeks and nobody knows what's going on.  |
|
| Back to top |
|
 |
| hughson |
| Posted: Sat Feb 17, 2024 2:27 am Post subject: Re: Segment issue with IMS Bridge/OTMA? |
|
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
| mswerve wrote: |
| This issue has been going on for weeks and nobody knows what's going on. |
Did it used to behave differently and some number of weeks ago "something" changed and it now behaves as you describe? Or is this a new application that has always behaved this way? Or is it just that some weeks ago someone noticed the difference in this application and started to pull on that loose thread!
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mswerve |
| Posted: Sat Feb 17, 2024 5:54 am Post subject: Re: Segment issue with IMS Bridge/OTMA? |
|
|
Newbie
Joined: 16 Feb 2024
Posts: 3
|
| hughson wrote: |
| mswerve wrote: |
| This issue has been going on for weeks and nobody knows what's going on. |
Did it used to behave differently and some number of weeks ago "something" changed and it now behaves as you describe? Or is this a new application that has always behaved this way? Or is it just that some weeks ago someone noticed the difference in this application and started to pull on that loose thread!
Cheers,
Morag |
It's a new application that has always behaved this way to my knowledge. And yes, I noticed that we are not providing LLZZ and started questioning it.... but I'm not as concerned regarding ommission LLZZ, but more so about this segment error (unless its somehow related). |
|
| Back to top |
|
|
| mswerve |
| Posted: Sat Feb 17, 2024 4:04 pm Post subject: |
|
|
Newbie
Joined: 16 Feb 2024
Posts: 3
|
| Anyway it looks like it's been put into the "too hard" basket and we've decided to restructure the application data in a way where it will never reach 9kb to avoid this issue altogether. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 18, 2024 8:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
No argument from me on this: the mainframe is complicated. IMS, CICS, COBOL may be old, but are alive and well, and continue to be productive and cost-effective.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
