Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first

2003-03-18 Thread Robert Broderick
From the Intercommunication Guide. MAYBE??
 bobbee

Heartbeat interval (HBINT)
This attribute applies to WebSphere MQ for AIX, iSeries, HP-UX, Linux,
Solaris,and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, Compaq
NonStop Kernel, Compaq OpenVMS Alpha, and OS/2 Warp, and for WebSphere MQ
for z/OS without CICS. You can specify the approximate time between
heartbeat flows that are to be passed from a sending MCA when there are no
messages on the transmission queue. Heartbeat flows unblock the receiving
MCA, which is waiting for messages to arrive or for the disconnect interval
to expire. When the receiving MCA is unblocked it can disconnect the channel
without waiting for the disconnect interval to expire. Heartbeat flows also
free any storage
buffers that have been allocated for large messages and close any queues
that have been left open at the receiving end of the channel.
The value is in seconds and must be in the range 0 through 999 999. A value
of zero means that no heartbeat flows are to be sent. The default value is
300. To be most useful, the value should be significantly less than the
disconnect interval value. This attribute is valid for sender,
cluster-sender, server, receiver, cluster-receiver, and requester channels.
Other than on z/OS and OS/400, it also applies to server-connection and
client-connection channels. On these channels, heartbeats
flow when a server MCA has issued an MQGET command with the WAIT option
on behalf of a client application.






From: Keith A. Hessong [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend
ing after server is dropped without dropping Bridge first
Date: Mon, 17 Mar 2003 17:20:21 -0500
We have tried ADOPTMCA to solve our problem and it didn't do any good.

We haven't tried ADOPTNEWMCA though.

Keith
-Original Message-
From: Crupi, Margherita [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2003 4:20 PM
To: [EMAIL PROTECTED]
Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend
ing after server is dropped without dropping Bridge first
Could the MQ channel ADOPTMCA*  ADOPTNEWMCA  parms help you in respect to
automatically retry channel operations
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Saturday, 15 March 2003 5:45 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend
ing after server is dropped without dropping Bridge first
Keith, by bridge are you referring to the channels? I don't know if this
will help, but a long time ago, we had something that sounds vaguely
similar
(although it was a Solaris system where you have Windows). What we ended up
doing is having the dist. side:
1) Send STOP CHANNEL commands to the mainframe telling it to stop the
sender
channel to the sun side
2) Issue STOP CHANNEL commands for the sender channels on the distributed
side.
Then at restart:

1) Send START CHANNEL commands to the mainframe telling it to restart its
sender channels
2) Issue START CHANNEL for the local sender
The only thing you have to watch for is if you WANT the channels to be down
and you do a reboot, although that could be scripted around.
Since we have no Windows qmgrs, I don't know if you can do something
similar, but at least you now got a response  :-)  Good luck!  HTH --
Rebecca
Rebecca Bullock
Computer Sciences Corporation
MFCoE/Newark CS Team
Educational Testing Service Account
Princeton, NJ 08541
email: [EMAIL PROTECTED] or [EMAIL PROTECTED]

-Original Message-
From: Keith A. Hessong [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2003 12:12 PM
To: [EMAIL PROTECTED]
Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend
ing after server is dropped without dropping Bridge first
Greetings:

I am trying this again.  I didn't get any responses from my first attempt
at
sending this issue to the list.
Thanks,
Keith Hessong
Senior Programmer/Analyst
Golden Rule Insurance Company
-Original Message-
From: Keith A. Hessong [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 10:32 AM
To: [EMAIL PROTECTED]
Subject: MQ connection(s) from distributed side to Mainframe show Pending
after server is dropped without dropping Bridge first


Greetings:

My shop is currently experiencing a problem with MQ Series between our
distributed side and our mainframe side
when a server is dropped and restarted on the distributed side without
dropping the bridge first.  My shop ends up having
at least one of our mainframe connections showing up on the distributed
side
as PENDING.
Our environment is as follows:

Distributed Side:  MQ Series Version 5.2
  MSMQ MQ Series Bridge within Host
Integration Server
  WINDOWS 2000 MSMQ Service Pack 3
Mainframe Side

Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first

2003-03-17 Thread Crupi, Margherita
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first



Could 
the MQ channel ADOPTMCA* ADOPTNEWMCA parms help you in respect 
to automatically retry channel operations

  -Original Message-From: Bullock, Rebecca (CSC) 
  [mailto:[EMAIL PROTECTED]Sent: Saturday, 15 March 2003 5:45 
  AMTo: [EMAIL PROTECTED]Subject: Re: MQ 
  connection(s) from distributed side to Mainframe show Pend ing after server is 
  dropped without dropping Bridge first
  Keith, by "bridge" are you referring to the channels? I don't know if 
  this will help, but a long time ago, we had something that sounds vaguely 
  similar (although it was a Solaris systemwhere you have Windows). What 
  we ended up doing is having the dist. side:
  
  1)Send STOP CHANNEL commands to the mainframe telling it to stop 
  the sender channel to the sun side
  2) 
  Issue STOP CHANNEL commands for the sender channels on the distributed side. 
  
  
  Then 
  at restart:
  
  
  1)Send START CHANNEL commands to the mainframe telling it to 
  restart its sender channels
  2) Issue START CHANNEL for the local sender 
  
  
  The 
  only thing you have to watch for is if you WANT the channels to be down and 
  you do a reboot, although that could be scripted 
  around.
  
  Since we have no Windows qmgrs, I don't know if you can do something 
  similar, butat least you now got a response 
  :-) Good luck! HTH -- Rebecca
  
  
  Rebecca BullockComputer Sciences 
  CorporationMFCoE/Newark CS TeamEducational Testing Service 
  AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or 
  [EMAIL PROTECTED] 
  
-Original Message-From: Keith A. Hessong 
[mailto:[EMAIL PROTECTED]Sent: Friday, March 14, 2003 
12:12 PMTo: [EMAIL PROTECTED]Subject: Re: MQ 
connection(s) from distributed side to Mainframe show Pend ing after server 
is dropped without dropping Bridge first
Greetings:

I 
am trying this again. I didn't get any responses from my first attempt 
at sending this issue to the list.

Thanks,
Keith Hessong
Senior Programmer/Analyst
Golden Rule Insurance Company

-Original Message-From: Keith A. Hessong 
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003 
10:32 AMTo: [EMAIL PROTECTED]Subject: MQ 
connection(s) from distributed side to Mainframe show Pending after server 
is dropped without dropping Bridge first
Greetings: 
My shop is currently experiencing a problem with 
MQ Series between our distributed side and our mainframe side 
when a server is dropped and restarted on the 
distributed side without dropping the bridge first. My shop ends up 
having 
at least one of our mainframe connections showing 
up on the distributed side as "PENDING". 
Our environment is as follows: 
 
Distributed Side: MQ Series Version 5.2  
MSMQ MQ Series Bridge within Host Integration Server  
WINDOWS 2000 MSMQ Service Pack 3 
 
Mainframe Side: OS/390 Version 2.5  
MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA 
parameter = YES
What are we currently doing now when a server is 
dropped and restarted on the distributed side?   1) Everything 
seems to be OK if we are able to shut the bridge down before dropping the 
server and  
restarting it on the distributed side.  2) If a server 
is dropped and restarted and no work kicks off from the distributed side to 
the mainframe side,
 
the channel on the mainframe can be stopped and restarted and everything 
seems to be OK.  3) If a server 
is dropped and restarted and work kicks off from the distributed side to the 
mainframe side,  
the channel on the mainframe must be forced down, messages must be waited on 
for arrival on the mainframe 
 
side to acknowledge loss of communication between the distributed side and 
the mainframe side, and the channel 
 
can be restarted on the mainframe side. 
I have a couple of questions. 
 
Are we handling what we are experiencing here correctly?  If not, 
what should we be doing that we aren't doing?  Any other 
suggestions? 
Thanks, Keith 
Hessong  
  
  ** 
  
  This e-mail and any files transmitted with it may contain 
  privileged or 
  confidential information. It is solely for use by the 
  individual for whom 
  it is intended, even if addressed incorrectly. If you received 
  this e-mail 
  in error, please notify the sender; do not disclose, copy, 
  distribute, or 
  take any action in reliance on the contents of this 
  information; and delete 
  it from your system. Any other use of this e-mail is 
  prohibited. Thank you 
  for your 
compliance.


Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first

2003-03-17 Thread Keith A. Hessong
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first



We
have tried ADOPTMCA to solve our problem and it didn't do any
good.

We
haven't tried ADOPTNEWMCA though.

Keith
-Original Message-From: Crupi, Margherita
[mailto:[EMAIL PROTECTED]Sent: Monday, March 17, 2003 4:20
PMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s)
from distributed side to Mainframe show Pend ing after server is dropped without
dropping Bridge first
Could
the MQ channel ADOPTMCA* ADOPTNEWMCA parms help you in respect
to automatically retry channel operations

  -Original Message-From: Bullock, Rebecca (CSC)
  [mailto:[EMAIL PROTECTED]Sent: Saturday, 15 March 2003 5:45
  AMTo: [EMAIL PROTECTED]Subject: Re: MQ
  connection(s) from distributed side to Mainframe show Pend ing after server is
  dropped without dropping Bridge first
  Keith, by "bridge" are you referring to the channels? I don't know if
  this will help, but a long time ago, we had something that sounds vaguely
  similar (although it was a Solaris systemwhere you have Windows). What
  we ended up doing is having the dist. side:
  
  1)Send STOP CHANNEL commands to the mainframe telling it to stop
  the sender channel to the sun side
  2)
  Issue STOP CHANNEL commands for the sender channels on the distributed side.
  
  
  Then
  at restart:
  
  
  1)Send START CHANNEL commands to the mainframe telling it to
  restart its sender channels
  2) Issue START CHANNEL for the local sender
  
  
  The
  only thing you have to watch for is if you WANT the channels to be down and
  you do a reboot, although that could be scripted
  around.
  
  Since we have no Windows qmgrs, I don't know if you can do something
  similar, butat least you now got a response
  :-) Good luck! HTH -- Rebecca
  
  
  Rebecca BullockComputer Sciences
  CorporationMFCoE/Newark CS TeamEducational Testing Service
  AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or
  [EMAIL PROTECTED] 
  
-Original Message-From: Keith A. Hessong
[mailto:[EMAIL PROTECTED]Sent: Friday, March 14, 2003
12:12 PMTo: [EMAIL PROTECTED]Subject: Re: MQ
connection(s) from distributed side to Mainframe show Pend ing after server
is dropped without dropping Bridge first
Greetings:

I
am trying this again. I didn't get any responses from my first attempt
at sending this issue to the list.

Thanks,
Keith Hessong
Senior Programmer/Analyst
Golden Rule Insurance Company

-Original Message-From: Keith A. Hessong
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003
10:32 AMTo: [EMAIL PROTECTED]Subject: MQ
connection(s) from distributed side to Mainframe show Pending after server
is dropped without dropping Bridge first
Greetings: 
My shop is currently experiencing a problem with
MQ Series between our distributed side and our mainframe side
when a server is dropped and restarted on the
distributed side without dropping the bridge first. My shop ends up
having 
at least one of our mainframe connections showing
up on the distributed side as "PENDING". 
Our environment is as follows: 

Distributed Side: MQ Series Version 5.2 
MSMQ MQ Series Bridge within Host Integration Server 
WINDOWS 2000 MSMQ Service Pack 3 

Mainframe Side: OS/390 Version 2.5 
MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA
parameter = YES
What are we currently doing now when a server is
dropped and restarted on the distributed side?   1) Everything
seems to be OK if we are able to shut the bridge down before dropping the
server and 
restarting it on the distributed side.  2) If a server
is dropped and restarted and no work kicks off from the distributed side to
the mainframe side,

the channel on the mainframe can be stopped and restarted and everything
seems to be OK.  3) If a server
is dropped and restarted and work kicks off from the distributed side to the
mainframe side, 
the channel on the mainframe must be forced down, messages must be waited on
for arrival on the mainframe 

side to acknowledge loss of communication between the distributed side and
the mainframe side, and the channel 

can be restarted on the mainframe side. 
I have a couple of questions. 

Are we handling what we are experiencing here correctly?  If not,
what should we be doing that we aren't doing?  Any other
suggestions? 
Thanks, Keith
Hessong 
  
  **
  
  This e-mail and any files transmitted with it may contain
  privileged or 
  confidential information. It is solely for use by the
  individual for whom 
  it is intended, even if addressed incorrectly. If you received
  this e-mail 
  in error, please notify the sen

Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first

2003-03-14 Thread Keith A. Hessong
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first



Greetings:

I am 
trying this again. I didn't get any responses from my first attempt at 
sending this issue to the list.

Thanks,
Keith 
Hessong
Senior 
Programmer/Analyst
Golden 
Rule Insurance Company

-Original Message-From: Keith A. Hessong 
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003 10:32 
AMTo: [EMAIL PROTECTED]Subject: MQ connection(s) 
from distributed side to Mainframe show Pending after server is dropped without 
dropping Bridge first
Greetings: 
My shop is currently experiencing a problem with MQ 
Series between our distributed side and our mainframe side when a server is dropped and restarted on the distributed side 
without dropping the bridge first. My shop ends up having 
at least one of our mainframe connections showing up 
on the distributed side as "PENDING". 
Our environment is as follows: 
 
Distributed Side: MQ Series Version 5.2  
MSMQ MQ Series Bridge within Host Integration Server  
WINDOWS 2000 MSMQ Service Pack 3 
 
Mainframe Side: OS/390 Version 2.5  
MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA parameter 
= YES
What are we currently doing now when a server is 
dropped and restarted on the distributed side?   1) Everything 
seems to be OK if we are able to shut the bridge down before dropping the server 
and  
restarting it on the distributed side.  2) If a server is 
dropped and restarted and no work kicks off from the distributed side to the 
mainframe side,
 
the channel on the mainframe can be stopped and restarted and everything seems 
to be OK.  3) If a server is 
dropped and restarted and work kicks off from the distributed side to the 
mainframe side,  
the channel on the mainframe must be forced down, messages must be waited on for 
arrival on the mainframe 
 
side to acknowledge loss of communication between the distributed side and the 
mainframe side, and the channel 
 
can be restarted on the mainframe side. 
I have a couple of questions. 
 Are 
we handling what we are experiencing here correctly?  If not, what should we 
be doing that we aren't doing?  Any other 
suggestions? 
Thanks, Keith 
Hessong  


Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first

2003-03-14 Thread Bullock, Rebecca (CSC)
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first



Keith,
by "bridge" are you referring to the channels? I don't know if this will help,
but a long time ago, we had something that sounds vaguely similar (although it
was a Solaris systemwhere you have Windows). What we ended up doing is
having the dist. side:

1)Send STOP CHANNEL commands to the mainframe telling it to stop
the sender channel to the sun side
2)
Issue STOP CHANNEL commands for the sender channels on the distributed side.


Then
at restart:


1)Send START CHANNEL commands to the mainframe telling it to
restart its sender channels
2) Issue START CHANNEL for the local sender 

The
only thing you have to watch for is if you WANT the channels to be down and you
do a reboot, although that could be scripted around.

Since
we have no Windows qmgrs, I don't know if you can do something similar,
butat least you now got a response :-) Good
luck! HTH -- Rebecca


Rebecca BullockComputer Sciences CorporationMFCoE/Newark
CS TeamEducational Testing Service AccountPrinceton, NJ
08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED]


  -Original Message-From: Keith A. Hessong
  [mailto:[EMAIL PROTECTED]Sent: Friday, March 14, 2003 12:12
  PMTo: [EMAIL PROTECTED]Subject: Re: MQ
  connection(s) from distributed side to Mainframe show Pend ing after server is
  dropped without dropping Bridge first
  Greetings:
  
  I am
  trying this again. I didn't get any responses from my first attempt at
  sending this issue to the list.
  
  Thanks,
  Keith Hessong
  Senior Programmer/Analyst
  Golden Rule Insurance Company
  
  -Original Message-From: Keith A. Hessong
  [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003
  10:32 AMTo: [EMAIL PROTECTED]Subject: MQ
  connection(s) from distributed side to Mainframe show Pending after server is
  dropped without dropping Bridge first
  Greetings: 
  My shop is currently experiencing a problem with MQ
  Series between our distributed side and our mainframe side when a server is dropped and restarted on the distributed
  side without dropping the bridge first. My shop ends up having
  
  at least one of our mainframe connections showing
  up on the distributed side as "PENDING". 
  Our environment is as follows: 
  
  Distributed Side: MQ Series Version 5.2 
  MSMQ MQ Series Bridge within Host Integration Server 
  WINDOWS 2000 MSMQ Service Pack 3 
  
  Mainframe Side: OS/390 Version 2.5 
  MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA
  parameter = YES
  What are we currently doing now when a server is
  dropped and restarted on the distributed side?   1) Everything
  seems to be OK if we are able to shut the bridge down before dropping the
  server and 
  restarting it on the distributed side.  2) If a server
  is dropped and restarted and no work kicks off from the distributed side to
  the mainframe side,
  
  the channel on the mainframe can be stopped and restarted and everything seems
  to be OK.  3) If a server
  is dropped and restarted and work kicks off from the distributed side to the
  mainframe side, 
  the channel on the mainframe must be forced down, messages must be waited on
  for arrival on the mainframe 
  
  side to acknowledge loss of communication between the distributed side and the
  mainframe side, and the channel 
  
  can be restarted on the mainframe side. 
  I have a couple of questions. 
  
  Are we handling what we are experiencing here correctly?  If not,
  what should we be doing that we aren't doing?  Any other
  suggestions? 
  Thanks, Keith
  Hessong 





** 

This e-mail and any files transmitted with it may contain privileged or 

confidential information. It is solely for use by the individual for whom 

it is intended, even if addressed incorrectly. If you received this e-mail 

in error, please notify the sender; do not disclose, copy, distribute, or 

take any action in reliance on the contents of this information; and delete 

it from your system. Any other use of this e-mail is prohibited. Thank you 

for your compliance.