Two Wolves
Sorry about the slip up in addressing that one, however, not a bad commentary on human nature was it? Cheers... Jim Nuckolls 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 going (RETRYING)
Thanks for your help, I looked at my log and couldn't make any sense of it. I attached the log below. Thanks, Hossam AMQ7924: Bad length in the PCF header (length = 538976288). EXPLANATION: Message data conversion cannot convert a message in Programmable Command Format (PCF) because the PCF header structure contains an incorrect length field. Either the message has been truncated, or it contains data that is not valid. ACTION: Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Do not discard these files until the problem has been resolved. Use the file containing the Message Descriptor of the message to determine the source of the message and to see how data that is not valid became included in the message. - amqxfdcx.c : 671 02/17/04 09:54:53 AMQ6184: An internal WebSphere MQ error has occurred on queue manager ENT.QMGR. EXPLANATION: An error has been detected, and the WebSphere MQ error recording routine has been called. The failing process is process 13759. ACTION: Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved. - amqxfdcx.c : 705 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Neil Casey Sent: Monday, February 16, 2004 10:38 PM To: [EMAIL PROTECTED] Subject: Re: Channel going (RETRYING) The reason for a channel going to RETRYING will be recorded in the error log at one end of the channel or the other (sometimes both if you are lucky). On the Solaris system, the error log is /var/mqm/qmgrs/QMGRNAME/errors/AMQERR01.LOG -- QMGRNAME is the actual name of your queue manager, not a contant. The ...01.LOG is always the newest log file, the 02 and 03 versions are progressively older. On a mainframe you need to look in the JES log for the CHIN address space. Look for messages which contain the channel name. Regards... Neil Casey. |-+ | | Khedr, Hossam | | | (GEI, MORT) | | | [EMAIL PROTECTED]| | | COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | n.AC.AT | | || | || | | 17/02/2004 09:22 | | | Please respond to| | | MQSeries List| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Channel going (RETRYING) | --| I'm trying to set my first test with MQ. I created all needed Qs and channels or at lease this is what I think :) I tried MQSender.java to send a message from Solaris to Mainframe; however it worked couple of times, and then the sender channel went crazy. every time you use this channel it gets activated by the XMITQ and then dies , when I checked the status of the channel using mqsc, I found it at STATUS(RETRYING). Any idea or clues would be much appreciated . Thanks, Hossam Khedr 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
Help with MQ, COM-PLETE and 2219 errors.
I'm writing to you all in hope you can help, because it seems no one else can. We have been using MQ together with Natural / Adabas under COM-PLETE and CICS, for about two years now. Everything running online under CICS has worked just fine. However along with CICS we run Software AG's COM-PLETE TP monitor, which is like CICS in that sense. We run batch Natural without any problems that I'm aware of. The problem occurs when we run Natural with MQ online in COM-PLETE. Occasionally we get 2219 errors, which says MQRC_CALL_IN_PROGRESS, or another words you can't issue more than one API call for one connection while another call is in progress for that connection. It is extremely random when the error comes up. Sometimes it is as soon as you log in and run a program which accesses MQ, or it could be after you have been logged in for a while. Sometimes the only way to get around it is to log off all together and come back in. Now I don't know that much about COM-PLETE, but it sounds as if various people coming in are getting the same connection handle (hard to prove when error occurs) and if one is already doing an API call then the other gets the 2219. At least that is my suspicions. Do any of you know of a way to get around this problem? Do you think that is what it is? Any help on this subject would be appreciated. Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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 going (RETRYING)
Title: RE: Channel going (RETRYING) I didn't see any sequence related errors. Thanks, Hossam -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Carroll, Y. (Yvette)Sent: Tuesday, February 17, 2004 1:19 AMTo: [EMAIL PROTECTED]Subject: Re: Channel going (RETRYING) Hi Are there any messages about sequence number errors in your logs? -Original Message- From: Khedr, Hossam (GEI, MORT) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 17, 2004 12:23 AM To: [EMAIL PROTECTED] Subject: Channel going (RETRYING) I'm trying to set my first test with MQ. I created all needed Qs and channels or at lease this is what I think :) I tried MQSender.java to send a message from Solaris to Mainframe; however it worked couple of times, and then the sender channel went crazy. every time you use this channel it gets activated by the XMITQ and then dies , when I checked the status of the channel using mqsc, I found it at STATUS(RETRYING). Any idea or clues would be much appreciated . Thanks, Hossam Khedr 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 email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version.
CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004
Hi, I put on some maintenance on WMQ Ver 5.3 on OS/390 V2.10. I got the following messages. I searched the WMQ doc and I went on IBMLINK and could not get a clear indication of how to debug the CSQV086E w/Reason Code 00C6004. When I backed out the maintenance, I was greeted by S6C6 abends. I re-initialized the LOGs, BSDS files and the Page datasets and everything started OK. Since this was a test Queue Manager, there was no big impact. I am not comfortable with that solution or the fact that I could not find a clear path in the doc to at least identify the problem I have opened a problem record with IBM on this, but I'd be interested to know if anyone has seen anything like the messages below and if so, what was done to identify and to solve the problem. Right now, the path through the diagnostics is the more important part of the answer, as far as I am concerned Thanx much, 21.46.55 STC14869 SUNDAY,15 FEB 2004 21.46.55 STC14869 IEF695I START MQSBMSTR WITH JOBNAME MQSBMSTR IS ASSIGNED TO USER MQMSTC , GROUP OMVSIS 21.46.55 STC14869 $HASP373 MQSBMSTR STARTED 21.46.55 STC14869 IEF403I MQSBMSTR - STARTED - TIME=21.46.55 21.46.58 STC14869 IEA794I SVC DUMP HAS CAPTURED: 21.46.58 STC14869 *CSQV086E @MQSBQUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004 DUMPID=001 REQUESTED BY JOB (MQSBMSTR) DUMP TITLE=MQSB,ABN=5C6-00C60004,U=SYSOPR ,C=F1000.530.IPC -CS QYSIRM,M=CSQYECTE,LOC=CSQFIEPL.CSQFMGIN+01AE 21.47.08 STC14869 IEF450I MQSBMSTR MQSBMSTR - ABEND=S5C6 U REASON=00C60004 TIME=21.47.08 21.47.08 STC14869 IEF404I MQSBMSTR - ENDED - TIME=21.47.08 21.47.08 STC14869 $HASP395 MQSBMSTR ENDED 21.47.08 STC14869 *CTO282I DB2 SYSTEM MQSBMSTR HAS BEEN SHUTDOWN 0-- - Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004
00C60004 means: Explanation: MQSeries was unable to load the message table (CSQFMTAB). Module: CSQFMGIN System Action: MQSeries terminates. System Programmer Response: Ensure that the message table is in the required library (SCSQANLx, where x is your national language letter), and that it is referenced correctly, and restart MQSeries. earMERC Roberts [EMAIL PROTECTED]To: [EMAIL PROTECTED] BUSA.COMcc: Sent by: MQSeriesSubject: CSQV086E @MQSBQUEUE MANAGER ABNORMAL TERMINATION List REASON=00C60004 [EMAIL PROTECTED] n.ac.at 02/17/2004 10:15 AM Please respond to MQSeries List Hi, I put on some maintenance on WMQ Ver 5.3 on OS/390 V2.10. I got the following messages. I searched the WMQ doc and I went on IBMLINK and could not get a clear indication of how to debug the CSQV086E w/Reason Code 00C6004. When I backed out the maintenance, I was greeted by S6C6 abends. I re-initialized the LOGs, BSDS files and the Page datasets and everything started OK. Since this was a test Queue Manager, there was no big impact. I am not comfortable with that solution or the fact that I could not find a clear path in the doc to at least identify the problem I have opened a problem record with IBM on this, but I'd be interested to know if anyone has seen anything like the messages below and if so, what was done to identify and to solve the problem. Right now, the path through the diagnostics is the more important part of the answer, as far as I am concerned Thanx much, 21.46.55 STC14869 SUNDAY,15 FEB 2004 21.46.55 STC14869 IEF695I START MQSBMSTR WITH JOBNAME MQSBMSTR IS ASSIGNED TO USER MQMSTC , GROUP OMVSIS 21.46.55 STC14869 $HASP373 MQSBMSTR STARTED 21.46.55 STC14869 IEF403I MQSBMSTR - STARTED - TIME=21.46.55 21.46.58 STC14869 IEA794I SVC DUMP HAS CAPTURED: 21.46.58 STC14869 *CSQV086E @MQSBQUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004 DUMPID=001 REQUESTED BY JOB (MQSBMSTR) DUMP TITLE=MQSB,ABN=5C6-00C60004,U=SYSOPR ,C=F1000.530.IPC -CS QYSIRM,M=CSQYECTE,LOC=CSQFIEPL.CSQFMGIN+01AE 21.47.08 STC14869 IEF450I MQSBMSTR MQSBMSTR - ABEND=S5C6 U REASON=00C60004 TIME=21.47.08 21.47.08 STC14869 IEF404I MQSBMSTR - ENDED - TIME=21.47.08 21.47.08 STC14869 $HASP395 MQSBMSTR ENDED 21.47.08 STC14869 *CTO282I DB2 SYSTEM MQSBMSTR HAS BEEN SHUTDOWN 0-- - Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004
00C60004 Explanation: The queue manager was unable to load the message table (CSQFMTAB). System Action: The queue manager terminates. System Programmer Response: Ensure that the message table is in the required library (SCSQANLx, where x is your national language letter), and that it is referenced correctly, and restart the queue manager. Maybe this can help you. Is SCSQANLX LNK? Luiz Carlos Kmit Internet Mail Address: [EMAIL PROTECTED] Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004 Hi, I put on some maintenance on WMQ Ver 5.3 on OS/390 V2.10. I got the following messages. I searched the WMQ doc and I went on IBMLINK and could not get a clear indication of how to debug the CSQV086E w/Reason Code 00C6004. When I backed out the maintenance, I was greeted by S6C6 abends. I re-initialized the LOGs, BSDS files and the Page datasets and everything started OK. Since this was a test Queue Manager, there was no big impact. I am not comfortable with that solution or the fact that I could not find a clear path in the doc to at least identify the problem I have opened a problem record with IBM on this, but I'd be interested to know if anyone has seen anything like the messages below and if so, what was done to identify and to solve the problem. Right now, the path through the diagnostics is the more important part of the answer, as far as I am concerned Thanx much, 21.46.55 STC14869 SUNDAY, 15 FEB 2004 21.46.55 STC14869 IEF695I START MQSBMSTR WITH JOBNAME MQSBMSTR IS ASSIGNED TO USER MQMSTC , GROUP OMVSIS 21.46.55 STC14869 $HASP373 MQSBMSTR STARTED 21.46.55 STC14869 IEF403I MQSBMSTR - STARTED - TIME=21.46.55 21.46.58 STC14869 IEA794I SVC DUMP HAS CAPTURED: 21.46.58 STC14869 *CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004 DUMPID=001 REQUESTED BY JOB (MQSBMSTR) DUMP TITLE=MQSB,ABN=5C6-00C60004,U=SYSOPR ,C=F1000.530.IPC -CS QYSIRM,M=CSQYECTE,LOC=CSQFIEPL.CSQFMGIN+01AE 21.47.08 STC14869 IEF450I MQSBMSTR MQSBMSTR - ABEND=S5C6 U REASON=00C60004 TIME=21.47.08 21.47.08 STC14869 IEF404I MQSBMSTR - ENDED - TIME=21.47.08 21.47.08 STC14869 $HASP395 MQSBMSTR ENDED 21.47.08 STC14869 *CTO282I DB2 SYSTEM MQSBMSTR HAS BEEN SHUTDOWN 0-- - Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
monitor MQ z/OS with MO71 ?
has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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
Brian E Wilson/Albany/IBM is out of the office.
I will be out of the office starting February 17, 2004 and will not return until February 20, 2004. I will be out of the office on vacation 2/17 through 2/19, returning on February 20. I will respond to your e-mail as soon as I can. 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
MQ Along with GXS Enterprise Systems
Anybody used MQ with GXS Enterprise System? I would like to chat about the connectivity's between the 2 Systems and how can we get the best out of both. I'm very familiar with the GXS product, but I'm still new to the MQ World. Thanks, Hossam Khedr 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: monitor MQ z/OS with MO71 ?
We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 audit tracking / reporting
Title: Message John Thanks - it's a good starting point. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: John Scott [mailto:[EMAIL PROTECTED] Sent: 17 February 2004 9:11 PMTo: [EMAIL PROTECTED]Subject: Re: MQ audit tracking / reporting Rao, I am not sure whether this will do what you want, but... We have a script that runs every night. It uses the client version of saveqmgr to connect to each MQSeries server on all our known port numbers and attempt to save the queue manager configuration). Next it uses a version control system to compare the new saveqmgr scripts with yesterday's and mails a summary to the mqadmin group. It also checks the changes into a version control system, so we have a history of what changes were made and when. Thus we get a list of queue managers that have changed on a daily basis. If somebody deletes a queue or queue manager, this is recorded in the logs and sent as part of the mail. It doesn't tell you who changed the stuff, but at least it gives you a starting point... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: 17 February 2004 04:38To: [EMAIL PROTECTED]Subject: MQ audit tracking / reporting Fellows We have a request to audit the changes to MQ objects - ie basically to report on periodical basis who created the objects and who deleted the objects and when (date time). Our primary focus is on Windows SUN Solaris platforms. As you all know, Windows administrators and as well as UNIX "root" users inherit all the securities on the MQ objects and there is nothing much we can do within MQ to stop it. Am I right in making this statement (or can we do something). We are preventing normal users to create objects using OAM. Let me explain the background where I am coming from: We have situations where there are number of users in server administration group and only one or two in MQM group as designated MQ administrators. And the responsibility of maintaining MQ objects, obviously, falls in to MQM group users. Now the question being raised, how do we track report changes done by other administrators who are not in the "mqm" group. I do fully know that, if some administrator intentionally kills the queue manager and/or deletes the queue/log folders nothing much can be done - that's bad luck and other than tracking down UNIX / Windows logs who was logged on at that time etc.. It's not my current primary focus of the question. But if one of those other administrators adds/deletes queues, channels and forget to inform the "official" MQ administrator, is there anything this (poor) MQ administrator can rely/report on. I gave a go with DMPMQLOG utility and tried to analyse the report - even though it shows the user-id created the objects, it doesn't show the user-id who deleted the object and most importantly the date and time. 1) Am I missing something in the log or analysis process ??? 2) Is there anyway to filter the log by log record type - ie: Create Delete objects only 3) Are there any other better ways to report the differences and their audit trail 4) Through OAM process can we prevent administrator group users to create/delete the objects Appreciate your feedback/experiences. Thanks in advance Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.Thank you.***Click here to visit the Argos home page http://www.argos.co.ukThe 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 addressee, any disclosure, reproduction, dissemination or use of this communication is not authorised.If you have received this message in error, please advise the sender by using the 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. This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.Thank you.
Re: monitor MQ z/OS with MO71 ?
Ben, Yes, I've gotten it to work. In fact, it's worked since 1996. What kind of problem are you having ? do you check off the MVS box ? The queue is SYSTEM.COMMAND.INPUT (normally), not SYSTEM.ADMIN.COMMAND. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004
Thanx much, Jim. I eventually found the 00C60004 in the doc (WMQ info center). thanx for the tip IBM is going to look at the dump to identify the table (I hope). I didn't spot any message table information in the HOLDDATA for the maintenance I APPLYed(I'll recheck that.). I'm hoping I didn't misuse the IEBIBALL utility. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC - Forwarded by Ernest Roberts/171/DCAG/DCX on 02/17/2004 03:29 PM - Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: Re: CSQV086E @MQSBQUEUE MANAGER ABNORMAL TERMINATION MQSeries ListREASON=00C60004 [EMAIL PROTECTED] en.AC.AT 02/17/2004 01:10 PM Please respond to MQSeries List 00C60004 means: Explanation: MQSeries was unable to load the message table (CSQFMTAB). Module: CSQFMGIN System Action: MQSeries terminates. System Programmer Response: Ensure that the message table is in the required library (SCSQANLx, where x is your national language letter), and that it is referenced correctly, and restart MQSeries. earMERC Roberts [EMAIL PROTECTED]To: [EMAIL PROTECTED] BUSA.COMcc: Sent by: MQSeriesSubject: CSQV086E @MQSB QUEUE MANAGER ABNORMAL TERMINATION List REASON=00C60004 [EMAIL PROTECTED] n.ac.at 02/17/2004 10:15 AM Please respond to MQSeries List Hi, I put on some maintenance on WMQ Ver 5.3 on OS/390 V2.10. I got the following messages. I searched the WMQ doc and I went on IBMLINK and could not get a clear indication of how to debug the CSQV086E w/Reason Code 00C6004. When I backed out the maintenance, I was greeted by S6C6 abends. I re-initialized the LOGs, BSDS files and the Page datasets and everything started OK. Since this was a test Queue Manager, there was no big impact. I am not comfortable with that solution or the fact that I could not find a clear path in the doc to at least identify the problem I have opened a problem record with IBM on this, but I'd be interested to know if anyone has seen anything like the messages below and if so, what was done to identify and to solve the problem. Right now, the path through the diagnostics is the more important part of the answer, as far as I am concerned Thanx much, 21.46.55 STC14869 SUNDAY,15 FEB 2004 21.46.55 STC14869 IEF695I START MQSBMSTR WITH JOBNAME MQSBMSTR IS ASSIGNED TO USER MQMSTC , GROUP OMVSIS 21.46.55 STC14869 $HASP373 MQSBMSTR STARTED 21.46.55 STC14869 IEF403I MQSBMSTR - STARTED - TIME=21.46.55 21.46.58 STC14869 IEA794I SVC DUMP HAS CAPTURED: 21.46.58 STC14869 *CSQV086E @MQSBQUEUE MANAGER ABNORMAL TERMINATION REASON=00C60004 DUMPID=001 REQUESTED BY JOB (MQSBMSTR) DUMP TITLE=MQSB,ABN=5C6-00C60004,U=SYSOPR ,C=F1000.530.IPC -CS QYSIRM,M=CSQYECTE,LOC=CSQFIEPL.CSQFMGIN+01AE 21.47.08 STC14869 IEF450I MQSBMSTR MQSBMSTR - ABEND=S5C6 U REASON=00C60004 TIME=21.47.08 21.47.08 STC14869 IEF404I MQSBMSTR - ENDED - TIME=21.47.08 21.47.08 STC14869 $HASP395 MQSBMSTR ENDED 21.47.08 STC14869 *CTO282I DB2 SYSTEM MQSBMSTR HAS BEEN SHUTDOWN 0-- - Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 Along with GXS Enterprise Systems
Hossam, take a look at this page: http://www-106.ibm.com/developerworks/websphere/zones/newcomers/businessinte gration.html I just did a quick catch up read on GXS, sounds like a 'broker' type product. If it can use MQ as the undlying transport, there should be no problem combining the two. Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Khedr, Hossam (GEI, MORT) Verzonden: dinsdag 17 februari 2004 21:00 Aan: [EMAIL PROTECTED] Onderwerp: MQ Along with GXS Enterprise Systems Anybody used MQ with GXS Enterprise System? I would like to chat about the connectivity's between the 2 Systems and how can we get the best out of both. I'm very familiar with the GXS product, but I'm still new to the MQ World. Thanks, Hossam Khedr 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: monitor MQ z/OS with MO71 ?
Hi Arlen, thanks for the response. I set the MCA user field on mainframe to the id I used to access the qmgr. but it doesn't work. Is there anything else I need to set? I remember the command server is always started upon qmgr startup. So that isn't an issue. thanks, bfz Williams, Arlen To: [EMAIL PROTECTED] arlen.williams@ cc: EDS.COM Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List [EMAIL PROTECTED] en.AC.AT 02/17/2004 03:14 PM Please respond to MQSeries List We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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: monitor MQ z/OS with MO71 ?
bfz, We have been accessesing OS/390 via MO71 without any problems. When you were adding a location make sure you check both Client and MVS ? Regards, Ruzi --- Benjamin F. Zhou [EMAIL PROTECTED] wrote: Hi Arlen, thanks for the response. I set the MCA user field on mainframe to the id I used to access the qmgr. but it doesn't work. Is there anything else I need to set? I remember the command server is always started upon qmgr startup. So that isn't an issue. thanks, bfz Williams, Arlen To: [EMAIL PROTECTED] arlen.williams@ cc: EDS.COM Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List [EMAIL PROTECTED] en.AC.AT 02/17/2004 03:14 PM Please respond to MQSeries List We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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: monitor MQ z/OS with MO71 ?
Did you check the MVS selection so the correct command queue name will be used? Does the reply queue and monitor queue exist? Does the svrconn channel come up on the mainframe? What is the error you are getting? -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 3:05 PM To: [EMAIL PROTECTED] Subject: Re: monitor MQ z/OS with MO71 ? Hi Arlen, thanks for the response. I set the MCA user field on mainframe to the id I used to access the qmgr. but it doesn't work. Is there anything else I need to set? I remember the command server is always started upon qmgr startup. So that isn't an issue. thanks, bfz Williams, Arlen To: [EMAIL PROTECTED] arlen.williams@ cc: EDS.COM Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List [EMAIL PROTECTED] en.AC.AT 02/17/2004 03:14 PM Please respond to MQSeries List We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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: monitor MQ z/OS with MO71 ?
Ben, MO71, will tell you the reason code. If it's 2035, then perhaps RACF is the issue you cannot connect. Benjamin F. ZhouTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: USA.COM Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 02/17/2004 04:05 PM Please respond to MQSeries List Hi Arlen, thanks for the response. I set the MCA user field on mainframe to the id I used to access the qmgr. but it doesn't work. Is there anything else I need to set? I remember the command server is always started upon qmgr startup. So that isn't an issue. thanks, bfz Williams, Arlen To: [EMAIL PROTECTED] arlen.williams@ cc: EDS.COM Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List [EMAIL PROTECTED] en.AC.AT 02/17/2004 03:14 PM Please respond to MQSeries List We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Pick a port, any port.
Considering this goes against the second post to this thread, bu to tell you the truth after some years of doing this I have yet to run into a problem 1414 - 1419 - Dev/Test 1420 - 1424 - SIT 1425 - 1429 - UAT / QA 1430 - PROD Of course you have to do the Netstat crud and whatnot. It also isn't written in GOLD nut it's a guideline I use. bobbee From: TC [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Pick a port, any port. Date: Fri, 13 Feb 2004 06:35:32 -0800 FYIHere is a link for info on computer communication standard for port numbers. http://www.iana.org/assignments/port-numbers Awerbuch, David [EMAIL PROTECTED] wrote: Peter, This can vary from system to system, but here are a few clues ... First of all, we should only use ports above 1024. Then, as Tim told you, you can look at the official list of reserved port, and know which ones are reserved for your particular system. You can also issue 'netstat -a | grep LISTEN'. This will display all the ports that have active listeners. These certainly are not available for you to use. For safety, if I am not using 1414, I start my listeners on port 14140 and above; these tend to be safe numbers on most systems I have worked on. Regards, Dave Awerbuch -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 5:14 PM To: [EMAIL PROTECTED] Subject: Pick a port, any port. If one does not want to use 1414, how do you know what port is safe to use? Do you just pick some number up in the thousands and hope nothing conflicts in the future? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified *** Credit Lyonnais This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais 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 - Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online _ Get a FREE online computer virus scan from McAfee when you click here. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
WBI MQGET Node
Has anyone rebuilt the MQGET Plugin from 2.1 for 5.0 and want to share it. I hate to do the work twice. bobbee 917-453-6790 _ Watch high-quality video with fast playback at MSN Video. Free! http://click.atdmt.com/AVE/go/onm00200365ave/direct/01/ 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
AW: Re: Performance observations and questions
Pavel, thanks for responding and for your 2c ;), the hint with better not to check the size of the trans queue was a good one, especially the alternative to use the events which I had never used before - time to learn someting new ;). Enrico -Ursprüngliche Nachricht- Von: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. Februar 2004 01:54 An: [EMAIL PROTECTED] Betreff: Re: Performance observations and questions Enrico, Make sure your application does not check the size of the transmission queue each time before putting the message; otherwise, it may affect the performance, especially if you are interested in highest possible one. An alternative approach (I am not aware of *the* right one) would be to enable relevant events (see QDPHIEV, QDEPHHI queue attributes and QM's PERFMEV) and wait for them in a separate thread.. then stop the publisher. You can use QDPHLOEV to resume publishing in the same manner. Just my 2c Pavel Gurney, Matthew [EMAIL PROTECTED]To: [EMAIL PROTECTED] SFB.COM cc: Sent by: MQSeriesSubject: Re: Performance observations and questions List [EMAIL PROTECTED] n.AC.AT 02/16/2004 08:51 AM Please respond to MQSeries List Enrico, IBM provides performance information and tuning recommendations in the support pacs, this information is not in the manuals. I would recommend you review: http://www-306.ibm.com/software/integration/support/supportpacs/product.html MP6J MP78 In regard to your performance test, I think the reduction in performance when maximum queue depth was increased was due to you exceeding the QBufferSize for your queues. By default Q's have 64k of memory assigned to them. If the total size of all messages upon the queue exceeds 64k then the extra messages (or perhaps entire q, not sure) are written to disk. Obviously once the disk gets involved your performance reduces dramatically. You can adjust the QBufferSize in your qm.ini up to 1MB (you need to delete and recreate the q after making the qm.ini change). Matt. -Original Message- From: Fichtner Enrico [mailto:[EMAIL PROTECTED] Sent: 16 February 2004 10:06 To: [EMAIL PROTECTED] Subject: Performance observations and questions For a upcoming project we needed some figures on MQSeries throughput to base a design decision on. Throughput is very crucial in this project. On the last weekend I've conducted some tests in this regard. Some of the results I would like to discuss here. Facts: - the tests where conducted on two Intel machines running W2K with MQSeries 5.2, however, the project target platform will be SPARC/Solaris9 - the machines used in this test are a PIV 2.8GH and a 2xPIII 450MH, both 512MB, one has ultra fast SCSI HD's and one has a pretty fast IDE-RAID5 (4x160G) - both machines where connected via 100MB LAN through a switch, which had only the two machines connected to it - message size was 200 byte, I used a string made of repeated numbers of 0 through 9 - queues where not persistent - DOS based test applications are written in C++, using IBM's C++ interface rather than straight C-API - the 'putting' application runs in a loop, checking the depth of the transmission queue (avoiding overflow), if the depth is below a certain level it puts the message into the remote queue, every n successful puts the time is measured (through windows high frequency counter, very high precision) and the average messages per seconds is put on the screen - the 'getting' application runs in a endless loop, with a blocking 'get' on the (receiving) local queue, the same average measuring is implemented as in the 'putting' app Results: - the best throughput was 3200msgs/sec measured with one putting application and one getting application at a maximum queue depth of 5000 on both sides (remote and transmission queue), CPU's on both sides where far below 100% - overall throughput went down when several 'putting' applications where putting to the same queue (of course, taking the sum of all screen outputs) Questions: - what actually limits the throughput? the number of msgs/sec times the size in this case results in the best case to 625kB/sec which is far beyond the practical throughput of the mentioned LAN - is it a correct observation that synchronizing several applications putting into the same queue causes considerably overhead? if so, can this be assumed the same way under SPARC/Solaris9 ? - when the max queue depth is set to a high number (e.g. 50),
AW: Re: Performance observations and questions
Pavel, I have googled the web for a hint on how to use the events in a C++ app - but couldn't find any. The path is clear so far, use *something* in a separate thread that has thread-synchro with the thread that does the actual put, when the event occurs simply let the putting thread run idle (or whatsoever) until the opposite event rises. However, the *something* is the portion that is not clear, is it a API call that blocks until the event occurs - or is it a C++ object (wrapped API) that I have to use? Any hint on this would be extremely helpful. Thanks, Enrico -Ursprüngliche Nachricht- Von: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. Februar 2004 01:54 An: [EMAIL PROTECTED] Betreff: Re: Performance observations and questions Enrico, Make sure your application does not check the size of the transmission queue each time before putting the message; otherwise, it may affect the performance, especially if you are interested in highest possible one. An alternative approach (I am not aware of *the* right one) would be to enable relevant events (see QDPHIEV, QDEPHHI queue attributes and QM's PERFMEV) and wait for them in a separate thread.. then stop the publisher. You can use QDPHLOEV to resume publishing in the same manner. Just my 2c Pavel Gurney, Matthew [EMAIL PROTECTED]To: [EMAIL PROTECTED] SFB.COM cc: Sent by: MQSeriesSubject: Re: Performance observations and questions List [EMAIL PROTECTED] n.AC.AT 02/16/2004 08:51 AM Please respond to MQSeries List Enrico, IBM provides performance information and tuning recommendations in the support pacs, this information is not in the manuals. I would recommend you review: http://www-306.ibm.com/software/integration/support/supportpacs/product.html MP6J MP78 In regard to your performance test, I think the reduction in performance when maximum queue depth was increased was due to you exceeding the QBufferSize for your queues. By default Q's have 64k of memory assigned to them. If the total size of all messages upon the queue exceeds 64k then the extra messages (or perhaps entire q, not sure) are written to disk. Obviously once the disk gets involved your performance reduces dramatically. You can adjust the QBufferSize in your qm.ini up to 1MB (you need to delete and recreate the q after making the qm.ini change). Matt. -Original Message- From: Fichtner Enrico [mailto:[EMAIL PROTECTED] Sent: 16 February 2004 10:06 To: [EMAIL PROTECTED] Subject: Performance observations and questions For a upcoming project we needed some figures on MQSeries throughput to base a design decision on. Throughput is very crucial in this project. On the last weekend I've conducted some tests in this regard. Some of the results I would like to discuss here. Facts: - the tests where conducted on two Intel machines running W2K with MQSeries 5.2, however, the project target platform will be SPARC/Solaris9 - the machines used in this test are a PIV 2.8GH and a 2xPIII 450MH, both 512MB, one has ultra fast SCSI HD's and one has a pretty fast IDE-RAID5 (4x160G) - both machines where connected via 100MB LAN through a switch, which had only the two machines connected to it - message size was 200 byte, I used a string made of repeated numbers of 0 through 9 - queues where not persistent - DOS based test applications are written in C++, using IBM's C++ interface rather than straight C-API - the 'putting' application runs in a loop, checking the depth of the transmission queue (avoiding overflow), if the depth is below a certain level it puts the message into the remote queue, every n successful puts the time is measured (through windows high frequency counter, very high precision) and the average messages per seconds is put on the screen - the 'getting' application runs in a endless loop, with a blocking 'get' on the (receiving) local queue, the same average measuring is implemented as in the 'putting' app Results: - the best throughput was 3200msgs/sec measured with one putting application and one getting application at a maximum queue depth of 5000 on both sides (remote and transmission queue), CPU's on both sides where far below 100% - overall throughput went down when several 'putting' applications where putting to the same queue (of course, taking the sum of all screen outputs) Questions: - what actually limits the throughput? the number of msgs/sec times the size in this case results in the best case to 625kB/sec which is far beyond the
