| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ CICS bridge when CICS goes SOS? |
« View previous topic :: View next topic » |
| Author |
Message
|
| seanb |
 Posted: Wed Aug 27, 2003 12:05 am Post subject: MQ CICS bridge when CICS goes SOS? |
 |
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
We have an interface where front-end delivery channels access a back-end CICS transaction using the MQ CICS bridge.
When CICS goes Short On Storage (SOS) below the line, we have what appears to be memory overlay of message data. That is, it appears the same message data is being passed to many back-end CICS transactions rather than the message data sent from the front end. This is best shown by example. Note that the back-end transaction allocates (GETMAIN) some storage below the line.
The front end sends 5 messages:
MsgId Message data
5001 1234QWERTY9876
5002 THEQUICK
5003 BROWNFOXJUMPED
5004 OVERTHE
5005 LAZY
The MQ CICS Bridge starts 5 instances of, say, transaction ABT1. We would expect ABT1 to receive data as follows:
Tran TaskNo MsgId Message data
ABT1 1234 5001 1234QWERTY9876
ABT1 1235 5002 THEQUICK
ABT1 1238 5003 BROWNFOXJUMPED
ABT1 1243 5004 OVERTHE
ABT1 1256 5005 LAZY
What we appear to get is
Tran TaskNo MsgId Message data
ABT1 1234 5001 1234QWERTY9876
ABT1 1235 5002 THEQUICKTY9876
ABT1 1238 5003 BROWNFOXJUMPED
ABT1 1243 5004 OVERTHE
ABT1 1256 5005 LAZYQWERTY9876
In the above case, tasks 1234, 1238 and 1243 are ok, but tasks 1235 and 1256 have, what appears, overlaid data from task 1234.
We are still trying to identify the problem, but as it occurs infrequently, our investigations haven't found anything yet. As such, we haven't been able to identify whether the problem occurs in the MQ CICS bridge, the back-end application or has some other cause. We have spoken to the back-end support. They checked their programs and found nothing that could cause the problem. I am still not convinced though, but I need to pursue all avenues.
I have also noticed APAR PQ76140, which talks about the MQ CICS Bridge allocating memory below the line. We do not have this APAR applied (as yet) but intend doing so.
Has anyone encountered similar problems using the MQ CICS bridge? Does anyone have any ideas?
Our configuration is:
- OS/390 version 2.10
- MQ 2.1
- CICS TS 1.3
Thanks,
Sean. |
|
| Back to top |
|
 |
| bob_buxton |
| Posted: Wed Aug 27, 2003 1:42 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
What is the commarea length actually being passed to the programs? Check EIBCALEN in the EIB.
The MQ-CICS bridge sets the commare length based on the actual message lengh of the input message (unless you have set OutputDataLength in the MQCIH to indicate you want a longer Commarea).
It appears that you are seing residual data from a previous longer message. The bridge uses the INITIMG option on the Getmains used for message buffers but CICS does not guarantee what will follow the actual Commarea data length for a linked program.
i.e. in messgae 5005 your backend program should only be looking at the first four bytes of data (LAZY) and could abend if it attempts to look at the subsequent storage.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| seanb |
| Posted: Wed Aug 27, 2003 3:31 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
Bob,
Thanks for the quick response.
I have just realized my example is slightly incorrect. The overlay happens, but it happens from left to right, rather than being residual data like my example suggested. I have reworked the example to correctly show situation.
MsgId Message data MsgLen
5001 1234QWERTY9876 14
5002 THEQUICK 8
5003 BROWNFOXJUMPED 14
5004 OVER-THE 8
5005 LAZY 4
What we appear to get is:
Tran TaskNo MsgId Message data
ABT1 1234 5001 1234QWERTY9876
ABT1 1235 5002 THEQUICK
ABT1 1238 5003 THEQUICKJUMPED
ABT1 1243 5004 THEQUICK
ABT1 1256 5005 LAZY
Message 5002 processes correctly. However, its data has been copied over messages 5003 and 5004. In this example, messages 5002 and 5004 are the same length, while message 5003 is longer.
To answer your questions,
- The commarea length is being set correctly (to the actual message length). In the example above, in messages 5002 and 5004 it is set to 8 and in message 5003 it is set to 14. ABT1 then processes three 'THEQUICK' messages successfully and sends three replies, one for each message (5002, 5003 and 5004). The front-end treats the requests as successful. (we use request/reply messages)
- We don't set OutputDataLength in the MQCIH.
Not sure whether this has any bearing, but the driver (assembler) program for the back-end transaction does:
EXEC CICS RECEIVE SET (R6) LENGTH(...) NOHANDLE
One last note, we have only seen this occur when CICS is under stress (short on storage below the line).
Regards,
Sean. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Aug 27, 2003 6:15 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Something is seriously wrong if you are getting that sort of overlay.
I think you will probably need to open a problem with the IBM support centre. They are likely to ask you to collect trace data to try and help identify where the messages are being corrupted.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| seanb |
| Posted: Sun Aug 31, 2003 9:44 pm Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
Yes, it sure is.
We applied a heap of maintenance to CICS and thought the problem was solved - we couldn't get it to happen again. We then applied the same maintenance to production and it appeared ok, till it happened again. We are now downgrading a test region (pre-maintenance) to try and identify the cause. We are also trying to identify the differences between the two regions, but this is not an easy task.
Anyway, thanks for your input.
Regards,
Sean. |
|
| 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
|
|
|
|
