Re: Triggering across New Cluster not working
Howdy, I have set the system type to windows... I am just blowing away the queue defs and testing it clean to see hwat happens. Something very odd gowing on! Sid -Original Message- From: Tony Devitt [mailto:[EMAIL PROTECTED] Sent: Friday, 7 November 2003 3:00 PM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working ** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : It is a while since I did something similar but is it possible that the NT Trigger Monitor does not like the APPL_TYPE in the TMCwhat does Linux put in there? Have you tried running the TM in the foreground to see what is displayed when the the message hits the INIT queue? : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses and cleared by MailMarshal. : 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: Triggering across New Cluster not working
** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : It is a while since I did something similar but is it possible that the NT Trigger Monitor does not like the APPL_TYPE in the TMCwhat does Linux put in there? Have you tried running the TM in the foreground to see what is displayed when the the message hits the INIT queue? : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses and cleared by MailMarshal. : 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 across New Cluster not working
Yep got that, let me state the problem again. First, all queues are part of the cluster and both machines are in the cluster. The program to run is on the NT box and so is the trigger monitor and initiation queue. The target queue with triggering turned on is on the Linux box. I can put and get data to the queue on the linux box via a server channel to the NT box, with the cluster transfering the data, so my client see's one big machine, I have also tried this with a third machine and it works quite well exactly as stated in the doco "Queue Manager Clusters" This is what I am expecting. When data arives into the queue on the linux box the server finds triggering on and puts a trigger message into the initiation queue (which just happens to be on the NT box), and the process definition is locally defined so that gets copied into the MQTMC message. The trigger monitor on the NT box which is monitoring the queue then runs the process. Correct me if I am wrong and tell me exactly why and where in the book (page number please). Sid -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Friday, 7 November 2003 1:36 PM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working Hi Sid, it sounds like you may have missed the point of MQ clustering. A cluster queue is just a local queue with an alternative method of having messages arrive on the queue. Messages on a cluster queue (as is the case for non-cluster queues) can only be retreived (MQGET) by processes on that system (either local server bindings applications, or the channel agent for a client program). If your message is located on the Linux system in the cluster queue, you have to have the trigger monitor and the application program also running on the Linux system. The only ways to avoid this would be to run both the trigger monitor and the applicatoin program as client applications on the Windows system. MQSeries is quite different to some other queueing products in this way. Messages on a cluster queue are NOT visible or available to other queue managers. A cluster queue is a valid destination from any queue manager in the cluster, but the message will only be available on the system where the message is sent. The actual destination will be chosen by MQSeries or a cluster workload balancing exit. Regards, Neil Casey. |-+> | | [EMAIL PROTECTED]| | | .AU | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 07/11/2003 12:26 | | | Please respond to| | | MQSeries List| | || |-+> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Triggering across New Cluster not working | >--- ---| Howdy all, I have just put together a new cluster between two machine (NT4 and Linux) The process to run is on the NT machine as well as the trigger monitor and the initiation queue that it monitors. I have place a copy of the process definition on both machine and the queue with triggering turned on is located on the linux box. All queues have the cluster defined. I can see the required queues in the cluster using display qc(*) but when I put stuff into that queue (on the linux box) the triggering does not appear to work. I have 600 other queues still on the NT box which are triggering fine Any Ideas...Please Sid Young Brisbane Australia 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: Triggering across New Cluster not working
Title: Message Gary, Not likely, as the process is a windows win32 "exe" and the initiation queue (on the NT box) is part of the cluster, I would have thought that the Linux MQ server would place the trigger message into the queue on the NT box to run the trigger there. Sid -Original Message-From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Friday, 7 November 2003 1:36 PMTo: [EMAIL PROTECTED]Subject: Re: Triggering across New Cluster not working Sid, Could it be that you don't have a trigger monitor running on the Linux box? You need to start it manually. Once defined on Windows, the Windows MQ service generally starts the trigger monitor for you so most folks tend to forget about it... Just a thought... Gary -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]Sent: Thursday, November 06, 2003 8:27 PMTo: [EMAIL PROTECTED]Subject: Triggering across New Cluster not working Howdy all, I have just put together a new cluster between two machine (NT4 and Linux) The process to run is on the NT machine as well as the trigger monitor and the initiation queue that it monitors. I have place a copy of the process definition on both machine and the queue with triggering turned on is located on the linux box. All queues have the cluster defined. I can see the required queues in the cluster using display qc(*) but when I put stuff into that queue (on the linux box) the triggering does not appear to work. I have 600 other queues still on the NT box which are triggering fine Any Ideas...Please Sid Young Brisbane Australia
UNSUBSCRIBE
UNSUBSCRIBE
Re: Triggering across New Cluster not working
Hi Sid, it sounds like you may have missed the point of MQ clustering. A cluster queue is just a local queue with an alternative method of having messages arrive on the queue. Messages on a cluster queue (as is the case for non-cluster queues) can only be retreived (MQGET) by processes on that system (either local server bindings applications, or the channel agent for a client program). If your message is located on the Linux system in the cluster queue, you have to have the trigger monitor and the application program also running on the Linux system. The only ways to avoid this would be to run both the trigger monitor and the applicatoin program as client applications on the Windows system. MQSeries is quite different to some other queueing products in this way. Messages on a cluster queue are NOT visible or available to other queue managers. A cluster queue is a valid destination from any queue manager in the cluster, but the message will only be available on the system where the message is sent. The actual destination will be chosen by MQSeries or a cluster workload balancing exit. Regards, Neil Casey. |-+> | | [EMAIL PROTECTED]| | | .AU | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 07/11/2003 12:26 | | | Please respond to| | | MQSeries List| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Triggering across New Cluster not working | >--| Howdy all, I have just put together a new cluster between two machine (NT4 and Linux) The process to run is on the NT machine as well as the trigger monitor and the initiation queue that it monitors. I have place a copy of the process definition on both machine and the queue with triggering turned on is located on the linux box. All queues have the cluster defined. I can see the required queues in the cluster using display qc(*) but when I put stuff into that queue (on the linux box) the triggering does not appear to work. I have 600 other queues still on the NT box which are triggering fine Any Ideas...Please Sid Young Brisbane Australia 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 across New Cluster not working
Title: Message Sid, Could it be that you don't have a trigger monitor running on the Linux box? You need to start it manually. Once defined on Windows, the Windows MQ service generally starts the trigger monitor for you so most folks tend to forget about it... Just a thought... Gary -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]Sent: Thursday, November 06, 2003 8:27 PMTo: [EMAIL PROTECTED]Subject: Triggering across New Cluster not working Howdy all, I have just put together a new cluster between two machine (NT4 and Linux) The process to run is on the NT machine as well as the trigger monitor and the initiation queue that it monitors. I have place a copy of the process definition on both machine and the queue with triggering turned on is located on the linux box. All queues have the cluster defined. I can see the required queues in the cluster using display qc(*) but when I put stuff into that queue (on the linux box) the triggering does not appear to work. I have 600 other queues still on the NT box which are triggering fine Any Ideas...Please Sid Young Brisbane Australia
Triggering across New Cluster not working
Title: Message Howdy all, I have just put together a new cluster between two machine (NT4 and Linux) The process to run is on the NT machine as well as the trigger monitor and the initiation queue that it monitors. I have place a copy of the process definition on both machine and the queue with triggering turned on is located on the linux box. All queues have the cluster defined. I can see the required queues in the cluster using display qc(*) but when I put stuff into that queue (on the linux box) the triggering does not appear to work. I have 600 other queues still on the NT box which are triggering fine Any Ideas...Please Sid Young Brisbane Australia
Re: The syncpoint option is ignored when browsing????????
Thomas, Page 107. of the PGMRS REF manual "The locked message is always the one under the browse cursor, and the message can be removed from the queue by a later MQGET call that specifies the MQGMO_MSG_UNDER_CURSOR option. Other MQGET calls using the queue handle can also remove the message (for example, a call that specifies the message identifier of the locked message)." bobbee From: Thomas Dunlap <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: The syncpoint option is ignored when browsing Date: Wed, 5 Nov 2003 22:41:55 -0500 Randy, This is true. You cannot do MQGMO_SYNCPOINT with MQGMO_BROWSE_ options, it will result in an "options error". As for MQOO_BROWSE, this just declares the intent to perform a browse operation. It does not prevent you from performing normal MQGET calls. However, if you do not open a queue with MQOO_BROWSE, then you will not be able to perform an MQGET call with any of the MQGMO_BROWSE_... options. BTW; the only option you really need most of the time on an MQGET for browsing a queue is MQGMO_BROWSE_NEXT. Options like MQGMO_BROWSE_FIRST are for special processing while in the middle of a browse sequence of operations. As for the destructive MQGETs, these are possible even while processing a browse against a queue. The only message which may not be retrieved is one which was retrieve with the options MQGMO_BROWSE_NEXT and MQGMO_LOCK. This message is locked under the browse and is not visible to other MQGET calls. Randy J Clark wrote: "The syncpoint option is ignored when browsing" Is this a true statement? "Using the MQOO-BROWSE and not follwing it up with a MQGMO-BROWSE-FIRST, MQGMO-BROWSE-NEXT or MQGMO-BROWSE-MSG-UNDER-CURSOR is wasteful or serves no purpose." Is this a true statement? Wow as you can see I am confused about this Browse 'stuff'. The reason forthis confusion is I saw in a program the statement 'The syncpoint option is ignored when browsing' but yet the programmer is only using the browse open not the browse get options. MQOO-BROWSE. I do not see anywhere where it says just because the queue is opened in BROWSE messages will not be read destructively.It seems to me if the queue is opened for 'browse' and the GET is no syncpoint the messages are still read destructively that is unless a GMO-BROWSE-FIRST or MQGMO_BROWSE-NEXT option is not used for the MQGET. If one of these two GET options is used then I believe the message still is on the queue. I guess I am saying I think the MQOO-BROWSE has no affect on the destructive or not nature of the MQGET and its purpose is solely to create a browse cursor. To me the MQGMO-BROWSE-FIRST and MQGM-BROWSE-NEXT are the options that cause a message to be read nondestructively - not the MQOO-BROWSE option. I have a sneaking suspicion I am wrong. I see is the following in the APR: MQOO_BROWSE Open queue to browse messages. The queue is opened for use with subsequent MQGET calls with one of the following options: MQGMO_BROWSE_FIRST MQGMO_BROWSE_NEXT MQGMO_BROWSE_MSG_UNDER_CURSOR This is allowed even if the queue is currently open for MQOO_INPUT_EXCLUSIVE. An MQOPEN call with the MQOO_BROWSE option establishes a browse cursor, and positions it logically before the first message on the queue; see the Options field described in Chapter 7, MQGMO - Get-message options for further information. This option is valid only for local, alias, and model queues; it is not valid for remote queues, distribution lists, and objects which are not queues. It is also not valid if ObjectQMgrName is the name of a queue manager alias; this is true even if the value of the RemoteQMgrName attribute in the local definition of a remote queue used for queue-manager aliasing is the name of the local queue manager. Seems to me if I open in Browse mode and issue a syncpoint the messages should still be 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 -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000 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 _ MSN Shopping upgraded for the holidays! Snappier product search... http://shopping.msn.com 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: ms03 for Sun Solaris
Yup, I got the same error(s) too. It is one of those truly stupid things where the gcc compiler is getting confused. Go to line 340 of qmgr.c comment out: /* fprintf( fp, "*\n* This file generated by %s on %.4d-%.2d-%.2d at %.2d.%.2d.%.2d hours.\n", THISVERSION, (today->tm_year) + 1900, today -> tm_mon+1, today -> tm_mday, today -> tm_hour, today -> tm_min, today -> tm_sec ); */ I replaced it with: fprintf( fp, "*\n* This file generated by %s.\n", THISVERSION ); Basically, gcc is having a problem with the "today" pointer. The truly weird part is that gcc on Windows does not have a problem with this code!!! later Roger... Quoting "Yeh, Jeff" <[EMAIL PROTECTED]>: > Hi, > > Our company has several Sun Solaris boxes. They were loaded with WebSphere > MQ V5.3. I also downloaded ms03 (for Unix) from IBM Website. > > In order to make the saveqmgr work, we have to compile the makefile.solaris > ourselves. Our company standard is to use gnu compiler. After the > compilation, I got the following error messages. Please help! > > $ make -f makefile.solaris > gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc > saveqgr.c > gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc > channl.c > gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc > mqutis.c > gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc > proces.c > gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc > qmgr.qmgr.c: In function `AddToFileQMGR': > qmgr.c:338: warning: assignment makes pointer from integer without a cast > qmgr.c:343: error: dereferencing pointer to incomplete type > qmgr.c:344: error: dereferencing pointer to incomplete type > qmgr.c:345: error: dereferencing pointer to incomplete type > qmgr.c:346: error: dereferencing pointer to incomplete type > qmgr.c:347: error: dereferencing pointer to incomplete type > qmgr.c:348: error: dereferencing pointer to incomplete type > *** Error code 1 > make: Fatal error: Command failed for target `qmgr.o' > > Jeff Yeh > > > -- - > ***National City made the following annotations > -- - > > This communication is a confidential and proprietary business communication. > It is intended solely for the use of the designated recipient(s). If this > communication is received in error, please contact the sender and delete > this > communication. > === > > 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: MQSeries PERL modules
I would suspect the the answer lto that question would be IF PERL (either Active Perl, or one of the other versions) have been ported to the OE side OR if someone was bright enough and if it is at all possible, the MVS side. If you read the doc that comes with the MQ Perl installation there is an EMAIL of someone who supports the code. I EMAIL the gentleman and he responded rather quickly with an answer. I would believe that would be going to the "horses mouth" with your question! hope this helps. bee-oh-dubble-bee-dubble-egh And again, I am currently available From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MQSeries PERL modules Date: Thu, 6 Nov 2003 08:23:01 -0600 Greg, I don't know about running the code on the mainframe but it is possible to run on Unix/Windows and connect to the mainframe as a client or to pass the commands through a proxy QMgr. -- T.Rob -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 4:23 PM To: [EMAIL PROTECTED] Subject: MQSeries PERL modules Is anyone using the MQSeries PERL modules on OS/390? The modules say you can use it with the server API for OS/390, but I am not sure how that would actually work. Doesn't PERL have to run under UNIX System Services? Can you access MQ from USS? Just curious. Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. _ Is your computer infected with a virus? Find out with a FREE computer virus scan from McAfee. Take the FreeScan now! http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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: MS SQL 2000 Server Connection in WMQI
Question: Is the broker running on Windows also? Is the broker and SQLServer running on the same box? When you start the ODBC tracing from the Data Sources GUI, do you get any output? B -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Molai TsietsiSent: Thursday, November 06, 2003 10:12 AMTo: [EMAIL PROTECTED]Subject: MS SQL 2000 Server Connection in WMQI Hi all Has anyone tried connecting to SQL 2000 using WMQI compute node running on Windows 2000? I have tried to create an ODBC and I get an ODBC connection error when I run a trace on the compute node. It says the ODBC was not found! Any uncounted this? regards Tsietsi
Re: ms03 for Sun Solaris
I have found in the past that the supported compiles for MQSeries is normally what is the problem here. I believe there is a list of them in the installation manual for the MQ on the OS you are working with. bobbee From: "Yeh, Jeff" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: ms03 for Sun Solaris Date: Thu, 6 Nov 2003 11:56:00 -0500 Hi, Our company has several Sun Solaris boxes. They were loaded with WebSphere MQ V5.3. I also downloaded ms03 (for Unix) from IBM Website. In order to make the saveqmgr work, we have to compile the makefile.solaris ourselves. Our company standard is to use gnu compiler. After the compilation, I got the following error messages. Please help! $ make -f makefile.solaris gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc saveqgr.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc channl.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc mqutis.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc proces.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc qmgr.qmgr.c: In function `AddToFileQMGR': qmgr.c:338: warning: assignment makes pointer from integer without a cast qmgr.c:343: error: dereferencing pointer to incomplete type qmgr.c:344: error: dereferencing pointer to incomplete type qmgr.c:345: error: dereferencing pointer to incomplete type qmgr.c:346: error: dereferencing pointer to incomplete type qmgr.c:347: error: dereferencing pointer to incomplete type qmgr.c:348: error: dereferencing pointer to incomplete type *** Error code 1 make: Fatal error: Command failed for target `qmgr.o' Jeff Yeh --- ***National City made the following annotations --- This communication is a confidential and proprietary business communication. It is intended solely for the use of the designated recipient(s). If this communication is received in error, please contact the sender and delete this communication. === 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 _ Send a QuickGreet with MSN Messenger http://www.msnmessenger-download.com/tracking/cdp_games 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
ms03 for Sun Solaris
Hi, Our company has several Sun Solaris boxes. They were loaded with WebSphere MQ V5.3. I also downloaded ms03 (for Unix) from IBM Website. In order to make the saveqmgr work, we have to compile the makefile.solaris ourselves. Our company standard is to use gnu compiler. After the compilation, I got the following error messages. Please help! $ make -f makefile.solaris gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc saveqgr.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc channl.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc mqutis.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc proces.c gcc -c -DUNIX -m -I. -I/usr/include -I/usr/include/sys -I/usr/lpp/mqm/inc qmgr.qmgr.c: In function `AddToFileQMGR': qmgr.c:338: warning: assignment makes pointer from integer without a cast qmgr.c:343: error: dereferencing pointer to incomplete type qmgr.c:344: error: dereferencing pointer to incomplete type qmgr.c:345: error: dereferencing pointer to incomplete type qmgr.c:346: error: dereferencing pointer to incomplete type qmgr.c:347: error: dereferencing pointer to incomplete type qmgr.c:348: error: dereferencing pointer to incomplete type *** Error code 1 make: Fatal error: Command failed for target `qmgr.o' Jeff Yeh --- ***National City made the following annotations --- This communication is a confidential and proprietary business communication. It is intended solely for the use of the designated recipient(s). If this communication is received in error, please contact the sender and delete this communication. === 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: Report question (MQRO_COD)
Tim, the following quote is from the M21 Intro to MQ Security presentation at this year's conference. It explains why your COAs and CODs are working differently. Quote> When report messages are generated, then the authority needed varies based on the type of report. In particular COA messages use the authority of the putter to the target queue when putting the report message to the reply queue. And COD messages always use the authority of the MQMD.UserIdentifier to write to the reply queue. This is why COA and COD may appear to be different - one succeeds and one fails, because of different userids being used for the auth check to the reply queue. Note that because reply queues are normally specified as a fully-qualified name (qmgr and qname), then access to the XMIT queue may be needed. End Quote>> So my take on this is (someone correct me if I am wrong): Unless you are running your RCVR with a particular MCAUSER, the RCVR MCA put the message to the request queue, with the authority of the process that started the RCVR MCA, namely mqm. So the COA is put with "mqm" authority. But the COD is put with the authority of MQMD.UserIdentifier, which apparently is not defined on that server. -Original Message- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 9:30 AM To: [EMAIL PROTECTED] Subject: Re: Report question (MQRO_COD) Hello, Thanks for the quick feedback (David, Stephan & Binyamin). All of you have indicated that it may be a security issue. The reports are indeed (as you have suggested) sitting on the DLQ. I do find it odd that the GETting application does not have authority to send the COD to the reply-to-queue as this application routinely sends application generated messages to that same queue. However, we have not done anything with security such that it is very possible something with regard to security is just not configured correctly. We will look into this area. Thanks. Tim. -Original Message- From: Binyamin Dissen [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2003 6:32 PM To: [EMAIL PROTECTED] Subject: Re: Report question (MQRO_COD) On Tue, 4 Nov 2003 18:15:47 -0500 "Madsen, Timothy" <[EMAIL PROTECTED]> wrote: :>Hello, :>We have a small number of applications (some applications under our :>developmental control - some applications written by partners - outside our :>control) which exchange XML information using MQSeries. This is working :>successfully for us. However we would like to get additional feedback on :>the progress and disposition of our messages. :>We thought using the MQSeries (we are currently on MQ 5.2.1 running on :>Windows 2000) reports would be appropriate. :>Experimenting, we have the MQRO_COA working as it should. However, the :>MQRO_COD and MQRO_EXPIRATION are apparently not generating any reports. We :>do not understand why the COA would work but the COD / EXPIRATION not work? :>Options appear to be set correctly. Any suggestions about what to check :>for? :>It is our understanding that all we must do on the PUTting end is to specify :>the requested report option in the MQMD along with a valid reply to :>queue/manager. It would seem this is correct and certainly works for the :>COA report. We expect that the queue manager will automatically generate :>the COA, COD & EXPIRATION reports with no assistance from the GETting :>application. (Well - the application will destructively GET the message :>which should cause the queue manager to automatically generate the COD - but :>I mean the application itself does not have to actively create a report :>message.) Have you checked the DLQ (on the receiving side)? I have seen the COD / expiration occur under a different security authorization than the COA. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel 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
MS SQL 2000 Server Connection in WMQI
Hi all Has anyone tried connecting to SQL 2000 using WMQI compute node running on Windows 2000? I have tried to create an ODBC and I get an ODBC connection error when I run a trace on the compute node. It says the ODBC was not found! Any uncounted this? regards Tsietsi
[no subject]
>DISTL represents whether distribution list are supported by the partner queue manager. DISTL(YES) means the distribution list are supported by the partner queue manager and specify >DISTL(NO) if not. >Regards >Radha It is true that DISTL specified whether the partner Queue Manager supports distribution lists. However, the user is not expected to set this attribute. It is set automagically when the channel runs. Do not be suprised to see the value change when you start your channel. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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: Multiple client connections.....
We have several hundred users that start an MQ client app as soon as they arrive in the morning, and shut it down when they leave for the night. They are connected the whole time, and it doesn't cause any problems. As long as both halfs of the connection are "alive" (even if they're not especially active), MQ keeps the connection intact. I know that many of my users go hours without issuing an MQI call, and there isn't a problem. Dennis Bryngelson <[EMAIL PROTECTED]To: [EMAIL PROTECTED] RDLIFE.COM> cc: Sent by: MQSeries List Subject: Multiple client connections. <[EMAIL PROTECTED]> 11/06/2003 08:30 AM Please respond to MQSeries List Has anyone had any problems with hundreds of client connections to a Queue Manager left connected for long periods of time (hours)? Also if there is no activity on the connection for a period of time (hour or so) will MQ automatically drop that connection and if so can I set that time limit Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, 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: Does anyone have or know of a Channel Table Maintenance tool ?
Phil, We had a script that would let a user create a channel table file from the web and download it to the desktop, as well as a few others that converted between channel table and various other formats. I'd be happy to pass them along as examples. Have you talked with Hildo about whether and when the new format might be supported? Problem with the channel table code is the table formats are undocumented and have to be reverse-engineered so it represents a larger project then adding new PCF commands. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 8:50 AM To: [EMAIL PROTECTED] Subject: Re: Does anyone have or know of a Channel Table Maintenance tool ? Bill Thanks. I did find that, but it has to be updated to handle 5.3 parameters. There are two PERL scripts. The first transforms a channel table to an INI style file, and the second does the reverse. It seems OK so we're taking a look at it to see if we can change it to handle the 5.3 issues. I'll let you all know how it turned out. Generally, I do not like the idea of having to distribute the table, but it may be better to do that then force apps to recode for SSL. As you probably know, you cannot use MQSERVER variable for SSL SVRCONN channels. Phil Bill Anderson <[EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO> cc: Sent by: MQSeriesSubject: Re: Does anyone have or know of a Channel Table Maintenance tool ? List <[EMAIL PROTECTED] n.AC.AT> 11/04/2003 03:52 PM Please respond to MQSeries List Take a look at the PERL support site CPAN.com If memory serves me correctly (and there is no guarantee of that) some one has written a PERL program that eases the pain of managing channel tables. Hope that helps Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ [EMAIL PROTECTED] PMCHASE.COM To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Does anyone have or know of a Channel Table Maintenance tool ? <[EMAIL PROTECTED] .AC.AT> 11/04/2003 09:41 AM Please respond to MQSeries List All, We have had some interest in using the channel table, but without a proper maintenance tool, it is quite cumbersome. Using the queue manager to do this is awkward at best. Several years ago, I recall there was a firm which that said it had such a tool. Is anyone aware of a similar tool which can also handle SSL settings ? Thanks, Phil This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSeries PERL modules
Title: MQSeries PERL modules Greg, I don't know about running the code on the mainframe but it is possible to run on Unix/Windows and connect to the mainframe as a client or to pass the commands through a proxy QMgr. -- T.Rob -Original Message-From: Mabrito, Greg [mailto:[EMAIL PROTECTED]Sent: Wednesday, November 05, 2003 4:23 PMTo: [EMAIL PROTECTED]Subject: MQSeries PERL modules Is anyone using the MQSeries PERL modules on OS/390? The modules say you can use it with the server API for OS/390, but I am not sure how that would actually work. Doesn't PERL have to run under UNIX System Services? Can you access MQ from USS? Just curious. Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA.
Multiple client connections.....
Has anyone had any problems with hundreds of client connections to a Queue Manager left connected for long periods of time (hours)? Also if there is no activity on the connection for a period of time (hour or so) will MQ automatically drop that connection and if so can I set that time limit Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, 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
Re: HP-UX MQ V53 installation problem ...
Normally the reasons why a Queue manager will not start on a new installation are: 1) File Permissions on MQ directories/files 2) Kernel Parameters 3) mqm id / group not defined correctly 4) Mandatory OS patches not installed Turn on early tracing before starting the qmgr again and you should get some more ideas: strmqtrc -e -tall -tdetail Matt. -Original Message- From: EMRE KUNT (Ebi Bsk. - Sistem Prog) [mailto:[EMAIL PROTECTED] Sent: 06 November 2003 07:45 To: [EMAIL PROTECTED] Subject: HP-UX MQ V53 installation problem ... Hello, Platform: HP-UX 11i MQ 5.3 After installation, we got the following error message during the strmqm command. "AMQ8101: WebSphere MQ error (7E2) has occurred." Any idea or suggestion ? Thanks... Emre KUNT === Bu e-mail mesaji ve ekleri, isimleri yazili alicilar disindaki kisilere aciklanmamasi, dagitilmamasi ve iletilmemesi gereken kisiye ozel ve gizli bilgiler icerebilir. Mesajin muhatabi degilseniz lutfen gonderici ile irtibat kurunuz, mesaj ve eklerini siliniz. E-mail sistemlerinin tasidigi guvenlik risklerinden dolayi, mesajlarin gizlilikleri ve butunlukleri bozulabilir, mesaj virus icerebilir. Bilinen viruslere karsi kontrolleri yapilmis olarak yollanan mesajin sisteminizde yaratabilecegi olasi zararlardan Sirketimiz (T.H.Y. A.O.) sorumlu tutulamaz. This email and its attachments may contain private and confidential information intended for the use of the addressee only, which should not be announced, copied or forwarded. If you are not the intended recipient, please contact the sender, delete the message and its attachments. Due to security risks of email systems, the confidentiality and integrity of the message may be damaged, the message may contain viruses. This message is scanned for known viruses and our Company (Turkish Airlines Inc.) will not be liable for possible system damages caused by the message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive == This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. == 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: HP-UX MQ V53 installation problem ...
7e2 is 2018 Go to URL http://www-3.ibm.com/software/integration/mqfamily/library/manualsa/index.ht ml go to multiplatform manuals find the message and codes manuals 2018 X'07E2' MQRC_HCONN_ERROR The connection handle Hconn is not valid. If the handle is a shareable handle, the handle may have been made invalid by another thread issuing the MQDISC call using that handle. If the handle is a nonshareable handle, the call may have been issued by a thread that did not create the handle. This reason also occurs if the parameter pointer is not valid, or (for the MQCONN or MQCONNX call) points to read-only storage. (It is not always possible to detect parameter pointers that are not valid; if not detected, unpredictable results occur.) -Original Message- From: EMRE KUNT (Ebi Bsk. - Sistem Prog) [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 2:45 AM To: [EMAIL PROTECTED] Subject: HP-UX MQ V53 installation problem ... Hello, Platform: HP-UX 11i MQ 5.3 After installation, we got the following error message during the strmqm command. "AMQ8101: WebSphere MQ error (7E2) has occurred." Any idea or suggestion ? Thanks... Emre KUNT === Bu e-mail mesaji ve ekleri, isimleri yazili alicilar disindaki kisilere aciklanmamasi, dagitilmamasi ve iletilmemesi gereken kisiye ozel ve gizli bilgiler icerebilir. Mesajin muhatabi degilseniz lutfen gonderici ile irtibat kurunuz, mesaj ve eklerini siliniz. E-mail sistemlerinin tasidigi guvenlik risklerinden dolayi, mesajlarin gizlilikleri ve butunlukleri bozulabilir, mesaj virus icerebilir. Bilinen viruslere karsi kontrolleri yapilmis olarak yollanan mesajin sisteminizde yaratabilecegi olasi zararlardan Sirketimiz (T.H.Y. A.O.) sorumlu tutulamaz. This email and its attachments may contain private and confidential information intended for the use of the addressee only, which should not be announced, copied or forwarded. If you are not the intended recipient, please contact the sender, delete the message and its attachments. Due to security risks of email systems, the confidentiality and integrity of the message may be damaged, the message may contain viruses. This message is scanned for known viruses and our Company (Turkish Airlines Inc.) will not be liable for possible system damages caused by the message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. 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
HP-UX MQ V53 installation problem ...
Hello, Platform: HP-UX 11i MQ 5.3 After installation, we got the following error message during the strmqm command. "AMQ8101: WebSphere MQ error (7E2) has occurred." Any idea or suggestion ? Thanks... Emre KUNT === Bu e-mail mesaji ve ekleri, isimleri yazili alicilar disindaki kisilere aciklanmamasi, dagitilmamasi ve iletilmemesi gereken kisiye ozel ve gizli bilgiler icerebilir. Mesajin muhatabi degilseniz lutfen gonderici ile irtibat kurunuz, mesaj ve eklerini siliniz. E-mail sistemlerinin tasidigi guvenlik risklerinden dolayi, mesajlarin gizlilikleri ve butunlukleri bozulabilir, mesaj virus icerebilir. Bilinen viruslere karsi kontrolleri yapilmis olarak yollanan mesajin sisteminizde yaratabilecegi olasi zararlardan Sirketimiz (T.H.Y. A.O.) sorumlu tutulamaz. This email and its attachments may contain private and confidential information intended for the use of the addressee only, which should not be announced, copied or forwarded. If you are not the intended recipient, please contact the sender, delete the message and its attachments. Due to security risks of email systems, the confidentiality and integrity of the message may be damaged, the message may contain viruses. This message is scanned for known viruses and our Company (Turkish Airlines Inc.) will not be liable for possible system damages caused by the message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
