| Author |
Message
|
| NealM |
 Posted: Tue May 02, 2017 9:56 am Post subject: Another channel sequence question |
 |
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
We are moving legacy apps from Z/VSE to Z/OS (yes Jeff, finally!) within the year. These interact with z/Linux guests via the CICS DPL bridge, with brokers on z/Linux driving the requests, all using MQ v8. In testing our setup we have run into a problem never seen in the past with Z/VSE<-->Z/Linux channels.
If the ZOS QM is restarted the admins have something set that also causes the channel sequences to be reset to zero (on VSE the sequence reset was separate). Sometimes that is OK, the channel seq at the zlinux end seems to get zeroed as well. But most of the time not, or at least not until the first request message from the broker is sent. That first request message just seems to disappear, but in doing so the zlinux end of the channel does get its sequence reset to zero, so subsequent messages are fine. Until the next QM restart. We do not like this sacrificial message approach to sequence resets!
Additional info: 1. The request message is not persistent, but the remote bridge queue definition is. 2. ZLinux MQ is at 8.0.0.5, ZOS is a couple levels down. 3. Our admins haven't figured out how to restart the ZOS QM without it resetting the channel sequences so we could at least control when the volcano gods get their sacrifice.
This is likely a PMR situation but I thought I would float it here first. Any suggestions? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue May 02, 2017 11:13 am Post subject: Re: Another channel sequence question |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| NealM wrote: |
| (yes Jeff, finally!) |
   
If only we could tell Wayne...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue May 02, 2017 3:17 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| If the ZOS QM is restarted the admins have something set that also causes the channel sequences to be reset to zero (on VSE the sequence reset was separate). |
Is there a reason for doing this? Normally it is not required.
_________________
Glenn |
|
| Back to top |
|
|
| NealM |
| Posted: Thu May 04, 2017 6:55 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
From MQJeff:
| Quote: |
| If only we could tell Wayne... |
We did! From his email:
| Quote: |
It's nice to be remembered.
Thanks -wayne |
================================
Separately,
| Quote: |
| Is there a reason for doing this? Normally it is not required. |
Our admins are new to Z/OS and plan to check with IBM on how not to reset the channel seq #s on every QM restart. But that still begs the question of the sacrificial message. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 04, 2017 9:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| NealM wrote: |
| Our admins are new to Z/OS and plan to check with IBM on how not to reset the channel seq #s on every QM restart. |
Stop doing whatever it is they've done to make it reset. Channel reset is as manual a process on z/OS as it is on all other platforms (including z/VSE). Given the symptoms you're describing, I'd start with the channel initiator task rather than the queue manager task. And if you're not running them in 2 separate z/OS initiators as 2 separate started tasks, I've found your problem.
| NealM wrote: |
| But that still begs the question of the sacrificial message. |
Fix the channel problem, fix this problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 04, 2017 10:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Q. How often should you need to reset channel sequence numbers?
A. Almost never.
_________________
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 |
|
|
| hughson |
| Posted: Wed May 10, 2017 5:52 pm Post subject: Re: Another channel sequence question |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| NealM wrote: |
| Our admins haven't figured out how to restart the ZOS QM without it resetting the channel sequences so we could at least control when the volcano gods get their sacrifice. |
Get them to check the CSQINPX dataset on the CHINIT started task.
If they don't know where that is, look in the JESYSMSG of the CHINIT address space and find the message like this:-
| Code: |
| IEFC001I PROCEDURE MQG1MSTR WAS EXPANDED USING SYSTEM LIBRARY SYS1.PROCLIB |
Then go to that library and find the member with the same name as the CHINIT jog, e.g. MQG1CHIN.
Scroll down through that job until you see the CSQINPX DD card thus (you may or may not still have the comments from the sample that most people copy to set this up:-
| Code: |
//******************************************************************
//* SYSTEM INITIALIZATION INPUT DATA SETS *
//* *
//* This sample shows the IBM supplied samples being used for the *
//* initialization input data sets. These data sets *
//* should be copied into a user library and tailored. *
//******************************************************************
//CSQINPX DD DSN=MQDATA.MQG1.SCSQPROC(CSQ4INPX),DISP=SHR
//CSQOUTX DD SYSOUT=*
//* |
There may be several entries, one on each line, in the CSQINPX DD card. Open each dataset referenced until you find one that contains RESET CHANNEL commands, and comment them out (by putting an asterisk at the beginning of the line.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
