Re: Sending a PDF file as MQ payload
MQ doesn't care. Data is data. As long as you don't try and send it with md.format=MQFMT_STRING and turn conversion on, you'll be fine. tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Anderson > Sent: Monday, November 22, 2004 12:10 PM > To: [EMAIL PROTECTED] > Subject: Sending a PDF file as MQ payload > > Our development team asked me if it was possible to send a > PDF document as an MQ message. My "gut feeling" is yes, you > can, but I have never done it. > > anyone out there ever done such a thing? any hints or tips on > how to do it? > > > Thanks > > 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: Incorrect CURDEPTH displayed?
The only channels involved are the CLUSSDR/CLUSRCVR between cluster members. Applications connect only to the local queue manager. tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Miller, Dennis > Sent: Friday, November 05, 2004 2:18 PM > To: [EMAIL PROTECTED] > Subject: Re: Incorrect CURDEPTH displayed? > > I'm confused. Contrary to your claim, there are channels > involved, then? To further confuse, Amqrmppa may > contribute to OPROCS=4, but I don't believe it contributes to > the IPROCS=12. > > In any case, if I wanted to isolate the process that is > causing the problem, I would shutdown the channels to get > those out of the picture first. > > -Original Message- > From: Antony Boggis [mailto:[EMAIL PROTECTED] > Sent: Friday, November 05, 2004 8:37 AM > To: [EMAIL PROTECTED] > Subject: Re: Incorrect CURDEPTH displayed? > > > As some others have pointed out, I should have focused more on the > MQCMIT or as you say, look at the values used in the mqgmo.options > field. Although I have been assured by developers that > they're NOT using > syncpointing, I'm gonna search anyway. > > Of the 12 processes listed at that time, I should have > mentioned that 6 > of them were amqrmppa (the channel pooling process). These stay around > for a while, even after all the local processes are killed. > > tonyB. > > > -Original Message- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of > > Miller, Dennis > > Sent: Thursday, November 04, 2004 11:19 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Incorrect CURDEPTH displayed? > > > > Let me try to fill in a couple of blanks. First, the conventional > > wisdom would be that recycling the qmgr clears it up > because it forces > > > an end to all UOW's, eliminating all uncommitted gets/puts. > Second, > > client connections are more prone to some unexpected > effects because > > the qmgr is not always intimately aware of the client's state. > > Suppose for example, a client does an MQGET under syncpoint and then > > abends before the commit. In that state you have a queue > > depth 1 greater than the number of messages that you can > > "see" on the queue. That situation remains until the qmgr > > recognizes the client is gone and rolls back the MQGET, which > > might be awhile. Finally, I agree with others that the > > absence of MQBEGINs is not a fair test of whether you are > > using syncpoints. The operative indicator is the use of > > syncpoint on the > > GMO/PMO parameter. > > > > I notice from your display that 12 process have the queue > open when it > > > contains no messages. This suggests a lot of long-running > tasks and > > makes me ever-more suspicious that one of them is misbehaving with > > respect to uncommitted gets/puts. My approach to diagnosis would be > > this. First, see what DISPLAY THREAD shows. If that doesn't reveal > > the culprit, then, terminate the 12 processes one-by-one > and monitor > > the queue depth at each step. If the difference between available > > messages and qdepth changes, then that process is suspect. > > When all's-said-and-done if there are no open handles and > > there is still an inconsistency, then you can throw the > > uncommitted message theory out the window. > > > > Regards, > > Dennis > > > > > > -Original Message- > > From: Tony Boggis [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 03, 2004 3:54 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Incorrect CURDEPTH displayed? > > > > > > Recycling the qm does generally clear it up, yes. For a while. I've > > seen this a few times lately. I don't know how a restart is > clearing > > it. No client connections involved (why would that affect things?). > > All apps make direct connections (no channels involved). > > > > Granted that persistence is a message attrib. My error. > > > > Uncommitted gets? Hmmm. Granted that could be a possibility, but in > > our case, as I mentioned, we do not use syncpointing (but > your point > > about using syncpointing is interesting). A grep on all source code > > finds not > > one instance of MQBEGIN. > > > > tonyB. > > > > > Original Message > > > Subject: Re: Incorrect CURDEPTH displayed? > > > From: "Miller, Dennis" <[EMAIL PROTECTED]> > > > Date: Wed, November 03, 2004 2:27 pm > > > To: [EMAIL PROTECT
Re: Incorrect CURDEPTH displayed?
As some others have pointed out, I should have focused more on the MQCMIT or as you say, look at the values used in the mqgmo.options field. Although I have been assured by developers that they're NOT using syncpointing, I'm gonna search anyway. Of the 12 processes listed at that time, I should have mentioned that 6 of them were amqrmppa (the channel pooling process). These stay around for a while, even after all the local processes are killed. tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Miller, Dennis > Sent: Thursday, November 04, 2004 11:19 AM > To: [EMAIL PROTECTED] > Subject: Re: Incorrect CURDEPTH displayed? > > Let me try to fill in a couple of blanks. First, the > conventional wisdom would be that recycling the qmgr clears > it up because it forces an end to all UOW's, eliminating all > uncommitted gets/puts. Second, client connections are more > prone to some unexpected effects because the qmgr is not > always intimately aware of the client's state. Suppose for > example, a client does an MQGET under syncpoint and then > abends before the commit. In that state you have a queue > depth 1 greater than the number of messages that you can > "see" on the queue. That situation remains until the qmgr > recognizes the client is gone and rolls back the MQGET, which > might be awhile. Finally, I agree with others that the > absence of MQBEGINs is not a fair test of whether you are > using syncpoints. The operative indicator is the use of > syncpoint on the > GMO/PMO parameter. > > I notice from your display that 12 process have the queue > open when it contains no messages. This suggests a lot of > long-running tasks and makes me ever-more suspicious that one > of them is misbehaving with respect to uncommitted gets/puts. > My approach to diagnosis would be this. First, see what > DISPLAY THREAD shows. If that doesn't reveal the culprit, > then, terminate the 12 processes one-by-one and monitor the > queue depth at each step. If the difference between available > messages and qdepth changes, then that process is suspect. > When all's-said-and-done if there are no open handles and > there is still an inconsistency, then you can throw the > uncommitted message theory out the window. > > Regards, > Dennis > > > -Original Message- > From: Tony Boggis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 03, 2004 3:54 PM > To: [EMAIL PROTECTED] > Subject: Re: Incorrect CURDEPTH displayed? > > > Recycling the qm does generally clear it up, yes. For a > while. I've seen > this a few times lately. I don't know how a restart is clearing it. No > client connections involved (why would that affect things?). All apps > make direct connections (no channels involved). > > Granted that persistence is a message attrib. My error. > > Uncommitted gets? Hmmm. Granted that could be a possibility, > but in our > case, as I mentioned, we do not use syncpointing (but your point about > using syncpointing is interesting). A grep on all source code > finds not > one instance of MQBEGIN. > > tonyB. > > > Original Message > > Subject: Re: Incorrect CURDEPTH displayed? > > From: "Miller, Dennis" <[EMAIL PROTECTED]> > > Date: Wed, November 03, 2004 2:27 pm > > To: [EMAIL PROTECTED] > > > > Does recycling the QMgr clear it up? > > And, if so, how--by restoring the messages or by clearing > the qdepth? > > Are any applications using client connections? > > > > > > You said> > > The queues are set as non-persistent. > > > > >>Persistence is a property of a message, not a queue. Any queue can > > hold persistent messages. > > > > > > You said> > > We do not use units-of-work (no Begin/End). > > > > >>My-oh-my. There's a fair chance that uncommitted gets are the > > culprit. I have never heard a defensible argument for doing gets > > outside of syncpoint. Problems like phantom messages and dropped > > messages are an expected result. > > > > > > Regards, > > Dennis > > > > > > -Original Message- > > From: Tony Boggis [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 03, 2004 12:45 PM > > To: [EMAIL PROTECTED] > > Subject: Incorrect CURDEPTH displayed? > > > > > > I have a queue manager that is showing a current depth > (non-zero) on > > several application queues. However, when I browse the queues > > (MQExplorer or amqsbcg) I get nothing. Also, when I browse > the queues, > > > the count does not go down to zero (as I might expect if there were > > expired messages). > > > > The queues are set as non-persistent. > > We do not use units-of-work (no Begin/End). > > We do not set expiry time on messages. > > > > Apart from this "ghost" depth, everything seems ok. I can get/put > > messages as normal. I just can't seem to get curdepth to return to > > zero. > > > > Suggestions? Am I missing something obvious? > > > > This is on Solaris 5.8 with WMQ 5.3, CSD08. > > > > tonyB. > > > > Instructions for managing your mailing list subscription >
Re: MQ tcp/ip errors.
Thanks Paul, We did try a 5 second value for both BATCHHB and HBINT, but found that on some systems this causes a race condition where MQ spawns new processes beofre old threads/processes are really dead - resulting in a system failure - pretty serious. So, reducing these values to 10 seconds resolved it. Our reasoning behind such low values is partly due to our application requirements. We have a cluster workload exit in place that rejects messages is the destination cluster queue manager is unreachable (due to a channel in a non-running state). This enables our application to re-route messages to other, available, applications on other cluster queue managers. We need the change in channel status to happen as quickly as possible (and hence be "picked-up" when the CWLE queries the channel status) in order that a message is not accepted and then routed to the SYSTEM.CLUSTER.TRANSMIT.QUEUE where it would then sit until the MCA could deliver it. Lowering the HBINT/BATCHHB values certainly improved our application's response time to channel outages. tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Clarke > Sent: Wednesday, October 13, 2004 3:16 AM > To: [EMAIL PROTECTED] > Subject: Re: MQ tcp/ip errors. > > Tony, > > Would I be right in thinking that you have configured your > channels to use a 5 second heartbeat (although there are > other ways) ? If so, are you sure you need it this frequent ? > Essentially the default timeout used to receive data on a > socket is based off the heartbeat interval. For heartbeats > less than 1 minute the timeout is set to twice the heartbeat > value. For heartbeats greater than one minute we set the > timeout to heartbeat plus 1 minute. > > If the channel has a heartbeat of 5 seconds it means that we > will only wait for 10 seconds for the remote side to send > some data. This means that you need to have a pretty reliable > network and a pretty reliable server. If either the network > or the server has a glitch or flood of work that prevents it > getting round to delivering the heartbeat then you will see > an error like this one. It may well be that the socket is > still live and well but if it's not delivering data as often > as it 'promised' MQ regards it as failed. > > If you really don't need to detect a network glithc/failure > within 10 seconds then it may be worth you increasing the > heartbeat to say, 30 seconds. This will wait for up to a > minute for data to arrive. > > Cheers, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > > MQSeries List <[EMAIL PROTECTED]> wrote on 12/10/2004 21:22:25: > > > Env: Solaris 5.8, WMQ 5.3 (CSD05) > > > > We have an annoying situation where we are periodically receiving > > tcp/ip errors in the MQ error logs. This causes our cluster > channels > > to terminate [abnormally]. It's a transient error, because > the channel > > immediately retries and successfully restarts and > everything continues > > on it's merry way. In most cases we are getting error code > 11 from a > > select. This (as far as my research finds) maps to the socket error > > EAGAIN, or something like "insufficent resources". But I have been > > unable to find much more detailed information as the causes > and cures. > > > > > -- > - > > > 09/07/04 11:11:12 AM > > AMQ9213: A communications error for TCP/IP occurred. > > > > EXPLANATION: > > An unexpected error occurred in communications. > > ACTION: > > The return code from the TCP/IP(select) [TIMEOUT] 10 > seconds call was > > 11 (X'B'). Record these values and tell the systems administrator. > > - amqccita.c : 3075 > > --- > > 09/07/04 11:11:12 AM > > AMQ: Channel program ended abnormally. > > > > EXPLANATION: > > Channel program 'TO.AS1' ended abnormally. > > ACTION: > > Look at previous error messages for channel program 'TO.AS1' in the > > error files to determine the cause of the failure. > > - amqrccca.c : 804 > > > > > > I am at a loss as to why these errors are occurring since I > am unable > > to find any matching events in the Solaris system error logs. Since > > the errors do not occur with any predictability, running a packet > > sniffer is difficult because within 30 seconds we can generate > > megabytes of data and don't have enough available storage for the > > generated log files. > > > > Can anyone offer any insight as to what might cause these > errors and > > how we might go about preventing them? > > > > All of our MQ apps connect directly to the local queue manager, so > > there are no client (or Server Connection) channels in use. > The only > > channels are CLUSSDR/CLUSRCVR channels between cluster > members and it > > is these channels that are periodically interupted. > > > > I don't (at this time) see this as any
Reason code 2003, Message AMQ9591.
Environment: Solaris 5.8, WMQ 5.3 (CSD05). In running some application tests across our MQ cluster, I had the above error logged. There was a single instance of AMQ9591, with a logged reason code of 2003: --- 09/24/04 08:25:00 AMQ9591: Program cannot prepare queue manager object. EXPLANATION: The attempt to prepare object '%CHLBATCH.4' on queue manager 'CLUSTER2B.AS2.MANAGER' failed with reason code 2003. ACTION: Use the standard facilities supplied with your system to record the problem identifier. Contact your IBM support center. - amqrsyna.c : 1799 --- 09/24/04 08:25:00 AMQ: Channel program ended abnormally. EXPLANATION: Channel program 'TO.AR1' ended abnormally. ACTION: Look at previous error messages for channel program 'TO.AR1' in the error files to determine the cause of the failure. - amqrccca.c : 804 09/24/04 08:25:10 AMQ9002: Channel program started. EXPLANATION: Channel program 'TO.AR1' started. ACTION: None. Right after the error was logged and the channel failure, the channel restarted and everything carried on as normal. Beyond the documentation, can anyone offer any addition information? The description for reason code 2003 (MQRC_BACKED_OUT) talks about units of work. I assume it's related to the operation of the message batch on the channel, since we are not using units of work at the application level, nor are we sending persistent messages. tonyB. 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: CPU Usage in a cluster environment.
messages trying all the alternate paths over and over. Were any messages going to the DLQ on the target QMs? I would think that after the CLUSSRCVR went through its MessageRetryCount x MessageRetryInterval, it would put one message to the DLQ, before repeating the process on the next message it got. -Original Message- From: Antony Boggis [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 12:11 PM To: [EMAIL PROTECTED] Subject: Re: CPU Usage in a cluster environment. Yes, the "backed up" system was the qmgr with >5,000,000 messages on the cluster xmit q. I would not expect any "rerouting" to happen since the queue managers were "alive" and reachable. There was just no room for any more messages. No amount of re-routing would have changed that. What I thought interesting is that both the cluster sender channel instances from this system to the remote systems (where the dest q was full) were in a Running state, but the partner cluster receiver channels were Paused. However, your point about the cluster workload exit being called for every message every time a channel retry interval passes may be a clue. The system is now "cleared", but I will try some more testing again soon. Paul Clarke also suggested running a trace. A good point. I shall try that also. tonyB. _ From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 12:15 AM To: [EMAIL PROTECTED] Subject: Re: CPU Usage in a cluster environment. [Deutsche Boerse Systems:Virus checked] Antony, if the "backed up" system is the Queuemanager with the many messages in the SYSTEM.CLUSTER.TRANSMIT.QUEUE then the "cluster rerouting" may cause the cpu usage. If there are messages on the SYSTEM.CUSTER.TRANSMIT.QUEUE and the chosen destination (channel) is in retry, then MQ will try at every retry interval of the channel to find an alternate route to the destination queue. This is done by reading the message from the SYSTEM.CLUSTER.XMIT.QUEUE, followed by a put to the target queue. this will drive the cluster workload mechanism and make MQ chose a new destination (if any). Unfortunately, if there is only one destination, then this is just a waste of cpu and log space (if messages are persistent). I do not know if this is really the reason, because i do not know what amqzlaa0_nd is doing, so this is just a guess... Regards, Stefan Antony Boggis <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 24.05.2004 21:32 Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Stefan Raabe/DBS/GDB) Subject:CPU Usage in a cluster environment. [Deutsche Boerse Systems:Virus checked] . Environment: Solaris 5.8 (24 CPUs, 98Gb RAM), WMQ 5.3 CSD05. I have a cluster of 4 queue managers. This past weekend we were running some tests sending volumes of messages. After a period of time we had some application issues (not MQ) on two of the receiving queue managers. Eventually several local queues filled and, as expected the cluster receiver channal on those queue managers went into a PAUSED state and messages (to the tune of > 500,000) have piled up on the sending system's SYSTEM.CLUSTER.TRANSMIT.QUEUE. This all comes as no surprise and I'd expect to hear you all say "working as designed". My question is this... on the "backed up" system, which to all intents and purposes, is now idle (no applications are sending messages), why is my CPU usage (process: amqzlaa0_nd) pretty much maxing out one of the systems CPU's (>4% CPU usage on this 24 CPU box)? 'top' shows a CPU time for amqzlaa0_nd of 41.5H. The sending system is actually showing the cluster sender channels as RUNNING, but the receiving end is showing a status of PAUSED. Regards, Antony Boggis. -- Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. 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.
Re: CPU Usage in a cluster environment.
Yes, the "backed up" system was the qmgr with >5,000,000 messages on the cluster xmit q. I would not expect any "rerouting" to happen since the queue managers were "alive" and reachable. There was just no room for any more messages. No amount of re-routing would have changed that. What I thought interesting is that both the cluster sender channel instances from this system to the remote systems (where the dest q was full) were in a Running state, but the partner cluster receiver channels were Paused. However, your point about the cluster workload exit being called for every message every time a channel retry interval passes may be a clue. The system is now "cleared", but I will try some more testing again soon. Paul Clarke also suggested running a trace. A good point. I shall try that also. tonyB. From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Tuesday, May 25, 2004 12:15 AMTo: [EMAIL PROTECTED]Subject: Re: CPU Usage in a cluster environment. [Deutsche Boerse Systems:Virus checked] Antony, if the "backed up" system is the Queuemanager with the many messages in the SYSTEM.CLUSTER.TRANSMIT.QUEUE then the "cluster rerouting" may cause the cpu usage. If there are messages on the SYSTEM.CUSTER.TRANSMIT.QUEUE and the chosen destination (channel) is in retry, then MQ will try at every retry interval of the channel to find an alternate route to the destination queue. This is done by reading the message from the SYSTEM.CLUSTER.XMIT.QUEUE, followed by a put to the target queue. this will drive the cluster workload mechanism and make MQ chose a new destination (if any). Unfortunately, if there is only one destination, then this is just a waste of cpu and log space (if messages are persistent). I do not know if this is really the reason, because i do not know what amqzlaa0_nd is doing, so this is just a guess... Regards, Stefan Antony Boggis <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 24.05.2004 21:32 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: CPU Usage in a cluster environment. [Deutsche Boerse Systems:Virus checked] .Environment: Solaris 5.8 (24 CPUs, 98Gb RAM), WMQ 5.3 CSD05.I have a cluster of 4 queue managers. This past weekend we were running some tests sending volumes of messages. After a period of time we had some application issues (not MQ) on two of the receiving queue managers. Eventually several local queues filled and, as expected the cluster receiver channal on those queue managers went into a PAUSED state and messages (to the tune of > 500,000) have piled up on the sending system's SYSTEM.CLUSTER.TRANSMIT.QUEUE. This all comes as no surprise and I'd expect to hear you all say "working as designed".My question is this... on the "backed up" system, which to all intents and purposes, is now idle (no applications are sending messages), why is my CPU usage (process: amqzlaa0_nd) pretty much maxing out one of the systems CPU's (>4% CPU usage on this 24 CPU box)? 'top' shows a CPU time for amqzlaa0_nd of 41.5H.The sending system is actually showing the cluster sender channels as RUNNING, but the receiving end is showing a status of PAUSED.Regards,Antony Boggis. --Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bittesofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.The information contained in this message is confidential or protected bylaw. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.
CPU Usage in a cluster environment.
Title: CPU Usage in a cluster environment. Environment: Solaris 5.8 (24 CPUs, 98Gb RAM), WMQ 5.3 CSD05. I have a cluster of 4 queue managers. This past weekend we were running some tests sending volumes of messages. After a period of time we had some application issues (not MQ) on two of the receiving queue managers. Eventually several local queues filled and, as expected the cluster receiver channal on those queue managers went into a PAUSED state and messages (to the tune of > 500,000) have piled up on the sending system's SYSTEM.CLUSTER.TRANSMIT.QUEUE. This all comes as no surprise and I'd expect to hear you all say "working as designed". My question is this... on the "backed up" system, which to all intents and purposes, is now idle (no applications are sending messages), why is my CPU usage (process: amqzlaa0_nd) pretty much maxing out one of the systems CPU's (>4% CPU usage on this 24 CPU box)? 'top' shows a CPU time for amqzlaa0_nd of 41.5H. The sending system is actually showing the cluster sender channels as RUNNING, but the receiving end is showing a status of PAUSED. Regards, Antony Boggis.
Re: Problems building MQSeries Perl module on W2K
First thing... If Perl.exe & nmake.exe aren't on your path, as they say on tv "make it so". I have successfully built the MQ CPAN Perl stuff on NT. *HOWEVER* there are a couple (and I stress a couple) of bugs. The Perl stuff assumes a Unix environment and makes all sorts of assumptions (expecially regarding the INI files) based on that. So, don't rely on any of the routines that read the error logs - they may (or may not) work. Otherwise the rest of the stuff seems to work. tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Gurney, Matthew > Sent: Monday, May 17, 2004 10:46 AM > To: [EMAIL PROTECTED] > Subject: Problems building MQSeries Perl module on W2K > > I am having some problems installing the MQSeries Perl Module > on W2K. Perl V5.6.0 seems to be working ok, the samples work. > I can't build the mqseries perl module. The instructions state: > > 1) perl Makefile.PL > 2) make > 3) make test > 4) make install > > When I do step 1, I get, the following, does this mean there > is a problem? > > D:\MQPerl\MQSeries-1.23>perl makefile.pl Unable to find a > perl 5 (by these names: D:\Program Files\Perl\bin\Perl.exe > miniperl perl perl5 perl5.6.0, in these dirs > : D:\mqm\bin D:\mqm\java\bin D:\Program Files\Perl\bin > C:\BAB\CMQ20\BIN D:\Program Files\MQSeries\bin D:\Program Files\P > erl\bin) > Note (probably harmless): No library found for '-lmqicg' > Note (probably harmless): No library found for '-lmqic' > Note (probably harmless): No library found for '-lmqmcs' > Note (probably harmless): No library found for '-lmqmzse' > Note (probably harmless): No library found for 'oldnames.lib' > Note (probably harmless): No library found for 'kernel32.lib' > Note (probably harmless): No library found for 'user32.lib' > Note (probably harmless): No library found for 'gdi32.lib' > Note (probably harmless): No library found for 'winspool.lib' > Note (probably harmless): No library found for 'comdlg32.lib' > Note (probably harmless): No library found for 'advapi32.lib' > Note (probably harmless): No library found for 'shell32.lib' > Note (probably harmless): No library found for 'ole32.lib' > Note (probably harmless): No library found for 'oleaut32.lib' > Note (probably harmless): No library found for 'netapi32.lib' > Note (probably harmless): No library found for 'uuid.lib' > Note (probably harmless): No library found for 'wsock32.lib' > Note (probably harmless): No library found for 'mpr.lib' > Note (probably harmless): No library found for 'winmm.lib' > Note (probably harmless): No library found for 'version.lib' > Note (probably harmless): No library found for 'odbc32.lib' > Note (probably harmless): No library found for 'odbccp32.lib' > Note (probably harmless): No library found for 'msvcrt.lib' > Running '..\0 -ID:\Program Files\Perl\lib D:\Program > Files\Perl\lib\ExtUtils\xsubpp -v 2>&1' exits with status > 16777215 at (eval 265) line 17. > Running '..\0 D:\Program Files\Perl\lib\ExtUtils\xsubpp > temp000 2>&1' exits with status 16777215 at (eval 265) line 43. > Writing Makefile for MQClient::MQSeries > Writing Makefile for MQSeries::Message::DeadLetter Writing > Makefile for MQSeries::Message::PCF Writing Makefile for > MQSeries::Message::RulesFormat Writing Makefile for > MQSeries::PubSub Note (probably harmless): No library found > for '-lmqmcs' > Note (probably harmless): No library found for '-lmqmzse' > Note (probably harmless): No library found for 'oldnames.lib' > Note (probably harmless): No library found for 'kernel32.lib' > Note (probably harmless): No library found for 'user32.lib' > Note (probably harmless): No library found for 'gdi32.lib' > Note (probably harmless): No library found for 'winspool.lib' > Note (probably harmless): No library found for 'comdlg32.lib' > Note (probably harmless): No library found for 'advapi32.lib' > Note (probably harmless): No library found for 'shell32.lib' > Note (probably harmless): No library found for 'ole32.lib' > Note (probably harmless): No library found for 'oleaut32.lib' > Note (probably harmless): No library found for 'netapi32.lib' > Note (probably harmless): No library found for 'uuid.lib' > Note (probably harmless): No library found for 'wsock32.lib' > Note (probably harmless): No library found for 'mpr.lib' > Note (probably harmless): No library found for 'winmm.lib' > Note (probably harmless): No library found for 'version.lib' > Note (probably harmless): No library found for 'odbc32.lib' > Note (probably harmless): No library found for 'odbccp32.lib' > Note (probably harmless): No library found for 'msvcrt.lib' > Writing Makefile for MQServer::MQSeries > Writing Makefile for MQSeries > > > I am using nmake, when I run step 2 I get: > D:\MQPerl\MQSeries-1.23>nmake > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > NMAKE : fatal error U1073: don't know how to make 'D:\Program' > Stop. > > Thanks,
Wmq 5.3 & Sun Cluster.
Title: Wmq 5.3 & Sun Cluster. Anyone with experience with MQ & configuring Sun Cluster 3.x? I have found some docs on the matter and an old SupportPac, but wanted to pose a question to the list… What has been done (I "inherited" this environment) is that two hosts are both pointing to the same mount point (/var/mqm). So, doing a "cd /var/mqm" on either host will put me on the same physical disk. Each host has one queue manager (e.g. hostAqmgr & hostBqmgr). So, what I have in /var/mqm is: @SYSTEM hostAqmgr hostBqmgr This is where I see the problem… my understanding of things MQ is that much of what is in @SYSTEM is host/environment specific and can't be "shared" across hosts. This would seem to be borne out by the fact that only one queue manager works. Can anyone either affirm my thinking or suggest a better config that I can tell the system admin guys to look into? Regards, tonyB.
Re: Managing remote queue managers with RUNMQSC
Title: Managing remote queue managers with RUNMQSC Good suggestion (normally)... but I don't have access from my windows client to the cluster members in question. To access the queue manager(s) I have to SSH to a SSH server, then telnet from there (since once I get to the SSH server, I am on a trusted host). So, since I only have access to the Solaris environment through a terminal, can I do this? I have 32 cluster members (with more coming!). tonyB. From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT)Sent: Friday, March 26, 2004 12:31 PMTo: [EMAIL PROTECTED]Subject: Re: Managing remote queue managers with RUNMQSC Use the MO71 support pac. It allows you to open up a runmqsc window into any QM from your desktop. Very Cool. -Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]Sent: Friday, March 26, 2004 3:00 PMTo: [EMAIL PROTECTED]Subject: Managing remote queue managers with RUNMQSC I know it's possible to manage queue managers remotely using the "runmqsc" command processor. However, this (according to the docs) requires that transmission queues and queue manager aliases to the remote qmgrs be defined. What I can't find any mention of in the docs is whether this approach to remote management can be used to manage queue managers that belong to a cluster. Has anyone tried managing cluster queue managers from a single cluster member? Is it possible? Regards, tonyB. 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.
Managing remote queue managers with RUNMQSC
Title: Managing remote queue managers with RUNMQSC I know it's possible to manage queue managers remotely using the "runmqsc" command processor. However, this (according to the docs) requires that transmission queues and queue manager aliases to the remote qmgrs be defined. What I can't find any mention of in the docs is whether this approach to remote management can be used to manage queue managers that belong to a cluster. Has anyone tried managing cluster queue managers from a single cluster member? Is it possible? Regards, tonyB.
Cluster Workload Exit/Resolving Queues
Title: Cluster Workload Exit/Resolving Queues I have a cluster workload exit installed (Solaris environment, WMQ 5.3 CSD05) that is intented to reject messages that are destined for a queue manager that is not active (sender channel status not "Running"). However, today the exit is rejecting messages that were destined for cluster queues hosted on the local queue manager. I had not seen this behaviour before. It is the MQPUT that is failing (the open succeeds, bind not fixed). I am guessing that the MQOPEN is resolving to a cluster instance (even though there is only one instance of the queue in question and it is hosted on the local queue manager). In the call to MQOPEN (or MQPUT) is there a way I can set the options to resolve to a local queue first over the cluster instance? Regards, tonyB.
Re: Queues from non-cluster members...
Title: RE: Re: Queues from non-cluster members... Even though neither of the repositories show the old queue manager when I do a "dis clusqmgr(*)" ? tonyB. -Original Message- From: MQSeries List on behalf of Potkay, Peter M (PLC, IT) Sent: Tue 3/23/2004 3:45 PM To: [EMAIL PROTECTED] Subject: Re: Queues from non-cluster members... Use the RESET command to force a QM out of a cluster. RESET CLUSTER(yourclustername) QMID(thebadQMID) ACTION(FORCEREMOVE) QUEUES(YES) Issue it once from one of your Full Repositories. -Original Message----- From: Antony Boggis [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 23, 2004 6:26 PM To: [EMAIL PROTECTED] Subject: Queues from non-cluster members... I have a queue manager that has been removed from a cluster using the correct procedure (suspend, set channel attrs, stop channels...). I still have queues on other cluster members (even after having refreshed the cluster) from this (now, non-existant) queue manager showing up: dis clusqmgr(*) qmid 10 : dis clusqmgr(*) qmid AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AR1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AR1) QMID(CLUSTER3B.AR1.MANAGER_2004-01-07_10.56.23) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS1) QMID(CLUSTER3B.AS1.MANAGER_2004-01-07_11.01.47) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1C.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS1C) QMID(CLUSTER3B.AS1C.MANAGER_2004-01-07_11.02.22) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS2) QMID(CLUSTER3B.AS2.MANAGER_2004-02-11_17.42.37) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2C.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS2C) QMID(CLUSTER3B.AS2C.MANAGER_2004-02-11_17.42.52) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.DFMC1) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.TXN.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.TXN) QMID(CLUSTER3B.TXN.MANAGER_2004-02-04_12.20.33) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(VISA_BMON_QMGR) CLUSTER(CLUSTER3B) CHANNEL(TO.VISA_BMON_QMGR) QMID(VISA_BMON_QMGR_2004-01-15_08.24.56) and dis qcluster(AR1.IN) all 9 : dis qcluster(AR1.IN) all AMQ8409: Display Queue details. DESCR(Queue in which AR1 will put XU messages) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(FT01.PDFMC.MANAGER) QMID(FT01.PDFMC.MANAGER_2004-02-17_10.38.48) CLUSDATE(2004-03-23) CLUSTIME(15.02.33) ALTDATE(2004-02-17) ALTTIME(10.50.43) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED) DEFPRTY(0) DEFPSIST(NO) DEFBIND(NOTFIXED) AMQ8409: Display Queue details. DESCR(Input queue for AR1) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) CLUSDATE(2004-03-23) CLUSTIME(15.02.27) ALTDATE(2004-03-23) ALTTIME(14.47.40) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED) DEFPRTY(0) DEFPSIST(NO) DEFBIND(NOTFIXED) This is after doing a refresh (on all cluster members even). Regards, tonyB. 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
Queues from non-cluster members...
I have a queue manager that has been removed from a cluster using the correct procedure (suspend, set channel attrs, stop channels...). I still have queues on other cluster members (even after having refreshed the cluster) from this (now, non-existant) queue manager showing up: dis clusqmgr(*) qmid 10 : dis clusqmgr(*) qmid AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AR1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AR1) QMID(CLUSTER3B.AR1.MANAGER_2004-01-07_10.56.23) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS1) QMID(CLUSTER3B.AS1.MANAGER_2004-01-07_11.01.47) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1C.MANAGER)CLUSTER(CLUSTER3B) CHANNEL(TO.AS1C) QMID(CLUSTER3B.AS1C.MANAGER_2004-01-07_11.02.22) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS2) QMID(CLUSTER3B.AS2.MANAGER_2004-02-11_17.42.37) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2C.MANAGER)CLUSTER(CLUSTER3B) CHANNEL(TO.AS2C) QMID(CLUSTER3B.AS2C.MANAGER_2004-02-11_17.42.52) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.DFMC1) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.TXN.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.TXN) QMID(CLUSTER3B.TXN.MANAGER_2004-02-04_12.20.33) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(VISA_BMON_QMGR)CLUSTER(CLUSTER3B) CHANNEL(TO.VISA_BMON_QMGR) QMID(VISA_BMON_QMGR_2004-01-15_08.24.56) and dis qcluster(AR1.IN) all 9 : dis qcluster(AR1.IN) all AMQ8409: Display Queue details. DESCR(Queue in which AR1 will put XU messages) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(FT01.PDFMC.MANAGER) QMID(FT01.PDFMC.MANAGER_2004-02-17_10.38.48) CLUSDATE(2004-03-23)CLUSTIME(15.02.33) ALTDATE(2004-02-17) ALTTIME(10.50.43) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED)DEFPRTY(0) DEFPSIST(NO)DEFBIND(NOTFIXED) AMQ8409: Display Queue details. DESCR(Input queue for AR1) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) CLUSDATE(2004-03-23)CLUSTIME(15.02.27) ALTDATE(2004-03-23) ALTTIME(14.47.40) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED)DEFPRTY(0) DEFPSIST(NO)DEFBIND(NOTFIXED) This is after doing a refresh (on all cluster members even). Regards, tonyB. 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: Websphere Technical Exchange?
Gary, I've seen the URLs for various MQ/MQ-related conferences. BUT, is there a single page where all the possible MQ technical gatherings are consolidated. I myself might be able to justify attending at least one gathering here in the US, but I want to make sure that it is going to be the one of most benefit. Regards, tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Gary Ward > Sent: Sunday, February 15, 2004 1:45 PM > To: [EMAIL PROTECTED] > Subject: Re: Websphere Technical Exchange? > > Peter (and the rest of the list), > > I have been intimately involved in arranging the sessions and > speakers for the MQ and WBI sessions for almost 10 years now. > I can honestly tell you after having been at both > conferences that we customize content based on what the > attendees want to hear, not on what IBM wants to present. > The speakers from Hursley and Raleigh have a lot more time to > sit down with attendees in the nightly social time (called > SCIDS) and talk about all sorts of things. They're not > rushed off to have "power dinners" with "high profile" customers. > > Just as an example, we've had sessions on WBI Message Broker > V5 since last August. You couldn't see those sessions > anywhere else in the US at a conference. > > And in Long Beach, we're having a nostalgic 10th birthday > party for MQ with a session that will go over the history of > the product and there will also be some surprises for > long-time MQers... > > If we don't see some of you "listers" in Long Beach, we hope > we'll see you in New York in August! > > Regards, > Gary > > Gary Ward > SHARE DATA Program Mananger > (and interim MQ Project Manager) > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf > Of Heggie, Peter > Sent: Thursday, February 12, 2004 3:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Websphere Technical Exchange? > > > Thank you, that is helpful information, in many ways. > > Peter Heggie > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of WR > Sent: Thursday, February 12, 2004 2:11 PM > To: [EMAIL PROTECTED] > Subject: Re: Websphere Technical Exchange? > > > At 10:07 AM 2/12/2004, Heggie, Peter wrote: > >Can someone compare the MQ content gained from Share vs. T&M > >conference? I've been to several conferences, but never to Share. I > >should describe myself as an intermediate level MQ administrator. A > >trip to New York will be easier to justify than a trip to Las Vegas, > >but if the conference content is significantly greater, then > I'll stick > > >to the conference. > > Having attended several of both, my opinion is that Share > offers more variety and specificity, thereby allowing me to > be more selective. > Also, since Share is a non-profit user group, the > presentations seem to be more honest and candid. A lot of > the presenters are "real-world" > users of the products who are not afraid to tell horror > stories as well as success stories. There are always a lot > of IBM folk presenting as well, but because they are invited > guests rather than the "owners" of the conference, there > seems to be more credibility in what they present. > Maximum cost is $1,595 for a full week attendance. Discounts > apply if you are a member of Share, your company is a member, > you register early, or if you opt to only attend certain days. > > My impression of the T&M conferences is that they tend to be > more "broad-brush", and since they are run by IBM, the > sessions all seem to follow the "party line" and present > products in the best possible light. > Maximum cost is $1,925 for a full week with similar discounts > as for Share. > > -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 > > > 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 reply to > this message and let the sender know. > > 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: QRE: VPN's and MQ
I am accessing MQ servers over a VPN with no problems... > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Nick Dilauro > Sent: Tuesday, February 10, 2004 2:31 PM > To: [EMAIL PROTECTED] > Subject: QRE: VPN's and MQ > > Bill, > > I don't have an answer to the second question since I haven't > worked with clients and VPNs but I imagine it's similar. We > have VPNs set up for sender/receiver channels. As I > understand it the VPN has all the security so I don't think > you need SSL. You'd be doing redundant protection. The VPN > works at the network level so it's transparent to MQ. No > changes to the MQ confif should be needed. > > Nick > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Anderson > Sent: Tuesday, February 10, 2004 1:25 PM > To: [EMAIL PROTECTED] > Subject: VPN's and MQ > > Has anyone set up access to MQ through a VPN connection? I > know it can be done, but I am not very heavy on how VPN's > work. One big question is: > > Would it be best to find a SSL capable VPN, or just any old > VPN and make use of SSL with in WMQ5.3? > > Another thing is, I'm sure VPN clients are available for > free, but what is the cost associated with the server side? > > Thanks > > Bill Anderson > WebSphere MQ Services > SITA Atlanta, GA > 770-303-3503 (office) > 404-915-3190 (cell) > [EMAIL PROTECTED] > http://www.mconnect.aero/ > > 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: Cluster workload exit rejecting messages...
Title: RE: Cluster workload exit rejecting messages...
More information... We've added some logging to our exit and are seeing some interesting results:
MQWXP * parms
This is passed to the exit by MQ.
If parms->ExitReason == MQXR_INIT, we return parms->ExitResponse2 = MQXR2_DYNAMIC_CACHE to indicate that we supprt dynamic caching.
If parms->ExitReason != MQXR_CLWL_PUT, we return, having previously set parms->ExitResponse = MQXCC_OK, since we only care about controlling MQPUT's.
So, the very next things we do is check the target queue manager's availability:
qmgr = parms->DestinationArrayPtr[ 0 ]
if ((qmgr->QMgrFlags & MQQMF_AVAILABLE) == 0)
{
parms->ExitResponse = MQXCC_SUPPRESS_FUNCTION;
return;
}
This is causing the exit to exit (!). However, I *KNOW* the remote queue manager is available because I am connected to it, locally using runmqsc and via Websphere MQ Explorer. The value in qmgr->QMgrFlags is 0x225B, which (if my math is correct) equates to: (MQQMF_REPOSITORY_Q_MGR & MQQMF_CLUSSDR_USER_DEFINED & MQQMF_CLUSSDR_AUTO_DEFINED), plus a bunch of other flags (which the docs say are used internally). What I don't understand is how both USER... & AUTO... are set.
tonyB.
From: MQSeries List [mailto:[EMAIL PROTECTED]] On Behalf Of Antony Boggis
Sent: Tuesday, February 10, 2004 10:00 AM
To: [EMAIL PROTECTED]
Subject: Cluster workload exit reject messages...
I have a Solaris based environment (5.8, all running WMQ 5.3 CSD05) with 6 queue managers involved across four hosts.
All the queue managers are running.
The issue I am having is that periodically the cluster workload exit is rejecting messages that are put to a remote cluster queue when it thinks that the channel to the remote manager is not up (state != Running). However, there is no corresponding channel event logged (on either the sending or the receiving queue manager). We need to have this exit in place since we require that the putting application receives an error if the intended message destination is unavailable. This way we can implement failover processing for our time-critical messages.
The exit is basically a simplified version of the sample exit provided (amqswlm0.c) with the server installation.
As a work around we defined an additional CLUSSDR (locally) and a CLUSCVR (on the destination) and our messages started flowing again.
Can anyone provide any insight as to why the exit might reject messages even though no channel events were logged? We are working to put some debug/trace information into the exit so that we can "see" what it's doing when it rejects messages, but I wanted to see if there's anyone out there with some experience in troubleshooting issues related to cluster workload exits.
Regards,
tonyB.
Cluster workload exit reject messages...
Title: Cluster workload exit reject messages... I have a Solaris based environment (5.8, all running WMQ 5.3 CSD05) with 6 queue managers involved across four hosts. All the queue managers are running. The issue I am having is that periodically the cluster workload exit is rejecting messages that are put to a remote cluster queue when it thinks that the channel to the remote manager is not up (state != Running). However, there is no corresponding channel event logged (on either the sending or the receiving queue manager). We need to have this exit in place since we require that the putting application receives an error if the intended message destination is unavailable. This way we can implement failover processing for our time-critical messages. The exit is basically a simplified version of the sample exit provided (amqswlm0.c) with the server installation. As a work around we defined an additional CLUSSDR (locally) and a CLUSCVR (on the destination) and our messages started flowing again. Can anyone provide any insight as to why the exit might reject messages even though no channel events were logged? We are working to put some debug/trace information into the exit so that we can "see" what it's doing when it rejects messages, but I wanted to see if there's anyone out there with some experience in troubleshooting issues related to cluster workload exits. Regards, tonyB.
Re: AMQ9213 & Bind failures on Solaris
Larry, Where would one find these errors documented? Thanks, tonyB. > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Larry Hendersen > Sent: Thursday, January 22, 2004 11:46 AM > To: [EMAIL PROTECTED] > Subject: Re: AMQ9213 & Bind failures on Solaris > > There was an error 13 in the FDC. errno 13 is EACCESS, > permission denied. > > >From: Antony Boggis <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: AMQ9213 & Bind failures on Solaris > >Date: Wed, 21 Jan 2004 21:44:05 -0800 > > > >Some good suggestions. > > > >However, for future reference to all this turned out to be a Solaris > >permissions issue. Somehow permissions on /tmp had been reset and no > >userID (except root) was able to write files there. > > > >At one point I had a sev 1 PMR open on this. what finally > clued me in > >(I can be slow sometimes) was that the logs were reporting > files like > >/tmp/MQSeries.xxx.xxx and there was nothing in /tmp. Hope this helps > >someone else out. Even IBM support missed this one. > > > >Regards, > > > >tonyB. > > > > > > > > > > From: MQSeries List > [mailto:[EMAIL PROTECTED] On Behalf > >Of Dhavala > > Sent: Wednesday, January 21, 2004 4:45 PM > > To: [EMAIL PROTECTED] > > Subject: Re: AMQ9213 & Bind failures on Solaris > > > > > > > >From the FFST it looks like the program is "runmqlsr" and > which would > >mean that even though you believe your listener is starting > and binding > >the port you asked for, fine enough, it sure seems to have > some issues. > >Try using some other port or find out who is using that particular > >port(1414, if it is so). > > > >Cheers > >Kumar > > > > > > > > _ > There are now three new levels of MSN Hotmail Extra Storage! > Learn more. > http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 > > 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: AMQ9213 & Bind failures on Solaris
Some good suggestions. However, for future reference to all this turned out to be a Solaris permissions issue. Somehow permissions on /tmp had been reset and no userID (except root) was able to write files there. At one point I had a sev 1 PMR open on this. what finally clued me in (I can be slow sometimes) was that the logs were reporting files like /tmp/MQSeries.xxx.xxx and there was nothing in /tmp. Hope this helps someone else out. Even IBM support missed this one. Regards, tonyB. From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of DhavalaSent: Wednesday, January 21, 2004 4:45 PMTo: [EMAIL PROTECTED]Subject: Re: AMQ9213 & Bind failures on Solaris From the FFST it looks like the program is "runmqlsr" and which would mean that even though you believe your listener is starting and binding the port you asked for, fine enough, it sure seems to have some issues. Try using some other port or find out who is using that particular port(1414, if it is so). Cheers Kumar
AMQ9213 & Bind failures on Solaris
Title: AMQ9213 & Bind failures on Solaris Env: Solaris 5.8, WMQ 5.3 CSD05 I have a clustered queue manager that is reporting bind errors. Specifically: AMQ9213: A communications error for bind occurred. In the error log, I am getting bind error 13. Along with the error log reports, I am getting generated FDC files: +-+ | | | WebSphere MQ First Failure Symptom Report | | = | | | | Date/Time :- Tuesday January 20 20:42:09 PST 2004 | | Host Name :- vdpsusptas02 (SunOS 5.8) | | PIDS :- 5724B4103 | | LVLS :- 530.5 CSD05 | | Product Long Name :- WebSphere MQ for Sun Solaris | | Vendor :- IBM | | Probe Id :- RM07 | | Application Name :- MQM | | Component :- cccJobMonitor | | Build Date :- Sep 27 2003 | | CMVC level :- p530-05-L030926 | | Build Type :- IKAP - (Production) | | UserID :- 1002 (jlee) | | Program Name :- runmqlsr_nd | | Process :- 1437 | | Thread :- 0003 | | Major Errorcode :- rrcE_COMMUNICATIONS_ERROR | | Minor Errorcode :- OK | | Probe Type :- MSGAMQ9213 | | Probe Severity :- 2 | | Probe Description :- AMQ9213: A communications error for bind occurred. | | FDCSequenceNumber :- 0 | | Arith1 :- 13 d | | Arith2 :- 13 d | | Comment1 :- | | | | Comment2 :- bind | | | | Comment3 :- (/tmp/MQSeries.1437) | | | | | +-+ . . . Consequently, all the other cluster queue managers that are trying to communicate to this manager are failing (the cluster sender channel on these remote queue managers go to a BINDING or RETRYING state). I don't see anything also binding to the port (1414). The listener (not using inetd) process starts fine (it terminates if it can't bind to the specified port, right?). I have tried stopping/restarting. Even tried rebuilding and refreshing cluster info. ... to no avail.
Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors...
I seeing (with intermittent regularity) a bunch of 2009 reson codes in server applications on site here. The applications concerned are server apps (C++, no Java), running on the same box as the queue manager and are using server bindings (linking with libmqm.so), and connect using MQCONN, supplying the queue manager name (there is no default queue manager defined). Additional info: * Solaris 5.8 * MQ 5.2 CSD06 (I know CSD07 is availbale) * Applications linked with libmqm.so * There are no MQ environment variables defined (no MQSERVER). * This host has only two queue managers defined. * The queue manager is a member of a cluster (six qmgrs total). I'm not getting anything obvious in the error logs (neither the global or the queue manager local). Nothing that would indicate a server error prior to the application getting a reason code of 2009. -- tonyB. 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: Building an API exit on Solaris
Thank you. I tried that, and it did indeed generate a binary (smaller than my previous version!), but I still get the same error. Are there any issues with the value of LD_LIBRARY_PATH? tonyB. -Original Message- Sent: Thursday 10/16/2003 12:30:32 PM Subject: Re: Building an API exit on Solaris >Tony, > >Try something like this: > >CC -c -O -mt -KPIC mqAPIExit.cpp -o mqAPIExit.o >CC -G -mt -lmqmzf -lmqm -lmqmcs -lmqmzse mqAPIExit.o -o mqAPIExit.so > >HTH, >Peter > >--- Antony Boggis <[EMAIL PROTECTED]> wrote: >> I am trying to get MQ to run my API exit, written in C++ (it's a hacked >> version of the sample amqsaxe0.c). It works fine under Windows. >> >> I am using the following to build the .so file: >> >> CC -mt mqAPIExit.cpp -G -o mqAPIExit.so -lmqmzf -lmqm -lmqmcs -lmqmzse >> >> and no errors are generated, and the output is generated. >> >> I have added the following to qm.ini: >> >> ApiExitLocal: >>Sequence=100 >>Function=EntryPoint >>Module=/var/mqm/exits/mqAPIExit.so >>Name=mqAPIExit >>Data=16 >> >> But when I try to start the qmgr I get the following: >> >> [EMAIL PROTECTED]:/var/mqm/trace]$ strmqm TEST >> AMQ7214: The module '/var/mqm/exits/mqAPIExit.so' for Api Exit 'mqAPIExit' >> could not be loaded for reason xecU_S_LOAD_FAILED. >> >> I have tried running an early trace, but all the trace files give me is the >> same return code info, so I am suspecting that my build is not good. >> >> Any help/comments appreciated, >> >> Regards, >> >> tonyB. >> >> 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
Building an API exit on Solaris
I am trying to get MQ to run my API exit, written in C++ (it's a hacked version of the sample amqsaxe0.c). It works fine under Windows. I am using the following to build the .so file: CC -mt mqAPIExit.cpp -G -o mqAPIExit.so -lmqmzf -lmqm -lmqmcs -lmqmzse and no errors are generated, and the output is generated. I have added the following to qm.ini: ApiExitLocal: Sequence=100 Function=EntryPoint Module=/var/mqm/exits/mqAPIExit.so Name=mqAPIExit Data=16 But when I try to start the qmgr I get the following: [EMAIL PROTECTED]:/var/mqm/trace]$ strmqm TEST AMQ7214: The module '/var/mqm/exits/mqAPIExit.so' for Api Exit 'mqAPIExit' could not be loaded for reason xecU_S_LOAD_FAILED. I have tried running an early trace, but all the trace files give me is the same return code info, so I am suspecting that my build is not good. Any help/comments appreciated, Regards, tonyB. 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: C# or VB for learning .NET
Peter, My suggestion would be to go the C# route. Going from C# to VB is far easier than the other way. On the plus side also, you'll have a good understanding of the framework that Microsoft is betting most of the farm on. Given your experience with Java, I doubt you'll have any problems migrrating to C#. Both languages have their merits. I also feel that as time progresses MS will attempt to de-emphasise VB and focus more on C#, so it'll certainly (IMNSHO) be a better tool to have "on your toolbelt". Regards, tonyB. -Original Message- Sent: Thursday 10/9/2003 1:50:46 PM Subject: C# or VB for learning .NET >I have the opportunity to take an intro course to either C#.NET or VB.NET. >My goal is to better understand .NET in general, and how MQ plays with it. I >would like to make little GUI apps that use MQ once I am done. This should >help me support our application folks who use .NET and MQ. I have >programmed in COBOL, JAVA and ActionScript (Flash's scripting language). > >Is there any reason to choose one over the other when it comes to VB.NET >versus C#.NET? 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
Installing WMQ 5.2 on Solaris 8
My sysadmin has installed the WMQ package on a Solaris box and has followed the prereqs in the "Getting Started" manual. The kernel params are more than sufficient: [from 'sysdef -i'] * * IPC Messages * 4096 max message size (MSGMAX) 4096 max bytes on queue (MSGMNB) 50 message queue identifiers (MSGMNI) 1024 system message headers (MSGTQL) * * IPC Semaphores * 1424 semaphore identifiers (SEMMNI) 32868 semaphores in system (SEMMNS) 16384 undo structures in system (SEMMNU) 100 max semaphores per id (SEMMSL) 128 max operations per semop call (SEMOPM) 600 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) * * IPC Shared Memory * 4294967295 max shared memory segment size (SHMMAX) 1 min shared memory segment size (SHMMIN) 1124 shared memory identifiers (SHMMNI) 2048 max attached shm segments per process (SHMSEG) * The user (and group) 'mqm' exist and the package was installed with no errors (NOT the DCE option). When running crtmqm, I get the following: The system could not load the module '/opt/mqm/lib/amqzfu' for the installable service 'AuthorizationService' component 'MQSeries.UNIX.auth.service'. The system return code was 536895861. The Queue Manager is continuing without this component. MQSeries queue manager created. Setup completed. AMQ5615: Default objects cannot be created: CompCode = 2 Reason = 2035. As far as I can tell, the config on this machine (in terms of directories, sym-links and file/group ownership) is identical. For completeness, here's the AMQERRO1.LOG: # cat AMQERR01.LOG 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- 10/07/03 04:44:55 PM AMQ6184: An internal MQSeries error has occurred on queue manager TEST. EXPLANATION: An error has been detected, and the MQSeries error recording routine has been called. The failing process is process 23834. ACTION: Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved. --- 10/07/03 04:44:55 PM AMQ5008: An essential MQSeries process 23837 cannot be found and is assumed to be terminated. EXPLANATION: 1) A user has inadvertently terminated the process. 2) The system is low on resources. Some operating systems terminate processes to free resources. If your system is low on resources, it is possible it has terminated the process so that a new process can be created. ACTION: MQSeries will stop all MQSeries processes. Inform your systems administrator. When the problem is rectified MQSeries can be restarted. --- and some of the generated FDC file: # more AMQ23834.0.FDC +-+ | | | MQSeries First Failure Symptom Report | | = | | | | Date/Time :- Tuesday October 07 16:44:55 PDT 2003 | | Host Name :- vdpsusftdf01 (SunOS 5.8) | | PIDS :- 5765B75| | LVLS :- 520| | Product Long Name :- MQSeries for Sun Solaris 2 (Sparc) | | Vendor:- IBM| | Probe Id :- ZX005025 | | Application Name :- MQM| | Component :- zxcProcessChildren | | Build Date:- Dec 11 2002| | CMVC level:- p520-CSD06G| | Build Type:- IKAP - (Production)| | UserID:- 1002 (aboggis)
Tivoli & WMQ on Solaris.
I don't have much choice here at a client site on the monitoring tools (ie, Tivoli) but I have been unable (at this point) to find some answers to basic questions from the searching I have done through the Tivoli docs... I know that Tivoli can watch most of the major attributes I want (q-depth, DLQ, opprocs, ipprocs, channel status, etc)... BUT: I can't find anywhere what the timer granularity is... If I'm pushing 500+ messages per second at MQ, refreshing my stats every minute is not gonna cut it. ALSO: Can I watch enqueue/dequeue rates, or other values that are only available (I think) via PCF (ie through the command server) messages? Thanks for any feedback, tonyB. -- WMQ 5.2 (CSD06) on Solaris 5.8. 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: News
Well, I'm gonna chip in my $0.02 (and then hopefully I'll shut up). I can safely speak from both sides of the fence... I came over (well, actually I was bought over) to the US in late 1990 from the UK, to work on an IBM project for the State Of California. I was interviewed and recruited in England and landed in Sacramento with an H-1 visa in hand. The project was an OS/2-based system. There was a bunch of other Brits also recruited and we were subcontracted to IBM though an agency. I later found out we we're being paid significantly less that the "home grown talent". No surprises there. I am now a fully fledged permanent resident, only a few steps away from US citizenship. Over the recent few years I have had both the good fortune (in most cases) and bad fortune (in a few, rare, cases) to work with others who are now in the situation I was in. Whilst the H-1/H-1B workers are, by and large, intelligent and hard working, almost without exception they are also (and most importantly) - CHEAP. If any executive says anything else (s)he is only telling a small part of the story. The NUMBER ONE reason that high tech execs want to maintain a high visa limit is to have available a larger pool of CHEAP labour. In my opinion, the reduction in the limit of visas will not limit the trend of high tech projects to move "off-shore", but it may make it somewhat less cost-effective and may somewhat slow things down. But, let's face it, businesses exist to MAKE MONEY. They do this by maximising the return on investments. As long as GOOD off-shore workers are available at a reasonable rate of pay, local talent will barely get a look-see. Anyway... enough rambling. Please do not adjust your set... normal transmissions will be resumed shortly. Regards, Antony Boggis. -- What Patrick Duffy *really meant* to say was: >"But Patrick Duffy, Human Resources Attorney for Intel Corporation, >said finding the best-educated, CHEAP, engineering talent from >around the world was critical to his company's future." 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: TRIGGERING PROBLEMS
I totally concur with Neil's comments on the list and the helpful nature of the vast majority of those involved. Thank you too all those who have (and will) helped me out. On a side note... Neil, does this mean as a Brit, living in California, that I miss everything 'cos I'm asleep all the time :-) Regards, tonyB. -Original Message- Sent: Thursday 9/18/2003 9:18:44 PM Subject: Re: TRIGGERING PROBLEMS >Not at all, > >I chose to reply to your original post. No apologies necessary. > >There is a huge body of knowledge around MQSeries, and it is a lot to pick up in one >go. That's why there is an active community who are happy to help newcomers with >genuine issues. It is not obvious that a trigger monitor is going to have trouble >starting a GUI program, at least wasn't to me. I found out about it a few months ago >on the list when someone else had a similar issue. You got an answer from me this >time because I am in the right time zone here in Australia (ZE10) compared to you in >India (about ZE7 or 8?). So the Americans missed your post, and the Brits hadn't got >up yet. > >Regards, > >Neil C. 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
More cluster puzzlement...
I have a cluster with six member queue managers, two full respositories. All on Solaris ( 5.8 ) all running WMQ 5.2, CSD06. I am viewing the queue manager details using MQExplorer running on my Win2000 workstation (no local queue managers). When I add a cluster to the "Clusters" node on the MQExplorer, I specify the cluster name & one of the full repositories. It goes "discovering" and comes back with all but one of the queue managers in the cluster. It does however correctly identify both repositories. I then add the same cluster name again, this time specifying the other repository queue manager. This time ALL six queue managers are "discovered". I've checked the CLUSSDR/CLUSRCVR pairs on the queue managers and I can't see any obvious... QM1R (Repository #1 - which shows only 5 members): CLUSRCVR:TO.QM1R CLUSSDR:TO.QM2R QM1 (which shows up in both cases) has: CLUSRCVR:TO.QM1 CLUSSDR:TO.QM1R QM1C (which shows up in both cases) has: CLUSRCVR:TO.QM1C CLUSSDR:TO.QM1R QM2R (Repository #2 - which shows all 6 members): CLUSRCVR:TO.QM2R CLUSSDR:TO.QM1R QM2 (which only show up in one) has: CLUSRCVR:TO.QM2 CLUSSDR:TO.QM2R QM2C (which shows up in both cases) has: CLUSRCVR:TO.QM2C CLUSSDR:TO.QM2R So, of cource I check the queue manager logs (/var/mqm/qmgrs//errors and the same error shows in both logs: 09/16/03 02:01:19 PM AMQ9418: Only one repository for cluster CLUSTER2B. EXPLANATION: The queue manager has received information about a cluster for which it is the only repository. ACTION: Alter the REPOS or REPOSNL attribute of the queue manager, that is to have the second full repository for the cluster, to specify the cluster name. So, I hop over to 'runmqsc' on QM1R: DIS QMGR ALL 1 : DIS QMGR ALL AMQ8408: Display Queue Manager details. DESCR( )DEADQ(SYSTEM.DEAD.LETTER.QUEUE) DEFXMITQ( ) CHADEXIT( ) CLWLEXIT(...) CLWLDATA( ) REPOS(CLUSTER2B) The I do the same on QM2R: DIS QMGR ALL 1 : DIS QMGR ALL AMQ8408: Display Queue Manager details. DESCR( )DEADQ(SYSTEM.DEAD.LETTER.QUEUE) DEFXMITQ( ) CHADEXIT( ) CLWLEXIT(...) CLWLDATA( ) REPOS(CLUSTER2B) I issue a REFRESH CLUSTER command and both report that they successfully refreshed information... When I right click and view properties in the MQExplorer, both repositories show that they are members of the same cluster and that they are both full repositories. Any suggestions? tonyB. 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
Cluster puzzlement...
I have a cluster with six member queue managers, two full respositories. All on Solaris (5.8) all running WMQ 5.2, CSD06. I am viewing the queue manager details using MQExplorer running on my Win2000 workstation (no local queue managers). When I add a cluster to the "Clusters" node on the MQExplorer, I specify the cluster name & one of the full repositories. It goes "discovering" and comes back with all but one of the queue managers in the cluster. It does however correctly identify both repositories. I then add the same cluster name again, this time specifying the other repository queue manager. This time ALL six queue managers are "discovered". Any suggestions? tonyB. 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: 2058 errors when correctly specifying qmgr name...
I think, after further troubleshooting, what I have here is a local network issue.
After your comment on using amqsput (and it working) and Paul's reminder that Solaris
is case sensitive ('TCP' is ok, 'tcp' is not) I retried using ampsputc and was able to
put messages (as a client) to all the queue managers in my cluster.
So, I retried the same from my Windows workstation. No joy, still get 2058 errors,
regardless of 'tcp or 'TCP' in the MQSERVER environment. As Paul says, it shouldn't
matter on Windows, since it's case-insensitive.
So, I tried the Websphere MQ Explorer MMC and I can now connect to all the qmgrs in my
cluster. Going back to a fresh command prompt... everything now works.
Looks like I'll be having a conversation with our networking guys...
Thanks for all your pointers.
tonyB.
-Original Message-
Sent: Friday 9/12/2003 10:36:44 AM
Subject: Re: 2058 errors when correctly specifying qmgr name...
>Good call.
>
>amqsput works.
>
>However, it doesn't quite explain why my clients can't connect...
>
>tonyB.
>-Original Message-
>
>>Try amqsput. amqsputc is for client connections.
>>
>>-Original Message-
>>From: Antony Boggis [mailto:[EMAIL PROTECTED]
>>Sent: Friday, September 12, 2003 1:06 PM
>>To: [EMAIL PROTECTED]
>>Subject:
>>
>>
>>I am at a loss to explain the following... (Solaris 5.8, WMQ 5.2 CSD06):
>>
>>$ dspmq
>>QMNAME(CLUSTER2B.AR1.MANAGER) STATUS(Running)
>>.
>>.
>>$ export MQSERVER=SYSTEM.ADMIN.SVRCONN/tcp/127.0.0.1\(1414\)
>>$ /opt/mqm/samp/bin/amqsputc SYSTEM.DEFAULT.LOCAL.QUEUE CLUSTER2B.AR1.MANAGER
>>Sample AMQSPUT0 start
>>MQCONN ended with reason code 2058
>>$
>>
>>
>>I also tried the same from a Windows client and get the same error.
>>I also tried using SYSTEM.DEF.SVRCONN - same error. I am having the same problem on
>>all my queue managers.
>>
>>The only errors I have in my logs are cluster channel errors: 'AMQ9558: Remote
>>Channel is not currently available.'.
>>
>>I am reluncant to simply restart the queue managers, but I'm at a loss to explain.
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: 2058 errors when correctly specifying qmgr name...
Good call. amqsput works. However, it doesn't quite explain why my clients can't connect... tonyB. -Original Message- >Try amqsput. amqsputc is for client connections. > >-Original Message- >From: Antony Boggis [mailto:[EMAIL PROTECTED] >Sent: Friday, September 12, 2003 1:06 PM >To: [EMAIL PROTECTED] >Subject: > > >I am at a loss to explain the following... (Solaris 5.8, WMQ 5.2 CSD06): > >$ dspmq >QMNAME(CLUSTER2B.AR1.MANAGER) STATUS(Running) >. >. >$ export MQSERVER=SYSTEM.ADMIN.SVRCONN/tcp/127.0.0.1\(1414\) >$ /opt/mqm/samp/bin/amqsputc SYSTEM.DEFAULT.LOCAL.QUEUE CLUSTER2B.AR1.MANAGER >Sample AMQSPUT0 start >MQCONN ended with reason code 2058 >$ > > >I also tried the same from a Windows client and get the same error. >I also tried using SYSTEM.DEF.SVRCONN - same error. I am having the same problem on >all my queue managers. > >The only errors I have in my logs are cluster channel errors: 'AMQ9558: Remote >Channel is not currently available.'. > >I am reluncant to simply restart the queue managers, but I'm at a loss to explain. 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
[no subject]
I am at a loss to explain the following... (Solaris 5.8, WMQ 5.2 CSD06): $ dspmq QMNAME(CLUSTER2B.AR1.MANAGER) STATUS(Running) . . $ export MQSERVER=SYSTEM.ADMIN.SVRCONN/tcp/127.0.0.1\(1414\) $ /opt/mqm/samp/bin/amqsputc SYSTEM.DEFAULT.LOCAL.QUEUE CLUSTER2B.AR1.MANAGER Sample AMQSPUT0 start MQCONN ended with reason code 2058 $ I also tried the same from a Windows client and get the same error. I also tried using SYSTEM.DEF.SVRCONN - same error. I am having the same problem on all my queue managers. The only errors I have in my logs are cluster channel errors: 'AMQ9558: Remote Channel is not currently available.'. I am reluncant to simply restart the queue managers, but I'm at a loss to explain. tonyB. 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
saveqmgr (SupportPac: MS03) doesn't dump all attributes...
It seems that the version of saveqmgr that I have does not dump all qmgr attributes... Notably from the QMGR attributes the following are missing: COMMANDQ CCSID MAXPTRY DISTL This was running on Solaris 5.8, WMQ 5.2 (CSD05). Is this an intentional ommision or a "bug" ? -- tonyB. 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: Large number of QMgrs on a Solaris box...
> The short summary is that SEMUME and/or SEMMNU need increasing. Dan, thanks v. much. Further question however... I currently have SEMUME (semsys:seminfo_semume) set to 2048 (the default from the MQ docs is 256) and I have SEMMNU (semsys:seminfo_semmnu) set to 32768 (the mq default is 2048). As can be seen, these value are WAY above the recommended defaults. Given my errors, should I still be going higher, or should I look elsewhere? Regards, tonyB. 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: Large number of QMgrs on a Solaris box...
Dan,
Thanks for the pointers... I'm pretty certain it's just a case of nailing down the
correct kernel parameters.
However, I couldn't get to your doc because the site requires cookies enabled, which
our local security policy prevents. Could you email the doc directly to me?
Thanks,
tonyB.
-Original Message-
Sent: Monday 9/8/2003 2:23:24 PM
Subject: Re: Large number of QMgrs on a Solaris box...
>Antony,
>
>Here is some info that I put on the BMC support web site at
>http://service.bmc.com/bmc_mq/kb/view_article/0,,4960%2B4977%2B4990%2B4991%2
>B10423,00.html
>
>Overview
>
>FDCs are found in /var/mqm/errors. Also the error logs are there.
>AMQERR01.LOG is the current error log. The FDC filenames look like this:
>AMQ10450.0.FDC. Where 10450 is the pid of the process throwing the FDC.
>This resolution describes when tuning is needed due to a lack of semaphore
>undo structures. The FDCs will have these characteristics:
>
>Probe Id: XY324192
>Probe Description :- AMQ6119: An internal MQSeries error has occurred ('22
>| - Invalid argument' from semop.)
>
>This problem is seen most frequently with Solaris. It is not common with
>HP-UX and I have never seen the problem with AIX.
>
>Solution
>
>Recommendation:
>1. For Solaris, increase the value of SEMUME and SEMMNU in /etc/system and
>boot.
>
>2. Make sure you do not delete (ipcrm) MQSeries semaphores while MQSeries is
>running. This is not likely to be the problem but I have seen it.
>==
>DETAILS:
>The following are details on how to come to the conclusion above.
>At a Solaris computer type:
>
>man semop
>
>And see:
>
> EINVALThe semid argument is not a valid semaphore iden-
> tifier, or the number of individual semaphores for
> which the calling process requests a SEM_UNDO
> would exceed the limit.
>
>The EINVAL is E = error and INVAL = INVALID.
>
>So the FDC is saying that the semop call returned EINVAL. Looks like the
>number of SEM_UNDOs being requested is too large for the current kernel.
>Looks like you need to increase the number of SEM_UNDOs allowed.
>
>Looking at
>http://www.sun.com/sun-on-net/itworld/UIR960101perf.html we see that the
>kernel parm to increase is semsys:seminfo_semume. The kernel parms can be
>increased by changing /etc/system and then booting. How much should you
>increase it? I usually double it until I get to 4096 and then increase by
>smaller amounts.
>
>In the past I have seen increasing increasing just SEMUME helped with the
>EINVAL problem. But, to be safe you may wish to increase both SEMUME and
>SEMMNU.
>
>I usually double the values to start with. It is difficult to come up with
>exact recommendations. However, here is some info that will help. See
>http://www-3.ibm.com/software/ts/mqseries/txppacs/supportpacs/mp00.pdf
>Page 60 of 71. Here is the quote:
>"SEMMNU , semaphore undo's was increased from 256 to 2048. Without this
>only approx 90 clients could be MQCONNected."
>So based on that I would say that in addition to SEMUME (number of semaphore
>undos per process), also we have SEMNU (total number of undos in the
>system). It sounds like SEMMNU=256 handles approximately 90 MQCONNs. You
>could extrapolate from there.
>
>ANOTHER POSSIBILITY: Notice that the error explanation for EINVAL includes
>two possibilities. This article describes how to fix one possible problem.
>The other possibility is that the semaphore identifier being used by
>MQSeries is invalid. This probably means that something or someone has
>deleted the semaphore. Please examine for this, are there any jobs that use
>ipcrm to delete, to clean up, semaphores? It is ok to delete semaphores
>that are not MQSeries semaphores or to cleanup MQSeries semaphores while
>MQSeries is down. But if you delete (ipcrm) semaphores while MQSeries is
>running this error will occur.
>
>Dan Egner
>IBM WebSphere MQ V5.3 System Administration Certified
>Product Support
>BMC Software, Inc
>
>-Original Message-
>From: Antony Boggis [mailto:[EMAIL PROTECTED]
>Sent: Monday, September 08, 2003 2:02 PM
>To: [EMAIL PROTECTED]
>Subject: Large number of QMgrs on a Solaris box...
>
>
>I am in the midst of troubleshooting an issue where I am getting huge
>numbers of FDC files generated on one of our development Solaris machines.
>Some of these FDC files are are REALLY large too.
>
>The machine in question is an 8 CPU box with 32GB RAM.
>
>There are currently 70+ queue managers *DEFINED* on the box, many in a
>"local" cluster (ie the CLUSTER of queue managers is all on the same box -
>this is a DEVELOPMENT machine... in the real world the
Large number of QMgrs on a Solaris box...
I am in the midst of troubleshooting an issue where I am getting huge numbers of FDC
files generated on one of our development Solaris machines. Some of these FDC files
are are REALLY large too.
The machine in question is an 8 CPU box with 32GB RAM.
There are currently 70+ queue managers *DEFINED* on the box, many in a "local" cluster
(ie the CLUSTER of queue managers is all on the same box - this is a DEVELOPMENT
machine... in the real world the cluster members would be on different physical
machines).
At the moment I am showing 27 active queue managers.
The kernel parameters have been updated to the followiung values:
set shmsys:shminfo_shmmax = 4294967295
set shmsys:shminfo_shmseg = 2048
set shmsys:shminfo_shmmni = 2048
set semsys:seminfo_semaem = 16384
set semsys:seminfo_semmni = 1024
set semsys:seminfo_semmap = 1026
set semsys:seminfo_semmns = 16384
set semsys:seminfo_semmsl = 1
set semsys:seminfo_semopm = 100
set semsys:seminfo_semmnu = 2048
set semsys:seminfo_semume = 256
set msgsys:msginfo_msgmap = 1026
set msgsys:msginfo_msgmax = 4096
In addition to the FDC files in /var/mqm/errors, the AMQERROR0x files are also filled
with:
AMQ6119: An internal MQSeries error has occurred ('22 - Invalid argument' from semop.)
If anyone can shed some more light on the problem, I'd apreciate it. I am in the
process of reviewing the solaris kernel params to see if that (likely) is the root of
the problem.
Regards,
tonyB.
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
Solaris version of SupportPac MS03
Does anyone have available the Solaris version of the latest (or recent) version of SupportPac ms03? Could someone e-m me a copy. The compiler is not installed on any system I currently have access to, so I can't build it myself. Thanks, tonyB. 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
WMQ & Microsoft Terminal Services...
Title: WMQ & Microsoft Terminal Services... Can anyone tell me what the minimum requirement is for running WMQ and using MS Terminal Services to admin the box remotely? I have WMQ 5.2 CSD06 (and will be upgrading to WMQ 5.3 CSD04 hopefully soon) running on Windows 2000 Server, Service Pack 4 (AFAIK). I know that there are/were issues with Terminal Services and WMQ 5.2 prior to CSD06… does CSD06 fix most of the issues? TIA, Antony Boggis.
Re: Security and user IDs
Nope. There really are queues there. All the expected SYSTEM.* objects are there. The Pub/Sub broker is running and I can at least *view* the queues (using MQJExplorer) remotely. I'll try to run some other tests locally later (I can't access the machine until after the prod "operating window" is "closed"). I did not have time to try any "runmqsc" commands y'day. Oh, you're right on the user id it is MUSR_MQADMIN. I mis-spelt it. Regards, tonyB. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2003 5:00 AM To: [EMAIL PROTECTED] Subject: Re: Security and user IDs Maybe there are really no queues there. Did you try and create one? What if you go to the command line and use runmqsc commands to display and create queues? Do you get errors? (Not 100% sure on the below. May have nothing to do with it.) Also, your user should be MUSR_MQADMIN, not MUSR_ADMIN. It least that is the ucer name spelling on all my WIN2000 boxes. -Original Message- From: Tony Boggis [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2003 12:33 AM To: [EMAIL PROTECTED] Subject: Security and user IDs I have a scenario on a single WMQ 5.2 (CSD06) server running on Win2K that I've not come across before. The server has a single QM, the default. The QM runs fine and I can connect, send & receive messages. The mqm group is defined, with a single user MUSR_ADMIN. Logged on as Administrator (local), I do not seem to have authority to do any MQ operations. Althought I can start/stop the QM and see the status of the Command Server, etc from the Services MMC, the MQExplorer MMC is blank (even if I ensure "display system objects" is selected). So I added Administrator to the mqm group (it wasn't there before) and restarted the service. Still not authorized, even though as Administrator on a Windows system (according to the docs) I should be able to administer any local queue manager. Do I need to run "setmqaut" giving "Administrator" all necessary rights? I'll run away and try to find the solution myself, but if anyone can point me directly to the appropriate section (System Admin Guide:Websphere MQ Security), I'd appreciate it. tonyB. 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 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: Support for API exits?
Title: Message Ok, after much gnashing of teeth and pulling of hair I have the API exit working on WMQ 5.2 (CSD06). There seems to be some issues if the queue manager whch the exit is to be used is set to auto start under Windows. I haven't fully investigated at this point. Setting the queue manager to manual start and then issueing the strmqm/strmqcsv works fine, then using the Services MMC to start the listener so that is properly runs in the background. I found that for my purposes caputuring the MQPUT BEFORE and the MQGET AFTER, gives me all the data in and out of the server. I also modified the sample exit to only shown where Environment == MQXE_MCA_SVRCONN so that I only get data coming from clients across the server-connection channel. Thanks to David for the pointers. Tony Boggis. (Newly) IBM Certified Solution Developer -- WebSphere MQ V5.3 -Original Message-From: David C. Partridge [mailto:] Sent: Friday, July 25, 2003 1:15 AMTo: [EMAIL PROTECTED]Subject: Re: Support for API exits? Tony, The following are the minimum levels of MQ at which IBM will support the API crossing exit: Solaris MQ 5.2 CSD03 Windows NT etc, AIX, HP_UX, Linux, OS/400 etc WebSphere MQ 5.3 It was actually shipped (as against supported) on most (if not all) the distributed platforms at MQ 5.2 CSD03. Dave -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Antony BoggisSent: 24 July 2003 23:25To: [EMAIL PROTECTED]Subject: Support for API exits? What is the minimum level of MQ for API exit support. Specifically under Win2000. I have WMQ 5.2, CSD06. The sample API exit is there, but the amqmdain admin application and the MMC Services snap-in don't have the necessary support. Any pointers? tonyB.
Support for API exits?
Title: Support for API exits? What is the minimum level of MQ for API exit support. Specifically under Win2000. I have WMQ 5.2, CSD06. The sample API exit is there, but the amqmdain admin application and the MMC Services snap-in don't have the necessary support. Any pointers? tonyB.
Re: Channel Exit & Structure def...
Well, the API exit stuff looks good, but doesn't seem to be supported under 5.2. I'm still on 5.2 (CSD06) here and the Windows MMC snap-in and the amqmdain command don't support adding the appropriate registry entries. tonyB. -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 1:25 AM To: [EMAIL PROTECTED] Subject: Re: Channel Exit & Structure def... I'm pretty sure that the API crossing exit *will* do it for you, as regardless of the language the client is written in, by the time the MQ call is issued at the server, it is all one ... For you clients, you should be interested in MQXE_MCA_SVRCONN type invocations. Why not try to use the sample API xing which will trace all the MQ calls - you'll rapidly see what it captures, and will be able to determine whether it's worth going on to do your own. 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: Channel Exit & Structure def...
I'll give it a try and see what happens. Thanks for the pointers. After posting my initial view of the TSH struct I actually realised I was wrong... But it does seem to be 44 bytes in length and depending on whether it's a RECV message or a SEND message, it can be followed by various known (and unknown) MQ structs, such as MQOD & MQMD. During exit initialisation there's also security info passed (I see my userid). I'll try the API exit, but I'll come back to this as it's an interesting challenge. tonyB. -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 1:25 AM To: [EMAIL PROTECTED] Subject: Re: Channel Exit & Structure def... I'm pretty sure that the API crossing exit *will* do it for you, as regardless of the language the client is written in, by the time the MQ call is issued at the server, it is all one ... For you clients, you should be interested in MQXE_MCA_SVRCONN type invocations. Why not try to use the sample API xing which will trace all the MQ calls - you'll rapidly see what it captures, and will be able to determine whether it's worth going on to do your own. 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: Channel Exit & Structure def...
As you say... Reverse engineering is the order of the day...
Here's what I have so far:
struct tagMQTSH{
MQCHAR4StrucId;// Structure identifier "TSH "
unsigned short usSendLen ; // Only set if MQCXP.ExitId ==
MQXT_CHANNEL_SEND_EXIT
unsigned short usRecvLen ; // Only set if MQCXP.ExitId ==
MQXT_CHANNEL_RCV_EXIT
MQCHAR Version ; // Always "0x02".
MQCHAR TSHData[1] ;// Variable length data ((usSendLen
+ usRecvLen) - 9)
} ;
I don't think an API crossing exit will do it for me (but I'll look more
into it) since my client apps are all Java/JMS based, and we are using
Pub/Sub. What I am trying to achieve is some sort of server side logging
that I can use in the development environment so show when publish
messages come in and when they go out to subscribers.
And so, for anyone out there who is interested in my reverse engineering
results, here's a little more:
Here's the sequence of events for a single message send/recv exit
installed for a SVRCONN channel. The same exit is used for the send and
receive. This is WinNT 2000, Service Pack 4, WMQ 5.2, CSD06.
In this test case , I used AMQSPUTC to put the string "" to the queue TEST, on remote queue manager EOC1.TEST.
01. Message Exit Initialised [MQXT_CHANNEL_SEND_EXIT].
02. Message Exit Initialised [MQXT_CHANNEL_RCV_EXIT].
03. Message Written to log [160 (0x00a0) bytes] [MQXT_CHANNEL_RCV_EXIT].
04. Message Written to log [164 (0x00a4) bytes] [MQXT_CHANNEL_RCV_EXIT].
05. Message Written to log [44 (0x002c) bytes] [MQXT_CHANNEL_SEND_EXIT].
06. Message Written to log [216 (0x00d8) bytes] [MQXT_CHANNEL_RCV_EXIT].
07. Message Written to log [216 (0x00d8) bytes]
[MQXT_CHANNEL_SEND_EXIT].
08. Message Written to log [517 (0x0205) bytes] [MQXT_CHANNEL_RCV_EXIT].
09. Message Written to log [500 (0x01f4) bytes]
[MQXT_CHANNEL_SEND_EXIT].
10. Message Written to log [48 (0x0030) bytes] [MQXT_CHANNEL_RCV_EXIT].
11. Message Written to log [44 (0x002c) bytes] [MQXT_CHANNEL_SEND_EXIT].
12. Message Written to log [44 (0x002c) bytes] [MQXT_CHANNEL_RCV_EXIT].
13. Message Written to log [44 (0x002c) bytes] [MQXT_CHANNEL_SEND_EXIT].
14. Message Written to log [28 (0x001c) bytes] [MQXT_CHANNEL_RCV_EXIT].
15. Message Exit Terminated [MQXT_CHANNEL_SEND_EXIT].
16. Message Exit Terminated [MQXT_CHANNEL_RCV_EXIT].
For 01, 02, 15 & 16 the value in (*pDataLength) is 0.
03: First call with data. Seems to contain security info. My local user
ID is in this buffer twice (all uppercase and all lowercase).
04: Contains the put application name.
05: Unknown.
06: Looks like this has some data regarding the destination queue.
07: Almost a duplicate of the previous, except this is for a
MQXT_CHANNEL_SEND_EXIT.
08: The message (MQMD) is here. After the "TSH " header is the message I
entered, and it's format "MQSTR ". The MDMD is mostly blank.
09: The MQMD is sent back, but more fields populated, such as MsgId,
CorrelId, UserIdentifier, PutApplName, PutDate, PutTime...
10-13: More exchanges of TSH structs.
That's what I have so far. Anyone else care to chime in?
tonyB.
-Original Message-
From: David C. Partridge [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2003 1:45 AM
To: [EMAIL PROTECTED]
Subject: Re: Channel Exit & Structure def...
Welcome the FAQNRA (Frequently Asked Questions Never Really Answered)
section of the list!
The TSH is (for some reason) a control block that IBM consider to be
confidential and something they don't want us to know about. There is
certain information about its contents (in particular byte 10) in the
Intercommunication manual Part 7, in the section entitled "Channel send
and receive exit programs".
More than that I fear is not for us mortals to know (except by reverse
engineering).
Rather than climbing in at the send and receive exit on the SVRCONN
channel, why not use the MQ API crossing exit, as this will readily
allow you to do
what you want (I think). It is there on Windows on MQ 5.2 at anything
above CSD03 level, but just not supported. To enable it on 5.2, you'll
need to do a little registry hacking, but if you have a 5.3 system
you'll easily see what needs to be set up.
HTH
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
Channel Exit & Structure def...
Title: Channel Exit & Structure def... Env: Windows 2000, SP4, WMQ 5.2, CSD06. I am in the process of writing a channel exit (for a SVRCONN channel in this case) in order to log some data to/from the server. I'm only interested in the case where pChannelExitParams->ExitId == MQXT_CHANNEL_SEND_EXIT or pChannelExitParams->ExitId == MQXT_CHANNEL_RECV_EXIT. I have defined my SVRCONN channel, with only the Send/Receive exits defined, and exit data blank. I notice from looking at the data that there is, what seems to be, a number of bytes of data preceding the actual data that I'm interested in. All I really want is message traffic (ie something that has as associated MQMD). This is what is pointed to by the "AgentBuffer" parameter in the channel exit. The struct (pointed to by AgentBuffer) begins with "TSH ". Now for a mystery… the format of the data following the "TSH " seems inconsistent (I'm only interested in pChannelExitParams->ExitReason == MQXR_XMIT): [in hex] 54 53 48 20 00 00 00 A0 …"TSH " (160) 54 53 48 20 00 00 00 A4 …"TSH " (164) 54 53 48 20 2C 00 00 00 …"TSH " (44?) 54 53 48 20 00 00 00 D8 …"TSH " (216) 54 53 48 20 00 00 00 D8 …"TSH " (216) 54 53 48 20 00 00 02 00 …"TSH " 512 - This is where the MQMD finally shows for the single message I put. Since with intel byte-swapping, 2C 00 00 00 == 44, A4 00 00 00 == 160, and 00 00 00 A4 == 2751463424, so I am puzzled by the third "TSH " message. What's interesting (to me) is that the information that you would normally expect to be able to get/set in the message header is not there in one single TSH structure, but is spread over several. The data that I put in a message (using AMQSPUTC) doesn't appear until the sixth call of my channel exit. And, in that call, none of the normal fields of the MQMD are initialized… about the only one that is, is the format field (MQSTR). I can understand some of this since some information, such as MsgId, CorrelId, Put Date, etc, may not be known until after the message is put, so the SVRCONN channel (in this case) needs to send data back to the client with those MQMD fields populated. Is the sequence of calls to a send/receive exit better documented than in the Intercommunications manual? Is the "TSH " struct defined anywhere? Any comments/help appreciated. Regards, tonyB.
Re: DLL Help
This description, whilst a little informative, is really not gonna help us. I don't know of too many psychic developers out here. Now if could provide more detail, like how does the COM object connect to the UNIX platform. DLL on UNIX? No such thing. There are however, shared libraries, similar to DLLs. Regards, tonyB. -Original Message- From: Young.John [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 8:16 AM To: [EMAIL PROTECTED] Subject: DLL Help We have a bad situation here. VB applications are going thru a com object to access a DLL written in C++ on the unix side. The problem is that none of the connections are being released. So each time a VB app starts, it creates another connection until our max handle connection has reached it max. I am a mainframe person, and this is pretty much how the problem was explained to me. Does anyone have any suggesions? The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. 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: Spiraling downhill
It's not a reasonable rate anywhere I'm aware of... (in the US that is). tonyB. -Original Message- From: Brian S. Crabtree [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 1:01 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill Philip $25-30 is reasonable for an MQ Admin Current market rates are $30 MQ Admin $35 MQ Developer $40 WMQI/MQWF $45-50 MQ and WMQI and MQWF and WAS Project Leader/Architect There are companies that will pay more but if a contract gets out to the agencies then the rates drop especially when you are not dealing with the prime agent Brian S. Crabtree EAI Consultant - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 17, 2003 3:14 PM Subject: Re: Spiraling downhill > I believe we're missing the point here. This issues isn't $25-35 offered > rate, but if any MQer would work for that rate. The advertisement > could simply be a trial balloon. > > > > > > "Potkay, Peter M > (PLC, IT)" To: [EMAIL PROTECTED] > <[EMAIL PROTECTED]cc: > RTFORD.COM>Subject: Re: Spiraling downhill > Sent by: MQSeries > List > <[EMAIL PROTECTED] > AC.AT> > > > 06/17/2003 09:35 AM > Please respond to > MQSeries List > > > > > > > Hicksville??? > > maybe a hick MQ specialist is only worth 25-30 per hr... > > > -Original Message- > From: Williams, Dave (Systems Management) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 8:42 AM > To: [EMAIL PROTECTED] > Subject: Re: Spiraling downhill > > > Wow this isn't good. > > -Original Message- > From: Robert Broderick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 7:59 AM > To: [EMAIL PROTECTED] > Subject: Spiraling downhill > > This is not a technical issue so take a back seat if you want to > complain > > WOW. Look at this. Notice the rate > > SKILLS REQUIRED: MQ Series, Unix, mainframe > LOCATION: Hicksville, NY > RATE: $25-30/hr > AREA: 516 > LENGTH: 12 months > TERM: CON_IND CON_CORP > SUMMARY: X Xx has an immediate opening for a Software > Support Specialist. Candidate should be able work as a MQ Series > administrator and > support various MQ series messaging infrastructure related projects. > Candidate must be familiar with MQSeries V5.2 and... > > You know there is a vagrant who hangs out in fromnt of Grand Central > Station. They did and article on him a few years back in the NY Times. > He supposedly make about 100+ K a year pan handeling. I think after my > current > contract ends I'm going to the hardware store to get a tin cup and > increase > my revenue why decreasing my exposure to STRESS!! We need to start a > UNION!!! > > > bee-oh-dubble-bee-dubble-egh > > _ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > 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 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 > > > > > > 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 Gener
Problems with JMS Pub/Sub?
So, we're usung the JMS classes to do Pub/Sub. In our .class file we create the TopicSubscriber, which is successful. We then periodically do a subscriber.receive(100) in a loop. Now, whilst I realize that polling like this is probably not the best, what we are seeing is the local system time drift, by a noticable amount. If we change the code to do subscriber.receiveNoWait(), and "sleep" internally, we see no clock drift. Has anyone else seen this? Using WMQ 5.2. tonyB. 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
WMQ Event Log entry...
Title: WMQ Event Log entry... I've been getting a bunch of AMQ9228 errors this morning on one of my WMQ servers (running on Win2000, WMQ 5.2, CSD06). --- The TCP/IP responder program could not be started. An attempt was made to start an instance of the responder program, but the program was rejected. The failure could be because either the subsystem has not been started (in this case you should start the subsystem), or there are too many programs waiting (in this case you should try to start the responder program later). The reason code was 0. --- Before & after the occurences of this message in the application event log, I had a bunch of the old 10054 (WSAECONNRESET) errors from various client IP addresses. Could they be related? Also interesting to note is that the text of AMQ9228 specifies 5 substitutions in the message, but #5 (the sub point between "the" and "reason" in the last sentence) is empty. Any feedback welcomed, tonyB.
Re: MQ v5.3
Based on my experience, don't' install CSD03 on WMQ5.3 if you're running on Windows Server 2003. Although I haven't had a chance to do any exhaustive research, I had a working WMQ5.3 install on an evaluation copy of Win2003 Enterprise Server. I then applied CSD03 (& the additional APAR, IYxxx). Now, I can't do diddly. The MQExplorer MMC snap-in barfs and queue managers are unresponsive. I may just go back to running on Win2000. tonyB. -Original Message- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 12:58 AM To: [EMAIL PROTECTED] Subject: Re: MQ v5.3 Make sure you are running with CSD3 and apar IY43610 included. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] Sony Varghese <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ILEVER.COM> cc: Sent by: MQSeriesSubject: MQ v5.3 List <[EMAIL PROTECTED] N.AC.AT> 04/06/2003 14:26 Please respond to MQSeries List Hi everyone, Are there any known issues with MQSeries v5.3? Would like your inputs on this ... Thanks. Sony 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: IPProcs and OPProcs
If your are not consuming these event messages (no event monitoring, or third party monitoring tools), make sure that queue manager events are turned off(Authority/Inhibit/Local/Remote/Start-Stop/Performance/ChannelAutoDef ). Also check for queue events (MaxDepth/High/Low/SvcInt). tonyB. -Original Message- From: Conklin, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: IPProcs and OPProcs Hi All, Is there a way to determine which MQSeries object has a queue/channel open for input (IPPROCS) or output (OPPROCS)? These attributes changes of course as the Qmgr operates. I'm using MQSeries 5.3 on 390, Windows and Solaris. Second question, our SYSTEM.ADMIN.QMGR.EVENT is filling up very fast, in fact we had to clear it out before it filled up the page set. We just moved to 5.3 from 2.1 and we didn't experience this before. Do you know what events the Qmgr is Putting to this queue? I haven't been able to find any detail information about the behavior of this queue. Thanks a MILLION in advance. Bill C. 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
WMQ 5.3 & SupportPac MC74
Title: WMQ 5.3 & SupportPac MC74 Does anyone have any knowledge regarding the two items? Does WMQ 5.3 (CSD03) on Win2000 Server work with Microsoft Cluster Server & the latest incantation of MC74? Appreciate any feedback, tonyB.
.NET Question.
Title: .NET Question. Has anyone done any/much testing with the MA7P [WebSphere MQ classes for Microsoft .NET] SupportPac? I have been trying to connect to my qmgr using the version of MQQueueManager that takes both a channel name and connection name (as in MQCONNX), but to no avail. I keep getting an MQException thrown: 2277 (MQRC_CD_ERROR). To make sure I was using the right values, I used the C sample prog: amqscnxc and I successfully connect. Is the original author out there? I tried another MQSeries .NET implementation (from Neil Kolban, http://www.kolban.com/mq/DotNET/), but the MQCONNX-type functionality isn't there either. Any help appreciated. Regards, Antony Boggis.
Missing file...
Title: Missing file... I am tinkering with some .NET code and was looking at SupportPac MA7P. However, while testing out some other stuff, I uninstalled the package. Now I can't seem to re-install it. If I can get a copy of the actuall assembly file: amqmdnet.dll, then I can manually "register" it. Can anyone help? tonyB.
