Re: Client conversion from Windows to OS/390
If the msg is string format, the channel should convert it. You do have to stop/start the channel if it is running when you change the conversion option. -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Client conversion from Windows to OS/390 Peter, Thanks for your reply. The channel from the Windows client to the first OS/390 is a svrconn, so there is no conversion parameter to turn on. I have tried to turn on conversion for the channel between the first OS/390 and the second OS/390, but that does not help. Regards, John -Original Message- From: Peter Heggie [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 12:34 PM To: [EMAIL PROTECTED] Subject:Re: Client conversion from Windows to OS/390 You could dedicate a pair of channels for this application and perform the conversion on the channel.. From: "Dawson, John" <[EMAIL PROTECTED]> on 12/05/2002 01:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John 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: Expiry Overhead
Just a thought. Could the Perl script be opening the queue with exclusive access and somehow slowing some process in the application which also accesses this queue? -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 11:40 AM To: [EMAIL PROTECTED] Subject: Expiry Overhead We've had some performance problems in a synchronous app lately. It's a VB-NT client connected to a Solaris concentrator. Messages are put to a queues that go thru WMQI on Solaris. Flows convert XML to Cobol, and forward them to the mainframe. CICS programs do some DB2 work, and send replies that follow the same path in the opposite direction. We've noticed that these round trips slow way, way down at noon and 4:00 PM on Monday, Thursday and Friday. But we don't see this on Tuesday and Wednesday. After much research, we found a Perl script that runs on the WMQI server every day at noon and 4:00. The script goes through a queue and does GETs for a length of 0. This queue is an output only, archive queue, with messages that expire 3 days after they're put. The purpose of the script is to allow messages older than three days to expire. Our theory is that the overhead of expiration is noticeably slowing down WMQI. The reason Tuesday and Wednesday are OK is because far fewer messages expire on those days (since the only messages eligible to expire were from the previous weekend). We turned this script off, and will know on Friday if this is the problem. Our WMQI server is a dual processor machine loaded with memory. It's very surprising to me this script could hurt throughput this much, but it certainly looks that way. Has anyone seen this? Does IBM have any info as to what sort of overhead is involved in expiring messages? 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 when CKTI comes up
One of the prerequisites for trigging is that a trigger monitor must have the initiation queue open for input. This is likely the reason. -Original Message- From: MCSHEFFREY, MICHELLE (AIT) [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 12:38 PM To: [EMAIL PROTECTED] Subject: Triggering when CKTI comes up If there are messages on a queue that is set to trigger a CICS transaction on FIRST, and the CICS region is down, will a trigger message be generated when the CICS region and CKTI trigger monitor first come up? I thought yes, but IBM support just told me no. I don't want to spend a lot of time looking at the wrong problem (we're getting a trigger when CICS comes up in production but not in test), so please someone tell me which is correct. Thanks. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Am I asking too much to MQ?!?! (PROTOm@il:200211221193 CENTRO SIM)
According to the description of the reason code, this can happen if your logs aren't large enough to support the unit of work. How large are you're logs? circular or linear? -Original Message- From: Alessandro Caffarra [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 7:06 AM To: [EMAIL PROTECTED] Subject: R: Am I asking too much to MQ?!?! (PROTOm@il:200211221193 CENTROSIM) Dave, I have checked this parameter, and it is at his default value of 1. -Messaggio originale- Da: Hill, Dave [mailto:[EMAIL PROTECTED]] Inviato: venerdì 22 novembre 2002 15.52 A: [EMAIL PROTECTED] Oggetto: Re: Am I asking too much to MQ?!?! (PROTOm@il:200211221154 CENTROSIM) What is your max on uncommitted MSGS? -Original Message- From: Alessandro Caffarra [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:21 AM To: [EMAIL PROTECTED] Subject: Am I asking too much to MQ?!?! (PROTOm@il:200211221113 CENTROSIM) As many of know, I am sending a file from a Win2K MQ to a MVS-based MQ. For some file integrity reason I am sending all records within the same SYNCPOINT: if all records are gone (I.E. my app reached the EOF without any bad retcode from MQ), I will issue a MQCMIT once. Today the input file is about 6000 rks, about 380 byte each, and MQ return a retcode 2 with reason 2003, after 4754 rks. Am I asking too much?! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQGET with CORRELID on OS/390.
The default on OS390 is 3 which is the combination of 1 (match msg id) and 2 (match correlid), so adding 2 more gives 5 which is 4 (match group id) and 1 (match msg id), I think. Anyway, you're original code of moving MQMO-NONE (0) and then adding MQMO-MATCH-CORREL-ID (2) should have given you the desired value of 2. Are you sure the messages are committed to the queue? Are you sure the value '12345' you are moving into the field (right filled with spaces) has the same byte value as the actual correlid of the message? -Original Message- From: Shah, Urvesh (CAP, GEFA Contractor) [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 2:28 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. I have. Sorry, I did not mention it before. I have these 2 lines *before* the code I mentioned in my previous email. MOVE MQMI-NONE TO MQMD-MSGID MOVE MQCI-NONE TO MQMD-CORRELID Thanks and regards, Urvesh. -Original Message- From: Ronald Weinger [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 4:33 PM To: [EMAIL PROTECTED] Subject: Re: MQGET with CORRELID on OS/390. Try moving the appropriate 'none' value to MQMD-MSGID. "Shah, Urvesh (CAP, GEFA Contractor)" <[EMAIL PROTECTED]> @AKH-Wien.AC.AT> on 11/18/2002 03:23:16 PM Please respond to "MQSeries List" <[EMAIL PROTECTED]> Sent by:"MQSeries List" <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:MQGET with CORRELID on OS/390. Hi, I am trying to select a message based on the value in MQMD-CORRELID and am not able to. Here's what I am doing: 1. Putting 3 messages in a local queue in batch mode with the correlId's set as '12345', '8' and '9'. 2. Trying to get the message with the correlId = '12345' with the following code (again using a different program in batch): MOVE '12345' TO MQMD-CORRELID MOVE MQMO-NONE TO MQGMO-MATCHOPTIONS ADD MQMO-MATCH-CORREL-ID TO MQGMO-MATCHOPTIONS The queue is PUT and GET enabled with INDEX TYPE = C (for CORREL-ID). I tried commenting the second line in the code above making the MATCHOPTIONS field value = 5 (3 default + 2 for MQMO-CORREL-ID), but it doesn't seem to retrieve the message with correl-id = '12345'. Any pointers?? Thanks in advance for your help. Best regards, Urvesh. 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 The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Waitinterval and response time of CICS transaction
Title: Waitinterval and response time of CICS transaction I think this may be because the default on OS390 (if not otherwise specified) is that puts are done in syncpoint. I've seen this problem before. The program issues a put not knowing that it is within syncpoint and then waits for a reply. The reply doesn't come, the program ends (thus issuing an implicit commit) and voila, the messages suddenly appear on the queue. The truth is they were there all along but not hardened by a commit and therefore not available to the MQGET command. Nick -Original Message-From: Jose, Prince [mailto:[EMAIL PROTECTED]]Sent: Thursday, November 14, 2002 11:22 AMTo: [EMAIL PROTECTED]Subject: Waitinterval and response time of CICS transaction Environment: MQSeries 5.2 on OS390 and CICS Hello, I have never done any MQcoding myself, so please excuse me if this sounds very dumb It is about the response time of a CICS transaction and the wait interval coded on the MQGET. Our application programmers are working on a CICS transaction doing PUT(request) to an MQ queue and doing a GET with WAIT from a reply queue. The response time of this transaction is always equal to the Waitinterval coded in the MQGET call. As I understand it, waitinterval is the max time, the MQGET call waits for the messages to arrives in the queue. Now if we code a waitinterval of 30seconds and say, 10 message arrives in the queue within 2seconds, the program should be able to process these 10 messages immediately as they arrive in the queue right? Then what are we doing wrong here? Any inputs will be greatly appreciated. Thanks, Prince
Re: MQJMS3013
If you want to see your posts you need to send the message SET MQSERIES REPRO to [EMAIL PROTECTED] -- not the mqseries listserver address. Your messages have been reaching the listserver. "You may leave the list at any time by sending a "SIGNOFF MQSERIES" command to [EMAIL PROTECTED] You can also tell LISTSERV how you want it to confirm the receipt of messages you send to the list. If you do not trust the system, send a "SET MQSERIES REPRO" command and LISTSERV will send you a copy of your own messages, so that you can see that the message was distributed and did not get damaged on the way. After a while you may find that this is getting annoying, especially if your mail program does not tell you that the message is from you when it informs you that new mail has arrived from MQSERIES. If you send a "SET MQSERIES ACK NOREPRO" command, LISTSERV will mail you a short acknowledgement instead, which will look different in your mailbox directory." -Original Message- From: Stu Barrett [mailto:stu.barrett@;CALEBTECH.COM] Sent: Tuesday, November 12, 2002 9:42 AM To: [EMAIL PROTECTED] Subject: FW: MQJMS3013 Still not seeing this one... Is anyone else? Stu > -Original Message- > From: Stu Barrett > Sent: Tuesday, November 12, 2002 8:04 AM > To: '[EMAIL PROTECTED]' > Subject: FW: MQJMS3013 > > > I never saw this one... Sending again, to make sure that it gets distributed. > > Stu > > -Original Message- > From: Stu Barrett > Sent: Monday, November 11, 2002 5:30 PM > To: '[EMAIL PROTECTED]' > Subject: MQJMS3013 > > > I have a MQ/JMS publisher and many MQ/JMS subscribers. The publisher sends out messages are the rate of 1-5/sec. Periodically some subscribers will stop receiving messages. When this happens, the subscriber attempts to close the subscription and gets this exception: > > com.ibm.mq.MQException: Completion Code 2, Reason 2033 > javax.jms.JMSException: MQJMS3013: Failed to store admin. entry > at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.jav a:418) > at com.ibm.mq.jms.MQSubAdmin.removeND(MQSubAdmin.java:1045) > at com.ibm.mq.jms.MQTopicSubscriber.close(MQTopicSubscriber.java:452) > > This seems to confirm that something bad has happened to the subscription since not only do I stop receiving messages, but an exception is thrown when I attempt to do a normal unsubscribe. > > This is very sporadic, works fine most of the time. > > Any clues? > > I've been lucky in that JMS has insulated me from the details of MQ, but would like to know how to (I'm familiar with the runmqsc commands) find what JMS subscribers there are for a topic, and their state. Is this possible? > > Stu Barrett (512) 617-2119 > CALEB Technologies, Corp. (512) 345-1974 (fax) > 9130 Jollyville Road, Suite 100 [EMAIL PROTECTED] > Austin, TX 78759 www.calebtech.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 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: NT/2k: trigger monitor stalls in batch window, need Enter key .
Title: RE: NT/2k: trigger monitor stalls in batch window, need Enter key . Just curious. Is this somehow a better way to install a trigger monitor than by right clicking on the qmgr in the Services Explorer and selecting new/trigger monitor? -Original Message-From: DeFreitas, Nigel [mailto:[EMAIL PROTECTED]]Sent: Monday, November 04, 2002 12:31 PMTo: [EMAIL PROTECTED]Subject: Re: NT/2k: trigger monitor stalls in batch window, need Enter key . Go into the MQSeries Services and add a custom service with a start command like this: "C:/Program Files/IBM/MQSeries/bin/runmqtrm.exe -q YOUR_INIT_Q.INIT", execution: process, startup: after, startup type: automatic. This is better (than the dos option) because it starts automatically after the MQ Service starts when you reboot your servers. Nigel DeFreitas Insurance Services Office 201 469 3939 -Original Message-From: Benjamin Zhou [mailto:[EMAIL PROTECTED]] Sent: Monday, November 04, 2002 1:39 PMTo: [EMAIL PROTECTED]Subject: Re: NT/2k: trigger monitor stalls in batch window, need Enter key . Rich, thanks a lot for the info. we use v5.2.1 nt/2k with CSD5. if yours works fine, there's no reason for me to worry anymore. best regards, Ben -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] Sent: Monday, November 04, 2002 12:25 PM To: [EMAIL PROTECTED] Subject: Re: NT/2k: trigger monitor stalls in batch window, need Enter key . I have it running as a service on V5.2.1 Win/2000, CSD3 without any problems. I've also used it on V5.1 NT, CSD4 (I think) as well. Benjamin Zhou <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: cc: MQSeries List Subject: Re: NT/2k: trigger monitor stalls in batch window, en.AC.AT> 11/04/2002 11:49 AM Please respond to MQSeries List Hi Rick, thanks for the reminder. What's your experiece with running trigger monitor as service in the current version of MQ on Win2k server? I had bad experience with running triggermonitor as server in version 5 on NT a while back, when it just didn't trigger, and I can't see the cause. Since then I just refrain from using it. It might not be justified anymore. best regards, Ben -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] Sent: Monday, November 04, 2002 11:24 AM To: [EMAIL PROTECTED] Subject: Re: NT/2k: trigger monitor stalls in batch window, need Enter key. Why not run it as a service? Benjamin Zhou <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: cc: MQSeries List Subject: NT/2k: trigger monitor stalls in batch window, en.AC.AT> 11/04/2002 10:19 AM Please respond to MQSeries List Hi All, We run trigger monitor in a batch window. Once a while, I notice it stays there running but is not triggering, until I hit the Enter key. I never experienced such problem on other platforms. So I suppose it's a NT/2k bug. Has anyone also experienced such? is there a know solution or trick for this? thanks, Benjamin Zhou Princeton Financial. 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: NT/2k: trigger monitor stalls in batch window, need Enter key .
Title: RE: NT/2k: trigger monitor stalls in batch window, need Enter key. I run the trigger monitor using the MQ Explorer Services. I'm using it for the DLQ handler program and it's been working fine. Nick -Original Message-From: Benjamin Zhou [mailto:[EMAIL PROTECTED]]Sent: Monday, November 04, 2002 8:50 AMTo: [EMAIL PROTECTED]Subject: Re: NT/2k: trigger monitor stalls in batch window, need Enter key . Hi Rick, thanks for the reminder. What's your experiece with running trigger monitor as service in the current version of MQ on Win2k server? I had bad experience with running triggermonitor as server in version 5 on NT a while back, when it just didn't trigger, and I can't see the cause. Since then I just refrain from using it. It might not be justified anymore. best regards, Ben -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] Sent: Monday, November 04, 2002 11:24 AM To: [EMAIL PROTECTED] Subject: Re: NT/2k: trigger monitor stalls in batch window, need Enter key. Why not run it as a service? Benjamin Zhou <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: cc: MQSeries List Subject: NT/2k: trigger monitor stalls in batch window, en.AC.AT> 11/04/2002 10:19 AM Please respond to MQSeries List Hi All, We run trigger monitor in a batch window. Once a while, I notice it stays there running but is not triggering, until I hit the Enter key. I never experienced such problem on other platforms. So I suppose it's a NT/2k bug. Has anyone also experienced such? is there a know solution or trick for this? thanks, Benjamin Zhou Princeton Financial. 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: HELP: 2035, NOT_AUTHORIZED
You might check the qmgr error log for an 8077 msg to see what is causing (Bthe 2035 reason code. It may be that there are some security authorization (Bscripts which need to be run. (B (B-Original Message- (BFrom: taguti [mailto:[EMAIL PROTECTED]] (BSent: Monday, October 21, 2002 8:04 PM (BTo: [EMAIL PROTECTED] (BSubject: HELP: 2035, NOT_AUTHORIZED (B (B (BHello, (B (BI'm in trouble to connect to MQ server. (BI'm reading IBM MQ manuals, feeling sad, (Bsomwhat complexed in auhentication. (B (BMy fellow made windows dll for mq connectin for (BIIS vbscript with MA?? IBM support pack. (BIt is unnnig on windows NT4 server to connect to (BAIX MQ server. (BAnd he died some months ago, then the dll has come to (Bbe a black box. (B (BNow I must construct another windows IIS server with (Bwindows 2000 server. (BI copied all (dll, IIS's vbscript, registory info, (BAMQCLCHL.TAB $B!! (Band ENV info starting "MQ"), but the dll (Bsays just "MQ 2035 error". (B (BHow can I overcome this? (B (BRegards, (BHirosi Taguti ([EMAIL PROTECTED] (B (BInstructions for managing your mailing list subscription are provided in (Bthe Listserv General Users Guide available at http://www.lsoft.com (BArchive: http://vm.akh-wien.ac.at/MQSeries.archive (B (BInstructions for managing your mailing list subscription are provided in (Bthe Listserv General Users Guide available at http://www.lsoft.com (BArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Dynamic Queue Names
Now that I look at it, no. It appears they are just unique strings (letters & numbers). -Original Message-From: Tony Reddiough [mailto:[EMAIL PROTECTED]]Sent: Thursday, October 17, 2002 12:36 AMTo: [EMAIL PROTECTED]Subject: Re: Dynamic Queue Names I don't think so, I tried it out with the exerciser you get with MQ for Win2k. Do you still have time stamps on 5.2 ? Tony Reddiough Certified MQSeries Specialist Tel: +44 (0) 1793 616100 Mobile: +44 (0) 7711 264281 www.alphacourt.com Alphacourt - "The Integration Practice" -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of DiLauro, NickSent: 16 October 2002 18:51To: [EMAIL PROTECTED]Subject: Re: Dynamic Queue Names I'm not sure if it has changed since I'm still using v5.2. But remember that if the DynamicQueueName of the MQOD is not terminated with an asterisk, then the unique portion of the name will not be generated. Could an application be doing this inadvertently? -Original Message-From: Tony Reddiough [mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 16, 2002 3:30 AMTo: [EMAIL PROTECTED]Subject: Dynamic Queue Names Am I going mad ? I could have sworn that the unique part of a dynamic queue name used to be something that looked like a date/time stamp. Now it looks to have changed (at least on my 5.3 system on Win 2K). Can anyone else confirm when this changed and what it is now. It's not a big deal, I'm just curious. Tony. Tony Reddiough Certified MQSeries Specialist Tel: +44 (0) 1793 616100 Mobile: +44 (0) 7711 264281 www.alphacourt.com Alphacourt - "The Integration Practice"
Re: Dynamic Queue Names
I'm not sure if it has changed since I'm still using v5.2. But remember that if the DynamicQueueName of the MQOD is not terminated with an asterisk, then the unique portion of the name will not be generated. Could an application be doing this inadvertently? -Original Message-From: Tony Reddiough [mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 16, 2002 3:30 AMTo: [EMAIL PROTECTED]Subject: Dynamic Queue Names Am I going mad ? I could have sworn that the unique part of a dynamic queue name used to be something that looked like a date/time stamp. Now it looks to have changed (at least on my 5.3 system on Win 2K). Can anyone else confirm when this changed and what it is now. It's not a big deal, I'm just curious. Tony. Tony Reddiough Certified MQSeries Specialist Tel: +44 (0) 1793 616100 Mobile: +44 (0) 7711 264281 www.alphacourt.com Alphacourt - "The Integration Practice"
Re: AMQCLCHL.TAB for OpenVMS
Are you using one amqclchl.tab for all your qmgrs, new and existing? If so, you should be able to update the connection name for these existing qmgrs and re-export the channel table. -Original Message- From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 12:49 PM To: [EMAIL PROTECTED] Subject: AMQCLCHL.TAB for OpenVMS Hi, We have MQSeries Server on Windows NT. We tested OpenVMS client connectivity once after which name of the NT server was changed. Any new Queue Manager that is created on the server can be accessed from OpenVMS. But we cannot access existing (prior to renaming) Queue Managers. The OpenVMS connects using file AMQCLCHL.TAB How can we recreate this file for existing Queue Managers? Thanks == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == 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: MQRC_NOT_AUTHORIZED
There should be a corresponding message on the error log which tells you which userid was rejected (8077 I think). This will at least tell you what userid the server is seeing. Also, if you are using a SvrConn channel, check to see if it has an MCA UserId assigned to it. -Original Message- From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 9:02 AM To: [EMAIL PROTECTED] Subject: MQRC_NOT_AUTHORIZED Hi, We have MQSeries Server on WinNT. Existing application runs on same box. Just installed Client software on Solaris with user id mqm in group mqm. When tried sample, received 2035 Any suggestions? Thanks == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == 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: Oldest media log not advancing with rcdmqimg
This is a known problem which is supposed to be fixed by CSD05. You can find the description in the summary of changes for the CSD. I think the real problem is that the error logs are not rolling over properly because of an authority issue. Check your error logs for the queue manager and see when the latest update was. Since there are no updates, the log utility has no info on which logs are obsolete. As you can see this is a more far reaching problem since you are not getting any info on your error logs. We had a qmgr lock up but could not find the cause because the qmgr was not able to write to the logs. We got around the problem by manually changing the permissions on the error log directory and files. Also, we've already scheduled the install of CSD05. http://www-3.ibm.com/software/ts/mqseries/support/summary/wnt.html See APARs IC32609, IC32968, IY27208 for CSD05 v5.2 Nick -Original Message- From: GIES, STEVE [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 6:57 AM To: [EMAIL PROTECTED] Subject: Oldest media log not advancing with rcdmqimg Hello Listers - I've come across a problem this morning that I'm hoping someone can shed some light on. We have a test server that has three queue managers installed that all use linear logging. The server is WinNT V4 SP6a and MQSeries is V5.2 w/ CSD03 installed. Every night we run a job that issues a rcdmqimg against each queue manager and then runs a utility to clean up log files that are no longer needed. The utility makes this determination by looking at what is the oldest log required for media recovery. This morning we started getting alerts that we were running low on disk space on the logging drive. What I discovered is that for one of the queue managers, the oldest log needed for media recovery was from several months ago. I've tried manually running the rcdmqimg command and have checked the output for errors - thinking that we might have some queue that was causing an error - but I could not find anything. Now I'm stumped. Has anyone else run into a similar issue? If so, were you able to resolve it? Steve Gies SAFECO Insurance MQSeries Technical Support 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: Lost MQ message (They are fast and nonpersistent)
The reply could also be lost anywhere along the route if the expiry time has been exhausted. Is this a possibility? -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 10:02 AM To: [EMAIL PROTECTED] Subject: Lost MQ message (They are fast and nonpersistent) My customer's application is losing an occasional message and I can't figure out why. Maybe someone has something else I can look at. VB app client connects to QM1 to put a nonpersistent request message to a remote queue pointing to Queue1 on QM2. Put is outside of syncpoint and the Expiry is 3 days. Message is routed thru our Hub (QMHUB) and lands on Queue1 on QM2. Queue1 is triggered on first and starts up a C program running locally on the Unix Tru64 box housing QM2. The reply is built and put to the ReplytoQueue/ReplytoQueueManager of the Request message. The Expiry of the reply is equal to the remaining Expiry of the request. The request is nonpersistent and outside of syncpoint. The replying app has its internal logging turned on is outputting to a file the MQPUT1 RC, the reply to info it used, the expiry, etc. 99% of the time everything is OK. But occasionally the requestor said it didn't get a reply. The reply queue has no orphaned reply messages. The log for the replier says that it did receive the request and did in fact put out the reply. But the message is gone. Not on the reply queue, not on the DLQ or any XMIT queue on QM1, QM2 or QMHUB. Using MO71, I see via Queue statistics that the replier did get X messages put onto its request queue, and X messages were removed from the request queue. The replier confirms that they put X requests. The replier's log says they got X requests, and put X replies. The reply queue statistics however say that only X-1 messages were put to the queue and X-1 messages were gotten from the queue. Where is this message disappearing to? The only thing I have left now is the fact that the channel from QM2 to QMHUB and from QMHUB to QM1 is defined as MQNPS_FAST. And the Intercommunications manual says the following: > If a channel terminates while fast, nonpersistent messages are in transit, the messages may be lost and it is up to the application to arrange for their recovery if required. Similarly, if the MQPUT by the receiving MCA fails for any reason, the messages are lost. > Could my message be getting tossed? How would I know this is happening? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CSD rollback procedures v5.2 on NT
Never mind. I think I found the answer under the Start/programs/Ibm mqseries/remove latest csd. I'll try it out. > -Original Message- > From: DiLauro, Nick > Sent: Tuesday, August 13, 2002 3:28 PM > To: 'MQSeries listserver' > Subject: CSD rollback procedures v5.2 on NT > > I've never yet had to rollback a CSD, but I need to test the procedure to > estimate the time. What is the procedure for rolling back to a previous > CSD. The CSD creates a directory for this purpose, but using the > deinst.exe in the temp install directory directs me to use the add/remove > programs options in the Control Panel. This appears to have no option for > uninstalling just the previous CSD. Is there a procedure for a rollback? > TIA Nick > > Nicholas C. DiLauro > MQSeries Administrator > Technical Services > IBM Certified Specialist - MQSeries > IBM Certified Developer - MQSeries > > QRS Corporation > 1400 Marina Way South, MS 231 > Richmond, California 94804 > > 510 231 6544 Voice > 510 621 6544 Fax > [EMAIL PROTECTED] > > > 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
CSD rollback procedures v5.2 on NT
I've never yet had to rollback a CSD, but I need to test the procedure to estimate the time. What is the procedure for rolling back to a previous CSD. The CSD creates a directory for this purpose, but using the deinst.exe in the temp install directory directs me to use the add/remove programs options in the Control Panel. This appears to have no option for uninstalling just the previous CSD. Is there a procedure for a rollback? TIA Nick Nicholas C. DiLauro MQSeries Administrator Technical Services IBM Certified Specialist - MQSeries IBM Certified Developer - MQSeries QRS Corporation 1400 Marina Way South, MS 231 Richmond, California 94804 510 231 6544 Voice 510 621 6544 Fax [EMAIL PROTECTED] 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: Truncated Failed Messages and the BackOutCount
The backout count only applies for messages that are backed out within a unit of work, explicitly or through an abend. So, in the case described, even if the MQBACK command were issued, it would be a NO OP since the get was done with No-syncpoint. Even if the get was done with syncpoint and then an MQBACK was issued after receiving the 2080, the BACKOUT count is still zero, since the message was not backed out, but remained on the queue because of the 2080. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 12:03 PM To: [EMAIL PROTECTED] Subject: Truncated Failed Messages and the BackOutCount About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Intermittent failures MQIC32.dll
The default syncpoint option on OS390 is to use syncpoint. The default on distributed platforms is to not use syncpoint. If you are using the default, perhaps your put and get on OS390 are operating in the same syncpoint. Thus the reply never returns because the message is never put (i.e. you didn't explicitly commit so it takes place when the program ends). Just a possibility which I've seen happen in the past. Can't explain the 75% on one platform but one of many possibilities is that the response or request is expiring. -Original Message-From: Gary Chesser [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 8:42 AMTo: [EMAIL PROTECTED]Subject: Intermittent failures MQIC32.dll I am passing Structs back and forth from the raw MCIC32.dll wrapper on Windows 2000. This code is running concurrently with completely independent COM+ application which is also using the MQIC32.dll via CMQB.bas. The CMQB.bas file is working all the time and is able to retrieve messages which match the MSGID and CORRELID in production. TheThe wrapper application works 75% of the time in production and all the time in a similar development environment but the production environment is not able to find the matching message and returns 2033 ( Timeouts ). The Queue managers are on different machines and I do not know if they are set up identically. I have seen that the messages in production are on the queue but we do not pick them up. Which I assume is because the CorrelID and MSGID do not match.Could this be a problem with differences in the MQ Server ? I wondered about the CCSID butAnyone have any thoughts. I have been a single user and found that placing a message on the queue does have the correct Correl ID when I do not use this to retrieve the message via the correlID. Last and bewildered. Gary
Re: MQ5.2 install issue
Could it be missing one of the other required pieces such as MMC, or does it specifically indicate the server version? There is a directory on the disk which contains some of the prerequisites. Nick -Original Message- From: Bruce Baxter [mailto:[EMAIL PROTECTED]] Sent: Monday, July 15, 2002 9:42 AM To: [EMAIL PROTECTED] Subject: Re: MQ5.2 install issue Yes. I did that, and it verified '6a' build 1381, just like most of the other systems I've tested on. I wonder if this has anything to do with this being NT Server and not Workstation, like the other's I tested on. "Gorse, Darry" cc: Sent by: Subject: Re: MQ5.2 install issue MQSeries List 07/15/2002 11:45 AM Please respond to MQSeries List Have you verified by using WINVER? Look for "Revised Service Pack 6a" in the pop up window Cheers, Darry -Original Message- From: Bruce Baxter [mailto:[EMAIL PROTECTED]] Sent: Monday, July 15, 2002 9:39 AM To: [EMAIL PROTECTED] Subject: MQ5.2 install issue I'm having problems installing MQ Series 5.2 on a Win NT 4.0 Server that appears to have SP6A installed on it, yet the MQ installation process fails this for a pre-requisite. Has anyone else seen this problem? 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: Queue depth in Cobol
You can put a message to the SYSTEM.COMMAND.INPUT queue (assuming your program has the authority). DISPLAY QUEUE(MYQUEUE)CURDEPTH is the command. You have to specify a reply to q and qmgr. Then you get the reply messages and check the depth. I believe three messages are returned and the second one contains the depth. I haven't got time right now to look up the format, but it should be available in the Prorammable System Management manual. Nick -Original Message- From: Schaeffer, Dave [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:26 PM To: [EMAIL PROTECTED] Subject: Queue depth in Cobol Hi, Is there a way to get the queue depth in a Cobol program? Dave Schaeffer IT Database Leader Bendix Commercial Vehicle Systems LLC 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: AMQ6174 on WinNT V5.2.1 + CSD04
I
encountered the same problem with our exit when I installed MQ 5.2 without
uninstalling version 5.1. I was using CSD3 with an efix at the time.
I uninstalled and uninstalled completely and reinstalled 5.2 and the problem
disappeared. I opened a PMR with IBM but closed it when I resolved the
problem. I think the recommended procedure is to completely uninstall v5.1
before installing 5.2. Hope this helps.
Nick
-Original Message-From: Art Schanz
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, June 12, 2002
12:39 PMTo: [EMAIL PROTECTED]Subject: AMQ6174 on
WinNT V5.2.1 + CSD04Greetings, OK
folks...we have quite a 'stumper' here and need some help. For some
reason, our Receive exit on a SVRCONN chl will not load at chl startup.
Trace info indicates a 'not found' conditionwhich is not the
problem. We are guessing it might be maintenance related, as we have
another box at V5.2.1 base (CSD01) which does not encounter the
problem. The
AMQERR01.LOG entries follow: 06/10/02
09:18:51 AMQ6174: The library
D:\MQSeries\exits\RECEIVEX.dll was not found. The queue manager will continue without this module.
EXPLANATION: The dynamically loadable file
D:\MQSeries\exits\RECEIVEX.dll was not found. ACTION: Check that the file
exists and is either fully qualified or is in the appropriate directory. ---
06/10/02 09:18:51 AMQ9535: User exit not valid. EXPLANATION: Channel program 'JAVA.CHANNEL' ended because user exit 'RECEIVEX(RCV_EXIT)' is not valid. ACTION: Ensure
that the user exit is specified correctly in the channel definition,
and that the user exit program is
correct and available. ---
06/10/02 09:18:51 AMQ: Channel program ended abnormally.
EXPLANATION: Channel program 'JAVA.CHANNEL' ended abnormally.
ACTION: Look at previous error messages for channel program 'JAVA.CHANNEL' in
the error files to determine the cause
of the failure. ---
Snippet from the trace of RUNMQLSR process
follows: .
6A07 07 (000473) -{
rriInitExits 6A08 07
(000473) --{ lpiSPIAlter 6A09 06 (000473) ---{ zstVerifyPCD 6A0A 06 (000473) ---} zstVerifyPCD
(rc=OK) 6A0B 06 (000473)
---{ xcsCheckPointer 6A0C 06 (000473) ---} xcsCheckPointer (rc=OK)
6A0D 07 (000473) --}
lpiSPIAlter (rc=OK) 6A0E
08 (000473) --{ xcsLoadFunction 6A0F (000473) Object:RECEIVEX
6A10 (000473)
Trace from production path 6A11
22 (000473) ---{ xihGetConnSPDetails 6A12 07 (000473) ---}
xihGetConnSPDetails (rc=OK) 6A13 (000473)
D:\MQSeries\exits\RECEIVEX.dll not found 6A14 (000473)
FullPathObj:D:\MQSeries\exits\RECEIVEX.dll 6A15 005134 (000473) ---{
xcsDisplayMessageForSubpool 6A16 (000473) msgid:6174 a1:
a2: c1:D:\MQSeries\exits\RE c2:(null) c2:(null) 6A17 22 (000473) {
xcsGetMem 6A18
(000473) component:23 function:22 length:3001 options:0
*pointer:00EBBF00 6A19 37
(000473) } xcsGetMem (rc=OK) 6A1A 10 (000473) { xcsGetMessage 6A1B (000473)
msgid:6174 a1: a2: c1:D:\MQSeries\exits\RE c2:(null)
c2:(null) control 001A Anybody
seen anything like this? Anyone have any ideas? Any/all help is
greatly appreciated! Thanks,
ArtArthur C. SchanzOperating Systems Programmer I. -
SpecialistFederal Reserve Information TechnologyDistributed Systems
EngineeringIBM Certified Specialist / Solutions Expert -
MQSeries(804)
697-3889[EMAIL PROTECTED]
Re: Queue manager aliases and remote queue defintions
The most common other use would be cases where the queue names are unknown or temporary. What if an application decides it needs report messages or uses temp dyn queues for it's replies? Also it's more likely application queue names could change than qmgr names. -Original Message- From: Philip, Aby [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 11:47 AM To: [EMAIL PROTECTED] Subject: Queue manager aliases and remote queue defintions Hi everyone, This doubt is regarding the uses of the remote queue defintions vs queue manager aliases. One of the most basic uses of queue manager aliases (according to the manual) is that the application does not need to change the name of the queue manager which it would be putting in the MQOD structure and still get away with sending messages to different queue managers according to the values in the queue manager alias defintion. My doubt is using remote queue definitions also the application can still send a message to any queue manager it wants to without changing anything in the application. It will only put messages to the remote queue definition..and the transfer will take place again to any queue manager value in the remote queue defintion. I think we can reduce the total number of objects created when we are talking of multi hopping using queue manager aliases and all as compared to trying to acheive the same functionality using remote queue defintions...But otherwise is there some other particular advantage by using the queue manager alias? Or am I missing something in these assumptions? Thanks in advance. Kind Regards Aby Philip 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: COD delivery problem on AIX
Additionally, if you want to know the object for which the 2035 message was issued, look on the appropriate error log for the qmgr and there should be a corresponding 8077 message which specifies the object name. -Original Message-From: Alessandro Brezzi [mailto:[EMAIL PROTECTED]]Sent: Wednesday, June 05, 2002 2:37 PMTo: [EMAIL PROTECTED]Subject: Re: COD delivery problem on AIXHi,do you put a valid userId in the message header before MQPut in QM1? Do you put the message with PASS_IDENTITY?HTHAlessandroAt 12:09 PM 6/5/2002 -0400, you wrote: I am having a problem with report messages on AIX 4.3 MQ 5.2. I receive messages from QM1 with MQMD.Feedback set to MQFB_COA+MQFB_COD, MQMD.ReplyToQueue = DESTQ and MQMD.ReplyToQMgr = QM2Initially, the report messages were hitting my Dead Letter Queue. I created a QMgr Alias with QREMOTE(QM2) and RQMNAME(QM1). My intention was to force messages destined for QM2 to QM1 where they would be forwarded properly.COA messages are now being delivered, but the COD messages are still ending up on my DLQ with MQRC = 2035 (MQRC_NOT_AUTHORIZED). I also get an Event message at this time with MQ_OPEN_NOT_AUTHORIZED.If I run runmqdlq with a retry rule, the messages are transmitted successfully. How can I figure out what I'm failing to open and which process is failing to open it? Any hints will be appreciated. This one is starting to drive me crazy. 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: Strange Channel Behavior
Are you sure the discint is 6000 (that's 100 minutes by the way)? Could some transaction be trigger the channel and then be backed out? This still doesn't explain why the channel didn't stay running, does it? -Original Message- From: Jeff A Tressler [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 12:25 PM To: [EMAIL PROTECTED] Subject: Strange Channel Behavior We have a channel defined between OS/390 (Sender) and HP-UX (Receiver). Since I have no visibility on the OS/390, I set up a simple script to capture the CHLSTATUS every 30 minutes. The channel has a disconnect interval of 90 minutes. I use the msgs value of the CHLSTATUS to get an idea on the number of transaction that have passed through the channel. Four of the five channels work well, the channel starts, message pass along the channel and the channel disconnects properly. The fifth channel acts strangely. I examined the error log and got even more confused. Comparing the error log with the 30 minute CHLSTATUS shows. Channel Starts 02:53:22 No Transactions Sent 03:26:22 No Transactions Sent 05:02:35 No Transactions Sent 06:12:37 No Transactions Sent 06:35:31 No Transactions Sent 07:19:51 No Transactions Sent 07:53:55 1 Transaction Sent 08:58:06 439 Transactions Sent 09:33:10 No Transactions Sent 10:55:14 5 Transactions Sent 11:53:12 No Transactions Sent 12:35:22 No Transactions Sent 13:38:11 No Transactions Sent 14:32:49 No Transactions Sent It appears the channel is started, sends no transactions, and then shuts down before the discint(6000) runs out. We checked the operators and they are not stopping the channels. Any idea what might be happening. Jeff Tressler Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Error with Reply to Queue in a remote queue manager on Solari s
Lakshmi, I think you're assuming that QM1 leaves the ReplyToQMgrName blank and that QM2 will see it is blank and default to QM2. This is not the way it works. According to the APR, QM1 looks to see if it has a remote queue named QM2.REMOTE.QUEUE and if so uses that qmgr name otherwise it uses its own name. Since there is no remote queue of that name on QM1, it is putting QM1 in the ReplyToQMgr name. You'll have to explicitly populate the ReplyToQMgr name. >From the APR: "f the ReplyToQMgr field is blank, the local queue manager looks up the ReplyToQ name in its queue definitions. If a local definition of a remote queue exists with this name, the ReplyToQMgr value in the transmitted message is replaced by the value of the RemoteQMgrName attribute from the definition of the remote queue, and this value will be returned in the message descriptor when the receiving application issues an MQGET call for the message. If a local definition of a remote queue does not exist, the ReplyToQMgr that is transmitted with the message is the name of the local queue manager." Nick -Original Message- From: Lakshmi, Saraswathi [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 5:26 AM To: [EMAIL PROTECTED] Subject: Error with Reply to Queue in a remote queue manager on Solaris Hello, There is a requirement to be notified when a message has expired -in a queue (it could be sitting on a transmission queue or on a local queue on a remote system). I have defined 2 Queue Managers QM1 and QM2. The source of the message is from QM1 to QM2. When a message is being put from QM1 - a ReplyToQName has been specified a 'QM2.REMOTE.QUEUE (on QM2) and the 'ReplytoQMgrName' as blanks. The remote queue QM2.REMOTE.QUEUE on QM2 has a local definition QM1.LOCAL.QUEUE ón QM1. When a message is received by the Queue Manager QM2, the 'ReplyToQMgrName' has a value QM1 and 'ReplytoQname' is maintained as it is 'QM2.REMOTE.QUEUE' (which is incorrect). On expiry of a message QM2 puts the message into SYSTEM.DEAD.LETTER.QUEUE with reason code -0827 (2087) - Unknown Remote Object Queue Manager. I expect that the'ReplyToQName' would be updated as 'QM1.LOCAL.QUEUE' so that the message is placed in the appropriate queue on QM1. What could be reason for this error. 1. I have tried specifying the 'ReplyToQname as QM1.LOCAL.QUEUE' and 'ReplyToQMgrName as QM1, the error is the same (0827 or 2087). 2. I have also tried specifying 'ReplyToQName as QM2.REMOTE.QUEUE' and 'ReplyToQMgrName as QM2, then it works. The problem is that it not possible to get the remote queue manager name from the application. Hence I am looking for a solution. As per the MQSeries Application Programming Reference / "Message Descriptors" - the Queue Manager QM2 should update the ReplyToQName as QM1.LOCAL.QUEUE and ReplyToQMgrName as 'QM1, when the message is put with ReplyToQName as QM2.REMOTE.QUEUE and ReplyToQMgrName as blanks. It is expected that it looks up its local defintion. Thanks lakshmi The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail, by telephone or by fax at the above num- bers. E-mail communications are not secure and therefore we do not accept any res- ponsibility for the confidentiality or altered contents of this message. Please be aware that SIS Group and its subsidiary companies cannot accept any orders or other legally binding correspondence with a participant as part of an E-mail. The views expressed above are not necessarily those held by SIS Group and its subsidiary companies and not binding for them. 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: MQTriggering at client-windows NT
How are you connecting to the qmgr -- via a amqclchl.tab or via the mqserver environment variable? It sounds like you have a problem connecting to the qmgr. Can you open a DOS window and do an amqsputc to a test queue? -Original Message- From: ashish baby [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 01, 2002 5:17 AM To: [EMAIL PROTECTED] Subject: MQTriggering at client-windows NT Hi, I want to start a application at the client end when a message is put in a queue at server side(both in same environment).I am using MQSeries 5.1 in windows nt.How can I start a client side trigger monitor(runmqtmc -m queuemanager -q initq).I have applied the patch (MA7k.zip).What all parameters I have to set either in client side or server side to make trigger monitor work.I get a message queue manager not found when I run the patch. Hope it is possible to run a client side trigger in WIN NT. If so please help me how to proceed like how to set the process(application identifier ...) Thanks Ashkb 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: Newbie: Urgent : Connectivity problem from NT client to Solar is Server
2035 is security. NT differs in that the local userid of the client is
passed to the qmgr on the server. On the Solaris platform no userid is
passed so the userid of the qmgr is used (because the SVRCONN channel has
not been defined with an MCA userid). You can authorize the NT userid or
assign an MCA Userid to the SVRCONN channel and then give the userid
authority to access the specific objects it needs. You could assign the mqm
userid if you want the client to have full access, but this could be a
security problem in a production environment. If you're just testing, it
might work until you come up with a security strategy.
Nick
-Original Message-
From: hegde [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: Newbie: Urgent : Connectivity problem from NT client to Solaris
Server
Hi All,
I am new to the MQSeries. I have installed the
MQSeries V5.2 Server on Solaris 8. I have created the
queue as per Manuals Available on CD's. I am able to
connect the queue from another unix client, but I am
not able queue from windows NT. I have configured as
below.
1. I have created the Queue Manager as
crtmqm -q saturn.queue.manager
strmqm saturn.queue.manager
2. define qlocal (ORANGE.LOCAL.QUEUE)
3. define channel (CHANNEL1) +
chltype (SVRCONN) +
MCAUSER (' ') +
TRPTYPE (TCP)
4. I have modified the inetd and services file as per
document.
5. Started command Server and started listner and
channel (from runmqsc prompt)
6. On sun solaris I have set the environment as
MQSERVER=CHANNEL1/TCP/'199.221.81.102'
from solaris system I am able put the message as
amqsputc ORANGE.LOCAL.QUEUE saturn.manager.queue
and no problem in receive message using amqsgetc
7. On windows NT system I have set the MQSERVER
environment as
SET MQSERVER=CHANNEL1/TCP/199.221.81.102
amqsputc ORANGE.LOCAL.QUEUE saturn.queue.manager
I am getting MCONN ended the connection reason
2035
I don't know what I am missing or doing wrong. I
request some one to correct my mistake or guide me.
I appreciate you help.
Thanks
Prakash
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.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
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: Expiry
Jon, The expiry value is also decremented to reflect time spent on transmission queues and transmission times (if significant). If the channels from NT to OS390 are up and running this shouldn't be significant, but if channels have to be started this could account for some of the time (though 1 minute seems high). Nick -Original Message-From: Jon Shearer [mailto:[EMAIL PROTECTED]]Sent: Friday, May 24, 2002 2:55 PMTo: [EMAIL PROTECTED]Subject: Re: ExpiryNick, You caught me - the actual value in the field is 600 - 60 seconds However, this still doesn't explain #4 in my scenario. Messages are on the queue for more than a few seconds but less than a minute. Thanx Jon ShearerFarmers New World Life[EMAIL PROTECTED]206-236-6587 "DiLauro, Nick" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 05/24/2002 02:33 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: ExpiryExpiry is in 10ths of a second. What value are you putting in expiry? -Original Message- From: Jon Shearer [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: Expiry I'm seeing behavior that suggests the expiry interval is not simply a matter of decrementing the expiry field in the MD but is also a function of local time and/or the PutTime field in the MD. Is there some place to get the details of how MQSeries determines a message has expired? For those curious, here's my scenario: 1) Messages is put to queue on an NT box that is using GMT. Expiry field set to 10 minutes. PutTime is 1700 GMT 2) Message is received on a mainframe that is using local time. Local time is 1000 PDT 3)Time delta between 1) and 2) is 7 hours. 4) If the message sits on the queue for more that a few seconds, the first application MQGET returns MQRC=2033. 5) If the message is picked up by the application right away(less than a few seconds after arrival) all is OK. I want to know: 1) why does the message expire before 10 minutes has elapsed? 2) why are the messages that are processed rather quickly not expired? Jon Shearer Farmers New World Life [EMAIL PROTECTED] 206-236-6587
Re: Expiry
Expiry is in 10ths of a second. What value are you putting in expiry? -Original Message-From: Jon Shearer [mailto:[EMAIL PROTECTED]]Sent: Friday, May 24, 2002 1:40 PMTo: [EMAIL PROTECTED]Subject: ExpiryI'm seeing behavior that suggests the expiry interval is not simply a matter of decrementing the expiry field in the MD but is also a function of local time and/or the PutTime field in the MD. Is there some place to get the details of how MQSeries determines a message has expired? For those curious, here's my scenario: 1) Messages is put to queue on an NT box that is using GMT. Expiry field set to 10 minutes. PutTime is 1700 GMT 2) Message is received on a mainframe that is using local time. Local time is 1000 PDT 3)Time delta between 1) and 2) is 7 hours. 4) If the message sits on the queue for more that a few seconds, the first application MQGET returns MQRC=2033. 5) If the message is picked up by the application right away(less than a few seconds after arrival) all is OK. I want to know: 1) why does the message expire before 10 minutes has elapsed? 2) why are the messages that are processed rather quickly not expired? Jon ShearerFarmers New World Life[EMAIL PROTECTED]206-236-6587
Re: Setting MQMD properties in C++
Title: Message Yes to both questions. -Original Message-From: Anil Balakrishnan [mailto:[EMAIL PROTECTED]]Sent: Friday, May 24, 2002 1:17 PMTo: [EMAIL PROTECTED]Subject: Re: Setting MQMD properties in C++ Thanks Nick. So I take it that we should be able to set the MsgID, CorrelID or other MQMD properties that are outside the Identity or Origin context without impacting the properties that we don't set - i.e., the properties we don't set will continue to use the defaults? Secondly, if we set even a single property in the Origin Context, then we are responsible to set all properties in Origin context and Identity context. If we set even 1 property in the Identity Context, we are responsible to set other properties in Identity Context too. Correct? Thanks, Anil -Original Message-From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 12:09 PMTo: [EMAIL PROTECTED]Subject: Re: Setting MQMD properties in C++ Anil, The msgid and correlid are not part of either the identity context or origin context of the MQMD. I think you're stuck here since you take responsibility for all the fields and there is no way to be selective. You could format the date and time in the application (GMT). Alternatively, you could use the ApplIdentityData field of the identity context and use the set identity context option. This leaves the origin context to be populated by the qmgr. identity context UserIdentifier AccountingToken (may not be available on Windows NT since it is used to store SID) ApplIdentityData origin context PutApplType PutApplName PutDate PutTime ApplOriginData If you use the set identity context option you take responsibility for the identity context. If you use the set all context option you take on all the fields of both identity context and origin context. (There is not option to set just the origin context and there are no selective options). An inelegant option would be to put a dummy message to some queue and extract the context info you need, but then you take on added overhead and maintenance and the information (eg. time) is inaccurate. Nick -Original Message-From: Anil Balakrishnan [mailto:[EMAIL PROTECTED]]Sent: Friday, May 24, 2002 11:36 AMTo: [EMAIL PROTECTED]Subject: Setting MQMD properties in C++ We are trying to set some MQMD properties in C++. When we set the property PutApplName, we will need to enable the "set all context" option for the "put" msg call. However, this results in some other context properties (that are also affected by this flag) not having default settings any more. PutDate and PutTime values will become invalid if we don't explicitly set them. Is there a way to just set a selected few properties while still letting the QueueManager take care of the rest (inc. MsgID, CorrelID, PutDate, PutTime, etc.), when "set all context" is enabled? Or is there a way for us to retrieve the default settings, say, from the queue manager, and explicitly apply them to the message? Any help/input/suggestion is greatly appreciated. Thanks, Anil
Re: Setting MQMD properties in C++
Title: Setting MQMD properties in C++ Anil, The msgid and correlid are not part of either the identity context or origin context of the MQMD. I think you're stuck here since you take responsibility for all the fields and there is no way to be selective. You could format the date and time in the application (GMT). Alternatively, you could use the ApplIdentityData field of the identity context and use the set identity context option. This leaves the origin context to be populated by the qmgr. identity context UserIdentifier AccountingToken (may not be available on Windows NT since it is used to store SID) ApplIdentityData origin context PutApplType PutApplName PutDate PutTime ApplOriginData If you use the set identity context option you take responsibility for the identity context. If you use the set all context option you take on all the fields of both identity context and origin context. (There is not option to set just the origin context and there are no selective options). An inelegant option would be to put a dummy message to some queue and extract the context info you need, but then you take on added overhead and maintenance and the information (eg. time) is inaccurate. Nick -Original Message-From: Anil Balakrishnan [mailto:[EMAIL PROTECTED]]Sent: Friday, May 24, 2002 11:36 AMTo: [EMAIL PROTECTED]Subject: Setting MQMD properties in C++ We are trying to set some MQMD properties in C++. When we set the property PutApplName, we will need to enable the "set all context" option for the "put" msg call. However, this results in some other context properties (that are also affected by this flag) not having default settings any more. PutDate and PutTime values will become invalid if we don't explicitly set them. Is there a way to just set a selected few properties while still letting the QueueManager take care of the rest (inc. MsgID, CorrelID, PutDate, PutTime, etc.), when "set all context" is enabled? Or is there a way for us to retrieve the default settings, say, from the queue manager, and explicitly apply them to the message? Any help/input/suggestion is greatly appreciated. Thanks, Anil
[no subject]
I think this is also a case where the adoptMCA feature needs to be used. Unfortunately the platform or version was not specified. On OS390 v1.2 and NT we experienced this sort of problem with the OS390 side. There was a PMR (not sure of the number) which allowed the adopt an MCA feature to be used and this has solved the problem. All the other suggestions mentioned may improve the network connectivity, but they won't solve the problem if the network does experience a problem. -Original Message- From: Taylor, Neil [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 2:15 AM To: [EMAIL PROTECTED] Subject: Mark You may also want to look at TCP/IP KeepAlive. If you reach a state where Sender is in Retry state and receiver is in Running state KeepAlive allows the receiver to "detect" that it hasn't received any traffic from the sender, for a specified period of time, and so drops down to Inactive state automatically. Once done, the Sender can then connect successfully. I have used this to great effect and include it in all configurations. Regards Neil -Original Message- From: Michael F Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]] Sent: Fri 24/05/2002 02:35 To: [EMAIL PROTECTED] Cc: Subject: Mark, I have seen this many times. It would be helpful to know both the platforms because that can sometimes make a difference. I am not clear on exactly what is happening but since you say stopping and starting the receiver side as well corrects the problem, I am pretty sure I know what you are experiencing. This is very common between OS/390 and Unix or NT platforms but can happen between any platform occasionally. I think what you may notice is your sender is retrying but your corresponding receiver is in a RUNNING status still so it can't accept a new channel connection. If you look at the logs on the receiving end and see an error message stating something like a channel wants to start but there are not enough resources to start one (sorry, I don't remember the exact wording), you can use AdoptNewMCA to help correct the problem. This is done on the receiving side to correct a problem but I enable it on all queue managers. On NT it is done through the Services GUI in the queue manager properties on the Channels tab. On Unix you put it in the channels stanza in qm.ini, on OS/390 I can't tell you how, but it is available. If one side is OS/390, make sure the OS and TCP are up to date. AdoptNewMCA will cause the receiver stuck running to be dropped and "adopt" the new request to start the same channel again. This happens quickly and the drop is not really noticeable. I have been down the same road with all sorts of network engineers sniffing the network, looking at routers, but they never find a problem. Of course IBM says it is not MQSeries, it must be the network. I hope this helps. If this is completely wrong, we'll keep trying. Mike Murphy Sr. Middleware Consultant MQ Solutions, LLC http://www.mqsolutions.com Mark Lees <[EMAIL PROTECTED]> wrote: Date Recieved: 05/23/2002 11:00:09 PM To: [EMAIL PROTECTED] cc: Bcc Subject: Stefan / Ian, thanks for getting back to me. The AMQ log on host A, out machine, says that error 10054 occurred (This is an NT machine) which equates to WSAECONNRESET. The exact AMQ log entry on our machine (Host A) is as follows --- 24/05/02 06:57:35 AMQ9208: Error on receive from host 194.35.94.31. EXPLANATION: An error occurred receiving data from 194.35.94.31 over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. --- I've requested the AMQ error log from their machine but there rather MQSeries naive I can positively rule out a network outage. Our network dept has had tracing and monitoring on for two days now and there has been not network problems for over a month now (that in itself is a cause for celebration :-/ ) I'll endeavour to get Host B's AMQ log and hopefully this will shed some light on it. Regards Mark. -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED]] Sent: 24 May 2002 03:05 To: [EMAIL PROTECTED] Subject: what error message displayed at host B AMQERR01.LOG (tcp/ip err? mq error? etc) ? You can't start it at host A because host B receiver is stop and obviously has to be started at host B end. Regards, Ian -Original Message- From: Mark Lees [mailto:[EMAIL PROTECTED]] Sent: Thursday, 23 May 2002 10:29 PM To: [EMAIL PROTECTED] Subject: All, I need your help. We have two-way connection to a clients MQSeries using a sender and receiver channel on our machine (host A) and a corresponding receiver and sender channel
Re: Remote Admin
You could also use support pac MO71. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 5:29 AM To: [EMAIL PROTECTED] Subject: Re: Remote Admin A limitation on the OS390 platform is it does not accept PCF commands. Therefore there is a need to write MQSC commands directly to the SYSTEM.COMMAND.INPUT queue. NASTEL has written a PCF command server for the OS390. I do not know id the sell it seperatly. But with it I believe you can send PCF commands from any of the vendor apps that may be free to the OS390 and this server will process them and send back and answer. This is not a plug for the software just a statement that it exist. I used to work for them and I have a little knowledge of their product. bobbee >From: Marcin Grabinski <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Remote Admin >Date: Fri, 17 May 2002 09:12:41 +0200 > > > We want to use MQExplorer on NT to administer queue managers on remote > > systems I believe I can do this for remote queue managers running on >most > > platforms (UNIX etc) but not OS/390. > >Remote administration of MQ on OS/390 is pretty simple. Just send a command >to its SYSTEM.COMMAND.INPUT queue (and get a reply from a queue you >supply). > >See the attached REXX program. Basing on it, you can easily build your own, >more sophisticated app. > >Best regards, > >Marcin Grabinski <>< >[EMAIL PROTECTED] ><< mqremadm.rex >> _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.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 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel Status
Support pack MS0B is a Java PCF interface which will work.
Here's a sample which displays. Here's a sample program which monitors a
channel and also lists queue depth.
-Original Message-From: Panakkal, Hariskumar (SUPP)
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, May 14,
2002 2:29 PMTo: [EMAIL PROTECTED]Subject: Re:
Channel Status
Hi,
I like to know how can I find out using a java
program?
I am sorry as I did not mentioned the same.
Thanks,
Haris.
-Original Message-From: Glen Shubert
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, May 14, 2002 4:19
PMTo: [EMAIL PROTECTED]Subject: Re: Channel
StatusDIS
CHSTATUS(channel name) Glen
"Panakkal, Hariskumar (SUPP)"
<[EMAIL PROTECTED]> Sent by: MQSeries List
<[EMAIL PROTECTED]>
05/14/2002 04:08 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject:
Channel StatusHi all,Is there any way to
check the MQ Channel Status (Unix)? Like to knowwhether the
Channel is down or started?-
harisInstructions for managing your
mailing list subscription are provided inthe Listserv General Users
Guide available at http://www.lsoft.comArchive:
http://vm.akh-wien.ac.at/MQSeries.archive
ListChannelStatus.PROPERTIES
Description: Binary data
import java.io.*;
import java.util.*;
import com.ibm.mq.*;
import com.ibm.mq.pcf.*;
public class ListChannelStatus
{
private Properties properties = new Properties(); // Contains system settings.
//***
//** main()
//***
static public void main(String args[])
{
ListChannelStatus lcs = new ListChannelStatus();
try
{
lcs.init();
lcs.channelStatus(lcs.properties);
lcs.queueDepth(lcs.properties);
}
catch (Exception e)
{
System.out.println("general exception NOT handled in main");
e.printStackTrace();
}
}
//***
//** method init()
//***
public void init() throws Exception
{
// Load system properties from file "properties.ini"
FileInputStream fis = new FileInputStream("ListChannelStatus.properties");
properties.load(fis);
fis.close();
// List system properties
ByteArrayOutputStream baos = new ByteArrayOutputStream();
properties.list(new PrintWriter(baos, true));
System.out.println(baos.toString());
// turn off the mqji messages, since we're handling some of them
MQException.log = null;
}
//***
//** method void channelStatus(Properties p)
// This method accepts a Properties Oject which contains the details about the
// channel whose status is to be monitored
// Monitor_IP - the IP or DNS name for the Server which hosts the channel
// Monitor_Port - the listening port for the MQSeries Qmgr
// Monitor_Channel - svrconn channel used to connect to qmgr being monitored
// (this is not necessarily the channel being monitored)
// Target_Channel_Name - the channel being monitored
//
//***
public void channelStatus(Properties p) throws Exception
{
// Set the situation variables
String monitorIP = new String(p.getProperty("Monitor_IP"));
int monitorPort =
Integer.parseInt(p.getProperty("Monitor_Port"));
String monitorChannel = new String(p.getProperty("Monitor_Channel"));
String targetName = new
String(p.getProperty("Target_Channel_Name"));
int chlCount = 0;
// set up the PCF agent
PCFMessageAgentagent;
PCFMessage request;
PCFMessage [] responses;
// build a request
request = new PCFMessage (CMQCFC.MQCMD_INQUIRE_CHANNEL_STATUS);
// add a parameter designating the name of the channel for which status is
requested
request.addParameter(CMQCFC.MQCACH_CHANNEL_NAME, targetName);
// add a parameter designating the instance type (current) desired
request.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_TYPE,
CMQC.MQOT_CURRENT_CHANNEL);
// add a parameter designating the attributes desired, but first...
// .
Re: BackoutRequeueName
Your understanding is correct. These two fields are for inquiry so that the application can handle the backout. It does not happen automatically. Nick -Original Message- From: Philip, Aby [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: BackoutRequeueName Hi everyone, This is a question regarding the backout mechanism in MQ. I understand that for every backout we do on a message the backout count property of that message increases by 1. There are two properties in a local queue called BackoutRequeueName and BackoutThreshold. Question: These properties are just for inquiry right? I do not think that the queue manager will shift messages from the local queue to the BackoutRequeue queue when the backout count of the message increases beyond the backout threshold for the local queue, right? Or would it? Thanks. Kind Regards Aby 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: Log files
Title: RE: Log files Are you using circular logging? You may want to consider linear logging. -Original Message-From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 09, 2002 3:58 PMTo: [EMAIL PROTECTED]Subject: Re: Log files I changed the log size in services and stopped and restarted the server. The log files did not increase. Does anyone have an idea? -Original Message-From: Day, Stan [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 09, 2002 2:01 PMTo: [EMAIL PROTECTED]Subject: Re: Log files If they haven't changed the interface betweent NT4 and W2K, from the Start menu go into IBM MQSeries, then MQSeries Services. Right click the queue manager, click Properties and select the Log tab. This is where you manage the number of log files. If I'm not mistaken, you'll have to stop and restart the queue manager for the changes to become active. -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 1:55 PM To: [EMAIL PROTECTED] Subject: Re: Log files I will increase the number of logs. Is there a general rule? Also I am running 5.2 MQSERIES FOR Windows and there does not seem to be a MQS.INI. Where can I add logs? -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 1:39 PM To: [EMAIL PROTECTED] Subject: Re: Log files If I remember correctly, you can increase the number of logs but not the size of the logs. I believe you need to delete and create the queue manager. At one point I was about to attempt to create a queue manager with larger logs and then copy the old logs to the new logs, switch the logs between the managers and restart the old queue manager. I never got to try this or think it all the way through. BUT..unless someone else has information it may be worth a try. Of course you need to try this on the side first! bobbee >From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Log files >Date: Thu, 9 May 2002 13:00:42 -0500 > >I am only familiar with log files on OS/390 and I may have a problem with >the log file on a Windows 2000 server. Can anyone direct me to >documentation or instructions on how to increase the size of an MQ log on >Windows 2000? We are getting a 2003 error message on an MQGET and it seems >to point to a log problem. > > >--- Legal Disclaimer: The information contained in this communication may >be >confidential, is intended only for the use of the recipient named above, >and >may be legally privileged. If the reader of this message is not the >intended recipient, you are hereby notified that any dissemination, >distribution, or copying of this communication, or any of its contents, is >strictly prohibited. If you have received this communication in error, >please re-send this communication to the sender and delete the original >message and any copy of it from your computer system. 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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 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 --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. 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 --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified
