date:20040512

Here's a snippet from an old discussion on this subject.:


The MP61 support pack has a pdf "WebSphere MQ for AIX - Performance
Evaluations" which has some explanation.It includes a number of
comparisons of inetd and runmqlsr performance, and compares both methods
between 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text:
"the 'runmqlsr' has a reduced resource utilisation (one thread per
connection vs. a process per connection for the 'inetd' listener and a
smaller memory footprint), so is now the preferred method of running
client channels and server channels."

-Tom

==
Tom Schneider / IBM Global Services
(513) 274-4034
[EMAIL PROTECTED]
==



  "Lindberg,
  Gunilla" To:  [EMAIL PROTECTED]
  Subject: Listeners
  Sent by:
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  05/12/2004 03:20
  AM
  Please respond
  to MQSeries List





Hi!


Does anybody know the advantages, disadvantages in using inetd.conf verses
runmqlsr?


Regards Gunilla

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: Getting rid of expired messages

2004-05-12 Thread Tuben, Gregg

When an application attempts read a expired message using a destructive
MQGET on any version, the result is the same as if that message does not
exist. it doesn't matter if the application in the Channel initiator, MQ or
you. The difference with 5.3 is that the result is the same when browsing.
Gregg Tuben
Lead Developer z/OS WSMQ products
BMC Software Inc.

-Original Message-
From: Jeff A Tressler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 1:06 PM
To: [EMAIL PROTECTED]
Subject: Getting rid of expired messages


Two questions

1) "If you are using V5.3 a browse will remove the expired messages."
>From the Reason Code 2033 thread.

I thought browse would work on any version. We use MQSeries v5.1 for
HP-UX 11.x. If browse does not work how do we clean up unexpired
messages? Doing a destructive read and putting the unexpired
messages back seems extreme.


2) Sending system send bunch of messages with expiration. The
destination system is down so messages back up in transmission
queue and expiration time is exceeded. When the destination is
back on-line, does the MCA remove the expired messages or does
it pass them down the channel.

I expect the MCA, doing a destructive read, will result in the expired
messages being deleted.


Jeff Tressler

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

Getting rid of expired messages

2004-05-12 Thread Jeff A Tressler

Two questions

1) "If you are using V5.3 a browse will remove the expired messages."
>From the Reason Code 2033 thread.

I thought browse would work on any version. We use MQSeries v5.1 for
HP-UX 11.x. If browse does not work how do we clean up unexpired
messages? Doing a destructive read and putting the unexpired
messages back seems extreme.


2) Sending system send bunch of messages with expiration. The
destination system is down so messages back up in transmission
queue and expiration time is exceeded. When the destination is
back on-line, does the MCA remove the expired messages or does
it pass them down the channel.

I expect the MCA, doing a destructive read, will result in the expired
messages being deleted.


Jeff Tressler

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: Remote Event Queues and Active Channels

2004-05-12 Thread Wyatt, T. Rob

This is more in Joergen's territory than mine but here goes...

I was thinking that you could implement this as a security exit along the
lines of BlockIP.  Only instead of looking at the conname information, the
exit simply opens the XMitQ and looks at the first message.  If it's your
channel stop message, you delete it and suppress the channel start.  As we
have seen with BlockIP, suppressing the channel startup in the SCYEXIT does
not disable the channel.  I *think* triggering would reset at this point and
the next message would start the process all over again.

-- T.Rob

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin,
Paul
Sent: Wednesday, May 12, 2004 9:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Hi T. Rob,

I was wondering about an exit. Would it actually work, do you think?

I thought it would have to be a message exit which would parse the message
and, if it was a start channel event message for the event channel it would
shut down the channel without sending on the message.

But wouldn't this create another stop channel event and so on with the
channel going into a loop (stop channel event; start channel (to send event
message); discard event message and stop channel (message exit); stop
channel event etc)?

Did you have another method in mind?

Cheers,
Paul

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt,
T. Rob
Sent: 12 May 2004 14:21
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Paul,

How about a channel exit that suppresses the stop messages for this channel?
The compromise costs you the stop events for this channel but at least
allows it to time out.

-- T.Rob

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin,
Paul
Sent: Wednesday, May 12, 2004 7:02 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Dave,

I think you're right. Thanks for the confirmation, although it seems a bit
drastic!

Cheers,
Paul

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David
C. Partridge
Sent: 12 May 2004 11:48
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


I guess the only way round this is to use a local agent to collect events
and use an out of band (i.e. non MQ) transport to centralise the event data.
I think this is what some of the commercial monitoring products do.

Dave

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: Reason Code 2033.

2004-05-12 Thread Joerg Wende

or your messages are yet not committed.
Joerg




 Ronald Weinger
 <[EMAIL PROTECTED]
 .COM>  To
 Sent by: MQSeries [EMAIL PROTECTED]
 List   cc
 <[EMAIL PROTECTED]
 N.AC.AT>  Subject
   Re: Reason Code 2033.

 12/05/2004 18:21


 Please respond to
   MQSeries List







33 of the messages could have been expired. The message count will reflect
expired messages even though you will not retrieve them. If you are using
V5.3 a browse will remove the expired messages.




"Vaughan Phillips"
<[EMAIL PROTECTED]>  To:
Sent by: "MQSeries List"[EMAIL PROTECTED]
<[EMAIL PROTECTED]>   cc:
Subject:Reason
Code 2033.
05/12/2004 11:47 AM
Please respond to "MQSeries List"







Hi,
Can anyone offer any suggestion(s) for the following behaviour:


In a CICS/MQ application.


For a given Local Queue, when I use the MQINQ call I get a Current Q Depth
value of 34 returned.


Then, having closed the Queue, I reopen it for Browse.
The MQGET specifies the Options: MQGMO-BROWSE-FIRST, MQGMO-NO-WAIT and
MQGMO-ACCEPT-TRUNCATED-MSG, which returns a message from the queue. This
message is then processed.


Then the first time through the Browse(MQGET) Loop, Options:
MQGMO-BROWSE-NEXT, MQGMO-NO-WAIT and MQGMO-ACCEPT-TRUNCATED-MSG, I get a
Completion Code of 2 and a Reason Code of 2033, which suggests that there
are no more messages on the queue that satisfy the request. Processing
falls out of the Browse Loop and the messages processed count shows a value
of 1 when the process ends..


My first thought was that maybe the message counting logic was wrong, or
the combination of options is not correct.


When I follow the transaction through CEDF, I can see that it's the first
MQGET(Browse Next) that fails. This suggests that the messages processed
count is consistent with what I'm seeing. Then, when I change the
combination of MQGET options, to check each combination of BROWSE options
as used in the sample Cobol/CICS/MQ code, which can be found in
CSQ.SCSQCOBS(*), the result is the same.


If you can offer any help, that would be great.


TIA


Vaughan





---
QAS Ltd.
Developers of QuickAddress Software
www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---


The information contained in this message may be CONFIDENTIAL and is for
the intended addressee only. Any unauthorized use, dissemination of the
information, or copying of this message is prohibited. If you are not the
intended addressee, please notify the sender immediately and delete this
message.

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: Remote Event Queues and Active Channels

That would work - I think.

D.

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: Remote Event Queues and Active Channels

2004-05-12 Thread Brian S. Crabtree

David

But you could have a local app filtering the messages - event Q - monitoring
Q to remote Q

Brian S. Crabtree
WBI Consultant
- Original Message -
From: "David C. Partridge" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 12, 2004 9:56 AM
Subject: Re: Remote Event Queues and Active Channels


> No this won't work - the channel exit you could use to suppress the event
> message would be in the message exit
> (MQCXP.ExitResponse=MQXCC_SUPPRESS_FUNCTION), and this exit will only be
> invoked once the channel is running - catch 22!
>
> Dave
>
> 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: Reason Code 2033.

2004-05-12 Thread Ronald Weinger


33 of the messages could have been expired.
The message count will reflect expired messages even though you will not
retrieve them. If you are using V5.3 a browse will remove the expired
messages.








"Vaughan Phillips"
<[EMAIL PROTECTED]>
Sent by: "MQSeries List"
<[EMAIL PROTECTED]>
05/12/2004 11:47 AM
Please respond to "MQSeries
List"

        
        To:  
     [EMAIL PROTECTED]
        cc:  
     
        Subject:  
     Reason Code 2033.



Hi,

Can anyone offer any suggestion(s) for the following behaviour: 
In a CICS/MQ application. 
For a given Local Queue, when I use the MQINQ
call I get a Current Q Depth value of 34 returned. 
Then, having closed the Queue, I reopen it for
Browse. 
The MQGET specifies the Options: MQGMO-BROWSE-FIRST, MQGMO-NO-WAIT and
MQGMO-ACCEPT-TRUNCATED-MSG, which returns a message from the queue. This
message is then processed.
Then the first time through the Browse(MQGET)
Loop, Options: MQGMO-BROWSE-NEXT, MQGMO-NO-WAIT and
MQGMO-ACCEPT-TRUNCATED-MSG, I get a Completion Code of 2 and a Reason Code of
2033, which suggests that there are no more messages on the queue that satisfy
the request. Processing falls out of the Browse Loop and the messages
processed count shows a value of 1 when the process ends..
My first thought was that maybe the message
counting logic was wrong, or the combination of options is not correct.

When I follow the transaction through CEDF, I can
see that it's the first MQGET(Browse Next) that fails. This suggests that the
messages processed count is consistent with what I'm seeing. Then, when I
change the combination of MQGET options, to check each combination of BROWSE
options as used in the sample Cobol/CICS/MQ code, which can be found in
CSQ.SCSQCOBS(*), the result is the same.
If you can offer any help, that would be
great. 
TIA

Vaughan 



---
QAS Ltd.
Developers of QuickAddress Software
www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---



The information contained in this message may be CONFIDENTIAL and is for
the intended addressee only.  Any unauthorized use, dissemination of the
information, or copying of this message is prohibited.  If you are not the
intended addressee, please notify the sender immediately and delete this
message.

Re: Reason Code 2033.

Are you resetting the messageid and correlid when you move to browse next?

If you don't, you'll be specifically looking for another message with the
same
message and correlation ids as the first one and the likely result will be a
2033.

Also why do you INQ and then close, reopen and then browse?  Why not just do
a browse first and if you get a 2033, give up?

Dave

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: Reason Code 2033.

2004-05-12 Thread Jim Ford

Before you do the Browse(MQGET), make sure that you set the correlation ID
to MQCI-NONE and the message ID to MQMI-NONE in the appropriate message
descriptor. If there's data in either of these things you're telling MQ to
get a specific message with that ID. So if one or both contains residual
data, you get the 2033.




  Vaughan Phillips
  cc:
  Sent by: MQSeriesSubject:  Reason Code 2033.
  List
  <[EMAIL PROTECTED]
  n.ac.at>


  05/12/2004 10:47
  AM
  Please respond to
  MQSeries List






Hi,
Can anyone offer any suggestion(s) for the following behaviour:


In a CICS/MQ application.


For a given Local Queue, when I use the MQINQ call I get a Current Q Depth
value of 34 returned.


Then, having closed the Queue, I reopen it for Browse.
The MQGET specifies the Options: MQGMO-BROWSE-FIRST, MQGMO-NO-WAIT and
MQGMO-ACCEPT-TRUNCATED-MSG, which returns a message from the queue. This
message is then processed.


Then the first time through the Browse(MQGET) Loop, Options:
MQGMO-BROWSE-NEXT, MQGMO-NO-WAIT and MQGMO-ACCEPT-TRUNCATED-MSG, I get a
Completion Code of 2 and a Reason Code of 2033, which suggests that there
are no more messages on the queue that satisfy the request. Processing
falls out of the Browse Loop and the messages processed count shows a value
of 1 when the process ends..


My first thought was that maybe the message counting logic was wrong, or
the combination of options is not correct.


When I follow the transaction through CEDF, I can see that it's the first
MQGET(Browse Next) that fails. This suggests that the messages processed
count is consistent with what I'm seeing. Then, when I change the
combination of MQGET options, to check each combination of BROWSE options
as used in the sample Cobol/CICS/MQ code, which can be found in
CSQ.SCSQCOBS(*), the result is the same.


If you can offer any help, that would be great.


TIA


Vaughan





---
QAS Ltd.
Developers of QuickAddress Software
www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---

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

Reason Code 2033.

2004-05-12 Thread Vaughan Phillips

Title: Reason Code 2033.

Hi,

Can anyone offer any suggestion(s) for the following behaviour:

In a CICS/MQ application.

For a given Local Queue, when I use the MQINQ call I get a Current Q Depth value of 34 returned.

Then, having closed the Queue, I reopen it for Browse.

The MQGET specifies the Options: MQGMO-BROWSE-FIRST, MQGMO-NO-WAIT and MQGMO-ACCEPT-TRUNCATED-MSG, which returns a message from the queue. This message is then processed.

Then the first time through the Browse(MQGET) Loop, Options: MQGMO-BROWSE-NEXT, MQGMO-NO-WAIT and MQGMO-ACCEPT-TRUNCATED-MSG, I get a Completion Code of 2 and a Reason Code of 2033, which suggests that there are no more messages on the queue that satisfy the request. Processing falls out of the Browse Loop and the messages processed count shows a value of 1 when the process ends..

My first thought was that maybe the message counting logic was wrong, or the combination of options is not correct.

When I follow the transaction through CEDF, I can see that it's the first MQGET(Browse Next) that fails. This suggests that the messages processed count is consistent with what I'm seeing. Then, when I change the combination of MQGET options, to check each combination of BROWSE options as used in the sample Cobol/CICS/MQ code, which can be found in CSQ.SCSQCOBS(*), the result is the same.

If you can offer any help, that would be great.

TIA

Vaughan

---
QAS Ltd.
Developers of QuickAddress Software
www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---

Triggering in C#

2004-05-12 Thread Pius, Edward

Title: Message



Hello,
 
    I am trying to write an
application to trigger when a message is dropped into a queue. I have
already written the same application in Java and it works. I am trying to
emulate this in C#. In the process definition I have the applid defined as
"start c:\edward\webspheremq\dotnet\GWTriggerStart 'MQTMC2' /b". I cannot seem
to get the structure definition to read...
 
   
Any ideas would be very welcome.
 
Edward.

Re: VB with ActiveX - Get-Wait is not working

2004-05-12 Thread WR

At 05:19 AM 5/12/2004, Ruzi R wrote:
Hi,

One of our VB developers (on W2K/MQ 5.3) has pointed
out that GET with Wait was not working. He says he
sets MQGMO_WAIT for the MQGMO options, and
MQGMO_WAITINTERVAL =3. I suggested setting the
Wait-interval to even a bigger number to see if he
would notice any difference -- it did not make any
diff. I tested the "Get with Wait" in the sample VB
program that comes with MQ, and it works. So, I think
the problem has something to do with with ActiveX. Any
ideas?
Your input would be much appreciated.
Here's a code fragment that work for me:

Global GetMsg As MQMessage
Global getMsgOpts As MQGetMessageOptions
. . .

Set GetMsg = MQSess.AccessMessage()
Set getMsgOpts = MQSess.AccessGetMessageOptions()
getMsgOpts.Options = MQGMO_WAIT Or MQGMO_CONVERT
getMsgOpts.WaitInterval = 5000
InputQueue.Get GetMsg, getMsgOpts
-Will

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

UNIX System Load for MQSeries

2004-05-12 Thread Jeff A Tressler

Our SA has been task to determine the system load of MQSeries. The
only thing I can find is a two word description of the processes.

amqpcsea  command processor
amqhasmx  logger
amqharmx  log formatter
amqzllp0  checkpoint processor
amqzlaa0  queue manager agents
amqzma0   processing controller
amqcrsta  TCP/IP listener

Which of these are of any consequences such that the SA can
get system resource usage. I would assume command processor
can be safely ignored since I do not believe we use it. And the
TCP/IP listeners would be important since each inbound channel
spawns one of these processes.

At this point it seems amqcrsta, amqhasmx, and amqzlaa0 are the
most important processes to examine to determine load. The rest
contribute only in a minor way.

Am I missing something here?

Jeff Tressler

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: Remote Event Queues and Active Channels

No this won't work - the channel exit you could use to suppress the event
message would be in the message exit
(MQCXP.ExitResponse=MQXCC_SUPPRESS_FUNCTION), and this exit will only be
invoked once the channel is running - catch 22!

Dave

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: Remote Event Queues and Active Channels

Hi T. Rob,

I was wondering about an exit. Would it actually work, do you think?

I thought it would have to be a message exit which would parse the message
and, if it was a start channel event message for the event channel it would
shut down the channel without sending on the message.

But wouldn't this create another stop channel event and so on with the
channel going into a loop (stop channel event; start channel (to send event
message); discard event message and stop channel (message exit); stop
channel event etc)?

Did you have another method in mind?

Cheers,
Paul

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt,
T. Rob
Sent: 12 May 2004 14:21
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Paul,

How about a channel exit that suppresses the stop messages for this channel?
The compromise costs you the stop events for this channel but at least
allows it to time out.

-- T.Rob

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin,
Paul
Sent: Wednesday, May 12, 2004 7:02 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Dave,

I think you're right. Thanks for the confirmation, although it seems a bit
drastic!

Cheers,
Paul

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David
C. Partridge
Sent: 12 May 2004 11:48
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


I guess the only way round this is to use a local agent to collect events
and use an out of band (i.e. non MQ) transport to centralise the event data.
I think this is what some of the commercial monitoring products do.

Dave

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: Buffer pool storage

Denis,

I'm sorry but I don't quite understand.  When you refer to "...delay the
number of swap in pageset.", are you talking about log switches, or
contention for bufferspace when messages are read from a queue?




  "Blondiaux Denis
  (DBB)"   To:  [EMAIL PROTECTED]
 Subject: Re: Buffer pool storage
  Sent by:
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  05/12/2004 03:13
  AM
  Please respond
  to MQSeries List





Rick,


It concern a qmgr with a lot of pagesets and a lot of queues.
We increase size of buffer pool for delay the number of swap in pageset.
(the original reason of this intervention is some hardware problem on
random space volumes).
But you have right, this large size is not really required.

After increasing the size of the bufferpools (we reach than at least 1,5
Gb), applications using the qmgr began to have security access problem
(Abend 878-00C DURING RACINIT PROCESSING - There is not enough virtual
local system queue area (LSQA)).
After investigation, we see that there is a lot of multiple getmain without
freemain in extended private area. So the conclusion was that these getmain
overide the memory where was cached the RACF informations.

The global conclusion was that we have to consider that the total size of
bufferpool can not reached more than 1,5gb, otherwise, you can expect this
kind of problem. We don't find any recommendation from IBM about this
before.

Posted here for information...

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Rick
Tsujimoto
Sent: mardi 11 mai 2004 17:09
To: [EMAIL PROTECTED]
Subject: Re: Buffer pool storage


Denis,

Out of curiosity, why are you using so much bufferpool space, and not
letting most of the data flow to disk?




  "Blondiaux Denis
  (DBB)"   To:
[EMAIL PROTECTED]
 Subject: Re: Buffer pool
storage
  Sent by:
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  05/11/2004 01:22
  AM
  Please respond
  to MQSeries List





Hi,


About this point, does anyone know if IBM has planned to implement
bufferpool in dataspace, like in DB2 ?
A few month ago, we had memory problem after increasing bufferpool because
we already take at least 1,6Gb in extended private area.

Denis

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John M
Hammond
Sent: mardi 11 mai 2004 6:35
To: [EMAIL PROTECTED]
Subject: Re: Buffer pool storage


Yes, it's in the MSTR and it's above the line private storage.  There
should be plenty of that to go around :)

John M Hammond
Data Center - Middleware
(630) 521-4339



 Ronald Weinger
 <[EMAIL PROTECTED]  To:
[EMAIL PROTECTED]
 >  cc:
 Sent by: MQSeries  Subject: Buffer pool
storage
 List
 <[EMAIL PROTECTED]
 .AT>


 05/10/2004 09:45 AM
 Please respond to
 MQSeries List







Does anyone know where in z/OS the bufferpool storage is allocated? Is is
within  the MQ Master address space?


The information contained in this message may be CONFIDENTIAL and is for
the intended addressee only. Any unauthorized use, dissemination of the
information, or copying of this message is prohibited. If you are not the
intended addressee, please notify the sender immediately and delete this
message.

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

--
Dexia Bank disclaimer :
http://www.dexia.be/maildisclaimer.htm
--



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

--
Dexia Bank disclaimer :
http://www.dexia.be/maildisclaimer.htm
--



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-

Re: Remote Event Queues and Active Channels

2004-05-12 Thread Wyatt, T. Rob

Paul,

How about a channel exit that suppresses the stop messages for this channel?
The compromise costs you the stop events for this channel but at least
allows it to time out.

-- T.Rob

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin,
Paul
Sent: Wednesday, May 12, 2004 7:02 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Dave,

I think you're right. Thanks for the confirmation, although it seems a bit
drastic!

Cheers,
Paul

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David
C. Partridge
Sent: 12 May 2004 11:48
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


I guess the only way round this is to use a local agent to collect events
and use an out of band (i.e. non MQ) transport to centralise the event data.
I think this is what some of the commercial monitoring products do.

Dave

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: VB with ActiveX - Get-Wait is not working

ps.  replied to the wrong posting.  sorry about that.




  Ruzi R
  <[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
  .COM>cc:
  Sent by: Subject: VB with ActiveX - Get-Wait is 
not working
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  05/12/2004 08:19
  AM
  Please respond
  to MQSeries List





Hi,

One of our VB developers (on W2K/MQ 5.3) has pointed
out that GET with Wait was not working. He says he
sets MQGMO_WAIT for the MQGMO options, and
MQGMO_WAITINTERVAL =3. I suggested setting the
Wait-interval to even a bigger number to see if he
would notice any difference -- it did not make any
diff. I tested the "Get with Wait" in the sample VB
program that comes with MQ, and it works. So, I think
the problem has something to do with with ActiveX. Any
ideas?

Your input would be much appreciated.

Best regards,

Ruzi

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: VB with ActiveX - Get-Wait is not working

I found the manual that describes how to set the values.  Doing the
footwork for apps is not a pleasant task.




  Ruzi R
  <[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
  .COM>cc:
  Sent by: Subject: VB with ActiveX - Get-Wait is 
not working
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  05/12/2004 08:19
  AM
  Please respond
  to MQSeries List





Hi,

One of our VB developers (on W2K/MQ 5.3) has pointed
out that GET with Wait was not working. He says he
sets MQGMO_WAIT for the MQGMO options, and
MQGMO_WAITINTERVAL =3. I suggested setting the
Wait-interval to even a bigger number to see if he
would notice any difference -- it did not make any
diff. I tested the "Get with Wait" in the sample VB
program that comes with MQ, and it works. So, I think
the problem has something to do with with ActiveX. Any
ideas?

Your input would be much appreciated.

Best regards,

Ruzi

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

Setting CDATASECTION - XML.CDataSection in ESQL (WSBIB)

2004-05-12 Thread ewqqwe sdrtqwfwe

Has anyone know how to setup a data section in ESQL. We are able to set a simple data 
by the following
statement.

SET OutputRoot.XML.Data1.(XML.CDataSection) = 'TEST';

What we need to do is to set a full XML data tree.

Thanks



Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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: VB with ActiveX - Get-Wait is not working

2004-05-12 Thread Potkay, Peter M (PLC, IT)

Ruzi, what does "not working" mean? The MQGET ends immediately with a 2033,
as if there was no wait interval specified? Or does it end with some other
RC?

-Original Message-
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 8:19 AM
To: [EMAIL PROTECTED]
Subject: VB with ActiveX - Get-Wait is not working

Hi,

One of our VB developers (on W2K/MQ 5.3) has pointed
out that GET with Wait was not working. He says he
sets MQGMO_WAIT for the MQGMO options, and
MQGMO_WAITINTERVAL =3. I suggested setting the
Wait-interval to even a bigger number to see if he
would notice any difference -- it did not make any
diff. I tested the "Get with Wait" in the sample VB
program that comes with MQ, and it works. So, I think
the problem has something to do with with ActiveX. Any
ideas?

Your input would be much appreciated.

Best regards,

Ruzi

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, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.

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

VB with ActiveX - Get-Wait is not working

2004-05-12 Thread Ruzi R

Hi,

One of our VB developers (on W2K/MQ 5.3) has pointed
out that GET with Wait was not working. He says he
sets MQGMO_WAIT for the MQGMO options, and
MQGMO_WAITINTERVAL =3. I suggested setting the
Wait-interval to even a bigger number to see if he
would notice any difference -- it did not make any
diff. I tested the "Get with Wait" in the sample VB
program that comes with MQ, and it works. So, I think
the problem has something to do with with ActiveX. Any
ideas?

Your input would be much appreciated.

Best regards,

Ruzi

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: Data Conversion

2004-05-12 Thread Gina McCarthy

Mike,

If MQSTR is already set and you are still not converting...are you
clustered? We had the same issue when we went to clustering. The CLUSRCVRs
need to have conversion set to yes.

Gina

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Ward,
Mike S
Sent: Tuesday, May 11, 2004 6:51 PM
To: [EMAIL PROTECTED]
Subject: Data Conversion


Hi all, I have a question about MQ data conversion and I am hoping someone
out there has an answer for me. I have a Q mgr set up on Z/OS and one set up
on Windows. I have verified that both sender channels on either side are set
to data conversion yes. If I send a message from Z/OS(Via PQEDIT) to the
windows side and use the rfhutil to read it from the q. It's still in EBCDIC
format. If I send a message from the windows side(Via mqput2) and read it
from the queue using PQEDIT the data looks like it's in ASCII format. I have
been scratching my head over this all day. I made sure the sender channels
are set to convert yes and I have stopped and restarted them to make sure
they took. Does anyone have any idea's as to why this is occurring? I am at
the 5.3 level csd 6 on windows and on z/os I am also at the 5.3 level and I
thing equivalent to csd 3.

Thanks in advance for any reply's

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: Remote Event Queues and Active Channels

Dave,

I think you're right. Thanks for the confirmation, although it seems a bit
drastic!

Cheers,
Paul

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David
C. Partridge
Sent: 12 May 2004 11:48
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


I guess the only way round this is to use a local agent to collect events
and use an out of band (i.e. non MQ) transport to centralise the event data.
I think this is what some of the commercial monitoring products do.

Dave

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: Remote Event Queues and Active Channels

I guess the only way round this is to use a local agent to collect events
and use an out of band (i.e. non MQ) transport to centralise the event data.
I think this is what some of the commercial monitoring products do.

Dave

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: Remote Event Queues and Active Channels

That would avoid the channel events but of course the channels would still be 
permanently active.

Ideally the event channels would only be actived when they needed to send genuine 
events and could go inactive when things were quiet. Otherwise the central QMgr could 
potentially have many hundreds of active channels for event logging even though they 
may only be sending event messages about the event channels themselves (it's all a bit 
narcissistic, isn't it!).

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David
C. Partridge
Sent: 12 May 2004 11:02
To: [EMAIL PROTECTED]
Subject: Re: Remote Event Queues and Active Channels


Set the DISCINT on these channels to zero?

Dave

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: Remote Event Queues and Active Channels

Set the DISCINT on these channels to zero?

Dave

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

Remote Event Queues and Active Channels

Hi all,

We've got our Event queues defined as remote queues all pointing to a
central QMgr. This works fine except that the channels to the central QMgr
are always active.

If these "Event" channels shut down due to their disconnect interval, the
QMgr generates a Channel Stop event, which ends up starting the channel
again to send the event to the central QMgr!

We want to collect channel events but would prefer not to have to have these
channels permanently active because they are reporting on their own
stop/start activity.

Anyone else found this or got any ideas?

Cheers,
Paul

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: Data Conversion