Re: cause of channels out of sequence?

2003-08-14 Thread Steve D. Perkins
Title: cause of channels out of sequence?









Deleting
and then recreating the channel on one queue manager and not the other will
also cause this problem.

 

-Original
Message-
From: MQSeries List
[mailto:[EMAIL PROTECTED]On Behalf Of Benjamin
Zhou
Sent: Tuesday, August 05, 2003
8:41 AM
To: [EMAIL PROTECTED]
Subject: cause of channels out of
sequence?

 

Win2k, MQ5.2: 

Occasionally, a pair of channels between
two qmgrs on different machines become out of sync, while the sender MCA tries
to send a message with sequence number 1, but the receiving side is expecting a
different one, say 300.

While this is easy to fix, I want to
understand what cause the problem. I enabled tcp/ip keep alive, set heartbeat
interval to 60 sec, and discint to 600 sec.

Can anyone shed some light on what's
behind this out-of-sequence? 

thanks a lot. 

Benjamin Zhou 
State Street Corp. 








Re: MQGet Blocked Read

2003-08-05 Thread Steve D. Perkins
Tim,

Thanks, I'm going to go ahead with sending a Stop message.  It's the
easiest/cleanest solution for this particular app.  Arjan's idea is a great
idea I never considered and will try on the test bed   Thanks Arjan!
However, it's too easy to implement the STOP message and I don't have time
on my side.  Better solutions will need to be in revision 2

Thanks!

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim
Armstrong
Sent: Monday, August 04, 2003 7:09 PM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read

Sorry had my blinkers on. As others have said one solution is to send a
STOP message, I have done this using a different MsgType but the MQFB_QUIT
is probably more valid. Arjan's idea of get disabling the queue is possible
if you are prepared to permit +set access to clients and issue an MQSET API
call from within a client program.

Regards
Tim A



  "Steve D.
  Perkins" To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]> cc:
  Sent by: MQSeriesSubject:  Re: MQGet Blocked
Read
  List
  <[EMAIL PROTECTED]
  N.AC.AT>


  04/08/2003 18:23
  Please respond to
  MQSeries List





Yes, thanks Will, thought I had made that clear.

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of WR
Sent: Monday, August 04, 2003 2:30 AM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read

I think Steve is saying that he's stopping only his *application*, not
MQ...

-Will

At 09:23 PM Sunday 8/3/2003, Tim Armstrong wrote:
>Sorry must be misinterpreting what your problem is. When you stop MQ via
>the SCM it stops your queue managers i.e. issues an internal "endmqm
>MYQMGR" if you have MQGMO_FAIL_IF_QUIESCING coded then you should not time
>out as your MQGET will fail with RC=2161 in your app which can then
>gracefully exit.
>
>Regards
>Tim A
>
>
>
>   "Steve D.
>   Perkins" To:
> [EMAIL PROTECTED]
>   <[EMAIL PROTECTED]> cc:
>   Sent by: MQSeriesSubject:  Re: MQGet
> Blocked Read
>   List
>   <[EMAIL PROTECTED]
>   N.AC.AT>
>
>
>   04/08/2003 14:00
>   Please respond to
>   MQSeries List
>
>
>
>
>
>Tim,
>
>Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is
>shutting down.  That's not the problem.  The problem is terminating a
WIN32
>Client service gracefully when the service is in a blocked MQGET read.  It
>appears there isn't any way except to wait or issue a ::TerminateThread
>which works but generates a ton of memory leaks.  It would be nice if IBM
>would code an event handle that could be included as a parameter when
>issuing a MQGET.  Then when signaled the MQGET would return out of the
>read.
>Another alternative is simply to "PUT" a message onto the "GET" queue
prior
>to shutdown.  This will break the blocked MQGET read as a message is
>readily
>available.  I'm looking at that method as the best means of gracefully
>shutting down.  However, I don't know how well that method will be
received
>since I'm only supposed to be receiving messages from that queue.
>Therefore
>the hunt for an additional solution goes on
>
>Thanks for the reply!
>
>Steve
>
>-Original Message-
>From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim
>Armstrong
>Sent: Sunday, August 03, 2003 8:47 PM
>To: [EMAIL PROTECTED]
>Subject: Re: MQGet Blocked Read
>
>Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_
>equivalent etc.
>
>Regards
>Tim A
>
>
>
>   "Steve D.
>   Perkins" To:
>[EMAIL PROTECTED]
>   <[EMAIL PROTECTED]> cc:
>   Sent by: MQSeriesSubject:  MQGet Blocked
Read
>   List
>   <[EMAIL PROTECTED]
>   N.AC.AT>
>
>
>   03/08/2003 08:41
>   Please respond to
>   MQSeries List
>
>
>
>
>
>Hello,
>
> I have an application which one of the prerequisites is to call
>MQGET with
>a minimum 120 second WaitInterval!  This application is using MQSeries 5.3
>client on a WIN32 platform and runs as a s

Re: MQGet Blocked Read

2003-08-04 Thread Steve D. Perkins
Peter,

I'm looking at putting a message onto the get queue.  The message would
need to be generated from the client which is the identical app that's
trying to shut down.  Since it is multithreaded that wouldn't be a problem
since the "PUT" thread would be active and when signal to quit could HELP
the "GET" thread to shutdown by placing a message onto it's queue.  I'll
look at MQFB_QUIT.  Thanks.

Steve

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Heggie,
Peter
Sent: Monday, August 04, 2003 7:21 AM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read

Can you have a 'shutdown' command that runs a program to send a report
message to the app? With a feedback code of MQFB_QUIT ? The app /
service would have to be modified to look for this type of message and
feedback code.

Peter Heggie
(315) 428 - 3193


-Original Message-
From: Steve D. Perkins [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 12:00 AM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read


Tim,

Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is
shutting down.  That's not the problem.  The problem is terminating a
WIN32 Client service gracefully when the service is in a blocked MQGET
read.  It appears there isn't any way except to wait or issue a
::TerminateThread which works but generates a ton of memory leaks.  It
would be nice if IBM would code an event handle that could be included
as a parameter when issuing a MQGET.  Then when signaled the MQGET would
return out of the read. Another alternative is simply to "PUT" a message
onto the "GET" queue prior to shutdown.  This will break the blocked
MQGET read as a message is readily available.  I'm looking at that
method as the best means of gracefully shutting down.  However, I don't
know how well that method will be received since I'm only supposed to be
receiving messages from that queue.  Therefore the hunt for an
additional solution goes on

Thanks for the reply!

Steve

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim
Armstrong
Sent: Sunday, August 03, 2003 8:47 PM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read

Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the
MQOO_ equivalent etc.

Regards
Tim A



  "Steve D.
  Perkins" To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]> cc:
  Sent by: MQSeriesSubject:  MQGet Blocked
Read
  List
  <[EMAIL PROTECTED]
  N.AC.AT>


  03/08/2003 08:41
  Please respond to
  MQSeries List





Hello,

I have an application which one of the prerequisites is to call
MQGET with a minimum 120 second WaitInterval!  This application is using
MQSeries 5.3 client on a WIN32 platform and runs as a service.  The
minimum 120 second interval is there to supposedly keep the bandwidth
down to a minimum. However, the problem is with WIN32 the Service
Control Manager times out and cannot shut down the service in a timely
fashion.  MQGET will only return if the WaitInterval has expired or a
message is received.  My only solution is to put a message onto the "GET
Queue" prior to shutdown to force an exit out of the blocked read.  I
was hoping for a more elegant solution on WIN32. Are there any other
ways to "signal" a blocked MQI MQGET on Win32 to exit?

Thanks much!

Steve

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


This e-mail and any files transmitted with it, are confidential to National
Grid and are intended solely for the use of the individual or entity to whom
they are addressed.  If you have received this e-mail in error, please
contact the National Grid USA Enterprise Support Center on 508-389-3375 or
315-428-6360.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Re: MQGet Blocked Read

2003-08-04 Thread Steve D. Perkins
Arjan,

That would be great if I had access to the queue manager.  This is a Client
App running outside the four walls of the QMGR.

Steve

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Arjan M Van
Vught
Sent: Monday, August 04, 2003 3:04 AM
To: [EMAIL PROTECTED]
Subject: MQGet Blocked Read

Steve,

Another option to end your program nicely is to set the queue to get
disabled prior to shutdown.

Arjan

WebSphere MQ and EDI -->
http://edi.services.ibm.com/mqseries/spec_sheets.shtml

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Re: MQGet Blocked Read

2003-08-04 Thread Steve D. Perkins
Yes, thanks Will, thought I had made that clear.

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of WR
Sent: Monday, August 04, 2003 2:30 AM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read

I think Steve is saying that he's stopping only his *application*, not MQ...

-Will

At 09:23 PM Sunday 8/3/2003, Tim Armstrong wrote:
>Sorry must be misinterpreting what your problem is. When you stop MQ via
>the SCM it stops your queue managers i.e. issues an internal "endmqm
>MYQMGR" if you have MQGMO_FAIL_IF_QUIESCING coded then you should not time
>out as your MQGET will fail with RC=2161 in your app which can then
>gracefully exit.
>
>Regards
>Tim A
>
>
>
>       "Steve D.
>   Perkins" To:
> [EMAIL PROTECTED]
>   <[EMAIL PROTECTED]> cc:
>   Sent by: MQSeriesSubject:  Re: MQGet
> Blocked Read
>   List
>   <[EMAIL PROTECTED]
>   N.AC.AT>
>
>
>   04/08/2003 14:00
>   Please respond to
>   MQSeries List
>
>
>
>
>
>Tim,
>
>Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is
>shutting down.  That's not the problem.  The problem is terminating a WIN32
>Client service gracefully when the service is in a blocked MQGET read.  It
>appears there isn't any way except to wait or issue a ::TerminateThread
>which works but generates a ton of memory leaks.  It would be nice if IBM
>would code an event handle that could be included as a parameter when
>issuing a MQGET.  Then when signaled the MQGET would return out of the
>read.
>Another alternative is simply to "PUT" a message onto the "GET" queue prior
>to shutdown.  This will break the blocked MQGET read as a message is
>readily
>available.  I'm looking at that method as the best means of gracefully
>shutting down.  However, I don't know how well that method will be received
>since I'm only supposed to be receiving messages from that queue.
>Therefore
>the hunt for an additional solution goes on
>
>Thanks for the reply!
>
>Steve
>
>-Original Message-
>From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim
>Armstrong
>Sent: Sunday, August 03, 2003 8:47 PM
>To: [EMAIL PROTECTED]
>Subject: Re: MQGet Blocked Read
>
>Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_
>equivalent etc.
>
>Regards
>Tim A
>
>
>
>   "Steve D.
>   Perkins" To:
>[EMAIL PROTECTED]
>   <[EMAIL PROTECTED]> cc:
>   Sent by: MQSeriesSubject:  MQGet Blocked
Read
>   List
>   <[EMAIL PROTECTED]
>   N.AC.AT>
>
>
>   03/08/2003 08:41
>   Please respond to
>   MQSeries List
>
>
>
>
>
>Hello,
>
> I have an application which one of the prerequisites is to call
>MQGET with
>a minimum 120 second WaitInterval!  This application is using MQSeries 5.3
>client on a WIN32 platform and runs as a service.  The minimum 120 second
>interval is there to supposedly keep the bandwidth down to a minimum.
>However, the problem is with WIN32 the Service Control Manager times out
>and
>cannot shut down the service in a timely fashion.  MQGET will only return
>if
>the WaitInterval has expired or a message is received.  My only solution is
>to put a message onto the "GET Queue" prior to shutdown to force an exit
>out
>of the blocked read.  I was hoping for a more elegant solution on WIN32.
>Are there any other ways to "signal" a blocked MQI MQGET on Win32 to exit?
>
>Thanks much!
>
>Steve
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Re: MQGet Blocked Read

2003-08-03 Thread Steve D. Perkins
Tim,

Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is
shutting down.  That's not the problem.  The problem is terminating a WIN32
Client service gracefully when the service is in a blocked MQGET read.  It
appears there isn't any way except to wait or issue a ::TerminateThread
which works but generates a ton of memory leaks.  It would be nice if IBM
would code an event handle that could be included as a parameter when
issuing a MQGET.  Then when signaled the MQGET would return out of the read.
Another alternative is simply to "PUT" a message onto the "GET" queue prior
to shutdown.  This will break the blocked MQGET read as a message is readily
available.  I'm looking at that method as the best means of gracefully
shutting down.  However, I don't know how well that method will be received
since I'm only supposed to be receiving messages from that queue.  Therefore
the hunt for an additional solution goes on

Thanks for the reply!

Steve

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim
Armstrong
Sent: Sunday, August 03, 2003 8:47 PM
To: [EMAIL PROTECTED]
Subject: Re: MQGet Blocked Read

Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_
equivalent etc.

Regards
Tim A



      "Steve D.
  Perkins" To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]> cc:
  Sent by: MQSeriesSubject:  MQGet Blocked Read
  List
  <[EMAIL PROTECTED]
  N.AC.AT>


  03/08/2003 08:41
  Please respond to
  MQSeries List





Hello,

I have an application which one of the prerequisites is to call
MQGET with
a minimum 120 second WaitInterval!  This application is using MQSeries 5.3
client on a WIN32 platform and runs as a service.  The minimum 120 second
interval is there to supposedly keep the bandwidth down to a minimum.
However, the problem is with WIN32 the Service Control Manager times out
and
cannot shut down the service in a timely fashion.  MQGET will only return
if
the WaitInterval has expired or a message is received.  My only solution is
to put a message onto the "GET Queue" prior to shutdown to force an exit
out
of the blocked read.  I was hoping for a more elegant solution on WIN32.
Are there any other ways to "signal" a blocked MQI MQGET on Win32 to exit?

Thanks much!

Steve

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


MQGet Blocked Read

2003-08-02 Thread Steve D. Perkins
Hello,

I have an application which one of the prerequisites is to call MQGET with
a minimum 120 second WaitInterval!  This application is using MQSeries 5.3
client on a WIN32 platform and runs as a service.  The minimum 120 second
interval is there to supposedly keep the bandwidth down to a minimum.
However, the problem is with WIN32 the Service Control Manager times out and
cannot shut down the service in a timely fashion.  MQGET will only return if
the WaitInterval has expired or a message is received.  My only solution is
to put a message onto the "GET Queue" prior to shutdown to force an exit out
of the blocked read.  I was hoping for a more elegant solution on WIN32.
Are there any other ways to "signal" a blocked MQI MQGET on Win32 to exit?

Thanks much!

Steve

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Re: MQSeries 5.3 Client and SSL

2003-07-30 Thread Steve D. Perkins
Phillip,

Thanks, I also came to the same conclusion.  The only way to eliminate this
possibility is by using a "Static IP" address and controlling it via a
firewall or as you mentioned a channel security exit which then eliminates
the possibility of using DHCP.


Steve

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 8:35 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries 5.3 Client and SSL

If the cert is issued in PKCS12 format then that file can be given to as
many entities, and SSL will let it pass.  This is true even if you set the
SSLPEER, use SSLAUTH(Required), even if you do CRL checking.  you may want
to check the incoming IP address using a security exit.





      "Steve D.
      Perkins" To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]> cc:
  Sent by: MQSeriesSubject:  MQSeries 5.3 Client
and SSL
  List
  <[EMAIL PROTECTED]
  n.AC.AT>


  07/29/2003 02:29
  PM
  Please respond to
  MQSeries List






Hello

If a certificate is issued for a Client Connection using MQ 5.3 is there a
way to guarantee that that Cert may only be used for connectivity from a
single client.  In other words is it possible to prohibit copying an
identical Cert to multiple MQ Clients running on multiple platforms all
connecting to the same queue manager and using the same Server Connection
channel?  Thanks!


Steve

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive





This communication is for informational purposes only.  It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


MQSeries 5.3 Client and SSL

2003-07-29 Thread Steve D. Perkins
Hello

If a certificate is issued for a Client Connection using MQ 5.3 is there a
way to guarantee that that Cert may only be used for connectivity from a
single client.  In other words is it possible to prohibit copying an
identical Cert to multiple MQ Clients running on multiple platforms all
connecting to the same queue manager and using the same Server Connection
channel?  Thanks!


Steve

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Re: MQSeries Secured Connection

2002-09-06 Thread Steve D. Perkins



Kevin,
 
    Please distribute one to me!  
Thanks!
 
Steve

  -Original Message-From: MQSeries List 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin 
  TobinSent: Friday, September 06, 2002 12:57 AMTo: 
  [EMAIL PROTECTED]Subject: Re: MQSeries Secured 
  ConnectionIf anyone is 
  looking for a good tutorial on how to setup and configure MQ5.3 SSL using the 
  W2K platform then I have one and am 
  happy to distribute it to you. Kevin