ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ API SupportMQ OPEN 2045 error

Post new topicReply to topic Goto page Previous  1, 2, 3  Next
MQ OPEN 2045 error View previous topic :: View next topic
Author Message
tczielke
PostPosted: Fri Nov 27, 2020 4:06 pm Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 912
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
View user's profile Send private message
bruce2359
PostPosted: Fri Nov 27, 2020 4:33 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8887
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.
_________________
Five out of four people have trouble with fractions. - Steven Wright.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Nov 27, 2020 8:45 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20460
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
View user's profile Send private message Send e-mail
tczielke
PostPosted: Sat Nov 28, 2020 5:46 am Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 912
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
View user's profile Send private message
bruce2359
PostPosted: Sat Nov 28, 2020 8:25 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8887
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.
_________________
Five out of four people have trouble with fractions. - Steven Wright.
Back to top
View user's profile Send private message
tczielke
PostPosted: Sat Nov 28, 2020 5:09 pm Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 912
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
View user's profile Send private message
gbaddeley
PostPosted: Sun Nov 29, 2020 2:01 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2223
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
View user's profile Send private message
manojtare
PostPosted: Sun Nov 29, 2020 9:17 pm Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Nov 30, 2020 8:07 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8887
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?
_________________
Five out of four people have trouble with fractions. - Steven Wright.
Back to top
View user's profile Send private message
manojtare
PostPosted: Mon Nov 30, 2020 9:29 pm Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Nov 30, 2020 10:29 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8887
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?
_________________
Five out of four people have trouble with fractions. - Steven Wright.
Back to top
View user's profile Send private message
manojtare
PostPosted: Mon Nov 30, 2020 10:32 pm Post subject: Reply with quote

Novice

Joined: 24 Nov 2020
Posts: 11

Then we log the error, do some processing and stop the execution.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Tue Dec 01, 2020 5:41 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8887
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.
_________________
Five out of four people have trouble with fractions. - Steven Wright.
Back to top
View user's profile Send private message
manojtare
PostPosted: Wed Dec 02, 2020 8:05 pm Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
manojtare
PostPosted: Fri Dec 18, 2020 8:20 am Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3  Next Page 2 of 3

MQSeries.net Forum IndexIBM MQ API SupportMQ OPEN 2045 error
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.