Donna Russo/csc/NSPRINGS is out of the office.
I will be out of the office starting 10/28/2003 and will not return until 11/02/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
[no subject]
Whether distribution lists are supported by the partner queue manager. YES Distribution lists are supported by the partner queue manager. NO Distribution lists are not supported by the partner queue manager. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Pak, Francis [IT] Sent: 28 October 2003 11:11 PM To: [EMAIL PROTECTED] Subject: Anybody know what distl(no) means in mqseries v5.1. ? 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQExplorer Security Exit
How can you use this in the UNIX environment? More specifically, AIX. Is there a link for the source code? -Warren At 09:52 AM 10/28/2003, you wrote: You can use it on Unix. -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 12:50 PM To: [EMAIL PROTECTED] Subject: Re: MQExplorer Security Exit Peter, It is quite good. Any chance of getting this exit for UNIX environment ?? Regards Sony. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 17:34 To: [EMAIL PROTECTED] Subject: MQExplorer Security Exit Has anyone implemented this Security exit from Neil Kolban in production? I have been fiddling with it in my LAB environment and it seems to work well. http://www.kolban.com/mq/Security/security.htm I was considering putting it on all my SYSTEM.ADMIN.SVRCONN channels, and tagging the channels with "mqm" on the MCAUSER. Since only trusted people would have the partner exit on their side, and only trusted people would know the ID / Password combos to get thru the Exit, and access to the servers is restricted, I would think this would secure MQExplorer functions while at the same time not requiring me to keep a current list of valid IDs in the mqm group on every server. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Conflicting port usage on Tandem
Title: RE: Re: Conflicting port usage on Tandem MinIdleMCATCPResponders Specifies the minimum number of TCP/IP responder MCAs to maintain in an idle state. The default value is 0. From the System Administration Manual http://www-3.ibm.com/software/integration/mqfamily/library/manual01/amqpag00/amqpag0017.htm -Original Message- From: MQSeries List [SMTP:[EMAIL PROTECTED] On Behalf Of Thomas, Don Sent: Tuesday, October 28, 2003 3:19 PM To: [EMAIL PROTECTED] Subject: Re: Conflicting port usage on Tandem Does anyone know what the following QMINI stanza is for? MinIdleMCATCPResponders Does this value relate to the listeners? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 28, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Re: Conflicting port usage on Tandem I am working on the assumption that this Netweave application is a TCP client based on what was said in the response you had from Netweave, and will comment on that basis. As a client, the application should just be calling socket() followed by connect(). The TCP stack should then assign an ephemeral port for the conversation (see below). The port usage for TCP/IP is mapped into three ranges: 1) Well known ports (0 to 1023) 2) Registered ports (1024 to 49151) 3) Dynamic or Private ports (49152 to 65535). Ephemeral ports should be assigned in this range. If this correctly describes the situation, then I'm amazed that the TCP stack on Tandem uses such low numbers as 1414 for ephemeral ports. Is there some configuration for the TCP stack on Tandem to control what ports are used for ephemeral ports? If OTOH this is a TCP server, then all bets are off, as it should in its own configuration specify the port number it uses for the bind() call. Dave 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
setmqaut and MQExplorer
If a user signed on as "abc123" used MQExplorer to connect to QM1, could I use setmqaut to allow user "abc123" to only display MQ objects in the MQExplorer, that is they couldn't alter / delete / add new objects. Meanwhile other users in the mqm group would continue to have full authority. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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: Conflicting port usage on Tandem
Does anyone know what the following QMINI stanza is for? MinIdleMCATCPResponders Does this value relate to the listeners? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Re: Conflicting port usage on Tandem I am working on the assumption that this Netweave application is a TCP client based on what was said in the response you had from Netweave, and will comment on that basis. As a client, the application should just be calling socket() followed by connect(). The TCP stack should then assign an ephemeral port for the conversation (see below). The port usage for TCP/IP is mapped into three ranges: 1) Well known ports (0 to 1023) 2) Registered ports (1024 to 49151) 3) Dynamic or Private ports (49152 to 65535). Ephemeral ports should be assigned in this range. If this correctly describes the situation, then I'm amazed that the TCP stack on Tandem uses such low numbers as 1414 for ephemeral ports. Is there some configuration for the TCP stack on Tandem to control what ports are used for ephemeral ports? If OTOH this is a TCP server, then all bets are off, as it should in its own configuration specify the port number it uses for the bind() call. Dave 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
[no subject]
Anybody know what distl(no) means in mqseries v5.1. ? 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: Time Problem??
Hi Michael, All MQ Queue managers run internally using GMT (or UTC or whatever it is called at the moment). This means that MQ doesn't even have to be aware of summer time changes. The translation to local time is performed in the application which displays the MQMD. Look at the system clock of the client computer. It may not be set correctly. Regards, Neil Casey. "Fleck, Michael" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] R.DE>cc: Sent by: MQSeriesSubject: Time Problem?? List <[EMAIL PROTECTED] n.AC.AT> 29/10/2003 00:38 Please respond to MQSeries List Hi list members, we are running MQ V5.3 CSD04 on Windows 2000. Last weekend in Germany the time changed from summer to winter time (-1 hour). The Windows 2000 server got the new time automatically. Everything seems to be fine. If I look at the server, it shows the right time. If I look at a queue using MQ Explorer, the messages show the right time. But when we look at the queues from a client on another computer the same messages show a time - 1 hour. This happens only at the Windows 2000 server. We also have a queue manager on OS/390. The time there has also changed last weekend, but there is no "time problem". Any ideas? Am I missing any parameter? The Windows server people told me, that Windows always uses the system time. Best regards, Michael Fleck Landschaftsverband Rheinland InfoKom Datenbanken, Ressourcen, OS/390 Tel: 0221/809/2826 email: [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: Conflicting port usage on Tandem
Dave, Judging by the response from Netweave support I don't think that they are specifying a port. It seems that the TCP service is just randomly assigning them when a connection request is received. I'm still puzzled as to why the runmqlsr program is ending in the first place. I've just looked out on the IBM site though and sure enough, there is a new CSD02 for Compaq NSK and there are is a mention of the listener failing, so it looks like I'm going to have to take that route. Thanks for your time, I appreciate it. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 12:02 PM To: [EMAIL PROTECTED] Subject: Re: Conflicting port usage on Tandem Hmmm... Is it just possible that Netweave does socket() bind() /* Specifying port 1414 */ connect() This is not very common behaviour for a client application though and if it does this, then I'd expect that it would have its own configuration to override the sender port number (or numbers). Having said that MQ can do this by using either the MQTCPSDRPORT environment variable or (in 5.3) LOCLADDR in define channel that allow you to specify port ranges for the MQ channel sender port so that MQ can get through firewalls that are tightly screwed down. Dave 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: QMGR - PERMDYN/TEMPDYN
Be careful when you do remote administration. if your transmission queue to the queuemanager you are administering is defpsist(yes), the command message will be persistent, and so will the reply. if you use tempdyn queues your repies will end in the dead letter queue because you can not out persistent messages to a tempdyn queue. but thats the only reason that i came across that prevented me not to use a tempdyn command reply model. regards, stefan Rick Tsujimoto wrote: Not sure why IBM continues to use Permdyn in SYSTEM.COMMAND.REPLY.MODEL, but setting it to Tempdyn has been IBM's answer for eliminating the growth of temp dynamic queues generated by TSO sessions. "Herd, Stewart" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] S-INC.COM> cc: Sent by: Subject: QMGR - PERMDYN/TEMPDYN MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/28/2003 11:20 AM Please respond to MQSeries List Appreciate any comments and suggestions; We have QMGR's that are starting to accumulate a lot of dynamic queues that are not being deleted. I think that these are primarily from the Candle Command Center and SYSVIEW usage. I think this is being caused by the fact that the Dynamic Queue Type in SYSTEM.COMMAND.REPLY.MODEL is a P for Permanent Dynamic rather than a T for Temporary Dynamic. I would change this, but the thing that bothers me is that in the definitions that come with MQ, in member 'ACSNS.MQ.SCSQPROC(CSQ4INSG), the DEFTYPE for SYSTEM.COMMAND.REPLY.MODEL is PERMDYN and not TEMPDYN. This has been this way from the beginning in the QMGRs but these permanent dynamic queues are lost every time the QMGRs are bounced. Since the QMGRs are not bouncing on certain LPARs so these queues are accumulating. I wonder why MQ is distributed with DEFTYPE(PERMDYN) for SYSTEM.COMMAND.REPLY.MODEL? Thanks Stewart 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: MQExplorer Security Exit
brainfart on the MCAUSER part, I forgot that the security exit overides any value in there. My plan is to tag the MCAUSER with "nobody". Now, only people with the partner exit on their MQExplorer will be able to connect to exit on the SYSTEM.ADMIN.SVRCONN, where they will be prompted for an ID/Password. This ID will need to be in the mqm group, as well as the Security exit's ID/Password file. Any problems with this? -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 12:34 PM To: [EMAIL PROTECTED] Subject: MQExplorer Security Exit Has anyone implemented this Security exit from Neil Kolban in production? I have been fiddling with it in my LAB environment and it seems to work well. http://www.kolban.com/mq/Security/security.htm I was considering putting it on all my SYSTEM.ADMIN.SVRCONN channels, and tagging the channels with "mqm" on the MCAUSER. Since only trusted people would have the partner exit on their side, and only trusted people would know the ID / Password combos to get thru the Exit, and access to the servers is restricted, I would think this would secure MQExplorer functions while at the same time not requiring me to keep a current list of valid IDs in the mqm group on every server. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQExplorer Security Exit
You can use it on Unix. -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 12:50 PM To: [EMAIL PROTECTED] Subject: Re: MQExplorer Security Exit Peter, It is quite good. Any chance of getting this exit for UNIX environment ?? Regards Sony. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 17:34 To: [EMAIL PROTECTED] Subject: MQExplorer Security Exit Has anyone implemented this Security exit from Neil Kolban in production? I have been fiddling with it in my LAB environment and it seems to work well. http://www.kolban.com/mq/Security/security.htm I was considering putting it on all my SYSTEM.ADMIN.SVRCONN channels, and tagging the channels with "mqm" on the MCAUSER. Since only trusted people would have the partner exit on their side, and only trusted people would know the ID / Password combos to get thru the Exit, and access to the servers is restricted, I would think this would secure MQExplorer functions while at the same time not requiring me to keep a current list of valid IDs in the mqm group on every server. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: MQExplorer Security Exit
Peter, It is quite good. Any chance of getting this exit for UNIX environment ?? Regards Sony. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 17:34 To: [EMAIL PROTECTED] Subject: MQExplorer Security Exit Has anyone implemented this Security exit from Neil Kolban in production? I have been fiddling with it in my LAB environment and it seems to work well. http://www.kolban.com/mq/Security/security.htm I was considering putting it on all my SYSTEM.ADMIN.SVRCONN channels, and tagging the channels with "mqm" on the MCAUSER. Since only trusted people would have the partner exit on their side, and only trusted people would know the ID / Password combos to get thru the Exit, and access to the servers is restricted, I would think this would secure MQExplorer functions while at the same time not requiring me to keep a current list of valid IDs in the mqm group on every server. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
MQExplorer Security Exit
Has anyone implemented this Security exit from Neil Kolban in production? I have been fiddling with it in my LAB environment and it seems to work well. http://www.kolban.com/mq/Security/security.htm I was considering putting it on all my SYSTEM.ADMIN.SVRCONN channels, and tagging the channels with "mqm" on the MCAUSER. Since only trusted people would have the partner exit on their side, and only trusted people would know the ID / Password combos to get thru the Exit, and access to the servers is restricted, I would think this would secure MQExplorer functions while at the same time not requiring me to keep a current list of valid IDs in the mqm group on every server. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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: Conflicting port usage on Tandem
Hmmm... Is it just possible that Netweave does socket() bind() /* Specifying port 1414 */ connect() This is not very common behaviour for a client application though and if it does this, then I'd expect that it would have its own configuration to override the sender port number (or numbers). Having said that MQ can do this by using either the MQTCPSDRPORT environment variable or (in 5.3) LOCLADDR in define channel that allow you to specify port ranges for the MQ channel sender port so that MQ can get through firewalls that are tightly screwed down. Dave 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: Slow MQOPENs
No, there's no correlation. "Joe H. Smith" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTWEAR.COM> cc: Sent by: MQSeriesSubject: Re: Slow MQOPENs List <[EMAIL PROTECTED] N.AC.AT> 10/28/2003 10:20 AM Please respond to MQSeries List Any chance a check point or journal change happens at the same time? Joan Hughes (Embedded image moved to file: pic18467.gif) Jim Ford <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: Slow MQOPENs List <[EMAIL PROTECTED] n.AC.AT> 10/28/2003 09:55 AM Please respond to MQSeries List Actually CPU usage is way down at the time we have a slowdown. It's a 16-way Solaris machine, and the biggest users of processing power are MQ-enabled apps. So when those apps pause, the CPU utilization goes down to nearly nothing. I don't know what the apps are waiting for, but it shouldn't be the CPU. Rick Tsujimoto <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COM>cc: Sent by: MQSeries List Subject: Re: Slow MQOPENs <[EMAIL PROTECTED]> 10/28/2003 09:21 AM Please respond to MQSeries List Are they any other non-MQ apps/processes running during the slowdowns? Any candidates that might hog the cpu? Jim Ford <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OM> cc: Sent by: Subject: Slow MQOPENs MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/28/2003 09:54 AM Please respond to MQSeries List I posted a week or so ago about slow performance on MQPUTs, which I was convinced was caused by replication tasks on our EMC SAN. It was sporadic, and unpredictible, but when slowdowns occured they did correlate with some SAN work. When I reviewed the code, though, I found that they were actually doing a MQPUT1 (it's a reply queue), not an MQPUT. We do tons of these in a day, and it almost always is fast, by the way. So I wrote a little Perl script that does an MQOPEN, an MQPUT and an MQGET. It then waits 5 seconds, and repeats infinitely. Each iteration almost always completes in less than one second. But I occasionally see fluctuations in the MQOPENs. Last night we had a couple that took 30 seconds, and a few that took 10 seconds or so. But the overwhelming number took less than 1, as I said. So what could cause an MQOPEN to take 30 seconds? There isn't much disk access involved except for opening the queue file. The rest of it seems to be shared memory work and OAM work. I assume that no disk access is involved in the OAM. And maybe it means that the SAN work isn't interfering after all. I'm stumped. By the way, I wrote another program that repeatedly opens a file in /var/mqm, writes 4k to it, closes it and deletes it. This ALWAYS completes in under a second, so I'm starting to doubt my original hypothesis. But what causes MQOPEN to fluctuate? Any ideas? 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 message and its contents have been scanned for viruses] * (See attached file: pic18467.gif) <>
Re: QMGR - PERMDYN/TEMPDYN
Not sure why IBM continues to use Permdyn in SYSTEM.COMMAND.REPLY.MODEL, but setting it to Tempdyn has been IBM's answer for eliminating the growth of temp dynamic queues generated by TSO sessions. "Herd, Stewart" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] S-INC.COM> cc: Sent by: Subject: QMGR - PERMDYN/TEMPDYN MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/28/2003 11:20 AM Please respond to MQSeries List Appreciate any comments and suggestions; We have QMGR's that are starting to accumulate a lot of dynamic queues that are not being deleted. I think that these are primarily from the Candle Command Center and SYSVIEW usage. I think this is being caused by the fact that the Dynamic Queue Type in SYSTEM.COMMAND.REPLY.MODEL is a P for Permanent Dynamic rather than a T for Temporary Dynamic. I would change this, but the thing that bothers me is that in the definitions that come with MQ, in member 'ACSNS.MQ.SCSQPROC(CSQ4INSG), the DEFTYPE for SYSTEM.COMMAND.REPLY.MODEL is PERMDYN and not TEMPDYN. This has been this way from the beginning in the QMGRs but these permanent dynamic queues are lost every time the QMGRs are bounced. Since the QMGRs are not bouncing on certain LPARs so these queues are accumulating. I wonder why MQ is distributed with DEFTYPE(PERMDYN) for SYSTEM.COMMAND.REPLY.MODEL? Thanks Stewart 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
QMGR - PERMDYN/TEMPDYN
Appreciate any comments and suggestions; We have QMGR's that are starting to accumulate a lot of dynamic queues that are not being deleted. I think that these are primarily from the Candle Command Center and SYSVIEW usage. I think this is being caused by the fact that the Dynamic Queue Type in SYSTEM.COMMAND.REPLY.MODEL is a P for Permanent Dynamic rather than a T for Temporary Dynamic. I would change this, but the thing that bothers me is that in the definitions that come with MQ, in member 'ACSNS.MQ.SCSQPROC(CSQ4INSG), the DEFTYPE for SYSTEM.COMMAND.REPLY.MODEL is PERMDYN and not TEMPDYN. This has been this way from the beginning in the QMGRs but these permanent dynamic queues are lost every time the QMGRs are bounced. Since the QMGRs are not bouncing on certain LPARs so these queues are accumulating. I wonder why MQ is distributed with DEFTYPE(PERMDYN) for SYSTEM.COMMAND.REPLY.MODEL? Thanks Stewart
Re: Slow MQOPENs
Any chance a check point or journal change happens at the same time? Joan Hughes (Embedded image moved to file: pic18467.gif) Jim Ford <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: Slow MQOPENs List <[EMAIL PROTECTED] n.AC.AT> 10/28/2003 09:55 AM Please respond to MQSeries List Actually CPU usage is way down at the time we have a slowdown. It's a 16-way Solaris machine, and the biggest users of processing power are MQ-enabled apps. So when those apps pause, the CPU utilization goes down to nearly nothing. I don't know what the apps are waiting for, but it shouldn't be the CPU. Rick Tsujimoto <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COM>cc: Sent by: MQSeries List Subject: Re: Slow MQOPENs <[EMAIL PROTECTED]> 10/28/2003 09:21 AM Please respond to MQSeries List Are they any other non-MQ apps/processes running during the slowdowns? Any candidates that might hog the cpu? Jim Ford <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OM> cc: Sent by: Subject: Slow MQOPENs MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/28/2003 09:54 AM Please respond to MQSeries List I posted a week or so ago about slow performance on MQPUTs, which I was convinced was caused by replication tasks on our EMC SAN. It was sporadic, and unpredictible, but when slowdowns occured they did correlate with some SAN work. When I reviewed the code, though, I found that they were actually doing a MQPUT1 (it's a reply queue), not an MQPUT. We do tons of these in a day, and it almost always is fast, by the way. So I wrote a little Perl script that does an MQOPEN, an MQPUT and an MQGET. It then waits 5 seconds, and repeats infinitely. Each iteration almost always completes in less than one second. But I occasionally see fluctuations in the MQOPENs. Last night we had a couple that took 30 seconds, and a few that took 10 seconds or so. But the overwhelming number took less than 1, as I said. So what could cause an MQOPEN to take 30 seconds? There isn't much disk access involved except for opening the queue file. The rest of it seems to be shared memory work and OAM work. I assume that no disk access is involved in the OAM. And maybe it means that the SAN work isn't interfering after all. I'm stumped. By the way, I wrote another program that repeatedly opens a file in /var/mqm, writes 4k to it, closes it and deletes it. This ALWAYS completes in under a second, so I'm starting to doubt my original hypothesis. But what causes MQOPEN to fluctuate? Any ideas? 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 message and its contents have been scanned for viruses] * <>
Re: Slow MQOPENs
Actually CPU usage is way down at the time we have a slowdown. It's a 16-way Solaris machine, and the biggest users of processing power are MQ-enabled apps. So when those apps pause, the CPU utilization goes down to nearly nothing. I don't know what the apps are waiting for, but it shouldn't be the CPU. Rick Tsujimoto <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COM>cc: Sent by: MQSeries List Subject: Re: Slow MQOPENs <[EMAIL PROTECTED]> 10/28/2003 09:21 AM Please respond to MQSeries List Are they any other non-MQ apps/processes running during the slowdowns? Any candidates that might hog the cpu? Jim Ford <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OM> cc: Sent by: Subject: Slow MQOPENs MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/28/2003 09:54 AM Please respond to MQSeries List I posted a week or so ago about slow performance on MQPUTs, which I was convinced was caused by replication tasks on our EMC SAN. It was sporadic, and unpredictible, but when slowdowns occured they did correlate with some SAN work. When I reviewed the code, though, I found that they were actually doing a MQPUT1 (it's a reply queue), not an MQPUT. We do tons of these in a day, and it almost always is fast, by the way. So I wrote a little Perl script that does an MQOPEN, an MQPUT and an MQGET. It then waits 5 seconds, and repeats infinitely. Each iteration almost always completes in less than one second. But I occasionally see fluctuations in the MQOPENs. Last night we had a couple that took 30 seconds, and a few that took 10 seconds or so. But the overwhelming number took less than 1, as I said. So what could cause an MQOPEN to take 30 seconds? There isn't much disk access involved except for opening the queue file. The rest of it seems to be shared memory work and OAM work. I assume that no disk access is involved in the OAM. And maybe it means that the SAN work isn't interfering after all. I'm stumped. By the way, I wrote another program that repeatedly opens a file in /var/mqm, writes 4k to it, closes it and deletes it. This ALWAYS completes in under a second, so I'm starting to doubt my original hypothesis. But what causes MQOPEN to fluctuate? Any ideas? 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: Conflicting port usage on Tandem
Dave, The Netweave app is a client connection as you thought. Now I'm not a Tandem admin by any stretch, and like you I am trying to determine how/if the TCP service on a Tandem machine can be configured to allocate ports in a way so as to not disrupt other applications. (There are internationally recognized standards after all) But what I'm hearing is that Tandem doesn't allow for this. How can this be? Does anyone have and thoughts on this or developed a scheme to address this situation? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Re: Conflicting port usage on Tandem I am working on the assumption that this Netweave application is a TCP client based on what was said in the response you had from Netweave, and will comment on that basis. As a client, the application should just be calling socket() followed by connect(). The TCP stack should then assign an ephemeral port for the conversation (see below). The port usage for TCP/IP is mapped into three ranges: 1) Well known ports (0 to 1023) 2) Registered ports (1024 to 49151) 3) Dynamic or Private ports (49152 to 65535). Ephemeral ports should be assigned in this range. If this correctly describes the situation, then I'm amazed that the TCP stack on Tandem uses such low numbers as 1414 for ephemeral ports. Is there some configuration for the TCP stack on Tandem to control what ports are used for ephemeral ports? If OTOH this is a TCP server, then all bets are off, as it should in its own configuration specify the port number it uses for the bind() call. Dave 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: Slow MQOPENs
Are they any other non-MQ apps/processes running during the slowdowns? Any candidates that might hog the cpu? Jim Ford <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OM> cc: Sent by: Subject: Slow MQOPENs MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/28/2003 09:54 AM Please respond to MQSeries List I posted a week or so ago about slow performance on MQPUTs, which I was convinced was caused by replication tasks on our EMC SAN. It was sporadic, and unpredictible, but when slowdowns occured they did correlate with some SAN work. When I reviewed the code, though, I found that they were actually doing a MQPUT1 (it's a reply queue), not an MQPUT. We do tons of these in a day, and it almost always is fast, by the way. So I wrote a little Perl script that does an MQOPEN, an MQPUT and an MQGET. It then waits 5 seconds, and repeats infinitely. Each iteration almost always completes in less than one second. But I occasionally see fluctuations in the MQOPENs. Last night we had a couple that took 30 seconds, and a few that took 10 seconds or so. But the overwhelming number took less than 1, as I said. So what could cause an MQOPEN to take 30 seconds? There isn't much disk access involved except for opening the queue file. The rest of it seems to be shared memory work and OAM work. I assume that no disk access is involved in the OAM. And maybe it means that the SAN work isn't interfering after all. I'm stumped. By the way, I wrote another program that repeatedly opens a file in /var/mqm, writes 4k to it, closes it and deletes it. This ALWAYS completes in under a second, so I'm starting to doubt my original hypothesis. But what causes MQOPEN to fluctuate? Any ideas? 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: Conflicting port usage on Tandem
I am working on the assumption that this Netweave application is a TCP client based on what was said in the response you had from Netweave, and will comment on that basis. As a client, the application should just be calling socket() followed by connect(). The TCP stack should then assign an ephemeral port for the conversation (see below). The port usage for TCP/IP is mapped into three ranges: 1) Well known ports (0 to 1023) 2) Registered ports (1024 to 49151) 3) Dynamic or Private ports (49152 to 65535). Ephemeral ports should be assigned in this range. If this correctly describes the situation, then I'm amazed that the TCP stack on Tandem uses such low numbers as 1414 for ephemeral ports. Is there some configuration for the TCP stack on Tandem to control what ports are used for ephemeral ports? If OTOH this is a TCP server, then all bets are off, as it should in its own configuration specify the port number it uses for the bind() call. Dave 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: Conflicting port usage on Tandem
First of all, let me assure you that MQ on Tandem is one of the most critical systems used by almost all the major financial institutions. You are not the only one :). As for 1414 implementation, this is just the DEFAULT for MQ, NOT for Tandem. Mq on any platform assumes port 1414 as the default, if one is not explicitly specified. Now, as in your case, if you have other apps that may generate a conflict, then the best way at any time is to specify an EXPLICT port on your listener other than 1414. You could do this either in your pathway or you could specify this on the tacl prompt if you are starting it outside of pathway. There is NO way to reserve a port as such, but if you specify a port number in your listener, then MQ would try and bind to that port only. Once that port is bound, it of course cannot be allotted to any other app, if is requesting. Also, once the listener dies, O/s takes a little time to release the port. Hence your third party app should try and bind to a different port instead. Hope this helps. Cheers Kumar ---Original Message--- From: MQSeries List Date: Tuesday, October 28, 2003 09:33:45 AM To: [EMAIL PROTECTED] Subject: Conflicting port usage on Tandem I have run into a problem with running a listener on a Tandem machine in my MQ network. For several weeks now I've discovered that the listener had stopped running on this machine. I was able to restart it each time but was unable to identify what was causing it to abend. Until yesterday that is. While investigating this I was able to identify a Netweave application that was running using port 1414 and the listener was of course unable to bind to that port because of it. I had the system admin for this machine contact Netweave's tech support on this issue and below is their reply. Does anyone else run MQ on a Tandem machine? If so have you run into this? I'm thinking that there must be a way to reserve ports on a Tandem machine, not just for MQ but any TCP based service. Any direction that can be provided would be appreciated. Thanks. Don Thomas Netweave response: The answer to this is easy. The LADDR address is obtained automatically from the TCP/IP process (e.g., $ztc0) when any process (not just NetWeave) performs the connect socket call. There is no easy way to avoid this. MQ Series for Tandem made a terrible choice if 1414/1415 are hardcoded public ports. 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 . IncrediMail - Email has finally evolved - Click Here
Slow MQOPENs
I posted a week or so ago about slow performance on MQPUTs, which I was convinced was caused by replication tasks on our EMC SAN. It was sporadic, and unpredictible, but when slowdowns occured they did correlate with some SAN work. When I reviewed the code, though, I found that they were actually doing a MQPUT1 (it's a reply queue), not an MQPUT. We do tons of these in a day, and it almost always is fast, by the way. So I wrote a little Perl script that does an MQOPEN, an MQPUT and an MQGET. It then waits 5 seconds, and repeats infinitely. Each iteration almost always completes in less than one second. But I occasionally see fluctuations in the MQOPENs. Last night we had a couple that took 30 seconds, and a few that took 10 seconds or so. But the overwhelming number took less than 1, as I said. So what could cause an MQOPEN to take 30 seconds? There isn't much disk access involved except for opening the queue file. The rest of it seems to be shared memory work and OAM work. I assume that no disk access is involved in the OAM. And maybe it means that the SAN work isn't interfering after all. I'm stumped. By the way, I wrote another program that repeatedly opens a file in /var/mqm, writes 4k to it, closes it and deletes it. This ALWAYS completes in under a second, so I'm starting to doubt my original hypothesis. But what causes MQOPEN to fluctuate? Any ideas? 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
Conflicting port usage on Tandem
I have run into a problem with running a listener on a Tandem machine in my MQ network. For several weeks now I've discovered that the listener had stopped running on this machine. I was able to restart it each time but was unable to identify what was causing it to abend. Until yesterday that is. While investigating this I was able to identify a Netweave application that was running using port 1414 and the listener was of course unable to bind to that port because of it. I had the system admin for this machine contact Netweave's tech support on this issue and below is their reply. Does anyone else run MQ on a Tandem machine? If so have you run into this? I'm thinking that there must be a way to reserve ports on a Tandem machine, not just for MQ but any TCP based service. Any direction that can be provided would be appreciated. Thanks. Don Thomas Netweave response: The answer to this is easy. The LADDR address is obtained automatically from the TCP/IP process (e.g., $ztc0) when any process (not just NetWeave) performs the connect socket call. There is no easy way to avoid this. MQ Series for Tandem made a terrible choice if 1414/1415 are hardcoded public ports. 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
Time Problem??
Hi list members, we are running MQ V5.3 CSD04 on Windows 2000. Last weekend in Germany the time changed from summer to winter time (-1 hour). The Windows 2000 server got the new time automatically. Everything seems to be fine. If I look at the server, it shows the right time. If I look at a queue using MQ Explorer, the messages show the right time. But when we look at the queues from a client on another computer the same messages show a time - 1 hour. This happens only at the Windows 2000 server. We also have a queue manager on OS/390. The time there has also changed last weekend, but there is no "time problem". Any ideas? Am I missing any parameter? The Windows server people told me, that Windows always uses the system time. Best regards, Michael Fleck Landschaftsverband Rheinland InfoKom Datenbanken, Ressourcen, OS/390 Tel: 0221/809/2826 email: [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: CopyBook with Occurs Clause
Create default values for the other two elements that would have had '12XY'. The defualt values of the two elements must be an empty space. Copybook requires that all the fields contain values (this is subject to correction) in then, by doing the above, you will have 'AB '. Hope this helps
