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 Index » General IBM MQ Support » z/OS QM pub sub mode

Post new topic  Reply to topic
 z/OS QM pub sub mode « View previous topic :: View next topic » 
Author Message
zpat
PostPosted: Tue Sep 24, 2019 12:28 pm    Post subject: z/OS QM pub sub mode Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

I have a z/OS MQ v9.0 QM - it was originally PSMODE(DISABLED).

I changed it to PSMODE(ENABLED), however DISPLAY PUBSUB shows it as INACTIVE.

Presumably I need to restart the QM (or CHIN) which is quite disruptive - is there any way to kick the PS engine into life without that?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Sep 24, 2019 8:28 pm    Post subject: Re: z/OS QM pub sub mode Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

zpat wrote:
I have a z/OS MQ v9.0 QM - it was originally PSMODE(DISABLED).

I changed it to PSMODE(ENABLED), however DISPLAY PUBSUB shows it as INACTIVE.

Presumably I need to restart the QM (or CHIN) which is quite disruptive - is there any way to kick the PS engine into life without that?


My memory is that the CHINIT gets a prod from the queue manager when the PSMODE attribute is altered, so that the Pub/Sub Daemon (which you correctly infer runs in the CHINIT address space) gets started. But my memory may be wrong. Are there any messages in the CHINIT JESMSGLG to suggest it attempted to start up after you did the ALTER QMGR command, and perhaps failed due to some missing configuration?

STATUS(INACTIVE) says that both the Pub/Sub engine in the queue manager AND the Queued Pub/Sub Daemon in the CHINIT are not running, so it is not just the CHINIT that hasn't picked up on your ALTERation. So, also check for any error messages in the queue manager JESMSGLG.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Wed Sep 25, 2019 12:24 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

CHIN log shows error

CSQXFCTL Queued Pub/Sub Daemon failed, reason=00005803

Another cryptic clue from Z/os MQ !!!
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Sep 25, 2019 1:30 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

zpat wrote:
CHIN log shows error

CSQXFCTL Queued Pub/Sub Daemon failed, reason=00005803

Another cryptic clue from Z/os MQ !!!


Looking up the message in "Messages and Codes" reveals:-

IBM Knowledge Center wrote:
CSQT855E csect-name Queued Pub/Sub Daemon failed, reason=mqrc

Severity
8
Explanation
An attempt has been made to run the queued publish/subscribe interface (Queued Pub/Sub Daemon) but the interface has ended for reason mqrc.

If mqrc is a number in the range of 2000 - 3000, it is an API reason code. If it is of the form 5nnn, it is a queued publish/subscribe message code associated with the message CSQT nnnE, which is normally issued previously.

System programmer response
If mqrc is an API reason code, see API completion and reason codes for more information about the mqrc. If mqrc is a queued publish/subscribe message code, see the corresponding message explanation for more information. Where no such message exists, see Queued Publish/Subscribe message codes for the corresponding message number.

Determine why the queued publish/subscribe daemon ended. The message logs for the Channel Initiator might contain more detailed information about why the queued publish/subscribe daemon cannot be started. Resolve the problem that is preventing the daemon from completing and restart the Channel Initiator.


No such message as CSQT803E exists, and the referenced "Queued Publish/Subscribe message codes" is less than helpful since it doesn't mention 803 either. However, looking it up as a distributed platform message reveals the following:-

Code:
mqrc AMQ5803


Code:
 276846595  0x10805803  frcW_BROKER_STOPPING


So it's not being hugely helpful about why the Queued Pub/Sub Daemon (aka "Broker" in this message) didn't start. But you do know that the CHINIT address space heard about the fact that you did an ALTER QMGR PSMODE(ENABLED). So for the mean time, I wouldn't suggest there is any point in restarting the CHINIT until you can figure out why it didn't start, since you don't know that it is going to fix anything.

Are there no other messages anywhere in the MSTR or CHIN JESMSGLGs?

And nothing in CSQSNAP on the CHINIT?

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Wed Sep 25, 2019 2:56 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

No other info that I can see. No csqsnap at that time....

I was thinking maybe a missing object but I have defined the obvious stuff from CSQ4INSX

Can anyone provide a definitive list of system objects that must be present on z/os for the pub/sub engine to work?

I've opened a PMR anyway.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Sep 25, 2019 7:48 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

zpat wrote:
Can anyone provide a definitive list of system objects that must be present on z/os for the pub/sub engine to work?

Do you only need the Queue Manager Pub/Sub engine or do you also need the Queued Pub/Sub Daemon (the thing that reads the SYSTEM.BROKER.CONTROL.QUEUE and Stream queues)?

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Wed Sep 25, 2019 11:15 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

The pub will be via topic alias.

The sub may be admin defined (define sub fails if I try now) or it might be JMS subscribed.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Sep 26, 2019 12:46 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

Doesn't sound like you need the Queued Pub/Sub Daemon then. Perhaps we should concentrate of getting just the queue managers pub/sub engine enabled.

When you issue this command, what are the error messages (in MSTR) if any?

Code:
ALTER QMGR PSMODE(COMPAT)


Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Thu Sep 26, 2019 12:47 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

No CHIN errors shown with PSMODE(COMPAT) but pub sub still INACTIVE and define sub fails.

Then I restarted the QM/CHIN and PSMODE(ENABLED) worked - so that is a mystery.

I will reproduce the issue on another QM and take a trace/dump for the PMR.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Sep 26, 2019 3:06 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

zpat wrote:
No CHIN errors shown with PSMODE(COMPAT) but pub sub still INACTIVE and define sub fails.

The CHIN is not involved unless you request the Queued Pub/Sub Daemon be started. PSMODE(COMPAT) requests that you only start the queue manager pub/sub engine and not the Daemon.

zpat wrote:
Then I restarted the QM/CHIN and PSMODE(ENABLED) worked - so that is a mystery.

I will reproduce the issue on another QM and take a trace/dump for the PMR.

Glad to hear a queue manager restart fixed the main pub/sub engine.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Fri Sep 27, 2019 1:52 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

I still want to solve the issue though as restarting the QMs would be about many more change management effort than just enabling it with a command (in production).

When exactly is the queued pub/sub actually still needed (assuming we have never used pub/sub before)?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Sep 27, 2019 2:58 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

zpat wrote:
I still want to solve the issue though as restarting the QMs would be about many more change management effort than just enabling it with a command (in production).

When exactly is the queued pub/sub actually still needed (assuming we have never used pub/sub before)?


The queued pub/sub daemon is there for compatibility with applications written pre-V6 to use that old queued broker style pub/sub interface. It is unlikely that you will need it if you are writing your first apps to use pub/sub now, and as you have seen, a restart of the CHIN is not necessary to prod it into attempting to start the daemon.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » z/OS QM pub sub mode
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.