| Author |
Message
|
| zpat |
 Posted: Tue Sep 24, 2019 12:28 pm Post subject: z/OS QM pub sub mode |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
 |
| hughson |
| Posted: Tue Sep 24, 2019 8:28 pm Post subject: Re: z/OS QM pub sub mode |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| zpat |
| Posted: Wed Sep 25, 2019 12:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| hughson |
| Posted: Wed Sep 25, 2019 1:30 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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: |
| 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 |
|
|
| zpat |
| Posted: Wed Sep 25, 2019 2:56 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| hughson |
| Posted: Wed Sep 25, 2019 7:48 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| zpat |
| Posted: Wed Sep 25, 2019 11:15 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| hughson |
| Posted: Thu Sep 26, 2019 12:46 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| zpat |
| Posted: Thu Sep 26, 2019 12:47 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| hughson |
| Posted: Thu Sep 26, 2019 3:06 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| zpat |
| Posted: Fri Sep 27, 2019 1:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| hughson |
| Posted: Fri Sep 27, 2019 2:58 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
|
|
