| Author |
Message
|
| belchman |
 Posted: Wed Aug 20, 2008 9:00 am Post subject: z/OS sender won't run (some sort of conflict) |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
2 LPARS called LParA and LParB are on the same sysplex on z/OS 1.9.
LparA hosts QMgrA. LParB hosts QmgrB.
On QMgrA there is a Sender called AtoB and a Receiver called BtoA.
On QMgrB there is a Sender called BtoA and a Receiver called AtoB.
Issue:
I can start AtoB @ QMgrA and then I see AtoB @ QMgrB running as expected.
If AtoB @ QMgrA is running, then BtoA @ QMgrB will not run. If I stop AtoB @ QMgrA then BtoA @ QMgrB will run.
Has anyone addressed such a poser before?
Does anyone have any nice breadcrumbs to throw me?
Thanks in advance.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
 |
| belchman |
| Posted: Wed Aug 20, 2008 9:05 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
By the way... MQv6 on both LPars
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Wed Aug 20, 2008 9:12 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
|
| Back to top |
|
|
| belchman |
| Posted: Wed Aug 20, 2008 9:14 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
TCP
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Wed Aug 20, 2008 9:18 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
That is... the TRPTYPE on all channels in scope is TCP...
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 20, 2008 10:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If AtoB @ QMgrA is running, then BtoA @ QMgrB will not run. If I stop AtoB @ QMgrA then BtoA @ QMgrB will run. |
These are new channels, yes? Re-check CONNAME(ipaddress(port)) on sender channels.
And when you say '...will not run." what state is the sender and receiver channels that fail?
And, what error messages were posted in the channel initiator address space SYSLOG? At the failing end(s)?
_________________
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 |
|
|
| belchman |
| Posted: Wed Aug 20, 2008 10:21 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
The queue managers and the lpars are new. They were working OK when I first built them. I do not know of all the changes between then and now. I do know that z/OS1.9 was applied between then and now.
I can't remember explicitly but I suspect that then I could remote connect. Now I can only remote connect to nodeA.
This is from Receiving CHIN log... MQS6 = QMgrA... MQS8 = QMgrB..
CSQX036E (MQS8 CSQXSUPR Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 448
MQRC=2042
CSQX501I (MQS8 CSQXRESP Channel MQS6.TO.MQS8 is no longer active
CSQX500I (MQS8 CSQXRCTL Channel MQS8.TO.MQS6 started
CSQX036E (MQS8 CSQXSUPR Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 451
MQRC=2042
CSQX036E (MQS8 CSQXRESP Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 452
MQRC=2042
CSQX599E (MQS8 CSQXRESP Channel MQS6.TO.MQS8 ended abnormally
CSQX036E (MQS8 CSQXRESP Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 454
MQRC=2042
CSQX599E (MQS8 CSQXRESP Channel MQS6.TO.MQS8 ended abnormally
CSQX036E (MQS8 CSQXRESP Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 456
MQRC=2042
CSQX599E (MQS8 CSQXRESP Channel MQS6.TO.MQS8 ended abnormally
CSQX036E (MQS8 CSQXRESP Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 459
System channel syncq exists on both systems... on the receiving side, only one open handle and it is input shared...
The channel that wont run stays in RETRY state...
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Wed Aug 20, 2008 10:47 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
I just stopped the sender on MQS8.TO.MQS6 and restarted the sender MQS6.TO.MQS8...
Here are the MQS8CHIN log entries for that...
STC82704 +CSQX599E (MQS8 CSQXRESP Channel MQS6.TO.MQS8 ended abnormally
STC82704 +CSQX519E (MQS8 CSQXSTOP Channel MQS8.TO.MQS6 not defined
STC82704 +CSQX528I (MQS8 CSQXRCTL Channel MQS8.TO.MQS6 stopping
STC82704 +CSQX501I (MQS8 CSQXRCTL Channel MQS8.TO.MQS6 is no longer active
STC82704 +CSQX500I (MQS8 CSQXRESP Channel MQS6.TO.MQS8 started
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Wed Aug 20, 2008 10:52 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
From MQS6CHIN log...
14.13.59 STC82649 +CSQX527E (MQS6 CSQXRCTL Unable to send message for channel
14.13.59 STC82649 +CSQX599E (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 ended abnormal
14.15.02 STC82649 +CSQX500I (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 started
14.15.02 STC82649 +CSQX527E (MQS6 CSQXRCTL Unable to send message for channel
14.15.02 STC82649 +CSQX599E (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 ended abnormal
14.16.05 STC82649 +CSQX500I (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 started
14.16.05 STC82649 +CSQX527E (MQS6 CSQXRCTL Unable to send message for channel
14.16.05 STC82649 +CSQX599E (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 ended abnormal
14.17.08 STC82649 +CSQX500I (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 started
14.17.08 STC82649 +CSQX527E (MQS6 CSQXRCTL Unable to send message for channel
14.17.08 STC82649 +CSQX599E (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 ended abnormal
14.41.55 STC82649 +CSQX501I (MQS6 CSQXRESP Channel MQS8.TO.MQS6 is no longer a
14.42.28 STC82649 +CSQX500I (MQS6 CSQXRCTL Channel MQS6.TO.MQS8 started
Last entry is my successful restart... all prior to last entry is retrying noise...
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 20, 2008 11:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The queue managers and the lpars are new. They were working OK when I first built them. I do not know of all the changes between then and now. |
Which is it? The qmgrs and lpars are new? Or they or they aren't new, and they were working before? Are these cloned lpars and qmgrs?
If the lpar is new AND if the qmgr is new; then the channels are new, too. Yes?
Check the sender channel definition. Does the CONNAME specify the correct ipaddress and port of the receiver end of the channel? I don't imagine that you are using the same ipaddresses across lpars.
Are there other qmgrs in the lpar at the receiver end?
_________________
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 |
|
|
| belchman |
| Posted: Wed Aug 20, 2008 11:30 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
It depends on what your definition of new is.
These queue managers support SDSF on a new sandbox sysplex. The sandbox sysplex was created earlier this year. I then built the queue managers on the LPARS.
As best as I can remember, all was working fine when I was done earlier this year. But at that time the OS was z/OS 1.7.
The mainframe system programmers were diverted from the sandbox while they upgraded production to z/OS 1.9.
They are back on this now and report that SDSF is slow.
I diagnose and discover that the sender from 1 queue manager wont run when the other is running.
Would I bet my paycheck that it wasn't like this when I initially built the queue managers? no. But I typically do loads of unit testing before I announce to my customers that "I am done". So I suspect that something has changed between then and now that causes this but am not sure.
I suspect the LPARS and everything beneath MQ are cloned. The queue managers are not cloned. I created them from scratch.
If the problem was with the conname on the sender, it would never run. Both senders will run and their associated receivers. They just wont run at the same time.
In this case, there is only one qmgr and one mq listener on each end of the channel.
I am sure that the condescending tone is unintentional but just to play along... yes... if the queue manager is new, the channel is new. If the LPAR is new, the qmgr is new.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 20, 2008 11:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| CSQX036E (MQS8 CSQXSUPR Unable to open SYSTEM.CHANNEL.SYNCQ, MQCC=2 451 MQRC=2042 |
This is a clue that multiple MCAs are fighting over the syncq. The syncq is used by a channel end to keep UofW and other channel state data.
Are any MQ instances working with z/OS 1.9? Not to appear condescending or argumentative either, but what has changed? If other MQ instances are working fine with z/OS 1.9, I'd guess it isn't z/OS. But, search IBM support for the error message AND z/OS 1.9.
Look at last change dates on the usual channel-related objects.
| Quote: |
| They are back on this now and report that SDSF is slow. |
Not an MQ issue.
_________________
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 |
|
|
| belchman |
| Posted: Thu Aug 21, 2008 8:16 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
First of all thanks to everyone for your attention on this. Especially you Bruce. It takes a special person to put up with my attitude...
I used our Mainline LOTS service for the first time and my man Mike (now affectionately Mikey B.) suggested that I ensure that the queue SYSTEM.CHANNEL.SYNCQ was shareable. It was not shareable on MQS8.
When I corrected that, and bounced the channels, all worked.
Thanks all. It would have teken me weeks to figure this out. I was chasing all sorts of funky leads.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
|
|
