Re: Maximum size of defined message
Title: RE: Maximum size of defined message -Original Message-From: Stephan C. Moen [mailto:[EMAIL PROTECTED]Sent: Saturday, February 22, 2003 9:21 PMTo: [EMAIL PROTECTED]Subject: Re: Maximum size of defined message The simple answer Linda is there is no overhead or resource waste to set a queue to its architectural limit for a message size. This also has been validated multiple times by our esteemed friends who have supported this product since its inception IBMs MQSeries Support Team. Stephan C. Moen -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Kinnard.LindaSent: Thursday, February 20, 2003 12:52 PMTo: [EMAIL PROTECTED]Subject: Re: Maximum size of defined message I think another ways to ask is "is there overhead or resource waste to set queue to it's maximum architectural limit?" -Original Message- From: Stephan C. Moen [SMTP:[EMAIL PROTECTED] Sent: Thursday, February 20, 2003 07:02 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world "s-h-i-t" travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst", see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere..."You fight the battles you can win!" From: "Stephan C. Moen" [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message Date: Thu, 20 Feb 2003 00:14:13 -0600 Bobbee, I guess I take a different tack. I look for consistency, continuity, and simplicity in my operational environment. I don't want to create artificial limits for my technology stack because I know eventually, those limits will be tested and require changes; that has been proven over time. So why not start out by taking those limits off the table. Why should I place artificial limits on my infrastructure if I don't have to. Isn't that a primary goal of MQSeries - reliability, availability and scalability (RAS)? If the message size is raised ABOVE the maximum limit, the problem will be caught at the application ISSUING the call, which is where it should be; just following your viewpoint of determining where the BLAME should go. Lastly, the application can easily be coded to handle large message sizes. As we all know, the MQGET call will return the size of the message is
Re: Data conversion on mainframe
Rick, I have a rather unsophisticated environment - CEDF is the limit of my online debugging facilities and this doesn't step into the MQXCNVC call. The handle is fine for calls that follow the MQXCNVC call... wonder if it is a problem passing the parameters... Cheers Darren From: Rick Tsujimoto [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Date: Fri, 14 Mar 2003 15:37:52 -0500 Darren, If you have an online debugger, e.g. Intertest, just step throught the code and see where the handle gets whacked. Darren Douch [EMAIL PROTECTED] To: [EMAIL PROTECTED] COM cc: Sent by: Subject: Re: Data conversion on mainframe MQSeries List [EMAIL PROTECTED] en.AC.AT 03/14/2003 02:51 PM Please respond to MQSeries List Thanks Rebecca. I am already setting my Hcon to the supplied default (and using that same handle on other MQ calls quite happily before and after the MQXCNVC call). Might have to resort to trying the samples (assembler only unfortunately) and then seeing if I can link to them from C... certainly a more painful route. Maybe Morag will post a response and save the day :) Cheers Darren. - Original Message - From: Bullock, Rebecca (CSC) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:20 PM Subject: Re: Data conversion on mainframe Darren, while you don't have to do the MQCONN, I believe that there's still a connection handle (after all, it's a parm you need to specify on your MQOPEN). Check what you have this set to (I think it's MQHC_DEF_HCONN for CICS when you don't so the MQCONN) and that you haven't overwritten it. HTH -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 8:20 AM To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Ian and others... I can't argue about MQGET - it works as described in the manuals. But I have a scenario where I can't use it... long story short is that I have a couple of chained data structures in front of the message data itself, plus I don't know at the time of the GET whether I want to convert it 'properly' (using MQ's codepage support) or improperly (using some homegrown conversion tables that are needed to keep a downstream application happy). I've made a bit of progress - managed to build the module now (whether correctly I don't know) - but get 2018 - invalid connection handle - which is a bit odd because CICS apps don't really need / use a connection handle. Any more offers? Cheers Darren. From: Ian Metcalfe [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Date: Fri, 14 Mar 2003 21:59:53 +1100 Hey Darren, If I understand what you're asking correctly, I believe the recommended way is to simply use MQGMO_CONVERT on any MQGET calls on queues that may contain messages from other platforms. If it's a text message type, like MQSTR for example, it'll automatically be converted to the appropriate type for the platform you're on. This works in all cases in my experience, and manually converting within the application seems to be a bit of a waste of effort to me. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Darren Douch Sent: Friday, 14 March 2003 21:29 To: [EMAIL PROTECTED] Subject: Data conversion on mainframe Folks has anyone out there used this call on the mainframe? I'm trying to use it in a C / CICS program and not having much joy building (linking) the application (MQXCNVC not resolving). Can anyone tell me what MQ uses under the covers for data conversion on the mainframe ie the equivalent of iconv on AIX... if I can't use MQXCNVC is there some other way I can do character conversion? Thanks Darren. _ Overloaded with spam? With MSN 8, you can filter it out http://join.msn.com/?page=features/junkmailpgmarket=en-gbXAPID=32DI=1059 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
MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent
Hi, Today we face the problem of queue managers getting abended with the following error messages: IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=522 TIME=15.21.01 SEQ=50409 CPU= ASID=0045 PSW AT TIME OF ERROR 077C1000 8DE01B1A ILC 2 INTC 01 ACTIVE LOAD MODULE ADDRESS=0DE00F08 OFFSET=0C12 NAME=CSQYASCP DATA AT PSW 0DE01B14 - BF08AB0B 0A0194FE 90681F11 AR/GR 0: /8001 1: /0C3D41F8 2: /FF7F 3: /80200080 4: / 5: /0C3D4000 6: / 7: /0BA2E040 8: /0C3D41D0 9: /7F6F2690 A: /8DE01008 B: /7F6F2560 C: /0DE02007 D: /7F6F2560 E: 8C74936E/ F: / END OF SYMPTOM DUMP *CSQV086E +Q MQSERIES ABNORMAL TERMINATION REASON=00E80100 IEF450I MQZ1MSTR MQZ1MSTR - ABEND=S522 U REASON= TIME=15.21.11 On cheking the messages for CSQV086E 00E80100, it is stated that one of the problem for the could be that MQ unable to locate the CSQZPARM. But it is not the case. The Queue manager comes up normally and stays active for around 30 mins , then abends with the above mentioned error. The environment is OS/390 V2R10 with MQ ver 2.1. This environment runs fine for more than 1.5 years and we had not received this kind of problem. Also, we have not applied any maintainence recently to suspect any problem related to maintainence. Also, we face same problem in other subsystems in the LPAR. We are suspecting that the problem could be due to TCPIP WLM. Have any one in the list faced similar problems? Any resolutions?? Thanks in Advance, Karthik ***The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. Thank you.*** This message was scanned by Interscan Viruswall.
Re: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urg ent
Well, a S522 means the task has been in a SVC wait state for longer than that allowed by your systems definitions. I think that is set in SYS1.PARMLIB(SMFPRMxx) JWT parm if that is still the way its done. I'm not sure what you had set up to prevent tasks like MQSeries getting timed out like this, but I should suspect something has changed in this area (you mention you suspected WLM, maybe that is it). As a quick get around, coding ,TIME=NOLIMIT on the exec statement in your started task JCL should presumably solve it ? Pete. -Original Message- From: P Karthikeyan [mailto:[EMAIL PROTECTED] Sent: 17 March 2003 10:08 To: [EMAIL PROTECTED] Subject: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent Hi, Today we face the problem of queue managers getting abended with the following error messages: IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=522 TIME=15.21.01 SEQ=50409 CPU= ASID=0045 PSW AT TIME OF ERROR 077C1000 8DE01B1A ILC 2 INTC 01 ACTIVE LOAD MODULE ADDRESS=0DE00F08 OFFSET=0C12 NAME=CSQYASCP DATA AT PSW 0DE01B14 - BF08AB0B 0A0194FE 90681F11 AR/GR 0: /8001 1: /0C3D41F8 2: /FF7F 3: /80200080 4: / 5: /0C3D4000 6: / 7: /0BA2E040 8: /0C3D41D0 9: /7F6F2690 A: /8DE01008 B: /7F6F2560 C: /0DE02007 D: /7F6F2560 E: 8C74936E/ F: / END OF SYMPTOM DUMP *CSQV086E +Q MQSERIES ABNORMAL TERMINATION REASON=00E80100 IEF450I MQZ1MSTR MQZ1MSTR - ABEND=S522 U REASON= TIME=15.21.11 On cheking the messages for CSQV086E 00E80100, it is stated that one of the problem for the could be that MQ unable to locate the CSQZPARM. But it is not the case. The Queue manager comes up normally and stays active for around 30 mins , then abends with the above mentioned error. The environment is OS/390 V2R10 with MQ ver 2.1. This environment runs fine for more than 1.5 years and we had not received this kind of problem. Also, we have not applied any maintainence recently to suspect any problem related to maintainence. Also, we face same problem in other subsystems in the LPAR. We are suspecting that the problem could be due to TCPIP WLM. Have any one in the list faced similar problems? Any resolutions?? Thanks in Advance, Karthik ***The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. Thank you.*** _ Notice to recipient: The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity. If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority. _ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent
Hi ! What TIME have you in your STC or Job ? Try once with TIME=1440. Regards Guido -Original Message- From: P Karthikeyan [mailto:[EMAIL PROTECTED] Sent: Montag, 17. März 2003 11:08 To: [EMAIL PROTECTED] Subject: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent Hi, Today we face the problem of queue managers getting abended with the following error messages: IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=522 TIME=15.21.01 SEQ=50409 CPU= ASID=0045 PSW AT TIME OF ERROR 077C1000 8DE01B1A ILC 2 INTC 01 ACTIVE LOAD MODULE ADDRESS=0DE00F08 OFFSET=0C12 NAME=CSQYASCP DATA AT PSW 0DE01B14 - BF08AB0B 0A0194FE 90681F11 AR/GR 0: /8001 1: /0C3D41F8 2: /FF7F 3: /80200080 4: / 5: /0C3D4000 6: / 7: /0BA2E040 8: /0C3D41D0 9: /7F6F2690 A: /8DE01008 B: /7F6F2560 C: /0DE02007 D: /7F6F2560 E: 8C74936E/ F: / END OF SYMPTOM DUMP *CSQV086E +Q MQSERIES ABNORMAL TERMINATION REASON=00E80100 IEF450I MQZ1MSTR MQZ1MSTR - ABEND=S522 U REASON= TIME=15.21.11 On cheking the messages for CSQV086E 00E80100, it is stated that one of the problem for the could be that MQ unable to locate the CSQZPARM. But it is not the case. The Queue manager comes up normally and stays active for around 30 mins , then abends with the above mentioned error. The environment is OS/390 V2R10 with MQ ver 2.1. This environment runs fine for more than 1.5 years and we had not received this kind of problem. Also, we have not applied any maintainence recently to suspect any problem related to maintainence. Also, we face same problem in other subsystems in the LPAR. We are suspecting that the problem could be due to TCPIP WLM. Have any one in the list faced similar problems? Any resolutions?? Thanks in Advance, Karthik ***The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. Thank you.*** 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. exfe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urg ent
Karthik I think this will help: 522 Explanation: All of the tasks in a job step were in an SVC wait state for the time specified in the JWT parameter in the SMFPRMxx parmlib member. The event control block (ECB) specified in the wait request was never posted. This could be the result of waiting on the wrong ECB or not posting the correct ECB. System Programmer Response: Correct any errors and execute the job step again. If no errors are found and the wait is expected for that particular job step, specify TIME=NOLIMIT in the EXEC statement to bypass all job step timing. Source: System Management Facilities (SMF) Met vriendelijke groet, Erik Dijkerman X Rabobank ICT/Serverbedrijf PIM/OS390 ZL-S2064 Postbus 17100, 3500 HG Utrecht *(030) 215 4878 *(030) 215 3085 ? [EMAIL PROTECTED] Zonder zelf kleiner te worden kan men anderen doen groeien. Lao Tse -Original Message- From: P Karthikeyan [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:08 AM To: [EMAIL PROTECTED] Subject: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent Hi, Today we face the problem of queue managers getting abended with the following error messages: IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=522 TIME=15.21.01 SEQ=50409 CPU= ASID=0045 PSW AT TIME OF ERROR 077C1000 8DE01B1A ILC 2 INTC 01 ACTIVE LOAD MODULE ADDRESS=0DE00F08 OFFSET=0C12 NAME=CSQYASCP DATA AT PSW 0DE01B14 - BF08AB0B 0A0194FE 90681F11 AR/GR 0: /8001 1: /0C3D41F8 2: /FF7F 3: /80200080 4: / 5: /0C3D4000 6: / 7: /0BA2E040 8: /0C3D41D0 9: /7F6F2690 A: /8DE01008 B: /7F6F2560 C: /0DE02007 D: /7F6F2560 E: 8C74936E/ F: / END OF SYMPTOM DUMP *CSQV086E +Q MQSERIES ABNORMAL TERMINATION REASON=00E80100 IEF450I MQZ1MSTR MQZ1MSTR - ABEND=S522 U REASON= TIME=15.21.11 On cheking the messages for CSQV086E 00E80100, it is stated that one of the problem for the could be that MQ unable to locate the CSQZPARM. But it is not the case. The Queue manager comes up normally and stays active for around 30 mins , then abends with the above mentioned error. The environment is OS/390 V2R10 with MQ ver 2.1. This environment runs fine for more than 1.5 years and we had not received this kind of problem. Also, we have not applied any maintainence recently to suspect any problem related to maintainence. Also, we face same problem in other subsystems in the LPAR. We are suspecting that the problem could be due to TCPIP WLM. Have any one in the list faced similar problems? Any resolutions?? Thanks in Advance, Karthik ***The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. Thank you.*** 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
Re: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent
This suggests to me that perhaps CSQZPARM was enqueued by something, and the started task idled out waiting for the enqueue to be released? Try a 'd grs,c' perhaps? Stabbing wildly in the dark, Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of P Karthikeyan Sent: Monday, 17 March 2003 21:08 To: [EMAIL PROTECTED] Subject: MQSeries OS/390 QMGR Abend - CSQV086E - Reason 00E80100 - Urgent Hi, Today we face the problem of queue managers getting abended with the following error messages: IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=522 TIME=15.21.01 SEQ=50409 CPU= ASID=0045 PSW AT TIME OF ERROR 077C1000 8DE01B1A ILC 2 INTC 01 ACTIVE LOAD MODULE ADDRESS=0DE00F08 OFFSET=0C12 NAME=CSQYASCP DATA AT PSW 0DE01B14 - BF08AB0B 0A0194FE 90681F11 AR/GR 0: /8001 1: /0C3D41F8 2: /FF7F 3: /80200080 4: / 5: /0C3D4000 6: / 7: /0BA2E040 8: /0C3D41D0 9: /7F6F2690 A: /8DE01008 B: /7F6F2560 C: /0DE02007 D: /7F6F2560 E: 8C74936E/ F: / END OF SYMPTOM DUMP *CSQV086E +Q MQSERIES ABNORMAL TERMINATION REASON=00E80100 IEF450I MQZ1MSTR MQZ1MSTR - ABEND=S522 U REASON= TIME=15.21.11 On cheking the messages for CSQV086E 00E80100, it is stated that one of the problem for the could be that MQ unable to locate the CSQZPARM. But it is not the case. The Queue manager comes up normally and stays active for around 30 mins , then abends with the above mentioned error. The environment is OS/390 V2R10 with MQ ver 2.1. This environment runs fine for more than 1.5 years and we had not received this kind of problem. Also, we have not applied any maintainence recently to suspect any problem related to maintainence. Also, we face same problem in other subsystems in the LPAR. We are suspecting that the problem could be due to TCPIP WLM. Have any one in the list faced similar problems? Any resolutions?? Thanks in Advance, Karthik ***The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. 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
SIGN-OFF
SIGN-OFF Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MS03 on AS/400 question
You can try this. The output is readable with a 5250
emulator, but if you map the IFS folder in the windows
explorer and open the file it's not readable. When
browsing it with the dspf command it's not formatted in
a user friendly way, but it's at least readable.
/qsys.lib/mqm_elux.lib/saveqmgr.pgm -m qmgr_name -c /home/your_dir/aqmgr.txt
/Jonas
-Original Message-
From: Rick Tsujimoto [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Thu, 13 Mar 2003 17:09:43 -0500
Subject: Re: MS03 on AS/400 question
Jonas,
I had to change MSGTYPE to *LAST to get it to work. I tried to use the -c
parameter to redirect the I/O to an IFS file but it only went to STDOUT. I
got a quick test to work using -f within QSH (which was tricky because the
shell doesn't like parenthesis). If you got -c to work within QSH, I'd
like to see how you did it.
Jonas Nyberg
[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ME.SE cc:
Sent by: Subject: Re: MS03 on AS/400 question
MQSeries List
[EMAIL PROTECTED]
en.AC.AT
03/05/2003 12:09
PM
Please respond
to MQSeries List
You can try to use the unix shell on the AS/400.
This will give you a non zero réturn ocde if something
goes wrong. Try the code below.
PGM PARM(Qmgr)
DCL Qmgr TYPE(*CHAR) LEN( 48)
DCL QSHDTA TYPE(*CHAR) LEN( 4)
DCL CmdStr TYPE(*CHAR) LEN(256)
CHGVAR VAR(CmdStr) +
VALUE('/QSYS.LIB/MQM_ELUX.LIB/SAVEQMGR.PGM +
-m ' *CAT Qmgr)
QSHCMD(CmdStr)
RCVMSG MSGTYPE(*ANY) +
MSGDTA(QSHDTA)
IF COND(%BIN(QSHDTA) *NE 0) THEN(DO)
SNDPGMMSG MSGID(CPF9898) +
MSGF(QCPFMSG) +
MSGDTA('SaveQmgr ended with error') +
MSGTYPE(*ESCAPE)
ENDDO
ENDPGM
Jonas Nyberg
Electrolux IT Solutions - Sweden
-Original Message-
From: Rick Tsujimoto [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 4 Mar 2003 12:15:54 -0500
Subject: MS03 on AS/400 question
I'm not an AS/400 person, so if this seems elementary you'll know why.
I've been running MS03 on an AS/400 and it works fine. I call SAVEQMGR
from a CL script but just discovered that, if an error occurs (e.g. 2058),
no message is issued that can be trapped by MONMSG.
How should I code my CL script to trap problems in MS03?
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: SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes
I have heard that the RUNMQLSR has been much improved for 5.3 so it is SUPPOSEDLY as good asd INETD over 500 connections. This statement is not from experience or anyone else who has experience with it. bobbee From: Tim Armstrong [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes Date: Mon, 17 Mar 2003 09:47:36 +1100 Inetd for more than a couple of hundred connections is usually more reliable. Runmqlsr and threads uses less resources. As for your second question its determined by which type of listener you use. To quote from the manual. You can use inetd or the Run Listener (RUNMQLSR) command to define a TCP/IP connection on a UNIX systerm server, . If you use inetd, a process sis started for each connection you define. If you use the RUNMQLSR command, a thread is started for each connection. This method can therefore be more efficient. I have seen both working well on small systems, however for systems that have several thousand client connections we use inetd. Regards Tim A Stephan C. Moen [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: SWOT Analysis with listeners as inetd or runmqlsr AND channels as [EMAIL PROTECTED] threads or processes N.AC.AT 15/03/2003 16:03 Please respond to MQSeries List MQSeries Experts, I am inquiring from the vast array of knowledge within the MQSeries community on two simple topics. Please respond to the strengths and weaknesses of the following. 1) Choice of listener: inetd or runmqlsr process. 2) Choice of channel: start as a thread or process. Ib m not looking for book responses, just REAL-LIFE experiences, especially from a performance, reliability, scalability, and MQSeries Version (5.3, 5.2 and below) perspective. Thank you. Steve Moen _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Data conversion on mainframe
Darren, sounds like it's time for something drastic. How about adding some kind a dump/snap just before your call. Or my personal favorite -- simply zap the preceding instruction to x'00' and force an S0C1 (or whatever it's called in CICS). Not pretty, but generally pretty effective. Or you can try adding a WTO and wrote out the data... Rebecca -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 5:25 AM To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Rick, I have a rather unsophisticated environment - CEDF is the limit of my online debugging facilities and this doesn't step into the MQXCNVC call. The handle is fine for calls that follow the MQXCNVC call... wonder if it is a problem passing the parameters... Cheers Darren From: Rick Tsujimoto [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Date: Fri, 14 Mar 2003 15:37:52 -0500 Darren, If you have an online debugger, e.g. Intertest, just step throught the code and see where the handle gets whacked. Darren Douch [EMAIL PROTECTED] To: [EMAIL PROTECTED] COM cc: Sent by: Subject: Re: Data conversion on mainframe MQSeries List [EMAIL PROTECTED] en.AC.AT 03/14/2003 02:51 PM Please respond to MQSeries List Thanks Rebecca. I am already setting my Hcon to the supplied default (and using that same handle on other MQ calls quite happily before and after the MQXCNVC call). Might have to resort to trying the samples (assembler only unfortunately) and then seeing if I can link to them from C... certainly a more painful route. Maybe Morag will post a response and save the day :) Cheers Darren. - Original Message - From: Bullock, Rebecca (CSC) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:20 PM Subject: Re: Data conversion on mainframe Darren, while you don't have to do the MQCONN, I believe that there's still a connection handle (after all, it's a parm you need to specify on your MQOPEN). Check what you have this set to (I think it's MQHC_DEF_HCONN for CICS when you don't so the MQCONN) and that you haven't overwritten it. HTH -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 8:20 AM To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Ian and others... I can't argue about MQGET - it works as described in the manuals. But I have a scenario where I can't use it... long story short is that I have a couple of chained data structures in front of the message data itself, plus I don't know at the time of the GET whether I want to convert it 'properly' (using MQ's codepage support) or improperly (using some homegrown conversion tables that are needed to keep a downstream application happy). I've made a bit of progress - managed to build the module now (whether correctly I don't know) - but get 2018 - invalid connection handle - which is a bit odd because CICS apps don't really need / use a connection handle. Any more offers? Cheers Darren. From: Ian Metcalfe [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Date: Fri, 14 Mar 2003 21:59:53 +1100 Hey Darren, If I understand what you're asking correctly, I believe the recommended way is to simply use MQGMO_CONVERT on any MQGET calls on queues that may contain messages from other platforms. If it's a text message type, like MQSTR for example, it'll automatically be converted to the appropriate type for the platform you're on. This works in all cases in my experience, and manually converting within the application seems to be a bit of a waste of effort to me. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Darren Douch Sent: Friday, 14 March 2003 21:29 To: [EMAIL PROTECTED] Subject: Data conversion on mainframe Folks has anyone out there used this call on the mainframe? I'm trying to use it in a C / CICS program and not having much joy building (linking) the application (MQXCNVC not resolving). Can anyone tell me what MQ uses under the covers for data conversion on the mainframe ie the equivalent of iconv on AIX... if I can't use MQXCNVC is there some other way I can do character conversion? Thanks Darren.
Re: SWOT Analysis with listeners as inetd or runmqlsr AND channel s as threads or processes
I've experienced a couple of problems with inetd on AIX. As a result we've switched over to using runmqlsr. It did have some memory leaks but since CSD04/05 it works fine. I particularly found problems if you attempted to stop a queue manager when using inetd. Inetd would still accept incoming connections and spawn a process to handle it. This caused problems when attempting to restart the qm. It said that processes were still running that use MQ and refused to restart. With runmqlsr, you could end the listener and allow the queue manager to restart and then start the listener, thus controlling remote access to the qm (via client connections and/or channels). Regards John. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: 17 March 2003 13:24 To: [EMAIL PROTECTED] Subject: Re: SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes I have heard that the RUNMQLSR has been much improved for 5.3 so it is SUPPOSEDLY as good asd INETD over 500 connections. This statement is not from experience or anyone else who has experience with it. bobbee From: Tim Armstrong [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes Date: Mon, 17 Mar 2003 09:47:36 +1100 Inetd for more than a couple of hundred connections is usually more reliable. Runmqlsr and threads uses less resources. As for your second question its determined by which type of listener you use. To quote from the manual. You can use inetd or the Run Listener (RUNMQLSR) command to define a TCP/IP connection on a UNIX systerm server, . If you use inetd, a process sis started for each connection you define. If you use the RUNMQLSR command, a thread is started for each connection. This method can therefore be more efficient. I have seen both working well on small systems, however for systems that have several thousand client connections we use inetd. Regards Tim A Stephan C. Moen [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: SWOT Analysis with listeners as inetd or runmqlsr AND channels as [EMAIL PROTECTED] threads or processes N.AC.AT 15/03/2003 16:03 Please respond to MQSeries List MQSeries Experts, I am inquiring from the vast array of knowledge within the MQSeries community on two simple topics. Please respond to the strengths and weaknesses of the following. 1) Choice of listener: inetd or runmqlsr process. 2) Choice of channel: start as a thread or process. Ib m not looking for book responses, just REAL-LIFE experiences, especially from a performance, reliability, scalability, and MQSeries Version (5.3, 5.2 and below) perspective. Thank you. Steve Moen _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail 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 ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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: SWOT Analysis with listeners as inetd or runmqlsr AND channel s as threads or processes
Another way around this with INETD is to disable execution permissions on amqcrsta_nd. We experienced this because SeeBeyond connection factory was hammering the connection when it was lost due to the QMGR coming down. bobbee From: John Scott [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SWOT Analysis with listeners as inetd or runmqlsr AND channel s as threads or processes Date: Mon, 17 Mar 2003 14:11:11 - I've experienced a couple of problems with inetd on AIX. As a result we've switched over to using runmqlsr. It did have some memory leaks but since CSD04/05 it works fine. I particularly found problems if you attempted to stop a queue manager when using inetd. Inetd would still accept incoming connections and spawn a process to handle it. This caused problems when attempting to restart the qm. It said that processes were still running that use MQ and refused to restart. With runmqlsr, you could end the listener and allow the queue manager to restart and then start the listener, thus controlling remote access to the qm (via client connections and/or channels). Regards John. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: 17 March 2003 13:24 To: [EMAIL PROTECTED] Subject: Re: SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes I have heard that the RUNMQLSR has been much improved for 5.3 so it is SUPPOSEDLY as good asd INETD over 500 connections. This statement is not from experience or anyone else who has experience with it. bobbee From: Tim Armstrong [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes Date: Mon, 17 Mar 2003 09:47:36 +1100 Inetd for more than a couple of hundred connections is usually more reliable. Runmqlsr and threads uses less resources. As for your second question its determined by which type of listener you use. To quote from the manual. You can use inetd or the Run Listener (RUNMQLSR) command to define a TCP/IP connection on a UNIX systerm server, . If you use inetd, a process sis started for each connection you define. If you use the RUNMQLSR command, a thread is started for each connection. This method can therefore be more efficient. I have seen both working well on small systems, however for systems that have several thousand client connections we use inetd. Regards Tim A Stephan C. Moen [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: SWOT Analysis with listeners as inetd or runmqlsr AND channels as [EMAIL PROTECTED] threads or processes N.AC.AT 15/03/2003 16:03 Please respond to MQSeries List MQSeries Experts, I am inquiring from the vast array of knowledge within the MQSeries community on two simple topics. Please respond to the strengths and weaknesses of the following. 1) Choice of listener: inetd or runmqlsr process. 2) Choice of channel: start as a thread or process. Ib m not looking for book responses, just REAL-LIFE experiences, especially from a performance, reliability, scalability, and MQSeries Version (5.3, 5.2 and below) perspective. Thank you. Steve Moen _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail 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 ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** Instructions for managing your mailing list subscription are
Regarding new log et al
Presently, we have three active logs for a QMRG (using Dual logging mode). We're planning to 1) add a 4th log and 2) increase the size of our current logs so they'll all be the same allocation. Do we have to REPRO the contents of all the logs when we do the add (during an upcoming weekend IPL) or just the contents of the log that was last running when we shutdown MQ? Additionally, does the log get initialized? The JCL that we're using is part of the JCL (CSQ4BSDS) supplied (an additional question here - the space allocation is in records - I'm assuming that CYLs can be substituted, correct?) Thanks in advance, Dave W. 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: CHIN with millions of lines of output
Tim, A simple REXX exec that writes a JES msg to the job log of the CHIN, initiated by your AO product will do the trick. (I'm pretty sure there is also be a JES parm/exit that could accomplish the same thing). I wrote an EXEC that simply writes the date at 00:00 every day - that way, you have blocks of msgs that only span 24 hrs. Cheers, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified Specialist / Solutions Expert - MQSeries (804) 697-3889 [EMAIL PROTECTED] Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 03/11/2003 08:12 PM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:CHIN with millions of lines of output The problem we are having is that on some of our OS/390 systems where the MQ channel initiator and master address spaces are up and running for weeks or months at a time we get enormous amounts of output. This makes searching the job logs using SDSF a prolonged and resource intensive exercise. Has anyone come up with a way to effectively segment the output? Regards Tim A 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: Backout/Commit on queue-level
No. -Original Message- From: Rainer Nonk [SMTP:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:05 AM To: [EMAIL PROTECTED] Subject: Backout/Commit on queue-level Hi all, if i want to use MQs backout/commit feature on queue level: Can i achieve this by creating an own MQQueueManager instance for each queue: ... qMgr1 = new MQQueueManager(qm, env); qMgr2 = new MQQueueManager(qm, env); qMgr2 = new MQQueueManager(qm, env); ... queue1 = qMgr1.accessQueue(...); queue2 = qMgr2.accessQueue(...); queue3 = qMgr3.accessQueue(...); ... best regards, rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Channel problem
Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 problem
Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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
Windows 2000 domain
We recently have fixed our mq authentication errors following these instructions. == Configuring MQSeries Services to run under a domain user You can change the user account under which MQSeries Services runs to be other than the default MUSR_MQADMIN. To do this, first create the new domain user account that you wish to use. Then, on each MQSeries server running MQSeries V5.2, use the following command to configure the MQSeries Services to run under the user ID you require, and also to allocate the correct security rights and group memberships to this user account: AMQMSRVN -regserver -user [domain]\[userid] - password [password] Note that checking Password never expires when you create a user ID for use by MQSeries Services will prevent the need to reconfigure the services owing to password expiry. = I want to find how we can query the user/password that the mq service is using. I have not found an doc explaining the amqmsvrn command. FromScott Deiter Hanover Direct, Inc. Tech services (717) 633-3298 [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: Channel problem
Also make sure that the receiving QM does in fact know that it has a DLQ. Just because a DLQ is defined in not enough. The QM DLQ attribute needs to be set. Peter Potkay IBM MQSeries Certified [EMAIL PROTECTED] X 77906 -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:18 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel problem
Yes, the messages get to the DLQ. But my question is why is it building up in the transmit queue... As far as I know the DLQ did not get full.. What if any did you do to alleviate the situation? Edward. -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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 problem
Edward My 2 cents: Do you have DLQ DEFINED on the Receiving side and is PUT ENABLED and has sufficient MAXDEPTH as in that case your channels will shut down and Xmit Queue will be filled up you mentioned Hence, the queue filled up. which queue are you talking about, one on the recv side or the Xmit queue On restart of MQ the queue probably cleans up as the mesgs are non-persistent How about the status o the SDR Channel ? Arun Makhija TCS and Boeing in AISI WORK: 425-965-6899 FAX: 425-965-6777 http://dcaca225.ca.boeing.com/~axm4256/ Never argue with an idiot. They drag you down to their level and beat you with experience -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 10:29 AM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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: Windows 2000 domain
Scott, I've not actually done this but doesn't the service show up in the Control Panel Services applet? If so, the UserID should be listed in the dialog. Of course, the password will be starred out. I don't have a lab box to try this on but other services I've configured this way show up properly afterward. -- T.Rob -Original Message- From: Deiter Scott [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Windows 2000 domain We recently have fixed our mq authentication errors following these instructions. == Configuring MQSeries Services to run under a domain user You can change the user account under which MQSeries Services runs to be other than the default MUSR_MQADMIN. To do this, first create the new domain user account that you wish to use. Then, on each MQSeries server running MQSeries V5.2, use the following command to configure the MQSeries Services to run under the user ID you require, and also to allocate the correct security rights and group memberships to this user account: AMQMSRVN -regserver -user [domain]\[userid] - password [password] Note that checking Password never expires when you create a user ID for use by MQSeries Services will prevent the need to reconfigure the services owing to password expiry. = I want to find how we can query the user/password that the mq service is using. I have not found an doc explaining the amqmsvrn command. FromScott Deiter Hanover Direct, Inc. Tech services (717) 633-3298 [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 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
MQ5.2 Bug
Title: MQ5.2 Bug We are getting some inconsitent results in our MQ application running on Websphere4.0. Threads were hanging ... There seems to be a bug in MQ5.2 related to double posting a semaphore operation. There is an MQ Agent that polls for messages, and when a message was incoming at the same time the Agent threads were coming down, the messages would get hung and something bad would happen to the threads. Is this specific to a box (AIX only) or is this is a generic MQ bug? Are there any fix pack available ?? Any help or ideas would be highly appreciated. Thanks in advance Subhajit This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna
Re: Channel problem
This behavior is no doubt caused by the MRRTY and MRTMR parameters on the receiver channel's definition. The channel will pause MRTMR milliseconds, and then retry. This repeats MRRTY times, or until the put is successful. I'm not sure what the defaults are for the parameters, but they are sufficiently high to cause the behavior you're seeing. We first saw this when a destination application queue was either full or put disabled, I forget which. The channel slowed done quite a bit as a result. Once we understood the parameters we decided to change all of our receiver channels to MRRTY(0), thereby disabling retrying. Edward Pius [EMAIL PROTECTED]To: [EMAIL PROTECTED] ORNE.COMcc: Sent by: MQSeriesSubject: Channel problem List [EMAIL PROTECTED] N.AC.AT 03/17/2003 12:28 PM Please respond to MQSeries List Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 problem
Edward, all I did for the immediate problem was increase the maxdepth for the DLQ and restart the channel. Then had the programmer fix the original problem (app had a typo in the REplyToQ name). But likely you've done that kind of thing already; I'd look at the suggestions from others... -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Yes, the messages get to the DLQ. But my question is why is it building up in the transmit queue... As far as I know the DLQ did not get full.. What if any did you do to alleviate the situation? Edward. -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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
Fwd: WMQI Connectivity MQRC-2195
If anyone is interested. I deleted the broker and the config mgr. I then removed MQSeries 5.3. I then installed MQSeries 5.2.1 and recreated the broker and the configuration mgr. The control center now works with NO TCP/IP errors and I can import anything my little heart desires!! I am next going to try 5.3 with CSD01 and see what happens. AnywayHapyy St Pats Day! bobbee :-) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: WMQI Connectivity MQRC-2195 Date: Fri, 14 Mar 2003 10:00:04 -0500 Bobbee, If it helps I'm running the same configuration. (Maybe I should of played the lotto the day I installed !!) Win2k SP3 (I upgraded form SP2) WMQI 2.1 - CSD03 I initially installed WMQI V2.1, applied CSD02, and then some time later applied CSD03) DB2 7.1 - I then updated this to 7.2 by going to SP4 of DB2 MQ - V5.3 with CSD01 ( The October release not the initial June release) Thanks - John - Forwarded by John Sack on 03/14/2003 09:53 AM - Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 03/13/2003 01:23 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:WMQI Connectivity MQRC-2195 I upgraded to MQ5.3, doing so I updated my Win 2K to SP3 from SP2. MQ was complaining about a number of things missing which SP3 solved. I had WMQI 2.1 @ CSD03 and I am on DB2 7.1. Now I get a message MQRC-2195 (internal error), no errors in Logs, no FDC files. I do get an Event Viewer message indicating WMQI had a TCP/IP error. I just deleted DB2, WMQI and MQSeries. Going to reinstall. I think I am looking at a Win 2K re-install and not going past SP2. Which is where it wasat when it was working prior to the MQ 5.3 upgrade from MQ 5.2.1. ANYBODY bobbee _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail 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 _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Win2K Server / MQSeries restart problem
Folks, I running Win2K server on a dell box. MQSeries 5.2.1 with CSD 06 With the server up and running normal Queue manager running and set to Automatic startup Command Server running and set to Automatic startup Channel Initiator running and set to Automatic startup Listener running and set to Automatic startup When I restart the server the following occurs... Queue manager not running / shows stopped and set set to Manual startup Command Server not running / shows stopped and set to Manual startup Channel initiator not running / shows stopped and set to Manual startup (However, on this one, if I show Task Manager, Runmqchi shows running? ) The Listener does not appear and I would need to recreate it at this point. I have deinstalled and reinstalled MQSeries, tried an efix from IBM and then went to CSD 06. Currently IBM is suspecting a registry problem and I am in the process of collecting more doc. I am thinking it is environmental but wanted to see if anyone has seen this or has any thoughts? Thanks, Chris Chris A. Stone Specialist MQSeries Support GLOBE Center AMS (+1 818 549 5866 (+1 909 544 1026 (Cell) [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: Windows 2000 domain
Oddly enough after setting the user with the amqmsrvn command the userid does not show up in the security tab in the services properties window. Is this window bending the truth or is this a different userid than the amqmsrvn command sets? FromScott Deiter Hanover Direct, Inc. Tech services (717) 633-3298 [EMAIL PROTECTED] -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:45 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Windows 2000 domain Scott, I've not actually done this but doesn't the service show up in the Control Panel Services applet? If so, the UserID should be listed in the dialog. Of course, the password will be starred out. I don't have a lab box to try this on but other services I've configured this way show up properly afterward. -- T.Rob -Original Message- From: Deiter Scott [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Windows 2000 domain We recently have fixed our mq authentication errors following these instructions. == Configuring MQSeries Services to run under a domain user You can change the user account under which MQSeries Services runs to be other than the default MUSR_MQADMIN. To do this, first create the new domain user account that you wish to use. Then, on each MQSeries server running MQSeries V5.2, use the following command to configure the MQSeries Services to run under the user ID you require, and also to allocate the correct security rights and group memberships to this user account: AMQMSRVN -regserver -user [domain]\[userid] - password [password] Note that checking Password never expires when you create a user ID for use by MQSeries Services will prevent the need to reconfigure the services owing to password expiry. = I want to find how we can query the user/password that the mq service is using. I have not found an doc explaining the amqmsvrn command. FromScott Deiter Hanover Direct, Inc. Tech services (717) 633-3298 [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 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: Windows 2000 domain
Hello, try the command 'dcomcnfg'. Select the 'IBM MQSeries Services' entry, and request 'Properties'. Then go to the 'identity' tab. Regards... Neil Casey. Deiter Scott [EMAIL PROTECTED]To: [EMAIL PROTECTED] RECT.COMcc: Sent by: MQSeriesSubject: Re: Windows 2000 domain List [EMAIL PROTECTED] n.AC.AT 18/03/2003 07:52 Please respond to MQSeries List Oddly enough after setting the user with the amqmsrvn command the userid does not show up in the security tab in the services properties window. Is this window bending the truth or is this a different userid than the amqmsrvn command sets? FromScott Deiter Hanover Direct, Inc. Tech services (717) 633-3298 [EMAIL PROTECTED] -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:45 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Windows 2000 domain Scott, I've not actually done this but doesn't the service show up in the Control Panel Services applet? If so, the UserID should be listed in the dialog. Of course, the password will be starred out. I don't have a lab box to try this on but other services I've configured this way show up properly afterward. -- T.Rob -Original Message- From: Deiter Scott [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Windows 2000 domain We recently have fixed our mq authentication errors following these instructions. == Configuring MQSeries Services to run under a domain user You can change the user account under which MQSeries Services runs to be other than the default MUSR_MQADMIN. To do this, first create the new domain user account that you wish to use. Then, on each MQSeries server running MQSeries V5.2, use the following command to configure the MQSeries Services to run under the user ID you require, and also to allocate the correct security rights and group memberships to this user account: AMQMSRVN -regserver -user [domain]\[userid] - password [password] Note that checking Password never expires when you create a user ID for use by MQSeries Services will prevent the need to reconfigure the services owing to password expiry. = I want to find how we can query the user/password that the mq service is using. I have not found an doc explaining the amqmsvrn command. FromScott Deiter Hanover Direct, Inc. Tech services (717) 633-3298 [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 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: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first Could the MQ channel ADOPTMCA* ADOPTNEWMCA parms help you in respect to automatically retry channel operations -Original Message-From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]Sent: Saturday, 15 March 2003 5:45 AMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Keith, by "bridge" are you referring to the channels? I don't know if this will help, but a long time ago, we had something that sounds vaguely similar (although it was a Solaris systemwhere you have Windows). What we ended up doing is having the dist. side: 1)Send STOP CHANNEL commands to the mainframe telling it to stop the sender channel to the sun side 2) Issue STOP CHANNEL commands for the sender channels on the distributed side. Then at restart: 1)Send START CHANNEL commands to the mainframe telling it to restart its sender channels 2) Issue START CHANNEL for the local sender The only thing you have to watch for is if you WANT the channels to be down and you do a reboot, although that could be scripted around. Since we have no Windows qmgrs, I don't know if you can do something similar, butat least you now got a response :-) Good luck! HTH -- Rebecca Rebecca BullockComputer Sciences CorporationMFCoE/Newark CS TeamEducational Testing Service AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Keith A. Hessong [mailto:[EMAIL PROTECTED]Sent: Friday, March 14, 2003 12:12 PMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Greetings: I am trying this again. I didn't get any responses from my first attempt at sending this issue to the list. Thanks, Keith Hessong Senior Programmer/Analyst Golden Rule Insurance Company -Original Message-From: Keith A. Hessong [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003 10:32 AMTo: [EMAIL PROTECTED]Subject: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first Greetings: My shop is currently experiencing a problem with MQ Series between our distributed side and our mainframe side when a server is dropped and restarted on the distributed side without dropping the bridge first. My shop ends up having at least one of our mainframe connections showing up on the distributed side as "PENDING". Our environment is as follows: Distributed Side: MQ Series Version 5.2 MSMQ MQ Series Bridge within Host Integration Server WINDOWS 2000 MSMQ Service Pack 3 Mainframe Side: OS/390 Version 2.5 MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA parameter = YES What are we currently doing now when a server is dropped and restarted on the distributed side? 1) Everything seems to be OK if we are able to shut the bridge down before dropping the server and restarting it on the distributed side. 2) If a server is dropped and restarted and no work kicks off from the distributed side to the mainframe side, the channel on the mainframe can be stopped and restarted and everything seems to be OK. 3) If a server is dropped and restarted and work kicks off from the distributed side to the mainframe side, the channel on the mainframe must be forced down, messages must be waited on for arrival on the mainframe side to acknowledge loss of communication between the distributed side and the mainframe side, and the channel can be restarted on the mainframe side. I have a couple of questions. Are we handling what we are experiencing here correctly? If not, what should we be doing that we aren't doing? Any other suggestions? Thanks, Keith Hessong ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first We have tried ADOPTMCA to solve our problem and it didn't do any good. We haven't tried ADOPTNEWMCA though. Keith -Original Message-From: Crupi, Margherita [mailto:[EMAIL PROTECTED]Sent: Monday, March 17, 2003 4:20 PMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Could the MQ channel ADOPTMCA* ADOPTNEWMCA parms help you in respect to automatically retry channel operations -Original Message-From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]Sent: Saturday, 15 March 2003 5:45 AMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Keith, by "bridge" are you referring to the channels? I don't know if this will help, but a long time ago, we had something that sounds vaguely similar (although it was a Solaris systemwhere you have Windows). What we ended up doing is having the dist. side: 1)Send STOP CHANNEL commands to the mainframe telling it to stop the sender channel to the sun side 2) Issue STOP CHANNEL commands for the sender channels on the distributed side. Then at restart: 1)Send START CHANNEL commands to the mainframe telling it to restart its sender channels 2) Issue START CHANNEL for the local sender The only thing you have to watch for is if you WANT the channels to be down and you do a reboot, although that could be scripted around. Since we have no Windows qmgrs, I don't know if you can do something similar, butat least you now got a response :-) Good luck! HTH -- Rebecca Rebecca BullockComputer Sciences CorporationMFCoE/Newark CS TeamEducational Testing Service AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Keith A. Hessong [mailto:[EMAIL PROTECTED]Sent: Friday, March 14, 2003 12:12 PMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Greetings: I am trying this again. I didn't get any responses from my first attempt at sending this issue to the list. Thanks, Keith Hessong Senior Programmer/Analyst Golden Rule Insurance Company -Original Message-From: Keith A. Hessong [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003 10:32 AMTo: [EMAIL PROTECTED]Subject: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first Greetings: My shop is currently experiencing a problem with MQ Series between our distributed side and our mainframe side when a server is dropped and restarted on the distributed side without dropping the bridge first. My shop ends up having at least one of our mainframe connections showing up on the distributed side as "PENDING". Our environment is as follows: Distributed Side: MQ Series Version 5.2 MSMQ MQ Series Bridge within Host Integration Server WINDOWS 2000 MSMQ Service Pack 3 Mainframe Side: OS/390 Version 2.5 MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA parameter = YES What are we currently doing now when a server is dropped and restarted on the distributed side? 1) Everything seems to be OK if we are able to shut the bridge down before dropping the server and restarting it on the distributed side. 2) If a server is dropped and restarted and no work kicks off from the distributed side to the mainframe side, the channel on the mainframe can be stopped and restarted and everything seems to be OK. 3) If a server is dropped and restarted and work kicks off from the distributed side to the mainframe side, the channel on the mainframe must be forced down, messages must be waited on for arrival on the mainframe side to acknowledge loss of communication between the distributed side and the mainframe side, and the channel can be restarted on the mainframe side. I have a couple of questions. Are we handling what we are experiencing here correctly? If not, what should we be doing that we aren't doing? Any other suggestions? Thanks, Keith Hessong ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not
Re: Backout/Commit on queue-level
Probably not, can't be certain with java as I just dont know. However given the underlying call is likely to be MQCONN or MQCONNX then you get one connection per queue manager per thread, any additional connections just get given the same handle. So yes maybe you could do it by coordinating mutli-threaded code although even that is not certain and the added complexity in the code would make it hard to justify. What problem are you trying to solve? Regards Tim A Christopher D. Fryett To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: T Subject: Re: Backout/Commit on queue-level Sent by: MQSeries List [EMAIL PROTECTED] N.AC.AT 17/03/2003 21:10 Please respond to MQSeries List Rainer, Could you elaborate a little here. I would tend to think you would want to use the backout/commit at a message level. So, when you commit a message it is recognized in the target queue as visible and committed. You would use the backout if an error of some sort you designated occurred, and do not want it to be available in the target queue. Chris -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Nonk Sent: Monday, March 17, 2003 3:05 AM To: [EMAIL PROTECTED] Subject: Backout/Commit on queue-level Hi all, if i want to use MQs backout/commit feature on queue level: Can i achieve this by creating an own MQQueueManager instance for each queue: ... qMgr1 = new MQQueueManager(qm, env); qMgr2 = new MQQueueManager(qm, env); qMgr2 = new MQQueueManager(qm, env); ... queue1 = qMgr1.accessQueue(...); queue2 = qMgr2.accessQueue(...); queue3 = qMgr3.accessQueue(...); ... best regards, rainer 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: CHIN with millions of lines of output
Thanks, Someone else suggested suppressing messages, I did a quick bit of research on our output and if we suppress CSQX500I, CSQX501I, and CSQX545I it should reduce the total output by about 90-95% which makes things manageable. This is discussed in the z/OS System Setup Guide as follows. Task 21: Suppress information messages |--| | | | | | | |--| If your WebSphere MQ system is heavily used, with many channels stopping and starting, a large number of information messages are sent to the z/OS console and hardcopy log. The WebSphere MQ-IMS bridge and buffer manager might also produce a large number of information messages. If required, you can suppress some of these console messages by using the z/OS message processing facility list, specified by the MPFLSTxx members of SYS1.PARMLIB. The messages you specify still appear on the hardcopy log, but not on the console. Sample thlqual.SCSQPROC(CSQ4MPFL) shows suggested settings for MPFLSTxx. See the MVS Initialization and Tuning Reference manual for more information about MPFLSTxx. If you want to suppress selected information messages on the hardcopy log, you can use the z/OS installation exit IEAVMXIT. You can set the following bit switches ON for the required messages: CTXTRDTM Delete the message. The message is not displayed on consoles or logged in hardcopy. CTXTESJL Suppress from job log. The message does not go into the JES job log. CTXTNWTP Do not carry out WTP processing. The message is not sent to a TSO terminal or to the system message data set of a batch job. Notes: 1. For full details, refer to the MVS Installation Exits book. 2. You are not recommended to suppress messages other than those in the suggested suppression list, CSQ4MPFL. Regards Tim A Art Schanz [EMAIL PROTECTED]To: [EMAIL PROTECTED] IT.FRB.ORG cc: Sent by: MQSeriesSubject: Re: CHIN with millions of lines of output List [EMAIL PROTECTED] N.AC.AT 18/03/2003 04:17 Please respond to MQSeries List Tim, A simple REXX exec that writes a JES msg to the job log of the CHIN, initiated by your AO product will do the trick. (I'm pretty sure there is also be a JES parm/exit that could accomplish the same thing). I wrote an EXEC that simply writes the date at 00:00 every day - that way, you have blocks of msgs that only span 24 hrs. Cheers, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified Specialist / Solutions Expert - MQSeries (804) 697-3889 [EMAIL PROTECTED] Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List To: [EMAIL PROTECTED][EMAIL PROTECTED] cc: Subject:CHIN with 03/11/2003 08:12 PM millions of lines of output Please respond to MQSeries List The problem we are having is that on some of our OS/390 systems where the MQ channel initiator and master address spaces are up and running for weeks or months at a time we get enormous amounts of output. This makes searching the job logs using SDSF a prolonged and resource intensive exercise. Has anyone come up with a way to effectively segment the output? Regards Tim A 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
Joseph Gellis/CPA/CSC is out of the office.
I will be out of the office starting 03/17/2003 and will not return until 03/22/2003. I will respond to your message when I return. 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
