Re: Many Client connections - how many svrconn channels?
Hi Sid, Yes, I'll put your changes into the code, no problem. I thinks it's a good idea just to keep one version of BlockIP/BlockIP2 so we allways know how to solve problems, and not have to deal with at lot of cousins. Just send me the code, and I'll review the code before release. Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Date: Mon, 22 Mar 2004 11:26:44 +1000 Jxrgen, I need to make some changes to BlockIP2 for logging of information, the logs grow way to big on my systems and I need then stamped by date: ie BlockLog_2004_03_22.log I also need to be able to specify a log directory, so I was going to add the following commands: # on NT systems LogDirecty=\qml\log LogDrive=c: LogFormat=NameDate LogBaseName=BlockLog # on Linux systems LogDirecty=/var/spool/blockip2/logs LogFormat=NameDate LogBaseName=BlockLog On the linux the LogDrive would be ignored and just the LogDirectory would be applicable using /s If I make the changes, are you happy to add them into your code for the benefit of the community as a whole, or would you prefer me to start my own stream of BlockIP ??? Sid Young QML Pathology Brisbane _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: MO71 question - viaQM-monitored QM stays green very short
Ben, It's difficult to guess what you're problem is from here. I suggest you follow the message. When you send a monitor message where does it go and how far does it get ? You can easily see whether it makes the round trip by looking at your channel sequence number. If you still can't see anything then feel free to send me you MQMON.CFG file and DIS Q(*) ALL output from both queue managers. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Benjamin F. | | | Zhou| | | [EMAIL PROTECTED]| | | USA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 19:16 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question - viaQM-monitored QM stays green very short | | | | | -| Hi Paul, thanks for pointing that out. I set the two qmgrs as illustrated in the diagram. Although the queue MQMON in TEST is used for monitoring both qmgrs, those routed back from QMX are not being picked up. I tried both normal and loopback monitoring, with the same result. The only thing I didn't specify is the server queue field. What else could I be missing? many thanks for your help, Ben (Embedded image moved to file: pic08902.jpg) (See attached file: mqmon_infra.vsd) Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COMcc: Sent by: Subject: Re: MO71 question - viaQM-monitored QM stays green very short MQSeries List [EMAIL PROTECTED] en.AC.AT 03/19/2004 05:10 AM Please respond to MQSeries List Ben, It is not true to say that if you get commands to work, then monitoring will also work. You do have to configure your monitor queue correctly as well. Please read the section in the manual about monitoring. You can click on the location monitor button and see where the monitor messages go. If you still have problems perhaps you'd better contact me offline. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Benjamin F. | | | Zhou| | | [EMAIL PROTECTED]| | | USA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 18/03/2004 16:02 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question - viaQM-monitored QM stays green very short | | | | | -| Hi Paul, I'm pretty sure the viaQM-monitored QM already has all the right configuration needed for the monitor. Otherwise I won't get the correct result on the screen when I double click on that QM. My challenge now is how to set the definition to keep it green, not just for a few seconds. I actually set monitor interval to 3, 6 seconds. But it still stays red
Re: MO71
Mike, I'm not sure what your security policy is; whether you're using SSL, security exits or whatever but to get things working you could change the MCAUSER of the SVRCONN to something which has the required authority. If your MCAUSER is blank then you are even less secure since you'll effectively believe any userid the client cares to throw at you. On most platforms you can switch authority events on in the Queue Manager and then you'll get a message whenever a security check fails. This messages details the userid and the object being checked. Personally I find this quite useful when tracking down security violations. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 22:20 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 | | | | | -| Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+ --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | --- | Hi, is a client required at both ends in order for the monitoring to work? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive:
Re: Dead Letter Queue messages not appearing?
As per my understanding of you query, the MQ message is first tried to be delivered to the destination queue. In case of Queue depth exceeded scenarios, it tries putting into the DLQ of the destination failing which it delivers to the senders DLQ. Please ask your sender to examine his DLQ content. That should contain the message structure stating the issue. Cheers, Bharath Adiraju, Rao [EMAIL PROTECTED] To: [EMAIL PROTECTED] Z.CO.NZ cc: (bcc: bharathram.s/Polaris) Sent by: Subject: Re: Dead Letter Queue messages not appearing? MQSeries List [EMAIL PROTECTED] en.AC.AT 03/22/04 02:47 AM Please respond to MQSeries List Have you checked the dead-letter queue on KEWILL queue manager. Cheers Rao -Original Message- From: Michelle Russell [mailto:[EMAIL PROTECTED] Sent: 19 March 2004 11:36 PM To: [EMAIL PROTECTED] Subject: Dead Letter Queue messages not appearing? Hi all, I have a situation whereby an external company using an MQClient are trying to send messages to our Mainframe MQ Manager (V2.1) and the messages when being sent are not arriving on the destination queue or the Dead letter Queue. In our Queue Manager channel initiator we get the message: +CSQX548E MQSB CSQXRESP Messages for KEWILL.TO.MQSB sent to local dead-letter queue I can not see any messages on the dead letter queue on the local queue manager. I have however heard from the external company and prior to us getting this message they get an MQ Error Message of '2320'. Can anybody give any ideas on this. Regards Michelle. This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: Griffin House, 40 Lever Street, Manchester, M60 6ES. Registered in England No.814103. 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 confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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 may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in
Re: MO71
I'm not sure I understand. If my NT userid is db2admin why would it work if I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that only users I designate can use it? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 4:04 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, I'm not sure what your security policy is; whether you're using SSL, security exits or whatever but to get things working you could change the MCAUSER of the SVRCONN to something which has the required authority. If your MCAUSER is blank then you are even less secure since you'll effectively believe any userid the client cares to throw at you. On most platforms you can switch authority events on in the Queue Manager and then you'll get a message whenever a security check fails. This messages details the userid and the object being checked. Personally I find this quite useful when tracking down security violations. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 22:20 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 | | | | | --- --| Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+ --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | --- | Hi, is a client required at both ends in order for the monitoring to work? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Managing linear logs with MQ5.3 on Windows
The MS62 support pack found on Hursley applies to both UNIX and Windows (W2K/WNT/WXP). For Windows, there is no mqs.ini file therefore you MUST specify the -n option to prevent the parsing of .ini files. Assuming you've installed perl on windows and have gzip on the system with its location specified in the %PATH% environment variable then the cleanmqlogs.pl script should work as documented. (see the support pak documentation for instructions on installing perl and associating the .PL suffix with perl). Note that if there are spaces in the directories you'll need to put double quotes around the directory specification or use the 8.3 representation. Here is an example, on windows, of an actual run of the MS62 support pak: (The queue manager is named test) C:\PROGRA~1\IBM\WEBSPH~1\binrcdmqimg -l -m test -t ALL * Media image for object test, type catalogue recorded. Media image for object test, type qmgr recorded. Media image for object SYSTEM.DEFAULT.PROCESS, type process recorded. Media image for object SYSTEM.DEFAULT.NAMELIST, type namelist recorded. Media image for object SYSTEM.DEFAULT.AUTHINFO.CRLLDAP, type authinfo recorded. Media image for object KEN.QL, type queue recorded. Media image for object MQMON, type queue recorded. Media image for object SYSTEM.ADMIN.CHANNEL.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.ADMIN.PERFM.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.QMGR.EVENT, type queue recorded. Media image for object SYSTEM.AUTH.DATA.QUEUE, type queue recorded. Media image for object SYSTEM.CHANNEL.INITQ, type queue recorded. Media image for object SYSTEM.CHANNEL.SYNCQ, type queue recorded. Media image for object SYSTEM.CICS.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.REPOSITORY.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.TRANSMIT.QUEUE, type queue recorded. Media image for object SYSTEM.DEAD.LETTER.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.ALIAS.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.LOCAL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.MODEL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.REMOTE.QUEUE, type queue recorded. Media image for object SYSTEM.MQSC.REPLY.QUEUE, type queue recorded. Media image for object SYSTEM.PENDING.DATA.QUEUE, type queue recorded. AMQ7467: The oldest log file required to start queue manager test is S022.LO G. AMQ7468: The oldest log file required to perform media recovery of queue manager test is S015.LOG. C:\PROGRA~1\IBM\WEBSPH~1\bin Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perlcleanmqlogs.pl ^ More? -t C:\Program Files\IBM\WebSphere MQ -l C:\PROGRA~1\IBM\WEBSPH~1\log -n test Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Media Recovery: S015.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Qmgr Restart: S022.LOG About to gzip test's S004.LOG About to gzip test's S005.LOG About to gzip test's S006.LOG About to gzip test's S007.LOG About to gzip test's S008.LOG About to gzip test's S009.LOG About to gzip test's S010.LOG About to gzip test's S011.LOG About to gzip test's S012.LOG About to gzip test's S013.LOG About to gzip test's S014.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl C:\PROGRA~1\IBM\WEBSPH~1\log\test\activedir Volume in drive C has no label. Volume Serial Number is C002-5176 Directory of C:\PROGRA~1\IBM\WEBSPH~1\log\test\active 03/21/2004 18:04DIR . 03/21/2004 18:04DIR .. 03/21/2004 17:59 510,099 S0~1.GZ S000.LOG.gz 03/21/2004 18:02 704,207 S0~2.GZ S001.LOG.gz 03/21/2004 18:02 783,652 S0~3.GZ S002.LOG.gz 03/21/2004 18:02 658,033 S0~4.GZ S003.LOG.gz 03/21/2004 18:02 739,633 S0AB05~1.GZ S004.LOG.gz 03/21/2004 18:02 656,740 S0AB02~1.GZ S005.LOG.gz 03/21/2004 18:02 786,927 S0AB07~1.GZ S006.LOG.gz 03/21/2004 18:02 651,246 S0AB00~1.GZ S007.LOG.gz 03/21/2004 18:02 800,641 S0AB01~1.GZ S008.LOG.gz 03/21/2004 18:02 671,522 S0AB06~1.GZ S009.LOG.gz 03/21/2004 18:03 729,910 S0AC09~1.GZ S010.LOG.gz 03/21/2004 18:03 717,544 S0AC0E~1.GZ S011.LOG.gz 03/21/2004 18:04 674,490 S0AC03~1.GZ S012.LOG.gz 03/21/2004 18:04 724,322 S0AC04~1.GZ S013.LOG.gz 03/21/2004 18:04 712,174 S0AC05~1.GZ S014.LOG.gz 03/21/2004 18:04 1,049,600 S015.LOG 03/21/2004 18:04
Re: Managing linear logs with MQ5.3 on Windows
Rao, Sounds like this would be a good addition to the current Support Pac or even a stand-alone Support Pac. Why not submit it? -- T.Rob -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Sunday, March 21, 2004 4:12 PM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Hi all I have experienced the same problem for the past few weeks in my current client site. PERL and JAVA have their own problems and I can't locate MS62 zip file for Windows version so on.. So on.. I don't understand why IBM doesn't provide a support pack that is native to windows platform ?? My guess as good as anyone - so I will leave it here. But anyway, I have developed a VB Script which does exactly the same as any perl/java script and put in place. If anybody wants to use it - here it is (attached as a txt file and just rename it to .VBS). The principle is same, reads the AMQERR01.LOG, finds out the last log number for media recovery and then deletes all previous ones. Feel free to modify to suit your needs. Cheers Rao Ps: Disclaimer - even though it is tested thoroughly, no guarantees are given. -Original Message- From: Luc-Michel Demey [mailto:[EMAIL PROTECTED] Sent: 20 March 2004 11:54 AM To: [EMAIL PROTECTED] Subject: Managing linear logs with MQ5.3 on Windows Hi all, I am trying to find if any of the available support packs are suitable for managing linear logs on a MQ 5.3 Windows NT box. I have done a little testing, most of them rely on the qm.ini file not more present above 5.0. Even with a fake ini file on the right place, I was not able to use : - MS0L : Java exception - MS62 : Perl problems In both cases (Java Perl), I suspect NT 4 related problems. Any ideas / experiences to share ? TIA, LMD. -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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 confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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: MO71
This is becuase: If you specify a nonblank user name as the MCAUSER attribute of the server connection channel, all programs connecting to the queue manager using this channel run with the identity of the named user and have the same level of authority. So though u r connecting as db2admin, in effect u r using mqm user-id and all its authority. So create a new user id and give only the requisite permissions to this user-id like only browse to some MQ objects and put it in the MCAUSER. Then anybody can connect to this queue manager but will have only limited access. cheers krish Ward, Mike S [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: krishan.agarwal/Polaris) Sent by: Subject: Re: MO71 MQSeries List [EMAIL PROTECTED] en.AC.AT 03/22/04 06:45 PM Please respond to MQSeries List I'm not sure I understand. If my NT userid is db2admin why would it work if I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that only users I designate can use it? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 4:04 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, I'm not sure what your security policy is; whether you're using SSL, security exits or whatever but to get things working you could change the MCAUSER of the SVRCONN to something which has the required authority. If your MCAUSER is blank then you are even less secure since you'll effectively believe any userid the client cares to throw at you. On most platforms you can switch authority events on in the Queue Manager and then you'll get a message whenever a security check fails. This messages details the userid and the object being checked. Personally I find this quite useful when tracking down security violations. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 22:20 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 | | | | | --- --| Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+ --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | --- | Hi, is a client required at both ends
Re: MO71
I'm not sure I understand. If my NT userid is db2admin why would it work
if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
Mike,
Are you suggesting that MQ should *always* trust the userid sent from the
client ? This would be a dangerous thing. You can configure your SVRCONN to
use the userid passed in ( MCAUSER(' ') ) or always use a userid of your
choosing ( MCAUSER('FRED') ). Of course the ideal is that you authenticate
with your client using something like SSL and then make an informed
decision about what to set the userid to reflect the state of your known
client but in the meantime you can just set a pre-defined fixed user of
sufficient authority.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
Ward, Mike S
[EMAIL PROTECTED]To: [EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: Re: MO71
[EMAIL PROTECTED]
N.AC.AT
22/03/2004 13:15
Please respond to
MQSeries List
I'm not sure I understand. If my NT userid is db2admin why would it work if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 4:04 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
I'm not sure what your security policy is; whether you're using SSL,
security exits or whatever but to get things working you could change the
MCAUSER of the SVRCONN to something which has the required authority. If
your MCAUSER is blank then you are even less secure since you'll
effectively believe any userid the client cares to throw at you.
On most platforms you can switch authority events on in the Queue Manager
and then you'll get a message whenever a security check fails. This
messages details the userid and the object being checked. Personally I find
this quite useful when tracking down security violations.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+
| | Ward, Mike S |
| | [EMAIL PROTECTED]|
| | Sent by: MQSeries|
| | List |
| | [EMAIL PROTECTED]|
| | N.AC.AT |
| ||
| ||
| | 19/03/2004 22:20 |
| | Please respond to|
| | MQSeries List|
|-+
---
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: MO71
|
|
|
|
|
---
--|
Thanks, I got it to work. I am also trying to connect to a SCO Unix
qmanager
and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not
authorized. I tried defining the userid of the NT box that has mqmon
running
on it and then modifying that user so that it has mqm as a group but I
still
get the same message. Any thoughts?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 3:50 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
MO71 supports two types of monitoring.
1/ Normal monitoring relies on a program at the remote Queue Manager to
receive the messages and send them back to the reply fields
This does therefore require a client (program) running on the remote
system
2/ Loopback monitoring allows yoiu to define a remote queue on the remote
system which just 'points' back to the originating queue.
This does not therefore require a client (program) running on the
remote system
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+
| | Ward, Mike S |
| | [EMAIL PROTECTED]|
| | Sent by: MQSeries|
| | List |
| | [EMAIL PROTECTED]|
| | N.AC.AT |
| ||
| ||
| | 16/03/2004 14:32 |
| | Please respond to|
| | MQSeries List|
|-+
---
|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: MO71
|
|
|
|
|
Re: MO71
Hi Mike, You could use BlockIP2 to help you there. BlockIP2 can filter on your connection name together with the userid. And if you have a match it can even change/set MCAUSER depending on your choise. Another ting is when leaving a SVRCONN open you can let everybody inside. If somebody can write a JMS/JAVA program they can connect to your queuemanager and set the usterid to whatever they want: mqm, root, db2admin. All they need is a know userid with the right auth. (and ofcause the connctionname/channel of your qmgr, typicly: 'SYSTEM.DEF.SVRCONN/TCP/conname(1414)') BlockIP2 was designed to help MQ-administrators to keep the mqnetwork more secure. http://www.mrmq.dk/BlockIP.htm#BlockIP2 Just my $0.02 ;o) Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: Ward, Mike S [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MO71 Date: Mon, 22 Mar 2004 07:15:17 -0600 I'm not sure I understand. If my NT userid is db2admin why would it work if I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that only users I designate can use it? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 4:04 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, I'm not sure what your security policy is; whether you're using SSL, security exits or whatever but to get things working you could change the MCAUSER of the SVRCONN to something which has the required authority. If your MCAUSER is blank then you are even less secure since you'll effectively believe any userid the client cares to throw at you. On most platforms you can switch authority events on in the Queue Manager and then you'll get a message whenever a security check fails. This messages details the userid and the object being checked. Personally I find this quite useful when tracking down security violations. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 22:20 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 | | | | | --- --| Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+ --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | --- | Hi, is a client required at both ends in order for the monitoring to work? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive:
Re: NY / NJ WS MQ UG Meeting April 27
Re:upcoming meeting on April 27, at World Financial Center in New York City. If you would like to attend, please registerat http://www.nynjmq.org Meeting agenda and location address are listed at the web-site.
Re: MO71 question - viaQM-monitored QM stays green very short
Hi Paul, I figured out what I was missing. I was pointing the remote MQMON queue to the MQMON on the viaQM. it should be pointing to the command reply queue instead. The icon is now green all the time, even for my mainframe QM without CAF installed. many thanks for your help. Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COMcc: Sent by: Subject: Re: MO71 question - viaQM-monitored QM stays green very short MQSeries List [EMAIL PROTECTED] en.AC.AT 03/22/2004 04:57 AM Please respond to MQSeries List Ben, It's difficult to guess what you're problem is from here. I suggest you follow the message. When you send a monitor message where does it go and how far does it get ? You can easily see whether it makes the round trip by looking at your channel sequence number. If you still can't see anything then feel free to send me you MQMON.CFG file and DIS Q(*) ALL output from both queue managers. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Benjamin F. | | | Zhou| | | [EMAIL PROTECTED]| | | USA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 19:16 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question - viaQM-monitored QM stays green very short | | | | | -| Hi Paul, thanks for pointing that out. I set the two qmgrs as illustrated in the diagram. Although the queue MQMON in TEST is used for monitoring both qmgrs, those routed back from QMX are not being picked up. I tried both normal and loopback monitoring, with the same result. The only thing I didn't specify is the server queue field. What else could I be missing? many thanks for your help, Ben (Embedded image moved to file: pic08902.jpg) (See attached file: mqmon_infra.vsd) Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COMcc: Sent by: Subject: Re: MO71 question - viaQM-monitored QM stays green very short MQSeries List [EMAIL PROTECTED] en.AC.AT 03/19/2004 05:10 AM Please respond to MQSeries List Ben, It is not true to say that if you get commands to work, then monitoring will also work. You do have to configure your monitor queue correctly as well. Please read the section in the manual about monitoring. You can click on the location monitor button and see where the monitor messages go. If you still have problems perhaps you'd better contact me offline. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Benjamin F. | | | Zhou| | | [EMAIL PROTECTED]| | | USA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 18/03/2004 16:02 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question - viaQM-monitored QM stays green very short | | | | | -| Hi
Use channel exits or not?
Hi, We are planning on having a hub and spoke architecture that will see 100's of applications connect into the WBI MB hub we will implement. We have a requirement to be able to determine the amount of time that the messages have spent in the hub. We thought we would do this by implementing some auditing functionality using channel exits to copy the messages to another destinations as it arrives and as it leaves. We have had some worrying comments regarding using channel exits for this purpose, these comments are: this will degrade channel performance an error in the exit could cause message loss The alternatives to this approach are as follows: Use a message get MQ exit Use a stand-alone program Add a metrics node into the message flow. The main problems with the above approach are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits. Would anyone like to comment on this? Cheers, Kulbir.
Re: Use channel exits or not?
Application connects to QMSpoke1. QMSpoke1 hosts aRemoteQueueA, pointing at RemoteQueueB, which lives on QMHub. RemoteQueueB on QMHub points back at LocalQueue1 on SpokeQM1. Application connects to QMSpoke1, and Opens RemoteQueueA for putting, and opens LocalQueue1 for getting. Put a message into RemoteQueueA. Record the time. Application immediatly MQGets from LocalQueue1. Record the time. Subtract the two times, and you have the amount of time a message takes to get thru the hub. Yes it includes time spent on the channels, but that is relevant. Put both QMs on the same box, and have your channels already running to eliminate these variables as much as possible. Do the test again by changing RemoteQueueA to point right to LocalQueue1 to see what a difference there is if you eliminate the channel/HUB hops. -Original Message-From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]Sent: Monday, March 22, 2004 2:00 PMTo: [EMAIL PROTECTED]Subject: Use channel exits or not?Hi, We are planning on having a hub and spoke architecture that will see 100's of applications connect into the WBI MB hub we will implement. We have a requirement to be able to determine the amount of time that the messages have spent in the hub. We thought we would do this by implementing some auditing functionality using channel exits to copy the messages to another destinations as it arrives and as it leaves. We have had some worrying comments regarding using channel exits for this purpose, these comments are: this will degrade channel performance an error in the exit could cause message lossThe alternatives to this approach are as follows: Use a message get MQ exit Use a stand-alone program Add a metrics node into the message flow.The main problems with the above approach are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits. Would anyone like to comment on this? Cheers, Kulbir. 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.
Re: Dead Letter Queue messages not appearing?
The 2030 error usually originates from calls to MQAI (Administrative Interface). It means the programmer used an invalid handle when programming to that API. It would be roughly similar to using an invalid HCONN with the regular MQ API. I would not expect a message on the destination queue or the DLQ after a 2030 error. The CSQ548E error is a tad mysterious. Is KEWILL.TO.MQSB a client connection channel? -Original Message- From: Michelle Russell [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 2:36 AM To: [EMAIL PROTECTED] Subject: Dead Letter Queue messages not appearing? Hi all, I have a situation whereby an external company using an MQClient are trying to send messages to our Mainframe MQ Manager (V2.1) and the messages when being sent are not arriving on the destination queue or the Dead letter Queue. In our Queue Manager channel initiator we get the message: +CSQX548E MQSB CSQXRESP Messages for KEWILL.TO.MQSB sent to local dead-letter queue I can not see any messages on the dead letter queue on the local queue manager. I have however heard from the external company and prior to us getting this message they get an MQ Error Message of '2320'. Can anybody give any ideas on this. Regards Michelle. This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: Griffin House, 40 Lever Street, Manchester, M60 6ES. Registered in England No.814103. 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: Managing linear logs with MQ5.3 on Windows
Ken With due to respect, I am not sure what is this Hursley you are talking and how to get there. I usually logon to IBM WMQ Support pack homepage to download any support pack and here is the address: http://www-306.ibm.com/software/integration/support/supportpacs/individual/m s62.html On this page MS62 talks about how to install and run on windows, BUT NO ZIP FILE CAN BE SEEN. In I fact asked this question a month back, and haven't heard anything since then. Are you talking of another home page for Hursley where we can download this service pack. Believe me, it was damn frustrating to download something which doesn't exist. Hence I said bugger all, and built my own VB script for it. Cheers Rao -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: 11 January 2001 1:52 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows The MS62 support pack found on Hursley applies to both UNIX and Windows (W2K/WNT/WXP). For Windows, there is no mqs.ini file therefore you MUST specify the -n option to prevent the parsing of .ini files. Assuming you've installed perl on windows and have gzip on the system with its location specified in the %PATH% environment variable then the cleanmqlogs.pl script should work as documented. (see the support pak documentation for instructions on installing perl and associating the .PL suffix with perl). Note that if there are spaces in the directories you'll need to put double quotes around the directory specification or use the 8.3 representation. Here is an example, on windows, of an actual run of the MS62 support pak: (The queue manager is named test) C:\PROGRA~1\IBM\WEBSPH~1\binrcdmqimg -l -m test -t ALL * Media image for object test, type catalogue recorded. Media image for object test, type qmgr recorded. Media image for object SYSTEM.DEFAULT.PROCESS, type process recorded. Media image for object SYSTEM.DEFAULT.NAMELIST, type namelist recorded. Media image for object SYSTEM.DEFAULT.AUTHINFO.CRLLDAP, type authinfo recorded. Media image for object KEN.QL, type queue recorded. Media image for object MQMON, type queue recorded. Media image for object SYSTEM.ADMIN.CHANNEL.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.ADMIN.PERFM.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.QMGR.EVENT, type queue recorded. Media image for object SYSTEM.AUTH.DATA.QUEUE, type queue recorded. Media image for object SYSTEM.CHANNEL.INITQ, type queue recorded. Media image for object SYSTEM.CHANNEL.SYNCQ, type queue recorded. Media image for object SYSTEM.CICS.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.REPOSITORY.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.TRANSMIT.QUEUE, type queue recorded. Media image for object SYSTEM.DEAD.LETTER.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.ALIAS.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.LOCAL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.MODEL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.REMOTE.QUEUE, type queue recorded. Media image for object SYSTEM.MQSC.REPLY.QUEUE, type queue recorded. Media image for object SYSTEM.PENDING.DATA.QUEUE, type queue recorded. AMQ7467: The oldest log file required to start queue manager test is S022.LO G. AMQ7468: The oldest log file required to perform media recovery of queue manager test is S015.LOG. C:\PROGRA~1\IBM\WEBSPH~1\bin Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perlcleanmqlogs.pl ^ More? -t C:\Program Files\IBM\WebSphere MQ -l C:\PROGRA~1\IBM\WEBSPH~1\log -n test Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Media Recovery: S015.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Qmgr Restart: S022.LOG About to gzip test's S004.LOG About to gzip test's S005.LOG About to gzip test's S006.LOG About to gzip test's S007.LOG About to gzip test's S008.LOG About to gzip test's S009.LOG About to gzip test's S010.LOG About to gzip test's S011.LOG About to gzip test's S012.LOG About to gzip test's S013.LOG About to gzip test's S014.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl C:\PROGRA~1\IBM\WEBSPH~1\log\test\activedir Volume in drive C has no label. Volume Serial Number is C002-5176 Directory of C:\PROGRA~1\IBM\WEBSPH~1\log\test\active 03/21/2004 18:04DIR . 03/21/2004 18:04DIR .. 03/21/2004 17:59 510,099 S0~1.GZ S000.LOG.gz 03/21/2004 18:02 704,207 S0~2.GZ S001.LOG.gz 03/21/2004 18:02
Re: MO71
No, I want the connection secure. I am going to use blockip program there.
It seems to be a good fit. I am just testing the MO71 pack to see if I can
get it to manage the unix type queue managers. I changed the mcauser to a
userid that works for me. I now get a green status on MQMON. The problem I
now have is that when I do a queue list or channel list mqmon says that it
sent the request but does not get anything back to display. Is there
something else on unix that I am overlooking?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 8:29 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
I'm not sure I understand. If my NT userid is db2admin why would it work
if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
Mike,
Are you suggesting that MQ should *always* trust the userid sent from the
client ? This would be a dangerous thing. You can configure your SVRCONN to
use the userid passed in ( MCAUSER(' ') ) or always use a userid of your
choosing ( MCAUSER('FRED') ). Of course the ideal is that you authenticate
with your client using something like SSL and then make an informed
decision about what to set the userid to reflect the state of your known
client but in the meantime you can just set a pre-defined fixed user of
sufficient authority.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
Ward, Mike S
[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: Re: MO71
[EMAIL PROTECTED]
N.AC.AT
22/03/2004 13:15
Please respond to
MQSeries List
I'm not sure I understand. If my NT userid is db2admin why would it work if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 4:04 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
I'm not sure what your security policy is; whether you're using SSL,
security exits or whatever but to get things working you could change the
MCAUSER of the SVRCONN to something which has the required authority. If
your MCAUSER is blank then you are even less secure since you'll
effectively believe any userid the client cares to throw at you.
On most platforms you can switch authority events on in the Queue Manager
and then you'll get a message whenever a security check fails. This
messages details the userid and the object being checked. Personally I find
this quite useful when tracking down security violations.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+
| | Ward, Mike S |
| | [EMAIL PROTECTED]|
| | Sent by: MQSeries|
| | List |
| | [EMAIL PROTECTED]|
| | N.AC.AT |
| ||
| ||
| | 19/03/2004 22:20 |
| | Please respond to|
| | MQSeries List|
|-+
---
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: MO71
|
|
|
|
|
---
--|
Thanks, I got it to work. I am also trying to connect to a SCO Unix
qmanager
and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not
authorized. I tried defining the userid of the NT box that has mqmon
running
on it and then modifying that user so that it has mqm as a group but I
still
get the same message. Any thoughts?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 3:50 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
MO71 supports two types of monitoring.
1/ Normal monitoring relies on a program at the remote Queue Manager to
receive the messages and send them back to the reply fields
This does therefore require a client (program) running on the remote
system
2/ Loopback monitoring allows yoiu to define a remote queue on the remote
system which just 'points' back to the originating queue.
This does not therefore require a client (program) running on the
remote system
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+
| | Ward, Mike S |
| | [EMAIL PROTECTED]|
| | Sent by: MQSeries|
| | List
Re: Managing linear logs with MQ5.3 on Windows
Rob Love the idea, and I am sure this must have been asked before but HOW and WHOM to talk to?? Cheers Rao -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 2:04 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Rao, Sounds like this would be a good addition to the current Support Pac or even a stand-alone Support Pac. Why not submit it? -- T.Rob -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Sunday, March 21, 2004 4:12 PM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Hi all I have experienced the same problem for the past few weeks in my current client site. PERL and JAVA have their own problems and I can't locate MS62 zip file for Windows version so on.. So on.. I don't understand why IBM doesn't provide a support pack that is native to windows platform ?? My guess as good as anyone - so I will leave it here. But anyway, I have developed a VB Script which does exactly the same as any perl/java script and put in place. If anybody wants to use it - here it is (attached as a txt file and just rename it to .VBS). The principle is same, reads the AMQERR01.LOG, finds out the last log number for media recovery and then deletes all previous ones. Feel free to modify to suit your needs. Cheers Rao Ps: Disclaimer - even though it is tested thoroughly, no guarantees are given. -Original Message- From: Luc-Michel Demey [mailto:[EMAIL PROTECTED] Sent: 20 March 2004 11:54 AM To: [EMAIL PROTECTED] Subject: Managing linear logs with MQ5.3 on Windows Hi all, I am trying to find if any of the available support packs are suitable for managing linear logs on a MQ 5.3 Windows NT box. I have done a little testing, most of them rely on the qm.ini file not more present above 5.0. Even with a fake ini file on the right place, I was not able to use : - MS0L : Java exception - MS62 : Perl problems In both cases (Java Perl), I suspect NT 4 related problems. Any ideas / experiences to share ? TIA, LMD. -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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 confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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 confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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: Managing linear logs with MQ5.3 on Windows
Hursley is the location of the IBM Labs that develop MQ. -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Tuesday, 23 March 2004 7:45 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Ken With due to respect, I am not sure what is this Hursley you are talking and how to get there. I usually logon to IBM WMQ Support pack homepage to download any support pack and here is the address: http://www-306.ibm.com/software/integration/support/supportpacs/individual/m s62.html On this page MS62 talks about how to install and run on windows, BUT NO ZIP FILE CAN BE SEEN. In I fact asked this question a month back, and haven't heard anything since then. Are you talking of another home page for Hursley where we can download this service pack. Believe me, it was damn frustrating to download something which doesn't exist. Hence I said bugger all, and built my own VB script for it. Cheers Rao -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: 11 January 2001 1:52 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows The MS62 support pack found on Hursley applies to both UNIX and Windows (W2K/WNT/WXP). For Windows, there is no mqs.ini file therefore you MUST specify the -n option to prevent the parsing of .ini files. Assuming you've installed perl on windows and have gzip on the system with its location specified in the %PATH% environment variable then the cleanmqlogs.pl script should work as documented. (see the support pak documentation for instructions on installing perl and associating the .PL suffix with perl). Note that if there are spaces in the directories you'll need to put double quotes around the directory specification or use the 8.3 representation. Here is an example, on windows, of an actual run of the MS62 support pak: (The queue manager is named test) C:\PROGRA~1\IBM\WEBSPH~1\binrcdmqimg -l -m test -t ALL * Media image for object test, type catalogue recorded. Media image for object test, type qmgr recorded. Media image for object SYSTEM.DEFAULT.PROCESS, type process recorded. Media image for object SYSTEM.DEFAULT.NAMELIST, type namelist recorded. Media image for object SYSTEM.DEFAULT.AUTHINFO.CRLLDAP, type authinfo recorded. Media image for object KEN.QL, type queue recorded. Media image for object MQMON, type queue recorded. Media image for object SYSTEM.ADMIN.CHANNEL.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.ADMIN.PERFM.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.QMGR.EVENT, type queue recorded. Media image for object SYSTEM.AUTH.DATA.QUEUE, type queue recorded. Media image for object SYSTEM.CHANNEL.INITQ, type queue recorded. Media image for object SYSTEM.CHANNEL.SYNCQ, type queue recorded. Media image for object SYSTEM.CICS.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.REPOSITORY.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.TRANSMIT.QUEUE, type queue recorded. Media image for object SYSTEM.DEAD.LETTER.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.ALIAS.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.LOCAL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.MODEL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.REMOTE.QUEUE, type queue recorded. Media image for object SYSTEM.MQSC.REPLY.QUEUE, type queue recorded. Media image for object SYSTEM.PENDING.DATA.QUEUE, type queue recorded. AMQ7467: The oldest log file required to start queue manager test is S022.LO G. AMQ7468: The oldest log file required to perform media recovery of queue manager test is S015.LOG. C:\PROGRA~1\IBM\WEBSPH~1\bin Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perlcleanmqlogs.pl ^ More? -t C:\Program Files\IBM\WebSphere MQ -l C:\PROGRA~1\IBM\WEBSPH~1\log -n test Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Media Recovery: S015.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Qmgr Restart: S022.LOG About to gzip test's S004.LOG About to gzip test's S005.LOG About to gzip test's S006.LOG About to gzip test's S007.LOG About to gzip test's S008.LOG About to gzip test's S009.LOG About to gzip test's S010.LOG About to gzip test's S011.LOG About to gzip test's S012.LOG About to gzip test's S013.LOG About to gzip test's S014.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl C:\PROGRA~1\IBM\WEBSPH~1\log\test\activedir Volume in drive C has no label. Volume Serial Number is C002-5176 Directory of C:\PROGRA~1\IBM\WEBSPH~1\log\test\active 03/21/2004
Re: Managing linear logs with MQ5.3 on Windows
Rao, On the web page you've listed download the ms62.tar.gz file listed towards the bottom of the page. You can open it with WINZIP. You then will have access to the cleanmqlogs perl script which will work on windows and unix. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Adiraju, Rao Sent: Monday, March 22, 2004 14:45 To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Ken With due to respect, I am not sure what is this Hursley you are talking and how to get there. I usually logon to IBM WMQ Support pack homepage to download any support pack and here is the address: http://www-306.ibm.com/software/integration/support/supportpacs/individual/m s62.html On this page MS62 talks about how to install and run on windows, BUT NO ZIP FILE CAN BE SEEN. In I fact asked this question a month back, and haven't heard anything since then. Are you talking of another home page for Hursley where we can download this service pack. Believe me, it was damn frustrating to download something which doesn't exist. Hence I said bugger all, and built my own VB script for it. Cheers Rao -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: 11 January 2001 1:52 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows The MS62 support pack found on Hursley applies to both UNIX and Windows (W2K/WNT/WXP). For Windows, there is no mqs.ini file therefore you MUST specify the -n option to prevent the parsing of .ini files. Assuming you've installed perl on windows and have gzip on the system with its location specified in the %PATH% environment variable then the cleanmqlogs.pl script should work as documented. (see the support pak documentation for instructions on installing perl and associating the .PL suffix with perl). Note that if there are spaces in the directories you'll need to put double quotes around the directory specification or use the 8.3 representation. Here is an example, on windows, of an actual run of the MS62 support pak: (The queue manager is named test) C:\PROGRA~1\IBM\WEBSPH~1\binrcdmqimg -l -m test -t ALL * Media image for object test, type catalogue recorded. Media image for object test, type qmgr recorded. Media image for object SYSTEM.DEFAULT.PROCESS, type process recorded. Media image for object SYSTEM.DEFAULT.NAMELIST, type namelist recorded. Media image for object SYSTEM.DEFAULT.AUTHINFO.CRLLDAP, type authinfo recorded. Media image for object KEN.QL, type queue recorded. Media image for object MQMON, type queue recorded. Media image for object SYSTEM.ADMIN.CHANNEL.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.ADMIN.PERFM.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.QMGR.EVENT, type queue recorded. Media image for object SYSTEM.AUTH.DATA.QUEUE, type queue recorded. Media image for object SYSTEM.CHANNEL.INITQ, type queue recorded. Media image for object SYSTEM.CHANNEL.SYNCQ, type queue recorded. Media image for object SYSTEM.CICS.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.REPOSITORY.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.TRANSMIT.QUEUE, type queue recorded. Media image for object SYSTEM.DEAD.LETTER.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.ALIAS.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.LOCAL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.MODEL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.REMOTE.QUEUE, type queue recorded. Media image for object SYSTEM.MQSC.REPLY.QUEUE, type queue recorded. Media image for object SYSTEM.PENDING.DATA.QUEUE, type queue recorded. AMQ7467: The oldest log file required to start queue manager test is S022.LO G. AMQ7468: The oldest log file required to perform media recovery of queue manager test is S015.LOG. C:\PROGRA~1\IBM\WEBSPH~1\bin Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perlcleanmqlogs.pl ^ More? -t C:\Program Files\IBM\WebSphere MQ -l C:\PROGRA~1\IBM\WEBSPH~1\log -n test Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Media Recovery: S015.LOG Z:\mqseries_related\support_pacs\ms62_lin_log_maint_perl\cleanmqlogs.pl: test: N eeded for Qmgr Restart: S022.LOG About to gzip test's S004.LOG About to gzip test's S005.LOG About to gzip test's S006.LOG About to gzip test's S007.LOG About to gzip test's S008.LOG About to gzip test's S009.LOG About to gzip test's S010.LOG About to gzip test's S011.LOG About to gzip test's S012.LOG About to gzip test's S013.LOG About to gzip test's S014.LOG
Re: Managing linear logs with MQ5.3 on Windows
Tim You haven't got my point. I am not talking of physical location of Hursely and how to get there. If you tell me, only way to get the zip file is to visit Hursely labs personally, I will be more than happy to travel from Land of Middle Earth to Land of North end (I need a vacation anyway and if my employer pays for it all the more fun). Because of my sheer frustration I put that sarcastic mail. Every body says there is a wonderful thing called MS62. But no body tells me, where on earth I can download the windows compatible zip file from. Only file I can see in that webpage was .tar.gz and even that I had problems opening with Winzip (and hence eventually gave it up). Cheers Rao Ps: Fyi - I knew Hursely labs since early 1980s, when I started working as a CICS systems programmer. -Original Message- From: Tim Armstrong [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 9:00 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Hursley is the location of the IBM Labs that develop MQ. -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Tuesday, 23 March 2004 7:45 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows Ken With due to respect, I am not sure what is this Hursley you are talking and how to get there. I usually logon to IBM WMQ Support pack homepage to download any support pack and here is the address: http://www-306.ibm.com/software/integration/support/supportpacs/individual/m s62.html On this page MS62 talks about how to install and run on windows, BUT NO ZIP FILE CAN BE SEEN. In I fact asked this question a month back, and haven't heard anything since then. Are you talking of another home page for Hursley where we can download this service pack. Believe me, it was damn frustrating to download something which doesn't exist. Hence I said bugger all, and built my own VB script for it. Cheers Rao -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: 11 January 2001 1:52 AM To: [EMAIL PROTECTED] Subject: Re: Managing linear logs with MQ5.3 on Windows The MS62 support pack found on Hursley applies to both UNIX and Windows (W2K/WNT/WXP). For Windows, there is no mqs.ini file therefore you MUST specify the -n option to prevent the parsing of .ini files. Assuming you've installed perl on windows and have gzip on the system with its location specified in the %PATH% environment variable then the cleanmqlogs.pl script should work as documented. (see the support pak documentation for instructions on installing perl and associating the .PL suffix with perl). Note that if there are spaces in the directories you'll need to put double quotes around the directory specification or use the 8.3 representation. Here is an example, on windows, of an actual run of the MS62 support pak: (The queue manager is named test) C:\PROGRA~1\IBM\WEBSPH~1\binrcdmqimg -l -m test -t ALL * Media image for object test, type catalogue recorded. Media image for object test, type qmgr recorded. Media image for object SYSTEM.DEFAULT.PROCESS, type process recorded. Media image for object SYSTEM.DEFAULT.NAMELIST, type namelist recorded. Media image for object SYSTEM.DEFAULT.AUTHINFO.CRLLDAP, type authinfo recorded. Media image for object KEN.QL, type queue recorded. Media image for object MQMON, type queue recorded. Media image for object SYSTEM.ADMIN.CHANNEL.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.ADMIN.PERFM.EVENT, type queue recorded. Media image for object SYSTEM.ADMIN.QMGR.EVENT, type queue recorded. Media image for object SYSTEM.AUTH.DATA.QUEUE, type queue recorded. Media image for object SYSTEM.CHANNEL.INITQ, type queue recorded. Media image for object SYSTEM.CHANNEL.SYNCQ, type queue recorded. Media image for object SYSTEM.CICS.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.COMMAND.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.REPOSITORY.QUEUE, type queue recorded. Media image for object SYSTEM.CLUSTER.TRANSMIT.QUEUE, type queue recorded. Media image for object SYSTEM.DEAD.LETTER.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.ALIAS.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.INITIATION.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.LOCAL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.MODEL.QUEUE, type queue recorded. Media image for object SYSTEM.DEFAULT.REMOTE.QUEUE, type queue recorded. Media image for object SYSTEM.MQSC.REPLY.QUEUE, type queue recorded. Media image for object SYSTEM.PENDING.DATA.QUEUE, type queue recorded. AMQ7467: The oldest log file required to start queue manager test is S022.LO G. AMQ7468: The oldest log file required to perform media recovery of queue manager test is S015.LOG. C:\PROGRA~1\IBM\WEBSPH~1\bin
Re: MO71
Mike, see if you have the command server running (dspmqcsv). HTH, Rebecca
-Original Message-
From: Ward, Mike S [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 3:48 PM
To: [EMAIL PROTECTED]
Subject: Re: MO71
No, I want the connection secure. I am going to use blockip program there.
It seems to be a good fit. I am just testing the MO71 pack to see if I can
get it to manage the unix type queue managers. I changed the mcauser to a
userid that works for me. I now get a green status on MQMON. The problem I
now have is that when I do a queue list or channel list mqmon says that it
sent the request but does not get anything back to display. Is there
something else on unix that I am overlooking?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 8:29 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
I'm not sure I understand. If my NT userid is db2admin why would it work
if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
Mike,
Are you suggesting that MQ should *always* trust the userid sent from the
client ? This would be a dangerous thing. You can configure your SVRCONN to
use the userid passed in ( MCAUSER(' ') ) or always use a userid of your
choosing ( MCAUSER('FRED') ). Of course the ideal is that you authenticate
with your client using something like SSL and then make an informed
decision about what to set the userid to reflect the state of your known
client but in the meantime you can just set a pre-defined fixed user of
sufficient authority.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
Ward, Mike S
[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: Re: MO71
[EMAIL PROTECTED]
N.AC.AT
22/03/2004 13:15
Please respond to
MQSeries List
I'm not sure I understand. If my NT userid is db2admin why would it work if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 4:04 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
I'm not sure what your security policy is; whether you're using SSL,
security exits or whatever but to get things working you could change the
MCAUSER of the SVRCONN to something which has the required authority. If
your MCAUSER is blank then you are even less secure since you'll
effectively believe any userid the client cares to throw at you.
On most platforms you can switch authority events on in the Queue Manager
and then you'll get a message whenever a security check fails. This
messages details the userid and the object being checked. Personally I find
this quite useful when tracking down security violations.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+
| | Ward, Mike S |
| | [EMAIL PROTECTED]|
| | Sent by: MQSeries|
| | List |
| | [EMAIL PROTECTED]|
| | N.AC.AT |
| ||
| ||
| | 19/03/2004 22:20 |
| | Please respond to|
| | MQSeries List|
|-+
---
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: MO71
|
|
|
|
|
---
--|
Thanks, I got it to work. I am also trying to connect to a SCO Unix
qmanager
and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not
authorized. I tried defining the userid of the NT box that has mqmon
running
on it and then modifying that user so that it has mqm as a group but I
still
get the same message. Any thoughts?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 3:50 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
MO71 supports two types of monitoring.
1/ Normal monitoring relies on a program at the remote Queue Manager to
receive the messages and send them back to the reply fields
This does therefore require a client (program) running on the remote
system
2/ Loopback monitoring allows yoiu to define a remote queue on the remote
system which just 'points' back to the originating queue.
This does not therefore require a client (program) running on the
remote system
Cheers,
P.
Paul G Clarke
WebSphere
Re: Linear Log cleanup - on WINDOWS platforms
Title: RE: Linear Log cleanup - on WINDOWS platforms Fellas To cover the following situation, I have modified the VB Script that I published yesterday and here is the latest version of it: Basically without getting bogged down with the following, I thought conservative approach is to check the minimum log number among last AMQ7467 and AMQ7468 messages and then take the lowest number as cut-off point. Hence the change. Please feel to use it and if you have any suggestions to improve, please let me know. In all our production servers, we have scheduled a batch job that issues a rcdmqimg followed by this VB script. No more hassles of manual cleaning of log files. Cheers Rao Ps: As usual, I have renamed the file as txt rather than vbs and do other way round to execute it. MQLog.txt _ From: Adiraju, Rao Sent: 22 March 2004 5:41 PM To: 'MQForum' Subject: Linear Log cleanup Fellows So far my understanding and as well as observation is that, in the logs MQ writes two entries every time one with AMQ7467 for MQ manger restart followed by another one with AMQ7468 for Media recovery. And all most all the time, AMQ7467 log number will be HIGHER or EQUAL than AMQ7468 log number. Hence even the VB Script that I developed (and circulated today in the MQForum) only looks at AMQ7468 entries and cleans up all the logs before that sequence number. But today in one of our production MQ logs, I have noticed the following - where AMQ7467 log number is LESS THAN the AMQ7468. Both entries are posted at the same time. Does it mean my understanding is wrong and if so, do I need to scan AMQ7467 messages as well and then choose the lesser number of the both. Is that's how the other PERL and _javascript_s are handling the log cleanup. According to the below, if I run my VB script it will delete 32131 log as well. Any other explanations ?? Thanks in advance. Rao --- 22/03/2004 17:17:18 AMQ7467: The oldest log file required to start queue manager X is S0032131.LOG. EXPLANATION: The log file S0032131.LOG contains the oldest log record required to restart the queue manager. Log records older than this may be required for media recovery. ACTION: You can move log files older than S0032131.LOG to an archive medium to release space in the log directory. If you move any of the log files required to recreate objects from their media images, you will have to restore them to recreate the objects. --- 22/03/2004 17:17:18 AMQ7468: The oldest log file required to perform media recovery of queue manager is S0032132.LOG. EXPLANATION: The log file S0032132.LOG contains the oldest log record required to recreate any of the objects from their media images. Any log files prior to this will not be accessed by media recovery operations. ACTION: You can move log files older than S0032132.LOG to an archive medium to release space in the log directory. - This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.Thank you. '-- ' MQLog.VBS - clean up facility for MQ LINER LOGs ' Author: Rao Adiraju Date: 2004-03-19 ' Tested for MQ V5.3 CSD06 ' Arguments are: ' Folder/Directory name where AMQERR01.LOG resides ' Folder/Directory name where Active logs are kept ' Delete flag - value Y or anything else. If Y then ' log files are physcially removed ' If anything else, just a report is produced (no ' deletion of files takes place) ' It is recommended to test it first wihtout DELETE FLAG and make ' ' sure every thing is correct as expected and then rerun is with Y (no ' quotes are required ' ' an output file - MQLog.Out - is created in the active directory '-- Dim Fsys Dim Instream Dim CutOffFileName Dim File7467, File7468 Dim FileName Dim Tline, CsrPos Dim ErrFolder Dim LogFolder Dim ErrorLogFile on error resume next set Args = Wscript.Arguments If args.count 2 then wscript.echo no input parameters given Wscript.quit(1) end if ErrFolder = args(0) Logfolder = args(1) If args.count = 3 then DelFlag = args(2) else DelFlag = end if set Fsys = Createobject(Scripting.FileSystemObject) if err then Wscript.echo Error Creating Object Wscript.quit(1) end if ' ... check
Re: Use channel exits or not?
Hi Peter, Thanks for this but I'm afraid that may be the question was not clear enough. We have existing applications that will connect to a new broker. We wanted to implement channel exits on the broker for the receiving channels from the applications and the sending channels to the applications, this was so we could record how long the messages are taking to get processed in the WBI MB flows on the hub. We have a constraint on us that we are not allowed to change the application platforms or deploy new applications on to them. We wanted to use channel exits as it meant no change to the flows that we are migrating over and we believed the channel exits would give us the best performance. The channel exits would also give us a more accurate timing as it would take into account the time in the flows as well as time on the MQSeries queues on the hub. However, we were put off by a couple of statements that were made: this will degrade channel performance an error in the exit could cause message loss The alternatives to the channel exit design given our constraints are: Use a message get MQ exit Use a stand-alone program Add a metrics node into the message flow. The main problems with the above approaches are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits. I would like to get peoples views on the two negative comments regarding use of channel exits and advise on what they would do and why to achieve what we want to do. Cheers, Kulbir. Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 22-Mar-2004 19:23 Please respond to MQSeries List [EMAIL PROTECTED] To: MQSERIES cc: Subject: Re: Use channel exits or not? Application connects to QMSpoke1. QMSpoke1 hosts aRemoteQueueA, pointing at RemoteQueueB, which lives on QMHub. RemoteQueueB on QMHub points back at LocalQueue1 on SpokeQM1. Application connects to QMSpoke1, and Opens RemoteQueueA for putting, and opens LocalQueue1 for getting. Put a message into RemoteQueueA. Record the time. Application immediatly MQGets from LocalQueue1. Record the time. Subtract the two times, and you have the amount of time a message takes to get thru the hub. Yes it includes time spent on the channels, but that is relevant. Put both QMs on the same box, and have your channels already running to eliminate these variables as much as possible. Do the test again by changing RemoteQueueA to point right to LocalQueue1 to see what a difference there is if you eliminate the channel/HUB hops. -Original Message- From: Kulbir S. Thind [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 2:00 PM To: [EMAIL PROTECTED] Subject: Use channel exits or not? Hi, We are planning on having a hub and spoke architecture that will see 100's of applications connect into the WBI MB hub we will implement. We have a requirement to be able to determine the amount of time that the messages have spent in the hub. We thought we would do this by implementing some auditing functionality using channel exits to copy the messages to another destinations as it arrives and as it leaves. We have had some worrying comments regarding using channel exits for this purpose, these comments are: this will degrade channel performance an error in the exit could cause message loss The alternatives to this approach are as follows: Use a message get MQ exit Use a stand-alone program Add a metrics node into the message flow. The main problems with the above approach are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits. Would anyone like to comment on this? Cheers, Kulbir. 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.
Re: MO71
That fixed it thanks.
-Original Message-
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 3:49 PM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike, see if you have the command server running (dspmqcsv). HTH, Rebecca
-Original Message-
From: Ward, Mike S [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 3:48 PM
To: [EMAIL PROTECTED]
Subject: Re: MO71
No, I want the connection secure. I am going to use blockip program there.
It seems to be a good fit. I am just testing the MO71 pack to see if I can
get it to manage the unix type queue managers. I changed the mcauser to a
userid that works for me. I now get a green status on MQMON. The problem I
now have is that when I do a queue list or channel list mqmon says that it
sent the request but does not get anything back to display. Is there
something else on unix that I am overlooking?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 8:29 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
I'm not sure I understand. If my NT userid is db2admin why would it work
if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
Mike,
Are you suggesting that MQ should *always* trust the userid sent from the
client ? This would be a dangerous thing. You can configure your SVRCONN to
use the userid passed in ( MCAUSER(' ') ) or always use a userid of your
choosing ( MCAUSER('FRED') ). Of course the ideal is that you authenticate
with your client using something like SSL and then make an informed
decision about what to set the userid to reflect the state of your known
client but in the meantime you can just set a pre-defined fixed user of
sufficient authority.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
Ward, Mike S
[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: Re: MO71
[EMAIL PROTECTED]
N.AC.AT
22/03/2004 13:15
Please respond to
MQSeries List
I'm not sure I understand. If my NT userid is db2admin why would it work if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 4:04 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
I'm not sure what your security policy is; whether you're using SSL,
security exits or whatever but to get things working you could change the
MCAUSER of the SVRCONN to something which has the required authority. If
your MCAUSER is blank then you are even less secure since you'll
effectively believe any userid the client cares to throw at you.
On most platforms you can switch authority events on in the Queue Manager
and then you'll get a message whenever a security check fails. This
messages details the userid and the object being checked. Personally I find
this quite useful when tracking down security violations.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+
| | Ward, Mike S |
| | [EMAIL PROTECTED]|
| | Sent by: MQSeries|
| | List |
| | [EMAIL PROTECTED]|
| | N.AC.AT |
| ||
| ||
| | 19/03/2004 22:20 |
| | Please respond to|
| | MQSeries List|
|-+
---
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: MO71
|
|
|
|
|
---
--|
Thanks, I got it to work. I am also trying to connect to a SCO Unix
qmanager
and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not
authorized. I tried defining the userid of the NT box that has mqmon
running
on it and then modifying that user so that it has mqm as a group but I
still
get the same message. Any thoughts?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 3:50 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
MO71 supports two types of monitoring.
1/ Normal monitoring relies on a program at the remote Queue Manager to
receive the messages and send them back to the reply fields
This does therefore require a client (program) running on the remote
system
2/ Loopback monitoring allows yoiu to define a remote queue on the
Re: Managing linear logs with MQ5.3 on Windows
Ken - thanks and it's very much appreciated. Most of my whinging was aimed at the work that was put in on IBM pages. If an upcoming software company does this sort of thing, I can understand and would have gone along with it. But I haven't expected it from IBM. If it instructions says download .zip for windows platforms I will look for zip file (FULL STOP). If their intention is to download .tar.gz and use WINZIP, the webpage SHOULD SAY SO. I hope those who are responsible to maintain those pages, understand my frustration and make necessary changes to make it consistent. Enough whinging on one topic. Once again thanks to all forum members for bearing it. Rao -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: 11 January 2001 11:07 AM To: [EMAIL PROTECTED] Subject: RE: Managing linear logs with MQ5.3 on Windows Hi Rao, I've attached the MS62 support pac in .ZIP format. I didn't have any problem unzipping ms62.tar.gz using WINZIP. Cheers, KenW This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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: Managing linear logs with MQ5.3 on Windows
We currently use the MS62 support pack to clean up linear logs. It was mentioned that the MS0L support pack offers a JAVA solution for cleaning up linear logs for windows. I downloaded MS0L and found the following procedure to work on windows: For windows usage, first create a qm.ini in MQ top dir\qmgrs\queue mgr name eg: C:\PROGRA~1\IBM\WEBSPH~1\Qmgrs\test The contents of qm.ini should consist of one line: LogType=LINEAR Include the mqllm.jar file in the classpath: c:\set classpath=%classpath%;dir path to mqllm.jar\mqllm.jar eg: c:\ set classpath=%classpath%;c:\java_stuff\mqllm.jar For a queue manager named test execute the following: c:\ java com.ibm.aim.logfile.AimMqLinearLogfileMaint -q test -d C:\PROGRA~1\IBM\WEBSPH~1 -a C:\archive -v Here, C:\PROGRA~1\IBM\WEBSPH~1 is the mqseries top level directory and c:\archive is where the zipped logs are to be stored. I found the placement and contents of the qm.ini file by trial and error. The documentation doesn't seem to mention anything about qm.ini on windows. If anyone else has had experience with the JAVA version of MS0L on windows it would interesting to here from you. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Luc-Michel Demey Sent: Friday, March 19, 2004 16:54 To: [EMAIL PROTECTED] Subject: Managing linear logs with MQ5.3 on Windows Hi all, I am trying to find if any of the available support packs are suitable for managing linear logs on a MQ 5.3 Windows NT box. I have done a little testing, most of them rely on the qm.ini file not more present above 5.0. Even with a fake ini file on the right place, I was not able to use : - MS0L : Java exception - MS62 : Perl problems In both cases (Java Perl), I suspect NT 4 related problems. Any ideas / experiences to share ? TIA, LMD. -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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
