| Author |
Message
|
| tczielke |
 Posted: Fri Nov 27, 2020 4:06 pm Post subject: |
 |
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Code: |
compute OPTIONS = MQOO-OUTPUT +
MQOO-FAIL-IF-QUIESCING |
That command should set the OPTIONS field (a PIC 9(9) COMP or 4 byte unsigned binary integer) to the value of MQOO-OUTPUT (decimal 16) + MQOO-FAIL-IF-QUIESCING (decimal 8192) = 8208 every time it is executed. It does not depend on the initial value of OPTIONS, I am pretty sure.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Nov 27, 2020 4:33 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Presuming Enterprise COBOL for z/OS, V4.2, the COMPUTE verb replaces identifier-1 with the results of the arithmetic expression. Previous value in OPTIONS will be replaced.
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Nov 27, 2020 8:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Asking the z/OS experts about the Thread safety of the relevant storage... Could there be a problem with a different application, or thread of the same application interfering with this value? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Nov 28, 2020 5:46 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
For a COBOL application running in z/OS CICS, the standard way one transaction (thread) would overwrite the working storage of another transaction would be with transaction isolation turned off. That is why I asked the OP if they have transaction isolation turned on or not. However, it would be highly unlikely for one transaction to consistently overwrite another transaction's COBOL program working storage in the same place.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 28, 2020 8:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
IMS, CICS attaches a unique and pristine copy of working-storage to each concurrent instance if the same app, so storage violations from other app instances are highly unlikely.
_________________
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 |
|
|
| tczielke |
| Posted: Sat Nov 28, 2020 5:09 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
If possible, I would want from IBM a SLIP TRAP that can capture the relevant MQ and CICS address space when the 2045 is issued. If you can provide IBM with the COBOL compile listing of your program, they should be able to compare the OPTIONS field in your COBOL program with what MQ is complaining about. That should help get to the bottom of the issue.
You can run, but you can not hide from the SLIP TRAP. 
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Nov 29, 2020 2:01 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
How about displaying the date/time and the value of OPTIONS immediately before the call to MQOPEN. Display REASON immediately afterwards.
_________________
Glenn |
|
| Back to top |
|
|
| manojtare |
| Posted: Sun Nov 29, 2020 9:17 pm Post subject: |
|
|
Novice
Joined: 24 Nov 2020
Posts: 11
|
Hi all,
Thanks. Let me find out if I can get any more information from the trace/log etc. I am waiting for that. If that's not useful/possible, then perhaps I need to add display statements and initialize the variables.
Thanks everyone for the good ideas. I would come back here when I get any significant update.  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 30, 2020 8:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| manojtare wrote: |
Hi,
I dont think there is any bug here but here is the code anyway
| Code: |
compute OPTIONS = MQOO-INPUT-SHARED +
MQOO-FAIL-IF-QUIESCING
call 'MQOPEN' using HCONN,
OBJECT-DESCRIPTOR,
OPTIONS,
Q-HANDLE,
COMPLETION-CODE,
REASON
|
|
What code did you not show us? For example:
Was there any code after the compute statement?
What code is after the call MQOPEN?
_________________
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 |
|
|
| manojtare |
| Posted: Mon Nov 30, 2020 9:29 pm Post subject: |
|
|
Novice
Joined: 24 Nov 2020
Posts: 11
|
Hi bruce2359,
There is no code after compute. And the code immediately after MQOPEN is
| Code: |
if COMPLETION-CODE > 0
|
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 30, 2020 10:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| manojtare wrote: |
Hi bruce2359,
There is no code after compute. And the code immediately after MQOPEN is
| Code: |
if COMPLETION-CODE > 0
|
|
THEN ... what?
_________________
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 |
|
|
| manojtare |
| Posted: Mon Nov 30, 2020 10:32 pm Post subject: |
|
|
Novice
Joined: 24 Nov 2020
Posts: 11
|
| Then we log the error, do some processing and stop the execution. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 01, 2020 5:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| manojtare wrote: |
| Then we log the error, do some processing and stop the execution. |
Please provide the complete code that logs the error.
_________________
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 |
|
|
| manojtare |
| Posted: Wed Dec 02, 2020 8:05 pm Post subject: |
|
|
Novice
Joined: 24 Nov 2020
Posts: 11
|
Hi,
It will not be possible to provide the complete code because this operation is done in a submodule and the main module logs the error. I would have to provide too much code that will possibly violate IPR restrictions. Sorry for that. |
|
| Back to top |
|
|
| manojtare |
| Posted: Fri Dec 18, 2020 8:20 am Post subject: |
|
|
Novice
Joined: 24 Nov 2020
Posts: 11
|
Hi,
I hadnt forgotten to reply to this topic, it's just that I didnt get any useful information, yet.
So it turns out that there were two CICSs, each connected to different queue managers but otherwise same CICS transactions, shared db2 etc. Since everything else was working, everybody had forgotten/missed that queue managers are different. Because of cics sharing, some times the process would run on a 'wrong' cics. And for that cics, the correct queue manager was remote. And it is of course not possible to MQOPEN the remote queue for input_shared. So it was causing this intermittent 2045 error for MQOPEN.
What came in very handy to come to this conclusion is adding additional logging. I used another queue to put a message in the same process and displayed MQPMO-RESOLVEDQNAME and MQPMO-RESOLVEDQMGRNAME.
And these pointed to 'wrong' queue manager while we were thinking we are connected to the correct queue manager. |
|
| Back to top |
|
|
|
|
