| Author |
Message
|
| HenriqueS |
 Posted: Thu Sep 25, 2008 1:20 pm Post subject: Auto stating sender channels on Windows/Linux |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks,
In our mainframe (z/OS) MQ initiates all sender channels after an IPL (sure there is some delay, but no more than a few minutes).
I thought this had to do with the start of the channel initiation (*CHIN) task soon after the qmgr starts.
I expected similar behaviour on Windows/Linux. But we did reboot a few machines and saw that sender channels could not start (stayed in 'Inactive') and would keep this status for days until someone would manually start them.
Whats the deal? What to I need to change to have auto start of sender channels as soon the qmgr starts?
My qmgr is set with SCHINIT(QMGR), I thought that this setting controlled the channel auto start... |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Sep 25, 2008 1:29 pm Post subject: Re: Auto stating sender channels on Windows/Linux |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| HenriqueS wrote: |
Folks,
In our mainframe (z/OS) MQ initiates all sender channels after an IPL (sure there is some delay, but no more than a few minutes).
I thought this had to do with the start of the channel initiation (*CHIN) task soon after the qmgr starts.
I expected similar behaviour on Windows/Linux. But we did reboot a few machines and saw that sender channels could not start (stayed in 'Inactive') and would keep this status for days until someone would manually start them.
Whats the deal? What to I need to change to have auto start of sender channels as soon the qmgr starts?
My qmgr is set with SCHINIT(QMGR), I thought that this setting controlled the channel auto start... |
The channel initiator allows you to run channels.
What you are probably looking for is triggered channels.
Review the intercommunications manual.
Check your xmitq settings.
A channel in inactive mode is not a bad thing if it is triggered...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Thu Sep 25, 2008 1:39 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
The channels in our zOS system are not triggered. Any reason why they start automatically on z/OS and not on Windows/Linux?
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 25, 2008 2:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| HenriqueS wrote: |
| The channels in our zOS system are not triggered. Any reason why they start automatically on z/OS and not on Windows/Linux? |
You're sure they are not triggered because ?
You're sure they are not set up to run all the time because ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 26, 2008 6:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We've noticed this as well. If a channel is running on a Windows / UNIX server simply because its DISCINT hasn't expired yet, when the QM comes back up, the channel comes up Inactive. One might wonder why it didn't come up running and continue counting down where it left off on its DISCINT.
Not really a problem for us, just a curiousity.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Sep 26, 2008 10:10 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
This is the sysout of our z/OS MQ channel initiatior program. As you can notice, it pulls the channel names from somewhere and starts them right away.
I am checking if there is any parameter that sets this behavior and if there is an equivalent for Win/Linux systems.
| Code: |
13.14.12 STC14170 ---- SATURDAY, 23 AUG 2008 ----
13.14.12 STC14170 IEF695I START BCMHCHIN WITH JOBNAME BCMHCHIN IS ASSIGNED TO
13.14.12 STC14170 $HASP373 BCMHCHIN STARTED
13.14.12 STC14170 IEF403I BCMHCHIN - STARTED - TIME=13.14.12
13.14.12 STC14170 CSQX000I MQ CSQXJST IBM WebSphere MQ for z/OS V6
13.14.12 STC14170 CSQX001I MQ CSQXJST Channel initiator starting
13.14.12 STC14170 +CSQX070I MQ CSQXGIP CHINIT parameters ...
13.14.12 STC14170 +CSQX071I MQ CSQXGIP CHIADAPS=20, CHIDISPS=20, LSTRTMR=60
13.14.12 STC14170 +CSQX072I MQ CSQXGIP MAXCHL=1000, ACTCHL=1000
13.14.12 STC14170 +CSQX073I MQ CSQXGIP CHLEV=ENABLED, SSLEV=ENABLED
13.14.12 STC14170 +CSQX074I MQ CSQXGIP MONCHL=OFF, MONACLS=QMGR
13.14.12 STC14170 +CSQX075I MQ CSQXGIP ADOPTMCA=YES, ADOPTCHK=ALL
13.14.12 STC14170 +CSQX078I MQ CSQXGIP IGQ=DISABLED, CHADEXIT=
13.14.12 STC14170 +CSQX079I MQ CSQXGIP TRAXSTR=NO, TRAXTBL=2
13.14.12 STC14170 +CSQX080I MQ CSQXGIP SSLTASKS=0, SSLRKEYC=0
13.14.12 STC14170 +CSQX081I MQ CSQXGIP SSLKEYR=
13.14.12 STC14170 +CSQX082I MQ CSQXGIP SSLCRLNL=
13.14.12 STC14170 +CSQX085I MQ CSQXGIP LU62CHL=0, LUGROUP= , LUNAME= , LU62ARM
13.14.12 STC14170 +CSQX090I MQ CSQXGIP TCPCHL=1000, TCPKEEP=YES, TCPNAME=ZNETI
13.14.12 STC14170 +CSQX091I MQ CSQXGIP TCPSTACK=SINGLE, IPADDRV=IPV4
13.14.12 STC14170 +CSQX092I MQ CSQXGIP OPORTMIN=0, OPORTMAX=0
13.14.12 STC14170 +CSQX093I MQ CSQXGIP DNSWLM=NO, DNSGROUP=
13.14.12 STC14170 +CSQX094I MQ CSQXGIP RCVTIME=60, RCVTTYPE=ADD, RCVTMIN=0
13.14.12 STC14170 +CSQX011I MQ CSQXGIP Client attachment feature available
13.14.13 STC14170 +CSQX141I MQ CSQXADPI 20 adapter subtasks started, 0 failed
13.14.13 STC14170 +CSQX410I MQ CSQXREPO Repository manager started
13.14.13 STC14170 +CSQX151I MQ CSQXSSLI 0 SSL server subtasks started, 0 faile
13.14.13 STC14170 +CSQX015I MQ CSQXSPRI 20 dispatchers started, 0 failed
13.14.13 STC14170 +CSQX517E MQ CSQXSUPR Error in SYSTEM.CHANNEL.SYNCQ - channe
870 C62421979.00038166.1 repeated
13.14.13 STC14170 +CSQX517E MQ CSQXSUPR Error in SYSTEM.CHANNEL.SYNCQ - channe
871 C00795423.00038166.1 repeated
871 C00795423.00038166.1 repeated
13.14.13 STC14170 +CSQX022I MQ CSQXSUPR Channel initiator initialization compl
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.33479023.2 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel BCMH.TO.BCMT started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.03017677.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.62331228.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.33124959.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.33074683.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.62073200.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.61088183.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.58160789.2 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.60889128.2 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.61182408.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.00997185.2 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.71027866.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel SISBACEN.TO.SWIFT started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.00000001.1 started
13.14.13 STC14170 +CSQX500I MQ CSQXRCTL Channel C00038166.69141539.1 started
|
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 26, 2008 8:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You are looking in the wrong place. The sysout is just reporting on behavior.
The behavior is being controlled by the fact that the channel is either triggered or set to run continuously.
Read up in the intercommunications manual 
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Sun Sep 28, 2008 2:26 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
There are no trigger in those channels.
Run continously? Which property would do that? DISCINT? That's what
I am trying to say here. Our z/OS channels have DISCINT=0 and they do run continuosly. But the same does not happen on Linux/WIndows.
When I boot any Windows/Linux server on which MQ has channels running, the channels show up as Inactive.
There is clearly some difference on the z/OS vs. Windows/Linux behaviour I'd like to find written somewhere...
| fjb_saper wrote: |
You are looking in the wrong place. The sysout is just reporting on behavior.
The behavior is being controlled by the fact that the channel is either triggered or set to run continuously.
Read up in the intercommunications manual
Enjoy |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Sep 28, 2008 2:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well if you ask for best practice advice, I'd have to say I need a compelling reason to have a channel running all the time. I'm all for a triggered channel as it eliminates a number of problems, most specifically of the network kind...
Most of the time the extra time needed to trigger the channel is not important enough to warrant the channel running continuously with all the communications problems this creates in a network that is not 200 % stable.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Sun Sep 28, 2008 3:21 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
We ended up trigging our channels on the Linux/Windows as you just wrote. So the problem is over. For monitoring purposes we are changing some rules (if XMITQ !=0 AND Channel state = Inactive ---> beep alarm).
We were not used of doing this because our production systems were mostly z/OS based and rarely we ve had problems withing TCPIP communications even with DISCINT=0. When I arrived at this job things worked like that already. Monitoring only cared about (if Channel state != Running ---> Beep alarm) in business hours.
But yes, I've read a lot of material saying how much DISCINT=0 is bad, TCP/IP stack problems, etc.
We had to study the subject again since we are slowly moving some z/OS stuff to Windows/Linux and we had this issue of channels not starting right away when the queue manager goes up. I did apply some fix pack, rebooted the server, and the channels would not go back in Running state.
Like Peter said, this is pretty much an undocumented feature on z/OS: autostarting channels when the QM goes up. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Sep 28, 2008 4:03 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| HenriqueS wrote: |
For monitoring purposes we are changing some rules (if XMITQ !=0 AND Channel state = Inactive ---> beep alarm).
|
What if the XMITQ >0 and the channel status is Retrying, or Binding, or anything other than Running?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Sun Sep 28, 2008 5:04 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Also! Thanks.
| PeterPotkay wrote: |
| HenriqueS wrote: |
For monitoring purposes we are changing some rules (if XMITQ !=0 AND Channel state = Inactive ---> beep alarm).
|
What if the XMITQ >0 and the channel status is Retrying, or Binding, or anything other than Running? |
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Sep 28, 2008 9:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| HenriqueS wrote: |
For monitoring purposes we are changing some rules (if XMITQ !=0 AND Channel state = Inactive ---> beep alarm).
|
What if the XMITQ >0 and the channel status is Retrying, or Binding, or anything other than Running? |
And to give the channel the time to start without alerting you I would suggest
(If XMITQ > 0 and (channel status not running or XMITQ dequeue rate == 0)) and the situation stays that way for 5 seconds ----> beep alarm.
This should avoid you unnecessary alarms when the situation is true for a few milliseconds while the channel is starting.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Sep 29, 2008 6:30 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Do you have start commands for the channels in CSQINPX? |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Tue Sep 30, 2008 11:24 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
We have only the listeners starting...
| Code: |
//CSQINPX DD DISP=SHR,DSN=SSTP.HZ17.MQS600.SCSQPROC(LISTENER)
|
| Code: |
VIEW SSTP.HZ17.MQS600.SCSQPROC(LISTENER) - 01.01 Columns 00001 00072
Command ===> Scroll ===> PAGE
****** ***************************** Top of Data ******************************
000001 START LISTENER
000002 START LISTENER PORT(12422)
****** **************************** Bottom of Data ****************************
|
| kevinf2349 wrote: |
| Do you have start commands for the channels in CSQINPX? |
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
|
|
