AW: Design Review - custom trigger monitor vs triggered program
it will not work (see also dennis post). the design is definitly wrong. that should be strong enough to change it. regards stefan -Ursprungliche Nachricht- Von: Heggie, Peter [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 21:01 An: [EMAIL PROTECTED] Betreff: Re: Design Review - custom trigger monitor vs triggered program Sorry for blank reply. The rationale is that it was delivered by a consultant. And I need something strong and obvious to change it... Peter Heggie (315) 428 - 3193 -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 2:51 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Peter, what is your design rationale for having multiple initiation queues? Stefan >From: "Heggie, Peter" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Design Review - custom trigger monitor vs triggered >program >Date: Tue, 29 Jul 2003 13:01:11 -0400 > >Hi Phil.. I'm buried in ERP implementation. >Thanks for reply - Actually the program does close the application >queue after it gets a message, so it behaves nicely but does more opens >and closes. The actual usage is light, about 100 a day (initially). The >program is not multi-threaded, but the design was to call for more >trigger monitors (to monitor other initiation queues..). The >recommendation was to set the application queue triggering to EVERY, >but I think FIRST would be better. > >And Stefan, thank you also, I agree that triggering while already >triggered does not make sense, and somehow that must be a waste of >resources. In the past I have used the 'regular' triggering (ON FIRST). > >Peter Heggie >(315) 428 - 3193 > > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] >Sent: Tuesday, July 29, 2003 12:17 PM >To: [EMAIL PROTECTED] >Subject: Re: Design Review - custom trigger monitor vs triggered >program > > >Hi Pete ! Long time... > >After the program processes the Queue named in MQTMC2, does it close >the queue ? If not, then MQ will not issue a new trigger message. Is >the program multi-threaded? if not, then you're causing a bottle neck >for other trigger messages for other queues. > >It might be more efficient since MQ doesn't have to load a program to >process the queues, but depends upon how frequently it gets scheduled. >I assume it's TRIGGER FIRST. > > >Phil > > > > > "Heggie, Peter" > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > NGRID.COM> cc: > Sent by: MQSeriesSubject: Design Review - >custom trigger monitor vs triggered program > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 07/29/2003 11:16 > AM > Please respond to > MQSeries List > > > > > > >Hello all - would appreciate your responses on this one. > >We have someone who wants to use a custom trigger monitor to both read >the init queue message and process the application queue message. It >would be a long running process, on AIX, that waits forever (loops) on >the init queue. When a message arrives there (trigger message), it >extracts the queue name from the MQTMC2 and then opens the application >queue and processes the message. Then it goes back into the loop. > >Setup - A trigger monitor is started at MQ startup time, pointing to a >specific init queue. The first message coming into the application >queue triggers normally - MQ writes a trigger message to the init queue >and the native MQ trigger monitor starts program XYZ according to the >process definition. The program XYZ is also a trigger monitor, a custom >trigger monitor. > >Program XYZ has been passed the MQTMC2, so it reads it to get the >application queue name. It opens the application queue, reads and >processes the message and closes the application queue. It then goes >back into a loop where it reads the init queue. Because program XYZ has >the init queue open, MQ will not invoke another instance of program >XYZ. > >Every time another message arrives on the application queue, program >XYZ will get another trigger message. > > >This is not a classic trigger configuration, but are there problems >with it? The trigger monitor started at MQ startup time is a long >running process that basically feeds program XYZ trigger messages. >Program XYZ is also a long running process that monitors the init >queue. To shutdown the program, you have to treat it the same way as a >trigger monitor - disable the init queue for Get, but that's not a very >bad thing. > >I am used to the simplicity of a trigger monitor that starts an >application program, that reads application messages until >No-More-Messages, and gets triggered again when needed. That seems more
AW: Design Review - custom trigger monitor vs triggered program
Peter, after the trigger monitor has started xyz, xyz will also listen to the initq. so you have 2 programs listening to the initq, which one will get the next trigger message? (quote on) Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. (quote off) This is wrong in my opinion. an open application queue (open for input) will prevent mq to create another trigger message. but you wrote you close the application queue. so mq will create a trigger message if the trigger conditions are fullfilled. if the trigger monitor will get it, it will start another xyz program. if you trigger and stay alive, why do you trigger? 1. no triggering at all start xyz to listen on the application queue. if a message arrives, it will get processed. use fail if quiescing (and maybe get-disable) to end your application, or use a special kind of message content (a "stop message" that will make your program to end. 2. use triggering and end trigger monitor will start xyz, xyz will process all messages and wait a specific amount of time for more messages to arrive (get-wait). if nothing arrives, then xyz ends and will be triggered again if messages arrive on the queue. 3. use triggering and stay alive trigger monitor will start xyz, xyz will process all messages and wait infinite for mor messages to arrive. no need to read the initq if you have the application queue open for input (trigger first will not be fired because of this). check how frequent messages arrive in the queue and pick up the best and less-complex solution. seperate business and technics, application programs perform application work, trigger monitor does the technical stuff. I would not use the triggered application program to do the work of the trigger monitor. Regards, Stefan -Ursprungliche Nachricht- Von: Heggie, Peter [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 17:17 An: [EMAIL PROTECTED] Betreff: Design Review - custom trigger monitor vs triggered program Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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
AW: GET 3270 Bridge Reply
do you see the reply message arriving in the queue while your program ist still active and waiting? if so, then it is no commit problem. your request was processed, thats why there is an answer, and the request can only be processed if the message was committed (asuming you run with syncpoint on) are you sure that the reply msgid is equal to the request msgid? many applications return the requestors msgid in the correlid of the reply. check with ma10 / hex on if the msgid is really what you expected. (i dont know cics bridge details). regards stefan -Ursprungliche Nachricht- Von: Jeff Orris [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 24. Juli 2003 16:33 An: [EMAIL PROTECTED] Betreff: GET 3270 Bridge Reply I'm writing a COBOL z/OS batch program which puts a message to a CICS bridge queue and attempts to get the reply message from the reply queue. But the MQGET is failing with a reason code of MQRC_NO_MSG_AVAILABLE. I've made sure that MQGMO-WAITINTERVAL is long enough (6 ms). I also can browse the reply message in the queue with another utility (supportpac MA10) while the MQGET is waiting. My match options are set to match on MSGID only (and I don't change the id returned in MQMD-MSGID by the PUT to the bridge queue). I'm guessing that, since the batch job is considered one unit of work, the message is not available for GET until the batch job completes. I tried issuing an MQCMIT just before opening the reply queue, but the reply message is still unavailable. Any ideas or suggestions? Jeff Orris This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and any accompanying documentation after contacting the sender. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use 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 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: ascii binary get convert
Hi, if the msgid / correlid is unique then this may all work. Bt do you know it is unique? I know appications that set their msgid/correlid to specific values, so these fields can not be used to identify and get a specific message. i would do an open for browse + input, browse the queue and use "get_msg_under_cursor" if i decide to get the previous browsed message. maybe slower, but maybe safer. just my 2 cents. Regards, Stefan. -Ursprungliche Nachricht- Von: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 24. Juli 2003 15:19 An: [EMAIL PROTECTED] Betreff: All, Another idea: wouldn't it be possible to open the queue for the normal (destructive) MQGET and then get the message with truncated messages disabled and the data buffer length 0. It would return the truncation error and fill up the descriptor. Then, app would give the buffer of the appropriate length and appropriate conversion options, based on the descriptor contents (e.g. format field). This hack might possibly have some performance benefits in terms of the amount of transferred data, opened queue handles etc. Any drawbacks I did not notice? Just my 2c Pavel Stefan Sievert <[EMAIL PROTECTED]To: [EMAIL PROTECTED] TMAIL.COM> cc: Sent by: MQSeriesSubject: List <[EMAIL PROTECTED] n.AC.AT> 07/23/2003 07:32 PM Please respond to MQSeries List Rommel, open the queue with MQOO_BROWSE and issue an MQGET with MQGMO_BROWSE, the investigate the message descriptor or payload. Depending on the result, do a destructive MQGET with the msgId returned from the browse (and be prepared to handle the fact that the message might have been removed by another application while you were checking for binary/ascii). How would you test for binary/ASCII though? The better approach would be for the sending application to a) set MQFMT_NONE for binary messages and b) MQFMT_STRING for text messages and do the convert in any case (there will be no conversion for MQFMT_NONE, so you're safe). Or, since it looks like two completely different message formats to me, have them put to two different queues, if you can. HTH, Stefan >From: Rommel Uy <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Date: Wed, 23 Jul 2003 16:05:16 -0700 > >Hello all, > >Is there a way to determine if the message in a queue is ascii or binary >before you do an MQGET on it ? The reason is that if the message is ascii >then we would like to specify the MQGMO_CONVERT when we do the MQGET. > >Thanks >Rommel > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
AW: AW: 1 Queue Manager for both shared & private queues?
Lew, i am very interrested in the "why"... please keep us informed. Thanks, Stefan -Ursprüngliche Nachricht- Von: Lew Kaufman [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 18. Juli 2003 14:18 An: [EMAIL PROTECTED] Betreff: Re: AW: 1 Queue Manager for both shared & private queues? Stefan, Thanks for your response. This confirms my thoughts. My team has not spoken directly with IBM. We are dealing with second-hand information. We will keep researching. Thanks again, Lew In a message dated 7/18/2003 3:39:18 AM Eastern Standard Time, [EMAIL PROTECTED] writes: > > > Lew, > you can use shared and nonshared (local) queues in the same queuemanager. > > i do not know why ibm recommends not to do so. maybe you should ask them > for the reasons. > > there where some problems with mq 53 and shared queues in the past, so maybe > safety is a reason, in case of errors/problems with shared queues not to > affect applications that do not use shared queues, but a lot of bugs > are already fixed so i am not sure if this is still a reason to seperate. > > think of a cics that runs 2 applications, one > with "local" queues on qmgra, one with "shared" queues on qmgr. where > will you connect? where will your batch jobs connect (do you use the > default queuemanager) ? > > i would use a single qmgr unless there is more than an unfounded > recommendation. > > regards > > stefan > > > -Urspr|ngliche Nachricht- > Von: Lew Kaufman [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 17. Juli 2003 22:42 > An: [EMAIL PROTECTED] > Betreff: 1 Queue Manager for both shared & private queues? > > > Hello. I have a question for the list. Any advice would be greatly > appreciated. > > Can a single QManager be used to access both shared & private queues? > > Our "experts" claims that b IBM recommends NOT to use a single Queue > Manager to access both Shared and Private Queues.b > > I am questioning whether this is really true. > > Based on their claim, my project is planning to define 2 Queue Managers on a > single LPAR. One Queue Manager would support applications that use shared > queues, and the other would support applications that use private queues. > > Is this a good idea? > > Thanks in advance. > > Lew Kaufmann > SR Consulting > > 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
AW: 1 Queue Manager for both shared & private queues?
What are we talking about? a shared queue that resides in the coupling facility, or a "local" queue that is shared by applications? regards stefan -Ursprüngliche Nachricht- Von: Lew Kaufman [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Juli 2003 22:42 An: [EMAIL PROTECTED] Betreff: 1 Queue Manager for both shared & private queues? Hello. I have a question for the list. Any advice would be greatly appreciated. Can a single QManager be used to access both shared & private queues? Our "experts" claims that b IBM recommends NOT to use a single Queue Manager to access both Shared and Private Queues.b I am questioning whether this is really true. Based on their claim, my project is planning to define 2 Queue Managers on a single LPAR. One Queue Manager would support applications that use shared queues, and the other would support applications that use private queues. Is this a good idea? Thanks in advance. Lew Kaufmann SR Consulting 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
AW: 1 Queue Manager for both shared & private queues?
Lew, you can use shared and nonshared (local) queues in the same queuemanager. i do not know why ibm recommends not to do so. maybe you should ask them for the reasons. there where some problems with mq 53 and shared queues in the past, so maybe safety is a reason, in case of errors/problems with shared queues not to affect applications that do not use shared queues, but a lot of bugs are already fixed so i am not sure if this is still a reason to seperate. think of a cics that runs 2 applications, one with "local" queues on qmgra, one with "shared" queues on qmgr. where will you connect? where will your batch jobs connect (do you use the default queuemanager) ? i would use a single qmgr unless there is more than an unfounded recommendation. regards stefan -Ursprüngliche Nachricht- Von: Lew Kaufman [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Juli 2003 22:42 An: [EMAIL PROTECTED] Betreff: 1 Queue Manager for both shared & private queues? Hello. I have a question for the list. Any advice would be greatly appreciated. Can a single QManager be used to access both shared & private queues? Our "experts" claims that b IBM recommends NOT to use a single Queue Manager to access both Shared and Private Queues.b I am questioning whether this is really true. Based on their claim, my project is planning to define 2 Queue Managers on a single LPAR. One Queue Manager would support applications that use shared queues, and the other would support applications that use private queues. Is this a good idea? Thanks in advance. Lew Kaufmann SR Consulting 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
AW: Re : MQOPEN ended with reason code 2189, CLUSTERS
Looks like a configuration problem. I assume you missed the cluster name in one or more object definitions. please, can you show us these informaiton? on QM1 display qmgr all dis clusqmgr(*) all display channel (TO.QM1) all (the cluster receiver on QM1) display queue(test) all ip address/port of QM1 on QM2 display qmgr all display clusqmgr(*) all display channel(TO.QM1) all (the cluster sender display channel(TO.QM2) all (the cluster receiver) ip address/port of QM2 -Ursprüngliche Nachricht-Von: eai grp [mailto:[EMAIL PROTECTED]Gesendet: Mittwoch, 16. Juli 2003 23:47An: [EMAIL PROTECTED]Betreff: Re: Re : MQOPEN ended with reason code 2189, CLUSTERS no i dont c it on the other qmgr when i do a display qcluster.But u know the mq explorer , it shows the 'shared ' logo for that queue.I checked the log .. This is what my log says .. EXPLANATION:The queue manager has received information about a cluster for which norepositories are known.ACTION:Alter the REPOS or REPOSNL attribute of the queue manager, that is to have afull repository for the cluster, to specify the cluster name. BUT But when i display qmgr on the repos qmgr i still c that the repos property has the cluster name correctly defined , now what? Mqonnet <[EMAIL PROTECTED]> wrote: Ok. When you do a display qcluster(*) on both the qms do you see thisclustered queue on both qms???Does dis clusqmgr(*) show that both the qmgrs are in the cluster??? YouSHOULD NOT see any "...temp" in the dis clusqmgr(*). If you do, thenthere was something wrong somewhere. Check to see if all of your clussdrand clusrcvr channels are running properly and that their listeners too arerunning on the expected ports. Check the logs to see if there is somethingthat is evident.CheersKumar ---Original Message---From: MQSeries ListDate: Wednesday, July 16, 2003 11:02:11 AMTo: [EMAIL PROTECTED]Subject: Re: Re : MQOPEN ended with reason code 2189, CLUSTERSI tried after a while , I still ended up with the same error!Any otherproblem?Mqonnet <[EMAIL PROTECTED]>wrote: You usually get this because thenon-repository queue manager did not getthe clustered queue information publicized from the repository qm where theclustered queue is hosted. This is not a bug. Any clustered queue ispublicized only upon request. And since this was the first request, it mayor may not return a publication right away. Hence the best way to getaround this is to keep a wait after the first MQOPEN fails, for about 20 oddseconds and retry MQOPEN again. You are sure to succeed the next time.CheersKumar---Original Message---From: MQSeries ListDate: Tuesday, July 15, 2003 04:11:21 PMTo: [EMAIL PROTECTED]Subject: MQOPEN ended with reason code 2189, CLUSTERSHi I get a MQOPEN ended with reason code 2189 when i try to amqsput on a queue that isshared in a cluster.I have just two QMGRs QM1 and QM2 in the cluster and iam doing a amqsputtest QM2.QM2 does not have test and test is in QM1 and is shared. QM1 is the repos.Display clusqgr qmtype status, gives me the status as running ! what couldbe the problemDo you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveDo you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month! Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month!
AW: A double cluster to get 2 CLUSRCVR channels?
Peter, a message destigned for a "remote" cluster queue gets a target queue assinged and a cluster channel to use and is then put to the SYSTEM.CLUSTER.TRANSMIT.QUEUE. I assume, that every mca gets only the messages that are assigned to its channel. On os/390, the correlid field holds the channel name and the S.C.T.Q is indexed by correlid, it is most likely that the mca does a get by correlid to pick up the proper messages. You share the S.C.T.Q queue between the cluster channels, so you share the storage, but i do not think that the P and NP messages will be mixed over the channels because the target queue is not known in the other cluster. Regards Stefan -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 15. Juli 2003 14:29 An: [EMAIL PROTECTED] Betreff: Re: A double cluster to get 2 CLUSRCVR channels? I plan on separating the queues into the proper cluster. Queues that deal only with NP messages will be in CLUSTER1, and queues that deal with both P and NP messages will live in the other cluster. The goal being that WITHOUT replacing the standard cluster workload exit, NP messages destined for queues in CLUSTER1 will not be effected by channel problems in CLUSTER2. These channel "problems" could be large messages taking their time, or P messages holding up both P and NP messages while the P message waits to be logged on the receiving side. The only doubt I have is the fact that there is one common XMIT queue in this case (SYSTEM.CLUSTER.TRANSMIT.QUEUE) being serviced by 2 or more channels. ** I got to think that one message at the head of the SYSTEM.CLUSTER.TRANSMIT.QUEUE that is held up for whatever reason would not impeded others behind it destined for other channels to other QMs in the same cluster or other channels in other overlapping clusters. ** -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 12:30 AM To: [EMAIL PROTECTED] Subject: Re: A double cluster to get 2 CLUSRCVR channels? Hi Peter, you design pretty much pans out Ok. This is actually similar to the way we set up our clusters here. Our reasons for separating out the cluster channels are different (security rather than performance) but the result is the same. You might find that you need to use a cluster workload balancing exit to force the correct choice of cluster. If you are sending to a cluster queue (a request) and that queue is defined in only one of the clusters, then you will be fine. If you want to make the choice based not on the queue, but instead on the message size, then you will need to open your queues with bind(notfixed) and use the cluster workload exit to make the choice. If you are sending a response, based on the replyToQ and replyToQMgr fields, then either cluster is a valid choice, and the workload balancing algorithm gets to make the choice. The IBM default algorithm may not be able to make the choice that you want, in which case you will need to write or buy a workload balancing exit. This can also happen in an environment where the destination for a message is looked up in an external database (like LDAP) and the target queue manager and queue are both specified. Regards, Neil Casey. |-+--> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM>| | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 15/07/2003 13:09 | | | Please respond to | | | MQSeries List | | | | |-+--> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: A double cluster to get 2 CLUSRCVR channels? | >--- ---| 3 QueueManagers (QMs) on 3 servers, QM1, QM2 and QMGateway. QM1 has a CLUSRCVR called TO.QM1.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QM1.CLUSTER2 which is in CLUSTER2. QM1 is a full repository for a cluster name list called CLUSTER1andCLUSTER2. QM2 has a CLUSRCVR called TO.QM2.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QM2.CLUSTER2 which is in CLUSTER2. QM2 is a full repository for a cluster name list called CLUSTER1andCLUSTER2. QMGateway has a CLUSRCVR called TO.QMGateway.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QMGateway.CLUSTER2 which is in CLUSTER2. The point of all this
AW: Resume message receive
I do not think there is an add-on produkt for MQ to handle this. Either you need exits to perform this (i do not think this will work because you are still bound to the mca handshaking, syncpoint handling, comits, ) or you need to write your own sender and receiver mca to do the network transfer the way you want it to work. use small messages (if possible) and small batch sizes, so there is not many data to repeat in case there was a connection failure. regards stefan -Ursprungliche Nachricht- Von: Guy Shavitt [mailto:[EMAIL PROTECTED] Gesendet: Montag, 14. Juli 2003 14:16 An: [EMAIL PROTECTED] Betreff: Resume message receive Hello, We are sending large messages (more than 4MB each) over an Internet connection using MQSeries. The receiving end points are sometimes connected with a simple Dial-Up connection. Is someone familiar with a way in MQSeries to resume a "receive" for a message if the connection fails in the middle of the "receive" process and continue to load just the portion of the message that was not read yet? Today, we need to receive the whole message all over again. Is there a product that supports this feature in MQSeries? Did someone encounter this problem and found a solution for it? Thanks for your help Guy _ Protect your PC - get McAfee.com VirusScan Online 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 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: MsgExits on Clusters in CrossPlatform Environments
Brian,
i posted a chad some weeks ago. it was for testing purposes, i used
it to print out various fields in the data areas and i also used it
to wipe out the security exit name that came with the os/390
cluster channel definition. it did work, so you may use this and
check with your source.
regards
stefan
#include
#include
#include
#include
#include
#include
MQCHANNELAUTODEFEXIT MY_MQ_CHANNEL_AUTO_DEF_EXIT;
FILE *log;
char buf[100] = "";
char myexit[128] = "";
void MQStart() {;} /* dummy entry point - for consistency only */
void MQENTRY MY_MQ_CHANNEL_AUTO_DEF_EXIT ( PMQVOID pChannelExitParms,
PMQVOID pChannelDefinition)
{
PMQCXP pCEP = pChannelExitParms;
PMQCD pCD = pChannelDefinition;
time_t t1;
log=fopen("/var/mqm/cadlog.txt","a");
// do a log entry
(void) time(&t1);
strcpy(buf,"cad exit started - version 1.0012");
fprintf(log,"%s - %s \n", ctime(&t1), buf);
// ... Insert code here
// assume we do not allow the channel autodefinition
pCEP->ExitResponse = MQXCC_SUPPRESS_FUNCTION;
strcpy(buf,"ExitReason: ");
if (pCEP->ExitReason==MQXR_INIT)
{
strcpy(buf," CAD-EXIT Init Call, Returning MQXCC_OK");
fprintf(log,"%s \n", buf);
pCEP->ExitResponse = MQXCC_OK;
}
else
{
if (pCEP->ExitReason==MQXR_TERM)
{
strcpy(buf," CAD-EXIT Termination Call, Returning MQXCC_OK");
fprintf(log,"%s \n", buf);
pCEP->ExitResponse = MQXCC_OK;
}
else
{
CXP_output(pChannelExitParms);
CD_output(pChannelDefinition);
if (pCEP->ExitReason==MQXR_AUTO_CLUSSDR)
{
if (strncmp(pCD->SecurityExit,"MQMCHLX",7) == 0)
{
fprintf(log," ! erasing
channel security exit name %s \n", pCD->SecurityExit);
strncpy(pCD->SecurityExit," ",7) ;
}
}
pCEP->ExitResponse = MQXCC_OK;
}
}
// do a log entry
(void) time(&t1);
strcpy(buf,"cad exit ended");
fprintf(log,"%s - %s \n", ctime(&t1), buf);
fclose(log);
}
int CXP_output(PMQVOID pChannelExitParms)
{
PMQCXP pCEP = pChannelExitParms;
//
// now output cxp values
//
strcpy(buf," cxp structure output:");
fprintf(log,"%s \n", buf);
strcpy(buf,"strucid: ");
strcat(buf, pCEP->StrucId);
fprintf(log,"%s \n", buf);
fprintf(log,"Version: %d \n", pCEP->Version);
// strcpy(buf,"Version: ");
//
// ch_ptr = (char *) &pCEP->Version;
//
// switch (pCEP->Version)
// {
//case MQCXP_VERSION_1:
// strcat(buf,"MQCXP_VERSION_1");
// break;
//case MQCXP_VERSION_2:
// strcat(buf,"MQCXP_VERSION_2");
// break;
//case MQCXP_VERSION_3:
// strcat(buf,"MQCXP_VERSION_3");
// break;
//case MQCXP_VERSION_4:
// strcat(buf,"MQCXP_VERSION_4");
// break;
//default:
// strcat(buf,"!!! unknown Version number ");
// break;
// }
// fprintf(log,"%s \n", buf);
strcpy(buf,"ExitId: ");
switch (pCEP->ExitId)
{
case MQXT_CHANNEL_SEC_EXIT:
strcat(buf,"Channel Security Exit");
break;
case MQXT_CHANNEL_MSG_EXIT:
strcat(buf,"Channel Message Exit");
break;
case MQXT_CHANNEL_SEND_EXIT:
strcat(buf,"Channel Send Exit");
break;
case MQXT_CHANNEL_RCV_EXIT:
strcat(buf,"Channel Receive Exit");
break;
case MQXT_CHANNEL_MSG_RETRY_EXIT:
strcat(buf,"Channel Message Retry Exit");
break;
case MQXT_CHANNEL_AUTO_DEF_EXIT:
strcat(buf,"Channel Auto Definition Exit");
break;
default:
strcat(buf,"!!! unknown Channel Exit Point");
break;
}
fprintf(log,"%s (%d) \n", buf, pCEP->ExitId);
strcpy(buf,"ExitReason: ");
switch (pCEP->ExitReason)
{
case MQXR_INIT:
strcat(buf,"MQXR_INIT");
break;
case MQXR_TERM:
strcat(buf,"MQXR_TERM");
break;
case MQXR_MSG:
strcat(buf,"MQXR_MSG");
break;
case MQXR_XMIT:
strcat(buf,"MQXR_XMIT");
break;
case MQXR_SEC_MSG:
strcat(buf,"MQXR_SEC_MSG");
break;
case MQXR_INIT_SEC:
strcat(buf,"MQXR_INIT_SEC");
break;
case MQXR_RETRY:
strcat(buf,"MQXR_RETRY");
break;
case MQXR_AUTO_CLUSSDR:
strcat(buf,"MQXR_AUTO_CLUSSDR");
break;
case MQXR_AUTO_RECEIVER:
strcat(buf,"MQXR_AUTO_RECEIVER");
break;
case MQXR_AUTO_SVRCONN:
strcat(buf,"MQXR_AUTO_SVRCONN");
break;
case MQXR_AUTO_CLUSRCVR:
strcat(buf,"MQXR_AUTO_CLUSRCVR");
break;
default:
strcat(buf,"!!! unknown ExitReason");
break;
}
fprintf
AW: Still having problems with the CICS bridge
Paulo, (quote on) Put application name - RequestQueue name appended with CKTI (quote off) your cics trigger monitor ckti is started using the applicaition requestqueue instead of the initqueue. your setup looks to be wrong. go into your cics system start ckqc transaction place cursor on connection and press enter use 4 - display whats the name of the initqueue? it should be 'initqueue', but i bet it is 'requestqueue', which is wrong... (mhh... how much shall bet... mhhh :-)) thats what it should be: qlocal(requestqueue) specifies -> initq(initqueue) <- used by ckti thats what it looks like qlocal(requestqueue) <- used by ckti regards stefan -Ursprüngliche Nachricht- Von: Moreira, Paulo [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. Juli 2003 13:24 An: [EMAIL PROTECTED] Betreff: Re: Still having problems with the CICS bridge Stefan, First of all thanks for your great help. My message is going to the RequestQueue. Basically, the message has the following contents: -Does not use the RFH2 header -Format - None (since it doesn't use the RFH2 header I cannot define the Format) -Correlation ID -MQCI_NEW_SESSION -Message Content - program name (8 bytes) + commarea (31 bytes)- I tried with the program name in ASCII and in EBCDIC, and I had the same error (can you please which one should I use). I'm using a JMS ByteMessage. The message in the DLQ has the following contents: Reason Code -266 Queue - RequestQueue Put application name - RequestQueue name appended with CKTI We tried to change the queue configuration, and we started to have a different reason code - 2210 (MQRC_FORMAT_ERROR). After having this error, for any message I send to the request queue, I'll have the following error: CSQC746E CKBR 047 Invalid CCSID, 500 expected, 1208 received CSQC760I CKBR 047 MsgId =C3E2D840D4F5F3F04040404040404040B9A9A175074AB640 Then we have to restart the CICS bridge in order to solve this problem. I think that this is related with a bug fixed in APAR PQ68284. I'm not sure why am I getting the reason code 2210. The only reason I can imagine is that the message doesn't have a defined format, but the bridge is trying to convert the message data(MQGMO_CONVERT). But the MQ Application Programming guide states that I can use the MQFMT_NOME if I don't include an MQCIH, so I think I'm not doing anything wrong. Many thanks Paulo -Original Message- From: Raabe, Stefan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: AW: Still having problems with the CICS bridge sorry, I typed paolo instead of paulo and - in addition - the mail had some other old typing within it related to this problem before i typed what i wanted to send. i try again, please ignore the old mail: Paulo, check the information in the dead letter queue. You told us about the reason 266, but you should check further information from the dlq header. You may use the MA10 Supportpac (there is a little dead letter queue handler within it), otherwise browse the queue and check the bytes with the MQDLH structure (should be found in the application programmers reference) 1. what the queue name the message was destigned for? 2. whats the message contents? 3. what is the putapplication name? with these information it should be possible to find out what happened. if the queue is the initiation queue and the message contents is the request message, then you are putting to the wrong queue. if the queue is not the initiation queue but the putting application is the ckti (cics trigger monitor) then ckti is listening to the wrong queue. if it is something else (maybe a ckti in a different cics system) then you have to figure it out by yourself. maybe use display qstatus to see who is listening to the queue you put your requests too. i put a message to a cics initqueue to show you a sample output from the dlq handler that comes with the ma10 supportpac: COMMAND ===>, DLQName ,===>,MYQM.DEAD.QUEUE , MsgLen ,===>,0197, CurDepth ,===>,0006, (,0006,) StrucId ,===>,DLH , Version,===>,+0001, Reason ,===>,+0266, , , DestQ ,===>,MYCICS00.INITQ , DestQmgr,===>,MYQM, Encoding,===>,+0785, CodedCharSetId ,===>,+0273, Format ,===>,MQSTR , PutApplType,===>,+0001, ,CICS PutApplName ,===>,MYCICS00CKTI, PutDate ,===>,20030703, PutTime,===>,09394960, Dead Message: - REQUEST MESSAGE FOR PAOLO hope this helps. let us know what you found out. regards stefan Instructions for managing your mailing list subscr
AW: Still having problems with the CICS bridge
sorry, I typed paolo instead of paulo and - in addition - the mail had some other old typing within it related to this problem before i typed what i wanted to send. i try again, please ignore the old mail: Paulo, check the information in the dead letter queue. You told us about the reason 266, but you should check further information from the dlq header. You may use the MA10 Supportpac (there is a little dead letter queue handler within it), otherwise browse the queue and check the bytes with the MQDLH structure (should be found in the application programmers reference) 1. what the queue name the message was destigned for? 2. whats the message contents? 3. what is the putapplication name? with these information it should be possible to find out what happened. if the queue is the initiation queue and the message contents is the request message, then you are putting to the wrong queue. if the queue is not the initiation queue but the putting application is the ckti (cics trigger monitor) then ckti is listening to the wrong queue. if it is something else (maybe a ckti in a different cics system) then you have to figure it out by yourself. maybe use display qstatus to see who is listening to the queue you put your requests too. i put a message to a cics initqueue to show you a sample output from the dlq handler that comes with the ma10 supportpac: COMMAND ===>, DLQName ,===>,MYQM.DEAD.QUEUE , MsgLen ,===>,0197, CurDepth ,===>,0006, (,0006,) StrucId ,===>,DLH , Version,===>,+0001, Reason ,===>,+0266, , , DestQ ,===>,MYCICS00.INITQ , DestQmgr,===>,MYQM, Encoding,===>,+0785, CodedCharSetId ,===>,+0273, Format ,===>,MQSTR , PutApplType,===>,+0001, ,CICS PutApplName ,===>,MYCICS00CKTI, PutDate ,===>,20030703, PutTime,===>,09394960, Dead Message: - REQUEST MESSAGE FOR PAOLO hope this helps. let us know what you found out. regards stefan 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: Still having problems with the CICS bridge
Paolo,
check the information in the dead letter queue.
You told us about the reason 266, but you
should check further information from the dlq header.
You may use the MA10 Supportpac (there is a little
dead letter queue handler within it), otherwise
browse the queue and check the bytes with the
MQDLH structure (should be found in the application
programmers reference)
1. what the queue name the message was destigned for?
2. whats the message contents?
3. what is the putapplication name?
with these information it should be possible to find
out what happened.
if the queue is the initiation queue and the message
contents is the request message, then you are putting
to the wrong queue.
if the queue is not the initiation queue but the
putting application is the ckti (cics trigger monitor)
then ckti is listening to the wrong queue.
if it is something else (maybe a ckti in a different cics
system) then you have to figure it out by yourself.
maybe use display qstatus to see who is listening to
the queue you put your requests too.
i put a message to a cics initqueue to show you a sample
output from the dlq handler that comes with the ma10
supportpac:
COMMAND ===>,
DLQName ,===>,MYQM.DEAD.QUEUE ,
MsgLen ,===>,0197, CurDepth ,===>,0006, (,0006,)
StrucId ,===>,DLH , Version,===>,+0001,
Reason ,===>,+0266, , ,
DestQ ,===>,MYCICS00.INITQ ,
DestQmgr,===>,MYQM,
Encoding,===>,+0785, CodedCharSetId ,===>,+0273,
Format ,===>,MQSTR , PutApplType,===>,+0001, ,CICS
PutApplName ,===>,MYCICS00CKTI,
PutDate ,===>,20030703, PutTime,===>,09394960,
Dead Message: -
REQUEST MESSAGE FOR PAOLO
hope this helps.
let us know what you found out.
regards
stefan
2.
log on into the cics system
start transaktion ckqc
use connection, then 4- display
what is the name of the initq? it should be 'InitQueue', but
maybe it is 'RequestQueue')
3.
if it is 'InitQueue', then try the following:
put disable the 'InitQueue'
run your application
if you get a proper returncode (2051 put inhibited)
then the application is putting to the initq.
3
depending on the os/390 version
-Ursprüngliche Nachricht-
Von: Moreira, Paulo [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 3. Juli 2003 10:17
An: [EMAIL PROTECTED]
Betreff: Re: Still having problems with the CICS bridge
Hi,
The configuration I'm using is the following:
DEF QL('RequestQueue') +
TRIGGER +
TRIGTYPE(FIRST) +
INITQ('InitQueue') +
PROCESS('TestProcess')
DEF QL('InitQueue')
DEF PROCESS('TestProcess') +
APPLTYPE(CICS) +
APPLICID(ATG1)
My JMS application is putting the messages on the RequestQueue. Is there
anything wrong with this configuration?
Many thanks
Paulo
-Original Message-
From: Miller, Dennis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Still having problems with the CICS bridge
You are getting your queues mixed up. Either you are sending your request
message to the initq or the trigger monitor is reading the bridge queue. On
CICS there should be two distinct queues:
Bridge Queue
Send your CICS requests here
Input to bridge monitor
Triggering parameters specify the Initq
Used exclusively by the CICS bridge
Init Queue
Referenced in trigger parameters of the Bridge queue
Input to trigger monitor (CKTI)
Shared by many applications
> -Original Message-
> From: Moreira, Paulo [SMTP:[EMAIL PROTECTED]
> Sent: Wednesday, July 02, 2003 5:47 AM
> To: [EMAIL PROTECTED]
> Subject: Still having problems with the CICS bridge
>
> Hi,
>
> We have a MQ-CICS bridge running. I'm sending a message to the request
queue
> with the following format:
>
> MessageID - MQMI_NONE
> CorrelationID - MQCI_NEW_SESSION
> I'm not using the RFH2 header
> ReplytoQueue - Another queue that is used for replies
> Message content- CICS Program name (8 characters) + commarea (I tried to
> play around with format using ascii and ebcdic but I had always the same
> problem)
>
> The request message is being read, and I'm always having a response in a
> dead-letter queue, with the reason code 266 (MQFB_TM_ERROR - MQTM
structure
> not valid or missing).
> Anyone has any idea about what is going wrong?
>
> Many thanks
>
> Paulo
>
>
>
> --
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received
AW: Still having problems with the CICS bridge
Paolo, is the queue you are putting the request message to an init queue, read by a trigger monitor (most likely CKTI within cics)? regards stefan -Ursprüngliche Nachricht- Von: Moreira, Paulo [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 2. Juli 2003 14:47 An: [EMAIL PROTECTED] Betreff: Still having problems with the CICS bridge Hi, We have a MQ-CICS bridge running. I'm sending a message to the request queue with the following format: MessageID - MQMI_NONE CorrelationID - MQCI_NEW_SESSION I'm not using the RFH2 header ReplytoQueue - Another queue that is used for replies Message content- CICS Program name (8 characters) + commarea (I tried to play around with format using ascii and ebcdic but I had always the same problem) The request message is being read, and I'm always having a response in a dead-letter queue, with the reason code 266 (MQFB_TM_ERROR - MQTM structure not valid or missing). Anyone has any idea about what is going wrong? Many thanks Paulo -- The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. 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
AW: Questions about Shared Queues - Help!!!
Thomas, you should try to seperate between - sending messages to a shared queue (any queuemanager of the qsg will do, maybe using a "shared inbound channel" (group listener) and - processing messages from the shared queue. anyway, i encountered this problem too (p7 inquire results in a usecount of 0 if p3 has the queue open). one workaround could be not to inquire by call (call mqinquire ...) but by message put to the system.command.input queue. in this case you can use the CMDSCOPE(*) option and you will get multiple reply messages, one from every queuemanager within the queue sharing group. in your case you will also get a reply from p3, and you should see the proper input count of the queue. not very nice, but it should work. better: try to get rid of the "can only run in one system " affinity, otherwise you do not really use the benefits of a shared queue. regards stefan -Ursprüngliche Nachricht- Von: Thomas Lane [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 20. Juni 2003 13:31 An: [EMAIL PROTECTED] Betreff: Questions about Shared Queues - Help!!! I would appreciate any ideas about this issue we are having with Shared queues: Let me first setup the question and later I will explain the reason we have a requirement that apparently cannot be support by MQ Series. We have implemented shared queues across two Mainframe Queue Managers. Lets call them P3 and P7. Our configuration is primarily a Unix based middleware communicating to the Mainframe based two queue managers(P3 and P7). On the Mainframe we have two regions(mostly duplicated applications, except one application that has region affinity(can only process in one region). Also, our mainframe regions are limited to reading from one queue manager(I was told this is an IBM limitation). Because of this, the mainframe region that has the application that must process in that region only, can only read from one queue manager thus the readers are only running on the one queue managerlets say the P3 queue manager. Now here comes the issue. Our Unix middleware handles request messages coming from the front end. The middleware also detects whether the mainframe queue readers are up and running by inquiring for open input count(handles) on a queue. If our Unix Middleware connects to the same queue manager that the P3(region affinity) application connects to it works fine. Because the readers are local to the queue manager in question. However, we have two queue managers that Unix middleware uses. When the Unix middleware inquires for open input count for the shared queue and the queue manager is P7(meaning not the queue manager where the MF readers are running for the shared queue) it gets an open input count(mainframe readers) of 0. Thus the Unix middleware cannot determine if there is some process in the mainframe to read the queues. In this case we will not send messages because we don't want the messages to stale out. The way our infrastructure is set up it it(will) be extremely undesirable and counter-productive to have a single point of failure(just one queue manager). Does anyone have any suggestions on how we can get past this issue while still having two queue managers? If so, I would greatly appreciate it! Thanks in advance, Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 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
AW: Anyone have a CHAD exit Sample for MVS
i did some tests with a chad some time ago, its in c and it was on
unix, but maybe its of use too. i used it to output some fields
and to wipe out the security exit name in a cluster sender
channel.
i know its hard to find a sample (i did not found any at that time).
hope it helps.
regards, stefan.
#include
#include
#include
#include
#include
#include
MQCHANNELAUTODEFEXIT MY_MQ_CHANNEL_AUTO_DEF_EXIT;
FILE *log;
char buf[100] = "";
char myexit[128] = "";
void MQStart() {;} /* dummy entry point - for consistency only */
void MQENTRY MY_MQ_CHANNEL_AUTO_DEF_EXIT ( PMQVOID pChannelExitParms,
PMQVOID pChannelDefinition)
{
PMQCXP pCEP = pChannelExitParms;
PMQCD pCD = pChannelDefinition;
time_t t1;
log=fopen("/var/mqm/cadlog.txt","a");
// do a log entry
(void) time(&t1);
strcpy(buf,"cad exit started - version 1.0012");
fprintf(log,"%s - %s \n", ctime(&t1), buf);
// ... Insert code here
// assume we do not allow the channel autodefinition
pCEP->ExitResponse = MQXCC_SUPPRESS_FUNCTION;
strcpy(buf,"ExitReason: ");
if (pCEP->ExitReason==MQXR_INIT)
{
strcpy(buf," CAD-EXIT Init Call, Returning MQXCC_OK");
fprintf(log,"%s \n", buf);
pCEP->ExitResponse = MQXCC_OK;
}
else
{
if (pCEP->ExitReason==MQXR_TERM)
{
strcpy(buf," CAD-EXIT Termination Call, Returning MQXCC_OK");
fprintf(log,"%s \n", buf);
pCEP->ExitResponse = MQXCC_OK;
}
else
{
CXP_output(pChannelExitParms);
CD_output(pChannelDefinition);
if (pCEP->ExitReason==MQXR_AUTO_CLUSSDR)
{
if (strncmp(pCD->SecurityExit,"MQMCHLX",7) == 0)
{
fprintf(log," ! erasing
channel security exit name %s \n", pCD->SecurityExit);
strncpy(pCD->SecurityExit," ",7) ;
}
}
pCEP->ExitResponse = MQXCC_OK;
}
}
// do a log entry
(void) time(&t1);
strcpy(buf,"cad exit ended");
fprintf(log,"%s - %s \n", ctime(&t1), buf);
fclose(log);
}
int CXP_output(PMQVOID pChannelExitParms)
{
PMQCXP pCEP = pChannelExitParms;
//
// now output cxp values
//
strcpy(buf," cxp structure output:");
fprintf(log,"%s \n", buf);
strcpy(buf,"strucid: ");
strcat(buf, pCEP->StrucId);
fprintf(log,"%s \n", buf);
fprintf(log,"Version: %d \n", pCEP->Version);
// strcpy(buf,"Version: ");
//
// ch_ptr = (char *) &pCEP->Version;
//
// switch (pCEP->Version)
// {
//case MQCXP_VERSION_1:
// strcat(buf,"MQCXP_VERSION_1");
// break;
//case MQCXP_VERSION_2:
// strcat(buf,"MQCXP_VERSION_2");
// break;
//case MQCXP_VERSION_3:
// strcat(buf,"MQCXP_VERSION_3");
// break;
//case MQCXP_VERSION_4:
// strcat(buf,"MQCXP_VERSION_4");
// break;
//default:
// strcat(buf,"!!! unknown Version number ");
// break;
// }
// fprintf(log,"%s \n", buf);
strcpy(buf,"ExitId: ");
switch (pCEP->ExitId)
{
case MQXT_CHANNEL_SEC_EXIT:
strcat(buf,"Channel Security Exit");
break;
case MQXT_CHANNEL_MSG_EXIT:
strcat(buf,"Channel Message Exit");
break;
case MQXT_CHANNEL_SEND_EXIT:
strcat(buf,"Channel Send Exit");
break;
case MQXT_CHANNEL_RCV_EXIT:
strcat(buf,"Channel Receive Exit");
break;
case MQXT_CHANNEL_MSG_RETRY_EXIT:
strcat(buf,"Channel Message Retry Exit");
break;
case MQXT_CHANNEL_AUTO_DEF_EXIT:
strcat(buf,"Channel Auto Definition Exit");
break;
default:
strcat(buf,"!!! unknown Channel Exit Point");
break;
}
fprintf(log,"%s (%d) \n", buf, pCEP->ExitId);
strcpy(buf,"ExitReason: ");
switch (pCEP->ExitReason)
{
case MQXR_INIT:
strcat(buf,"MQXR_INIT");
break;
case MQXR_TERM:
strcat(buf,"MQXR_TERM");
break;
case MQXR_MSG:
strcat(buf,"MQXR_MSG");
break;
case MQXR_XMIT:
strcat(buf,"MQXR_XMIT");
break;
case MQXR_SEC_MSG:
strcat(buf,"MQXR_SEC_MSG");
break;
case MQXR_INIT_SEC:
strcat(buf,"MQXR_INIT_SEC");
break;
case MQXR_RETRY:
strcat(buf,"MQXR_RETRY");
break;
case MQXR_AUTO_CLUSSDR:
strcat(buf,"MQXR_AUTO_CLUSSDR");
break;
case MQXR_AUTO_RECEIVER:
strcat(buf,"MQXR_AUTO_RECEIVER");
break;
case MQXR_AUTO_SVRCONN:
strcat(buf,"MQXR_AUTO_SVRCONN");
break;
case MQXR_AUTO_CLUSRCVR:
strcat(buf,"MQXR_AUTO_CLUSRCVR");
break;
default:
strcat(buf,"!!! unknown ExitReason");
break;
}
fprintf(log,"%s
AW: How to trigger when using Shared Queues?
Brian, 1. if you trigger first 1a if your initiation queues are local a trigger message is put into every local initiation queue if the trigger conditions are fullfilled (e.g. trigger monitor running , ...) so every instance of the application is triggered 1b if your initiation queue is shared a trigger message is put into the initiation queue for every trigger monitor that is running. this may result in one ckti getting multiple messages, one ckti getting no message. so in some cases not every instance of the application is triggered. if you have multiple ckti running there is no way to get only one trigger message with trigger first. 2. if you trigger every one qmgr is selected to put a message into its initiation queue. with trigger every you get only 1 trigger message (but for every message that arrives on the destination queue). but - if that qmgr fails before the application is started, you will lose this one trigger message, the other qmgrs in the queue sharing group do not know about it. ibm recommends to use a shared queue for trigger every so you do not lose trigger messages there is a small section in the concepts and planning guide (page 25) for this. in most cases every cics system has its own initq, using the cics applid or sysid to build its name. but you can only specify a single initq in the shared queue that you want to trigger, so all ckti in the different cics system have to listen to the same queuename (maybe local, maybe shared). this may result in the need to run multiple ckti in a single cics system. Regards, Stefan -Ursprüngliche Nachricht- Von: McCarty, Brian [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Juni 2003 19:18 An: [EMAIL PROTECTED] Betreff: How to trigger when using Shared Queues? If you use Shared Queue's on MVS but want to use triggering, how would that work? If the message lands on a shared queue but you want multiple CICS regions supporting pulling the message off, how do you set it up so that only 1 trigger message is sent to an initiation queue? On the shared queue definition, how would you be able to put a trigger message on separate initiation queues on the actually queue managers in scope? Even if you were able to, how would you set it to only send one trigger message (on EVERY) for each unique application message? Please feel free to clue me in if someone has done this before, were new to shared queues. Thanks for the help, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist 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
AW: Cluster---AMQ4514
Ruzi, this sounds somehow familiar to me. are you using the mq explorer? i remember of similiar error messages telling me that the qmgr is not in the cluster when working with cluster objects, at least the definition worked and the qmgr was member of the cluster, it was just the mq explorer that was telling me silly messages. if you are using the mq explorer, try something else (e.g. remote runmqsc or mo71 supportpac) to create the definitions and check if the errors occur again. the mq explorer sometimes seems to be a bit confused regards stefan -Ursprüngliche Nachricht- Von: Ruzi R [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 5. Juni 2003 15:07 An: [EMAIL PROTECTED] Betreff: Cluster---AMQ4514 I created a cluster with QM1 and QM2 full-repositories. QM3 is a member of the cluster (not a full repository). The cluster queue Q1 is defined on QM2 and QM3. Q1: When I want to define Q1 on QM1 I get an error message AMQ4514 which basically says as the queue manager is not a member of the cluster, the queue cannot be defined as cluster. But the queue manager (QM1) is the full-repository. I have refreshed the cluster. Q2: When defining the cluster queue I expected to see the cluster name in the drop-down menu of the cluster tab --- it was just blank. Is this a normal behavior? I manually specified the cluster name for creating cluster queue Q1 on QM2 and QM3, and it worked. Thanks, Ruzi 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
AW: Need to move stuff from one xmitq to another
Rebecca, I do not know a supportpac that is doing exactly what you want. I think you have to write your own program (or channel exit) to change the queuemanagername. Anyway, the easiest way is a qmgr alias that is defined on QMGRC and makes QMGRC accept messages that are destined for QMGRB "define remoteq(QMGRB) RQMNAME(QMGRC)" If this is not possible because QMGRC has to know QMGRB as a seperate queuemanager, you should consider to - define the alias only in the case of a disaster or - to "fake" QMGRB, (e.g. use QMGRX as a destination for the messages and have a qmgr alias for QMGRX on QMGRB and QMGRC) I prefer the qmgr alias solution instead of programing. But - if programing is the only possible way to go - i would use a channel message exit. Regards, Stefan -Ursprüngliche Nachricht- Von: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 27. März 2003 17:17 An: [EMAIL PROTECTED] Betreff: Need to move stuff from one xmitq to another I am planning a backup/recovery scenario. The environment is OS/390 V5.2. . Basically, I have a bunch of messages on a transmission queue all ready to go to another qmgr (B). These messages specify RemoteQmgr B in their headers. I want to move them so they go to qmgr C. I know that I can move them to xmitq C so they will go to qmgr C (It's a bit awkward because of the get being disabled, but I can get around that). The problem/concern is that when the messages end up on C, they end up in the default XMIT queue because the transmission header has the RemoteQmgr set to B I've thought through several things using qmgr aliases and stuff like that, but rejected them for various reasons. (And before someone asks, I don't want to use clustering for this for several reasons I don't want to go into here.) It seems to me that the easiest way to do what I want is to write a simple program to read in the messages and modify the transmission header to point to RemoteQmgr C. Or, I suppose, I could strip the header and let MQ rebuild the header. But, I don't want to reinvent the wheel, which is why I'm putting this query out here Does anyone know of a SupportPac that will do this? (I went through the list, but didn't identify one that does what I want, but maybe I just missed it.) Or -- does someone have code they are willing to share? Remember -- It needs to run on OS/390. Thanks, all... Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 Phone: 609-734-5351 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: MQService doesn't start after changing NT domain
Title: MQService doesn't start after changing NT domain Ben, maybe userid musr_mqadmin is domain-controlled? or is there a local definition on every machine? check the event messages, if this is the reason use dcomcnfg to set the password vor the service. just a quick guess regards stefan -Ursprüngliche Nachricht-Von: Benjamin Zhou [mailto:[EMAIL PROTECTED]Gesendet: Dienstag, 25. März 2003 14:08An: [EMAIL PROTECTED]Betreff: MQService doesn't start after changing NT domain Hi, we just moved a couple of machines from one domain to another, after that MQ service couldn't be started on them. I suppose it's must be sth trivial to adjust. Does anyone know what need to be changes to make MQ running again? thanks for any input. Ben Zhou
AW: Backup CFstruct
Hello, here is a sample what you could do using netview or any other proper automation tool: do every hour if qmgr a available issue dis cfstruct(*) on qma else if qmgr b available issue dis cfstruct(*) on qmb endif issue backup cfstruct for every structure on proper qma/b end do anyway, it depends on your amount of data and the way the application works. messages should not reside in queues for hours , especially if these queues are shared queues. it also depends on how busy your queuemanager is and how many logdata has to be read in case of a recovery situation. anyway, try keep backups small (try to keep queues empty) and try to do frequent backups to minimize recovery time (especially for production systems) maybe it makes sense to do backups depending on queuemanager (or beter, qsg) activity, e.g. depending on the number of active log switches. just an idea, i did not think much about it yet. regards stefan -Ursprüngliche Nachricht- Von: Dijkerman, E (Erik) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. März 2003 10:44 An: [EMAIL PROTECTED] Betreff: Backup CFstruct Listeners, Did one of you already setup a Backup strategy for your structures and wants to share this?? Regards, Erik Dijkerman X Rabobank ICT/Serverbedrijf PIM/OS390 ZL-S206400 Mailbox 17100, 3500 HG Utrecht *(030) 215 4878 *(030) 215 3085 ? [EMAIL PROTECTED] "The greatest amount of wasted time is the time not getting started." - Dawson Trotman De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Removing a Pageset
Jim, I am not quite sure, but I think you have to follow the procedure "restarting if you have lost your log data sets" described in the system administration guide and omit the page set you want to remove. Regards Stefan -Ursprungliche Nachricht- Von: Jim Ford [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 19. Marz 2003 00:21 An: [EMAIL PROTECTED] Betreff: Removing a Pageset I've got a page set that no longer has any messages or storage classes associated with it. A DISPLAY USAGE command shows all pages are unused. To get MQSeries to stop using it, can I simply remove it from MSTR's JCL? The manual describes adding, shrinking and enlarging, but so far I haven't seen anything about removing. 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
AW: Opinion please
Hello "Is it possible to define shared and non-shared queues within the same QMGR? " no. "any messages coming in which are destined to the non-shared queues in the QMGR that has failed, will end up going to the dead letter queue until that QMGR has been restarted" you can not put messages to local (disposition qmgr) queue (no matter whether this is an application queue or a dead letter queue) of a queuemanager that is not active. the messages will stuck in the sending queuemanager xmitq until the queuemanager is available if you really want to have a automatic failover situation, you should consider the use of shared inbound channels together with shared queues. Remote Queuemanagers connect via the shared inbound channel (group listener, shared port or vtam generic ressource) to one of the queuemanagers within the queue sharing group, messages are put to a shared queue. On every queuemanager you will need an applicaiton to process the shared queue. If one of the queuemanagers dies, the other queuemanagers of the qsg are still active and able to (recover and ) handle the connection and to serve the application requests. This is only a brief description, check "Cncepts and Planing" manual for details. Regards Stefan -Ursprüngliche Nachricht-Von: Herd, Stewart [mailto:[EMAIL PROTECTED]Gesendet: Dienstag, 18. März 2003 18:01An: [EMAIL PROTECTED]Betreff: Opinion please The question involves two QMGRs that each have access to some shared queues. High availability customers connect from remote QMGRs to one of these QMGRs. When the active QMGR fails, we want a non-disruptive failover to the other QMGR. Is it possible to define shared and non-shared queues within the same QMGR? It is my impression that if one did this, then any messages coming in which are destined to the non-shared queues in the QMGR that has failed, will end up going to the dead letter queue until that QMGR has been restarted. For this reason, I feel it would be better to define no non-shared queues in the two QMGRs that contain the shared queues.appreciate anyones opinion as regard shared...non-shared.. Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland Office +353 21 2309331 Mobile +353 86 1713777
AW: Increase size of error logs
mhhh... no, i dont think so. there settings are related to mqseries activity logging (primary and secondary log files), not to the amqerr* error log files. regards stefan -Ursprüngliche Nachricht- Von: Marty G. Trice [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 13. März 2003 14:45 An: [EMAIL PROTECTED] Betreff: Re: Increase size of error logs My Friend, Goto to START | PROGRAM | IBM MQSERIES 5.2| MQSERIES SERVICES. From this point, right click on the qmgr that you plan to modify, and goto properties | log. Also, the LogPageSizes can only be adjusted by recreating the qmgr and initializing the needed size. Marty G. Trice WebSphere MQ/MQI Administrator Sara Lee Business Services - EAI Group [EMAIL PROTECTED] 336.519.2939 (Embedded image moved to file: pic26924.pcx) "Aatush Desai(PIPEX)"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: .PIPEX.COM> Subject: Increase size of error logs Sent by: MQSeries List <[EMAIL PROTECTED] n.AC.AT> 03/12/2003 07:12 PM Please respond to MQSeries List Hi... MQ error logs (amqerr01.log..etc) are cut when they go over 256KB. MQ also keeps 3 logs. Does anyone know either how to increase the size of the logs or the number of logs. Platform if NT, v5.2 and above. Thanks Aatus 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: Configuration problem with MQSeries under Microsoft Cluster S ervice (MSCS)
Hello, (quote on) "After running hamvmqm I notice that I now have a directory on my shared drive (D:) called D:\mqseries\qmgrs\MYQMGR, this directory is empty, is this supposed to be empty? The original directories for this QMGR are now gone from C:\mqm\Qmgrs. " (quote off) no. after using hamvmqm the directories should be the same but moved to the shared drive. if the directory structure on the shared drive is empty, then there is an error while moving. registry updates seem to be okay (the path shown in the error message is on the shared drive where it should be). its a long time since i used hamvmqm and i do not remeber if there is a success message or not... anyway, the directories should be moved, in your case they disappear sorry, not nuch help... regards stefan -Ursprüngliche Nachricht-Von: Matt Gurney [mailto:[EMAIL PROTECTED]Gesendet: Freitag, 28. Februar 2003 12:50An: [EMAIL PROTECTED]Betreff: Configuration problem with MQSeries under Microsoft Cluster Service (MSCS) Hello, I am having a problem with MQSeries under Microsoft Cluster Service (MSCS). There is no MQSeries Clustering involved. Environment Details = Windows Version on both nodes: Windows 2000 Version 5.0 (Build 2195: Service Pack 2) MQSeries version on both nodes: MQSeries Version: 521 CMVC level: p521-L010508 BuildType: IKAP - (Production) MSCS Version on both nodes: Cluster Node Version 3.2195 MSCS Support Pack on both servers: mc74 Updated version released 31/Dec/2002: http://www-3.ibm.com/software/ts/mqseries/txppacs/mc74.html The Issue = I am getting a problem starting my Queue managers after using the command hamvmqm.exe to move the normal unclustered Queue manager to the clustered environment. Here is the sequence of events: 1) I create a qmgr normally, using either crtmqm or MQSeries Explorer (I get the error with both techniques), I get the following directories created: Directory of C:\mqm\Qmgrs\MYQMGR 28/02/2003 11:45 . 28/02/2003 11:45 .. 28/02/2003 11:45 @ipcc 28/02/2003 11:46 56 amqalchk.fil 28/02/2003 11:45 auth 28/02/2003 11:45 dce 28/02/2003 11:45 errors 28/02/2003 11:45 NAMELIST 28/02/2003 11:45 plugcomp 28/02/2003 11:45 PROCDEF 28/02/2003 11:45 QMANAGER 28/02/2003 11:45 QUEUES 28/02/2003 11:45 startprm 2) I start the qmgr and test it out. Put a message, and Get it, everything seems fine. 3) I stop the qmgr, everything ok so far, no strange event log messages. 4) I run the command : hamvmqm /m MYQMGR /dd d:\mqseries /ld d:\mqseries\log I get absolutely no output from this command, perhaps it is a unix style command that only reports errors or perhaps it is a Windows style command that fails and then doesn't tell me, I am not sure which, does anybody have any ideas? After running hamvmqm I notice that I now have a directory on my shared drive (D:) called D:\mqseries\qmgrs\MYQMGR, this directory is empty, is this supposed to be empty? The original directories for this QMGR are now gone from C:\mqm\Qmgrs. D: is my shared drive, this "Resource" is currently active on the node where I am running the hamvmqm command. 5) When I attempt to start the QMGR using either strmqm or MQSeries Explorer (I get the error with both techniques): C:\>STRMQM MYQMGR AMQ7002: An error occurred manipulating a file. In the event viewer: An internal MQSeries error has occurred (rc=2: stat: d:[EMAIL PROTECTED]:) MQSeries detected an unexpected error when calling the operating system. The MQSeries error recording routine has been called. The QMGR does not start. When I look at the directories on my shared drive I see: Directory of D:\mqseries\qmgrs\MYQMGR 28/02/2003 11:52 . 28/02/2003 11:52 .. 28/02/2003 11:52 auth 28/02/2003 11:52 dce 28/02/2003 11:52 errors 28/02/2003 11:52 plugcomp 28/02/2003 11:52 startprm Notice that not all of the directories are present and in particular the @ipcc directory mentioned in the Event log message is missing. The userid I am using to do all of this is a member of: local administrators group local mqm group I have tested out MSCS on these servers and there does not seem to be any problems with it. I am able to "Move" a "Resource" between nodes. The Resources that I have tested are Notepad and SMTP server. Any input would be much appreciated. Thanks.---Matt Gurney
AW: Hopping messages across clusters
Randall, QM9 does not know about QC.LOCAL on QM1/QM2 because of the different cluster, so you can not put to QC.LOCAL. Using a remotequeue on QM9 (RNAME QC.LOCAL RQMGR QM1 for example) does not work because QM9 does not know about QM1 (different cluster) There is no way for QM9 to put to QC.LOCAL without additional definitions that are provided in cluster B (queues, qmgr alias, ) or defined in QM9 directly to make QM9 know the queue or the target queuemanager. Either make QM9 a member of cluster A, or use QM3 as a gateway to Cluster A. Regards, Stefan -Ursprüngliche Nachricht- Von: Crowder, Randall [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. Februar 2003 22:32 An: [EMAIL PROTECTED] Betreff: Re: Hopping messages across clusters Bridgette, I want to use the cluster features for load balancing. Likewise, what I'm wondering is if there is a way to do it without creating any other object definitions. Creating queue remotes is still creating other object definitions. Thanks, Randy -Original Message- From: Beardsley, Bridgette [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 4:18 PM To: [EMAIL PROTECTED] Subject: Re: Hopping messages across clusters Randy, Why not use a remote queue definition on QM9 that points to QC.LOCAL? -Bridgette Beardsley -Original Message- From: Crowder, Randall [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 2:56 PM To: [EMAIL PROTECTED] Subject: Hopping messages across clusters Intercommunication Gurus!!! I have the following setup - two overlapping clusters A and B. --- Cluster A | QM1 | QC.LOCAL - Local to QM1, shared in Cluster A | QM2 | QC.LOCAL - Local to QM2, shared in Cluster A |-| | | QM3 | | QC.LOCAL.ALIAS - Alias on QM3, shared in Cluster B |-|- | QM8 | | QM9 | |-- Cluster B In this example. QM3 is the only queue manager that is a part of both clusters. What I'm trying to figure out is how a program connected to QM9 can put messages to QC.LOCAL on QM1/QM2. So far, the only thing I've been able to get working is to create an alias for QC.LOCAL on QM3 and make the alias a part of Cluster B. Is there another way? I'd like to be able to do it programmatically - where I wouldn't have to create the alias definition on QM3... Thanks for any assistance. Randy C. 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
AW: OS/390 MQGET using Set Signal
Hi, from "Application Programming Reference", MQGMO-Option Field: [...] This option is not valid with any of the following options: MQGMO_UNLOCK MQGMO_WAIT [...] You said you are using signal AND wait option? Regards Stefan -Ursprüngliche Nachricht- Von: Vince Gibson [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 13. Februar 2003 22:17 An: [EMAIL PROTECTED] Betreff: OS/390 MQGET using Set Signal In batch, I am using the MQGET set signal and the wait interval options to notify me when a message is place on the queue. I do not receive the set signal request after this MQPUT. After one minute the wait interval expired, then I can determine the set signal ECB been posted for this timeout. Can anybody tell my why I can't get the ECB signal when the message arrived in the queue. Vince Gibson Thanks in advanced 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
AW: message lost
Hello Kritsana, even in a cluster environment mq should not lose any persistent message. 1. make sure that the messages are persistent. 2. no software is error-free, so maybe there is a very little chance of a mq software error that may result in the lost of the message. There is somethink called a "cluster re-routing mechanism". Lets assume message 2 is assigned to QM2, but QM2 is down, the channel from QM3 to QM2 is in retry and there is no indoubt situation. Message 2 is stuck in the SYSTEM.CLUSTER.TRANSMIT.QUEUE. Now - at every retry interval of the channel to QM2 - the cluster rerouting mechanism reads the message from the xmitq and puts it to the destination queue again. This put forces a new queue selection (as every put to a cluster queue). But now QM3 knows that the only available queue is at QM1 and it will put the message to the queue for QM1 and it will get delivered. I do not know from what version/on what platform this cluster rerouting mechanism is available. Have you checked if message 2 has been sent to QM1 and got processed there? Make also sure that TO.QM2 on QM3 is not indoubt (with a hold on that particular message). Regards Stefan -Ursprüngliche Nachricht-Von: Kritsana [mailto:[EMAIL PROTECTED]]Gesendet: Mittwoch, 12. Februar 2003 17:18An: [EMAIL PROTECTED]Betreff: message lost Dear all, Due to MQseries have special features of guaruntee delivery and no message lost. But in the cluster environment, which messages route to destination in round-robin fashion. There is message lost problem. Suppose there are three queue managers joined in the same cluster. Two of them (QM1,QM2) define a local queue, which has same name, and share them to the cluster. The rest queue manger (QM3) see those two local queues as two cluster queues. But when one of queue manager(QM2), which is an owner of cluster queue, is stopped. And the QM3 tries to put 4 messages to cluster queues. Suppose,first message route to QM1. This message normally delivers to QM1. And second message route to QM2, according to round-robin fashion. This message does not deliver to QM2, because QM2 already stopped. And I can see this message lefts in the cluster transmission queue. Then, the third message route to QM1. This message normally delivers to QM1. But the previous second message disappears from cluster transmission queue. And I can not find it in other queues such as dead letter queue. Finally, The forth message route to QM1. This message normally delivers to QM1. I wonder why the second message losts from MQSeries system. Because the outstanding feature of MQSeries is guaruntee no message lost. If I declares it as persistant message. Can I maintain no message lost feature of MQSeries in Cluster environment ? Or I mis-understand about that feature. Thank you Kritsana Loaboonsup system programmer
AW: MQ Q-Sharing question
Hi, @Tim: i do not think using an alias is curious, in most cases it is fine if an application is using an alias queue and its up to the mq administration to handle this alias (point to local queue, point to remote queue, point to shared queue). especially in this case, when switching an application to use a shared queue it is useful, you just switch the alias. if it does not work, you switch back to the local queue. anyway, back to the original question: @Bob: you can use the same alias name on both queuemanagers, both pointing to the shared queue. you can either have 2 alias definitions (1 in each queuemanager with DISP(QMGR)), or you can use a group definition (1 definition DISP(GROUP)) which will result in a group definition that is held in db2 and a local copy of this definition in each queuemanager (get rid of the DISP(QMGR definitions first)). I prefer the second solution, because the entry is the same in all participating queuemanagers. even if you add a queuemanager to the qsg it will get a local copy of that definition automatically. if you change the group entry the change is applied to all local copies on all queuemanagers of the qsg. i do the same to other object types that have to be the same on all queuemanagers within the qsg (e.g. CICS INITQs for CICS systems that can run with every queuemanager of the qsg). there is nothing special with alias queues and queue sharing groups, its just the group entry that you should be aware of. concepts and planing guide is also a good source to read about queue sharing groups hth Stefan -Ursprungliche Nachricht- Von: Tim Armstrong [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 6. Februar 2003 23:00 An: [EMAIL PROTECTED] Betreff: Re: MQ Q-Sharing question Curious as to why you are using aliases. That aside for V5.3 you need to look in the "Script(MQSC) Command Reference" which you can get at the following URL. http://www-3.ibm.com/software/ts/mqseries/library/manualsa/manuals/crosslate st.html. Up one level is a page you can access most Webshpere MQ product Manuals from http://www-3.ibm.com/software/ts/mqseries/library/manualsa/ Regards Tim A "Ofeldt, Robert" cc: Sent by: MQSeries Subject: Re: MQ Q-Sharing question List <[EMAIL PROTECTED] C.AT> 07/02/2003 08:07 Please respond to MQSeries List Hi, I am sure there are many of you out there that currently use MQ in a Q-Sharing environment. I am knew to Q-Sharing and hope you can help answer some questions for me. I plan to have 2 QMGRs in 1 Q-Sharing group. Each QMGR has 1 CICS region associated with it. Each CICS region has an application program that uses the same Q-alias name. Question is; can these programs use the same alias name to access a particular shared queue on the coupling facility? Can someone point me to a document or manual that explains use of alias qnames in a q-sharing environment? Thank you Bob Ofeldt 201-269-4076 MedcoHealth Messaging Infrastructure 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
AW: Help Needed: On clusters
Vinay, QM1 is a repository queuemanager, QM2 is "only" a member of the cluster. if you define a cluster queue on QM2, it will notify the repository about it. thats why you see the queue on QM2 and on QM1 if you define a cluster queue on QM1, it is only known to QM1. there is no need to give this information to QM2 because it does not host a full repository of the cluster. now try the sample put program on QM2, "amqsput Q1 QM2". what happenes is that QM2 looks for a local definition of a queue (type local, alias, remote). it does not find one. but QM2 is member of a cluster. so it ask the repository (QM1) "do you know a cluster queue named Q1 within cluster EDUC?" and the repository will replay "yes, i know it, and its on QM1" and from that moment on QM2 knows the queue QM1 as a cluster queue and will put that information in its own "partial" repository. lets assume that that Q1 is not defined in QM1 but on a third queuemanager named QM3 (also member of the cluster and connected the same way like QM1). In that case QM1 will answer "yes, i know cluster queue Q1, its on QM3" and will also pass the proper channel definition "TO.QM3" to QM2, QM2 will then create an implicit cluster sender channel definition and will send the messages to QM3 directly. Hope that helps, check "queuemanager clusters" manual for details. Regards, Stefan -Ursprüngliche Nachricht- Von: vinay_tiwari [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 5. Februar 2003 15:00 An: [EMAIL PROTECTED] Betreff: Help Needed: On clusters Hi, I am trying MQSeries cluster on 2 NT boxes MQSeries V5.2.I am able to queues on repository queue manager which are local to QM2 but not the messages which are lying in the queue.And not able to see Queues which are created on repository Qmgr on other Qmgr. Any help will be highly appreciated. TIA Vinay 1. On one QM1 I have executed following commands ALTER QMGR REPOS(EDUC) DEFINE CHANNEL(TO.QM1) + CHLTYPE(CLUSRCVR) CONNAME(ip address of QM1) + CLUSTER (EDUC) DEFINE CHANNEL(TO.QM2) + CHLTYPE(CLUSSDR) CONNAME(ip address of QM2) + CLUSTER (EDUC) DEFINE QLOCAL(Q1) CLUSTER(EDUC) 2. On QM2 I have executed following commands: DEFINE CHANNEL(TO.QM2) + CHLTYPE(CLUSRCVR) CONNAME(ip address of QM2) + CLUSTER (EDUC) DEFINE CHANNEL(TO.QM1) + CHLTYPE(CLUSSDR) CONNAME(ip address of QM1) + CLUSTER (EDUC) * 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
AW: MQ structures
Erik, there is not much to add to bobbee's mail, maybe some suggestions you should think about.. - leave your hands of the dlq, leave it to mq. create your own if you need one. - use separate pagesets for things that can fill up. if you have an outtage a pageset may fill up and harm other applications that share this pageset. in detail, separate dlq, xmitqs, applicationqueues, backoutqueues, heavy batch load, fast online applications within pagesets (and buffer pools for performance issues) if possible. - have a csqutil copy-q-to-file jobs ready in case a queue runs full. at least these messages do not get processed, but you can free space in an emergency and you can copy these messages back when the application is ready to process data again (watch out, some applications rely on message sequence). - dont use mq as a database (collect data over a long period of time until processing) - use monitoring to get alerts soon [.] regards stefan -Ursprungliche Nachricht- Von: Robert Broderick [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 4. Februar 2003 14:21 An: [EMAIL PROTECTED] Betreff: Re: MQ structures When I first read "structures" I thought of the MQMD, MQOD, etc. But then read the DLQ item. Usually you would have some monitoring software, home grown or after market, that monitors your signifigant queues for threshold abuse. When that happens alarms shoudl start to fire and the rescue team should come in and find out what is wrong with the consuming application. NOW, being anygodd at architecture, one should design the storage requirements to allow for certain sizing constraints. What that is? Ther is no set hardfast rule. Some people do the "Daily volume * 2 + 30%" Others do "Daily volume * 30% + 10% per year expected volume increase for 3 years" It is up to you. BUTyou should at least allow yourself enoung room to cover a 1-1/2 day outtage in production. Ther may be other considerations. I'm sure your about to get them from the others in a minute. bobbee >From: "Dijkerman, E (Erik)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: MQ structures >Date: Tue, 4 Feb 2003 12:36:52 +0100 > >Dear Listeners, > >I would like to know how you deal with your MQ-structures and how you >protect yourself from over-filling them. >Do you use the DLQ as a backup or do you have another trick?? >Hope to hear from you. > >Regards, >Erik Dijkerman X >Rabobank ICT/Serverbedrijf >PIM/OS390 ZL-S206400 >Mailbox 17100, 3500 HG Utrecht >*(030) 215 4878 >*(030) 215 3085 > > >? [EMAIL PROTECTED] > > > >"The greatest amount of wasted time is the time not getting started." > >- Dawson Trotman > > > > > > > >De informatie opgenomen in dit bericht kan vertrouwelijk zijn en >is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht >onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en >de afzender direct te informeren door het bericht te retourneren. > >The information contained in this message may be confidential >and is intended to be exclusively for the addressee. Should you >receive this message unintentionally, please do not use the contents >herein and notify the sender immediately by return e-mail. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Triggering anomaly update
Kevin, i think Morag already gave you the answer, i also think the queue is still open thats why trigger first does not fire. The Apar you refer to is related to shared queues, this means queues that are placed in the coupling facility. "sharing" a queue by using mqseries clustering between mq on os/390 and mq on windows nt is a completely different issue and maybe a bad verbalisation in this case... in a mq cluster you get information about a queue and how to put data into the queue by making your queuemanager member of the cluster and by accessing repository information. but you do not share a queue. please let us know if the triggering issue is solved... regards stefan -Ursprungliche Nachricht- Von: Kevin Ferguson [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 29. Januar 2003 17:24 An: [EMAIL PROTECTED] Betreff: Triggering anomaly update Folks Looks like this is a known problem I have found a fix (UQ72551) (APAR PQ67053). Kevin Ferguson _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Wish list for Conference (multiple ckti)
afaik you still need a terminal to run the task that starts
ckti.
here is a way you could set up multiple ckti transaktions with
automatic restart (only the "default" CKTI is restartet when
CICS disconnects / reconnects from/to MQ).
i wrote a xephon article for it which got published
at the end of 2002 so you may find it there too...
setup a console with the cics stc userid (or whatever userid you
prefer)
transaction A starts transaktion B on the console. transaction
B reads a namelist holding INITQ names and starts as many ckti
as required.
this can either be used manually or by operation automation tools
or whatever exists in your environment.
one way to make it happen automatically is to use ckti to trigger
this procedure.
so have a "default" ckti/initq in your cics system
define a local queue ("control"), put in a persistent message, trigger
first,
"default" initq, process A (transaction a)
whenever the default ckti becomes active (cics start, adapter
reconnect, ...) the default initq is opened. because of this the
"control" queue gets triggered and transaction A is started,
this will start transaction B at the specified console, and
B will start the CKTI transactions.
so you have automatic start and restart, you can add / remove
initqs during cics run without restart by editing the
namelist and force a trigger manually
just one way to accomplish multiple ckti.
regards
stefan
-Ursprüngliche Nachricht-
Von: Miller, Dennis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 28. Januar 2003 21:20
An: [EMAIL PROTECTED]
Betreff: Re: Wish list for Conference
Just an idea...I don't have it working. I thought IBM lifted the restriction
on termid in CICS V3 or V4. I know you have to setup surrogate authorities
differently if there is no termid, but I didn't think it was a show stopper.
> -Original Message-
> From: Bullock, Rebecca (CSC) [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 11:59 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Wish list for Conference
>
> Thanks, Dennis. Actually, I think I played around with this and finally
gave
> up. It wasn't as easy as I thought it would be. As I remember (and it's
hazy
> since it was a long while back), the problem was that there's no terminal
> facility to tie the userid to. But thanks for suggesting it. (Or did you
> have a working model?)
>
> -Original Message-
> From: Miller, Dennis [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 2:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Wish list for Conference
>
>
> > Sure would be nice to be able to easily restart the CICS trigger monitor
> > and end up with the address space userid, the same as you get when it's
> > started from the PLT.
>
> Doesn't seem like much of a stretch to write a small program to accomplish
> that.
>
>
> Something like:
>
> EXEC CICS ASSIGN STARTCODE(MYSTART) END EXEC
>
> IF MYSTART NOT EQUAL "SD"
>MOVE 'CKQC STARTCKTI' TO mydata (or build CKQC commarea
> from input source)
>EXEC CICS START(EIBTRNID) FROM (mydata ) USERID(myuserid) END-EXEC
>EXEC CICS RETURN END-EXEC
> END IF
>
> EXEC CICS RETRIEVE INTO(mydata) END EXEC
> EXEC CICS LINK PROGRAM('CSQCSSQ ') INPUTMSG(mydata)
> EXEC CICS RETURN END-EXEC
>
>
>
>
> > -Original Message-
> > From: Bullock, Rebecca (CSC) [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 28, 2003 9:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Wish list for Conference
> >
> > Well, of course, some of us won't get to go to the conference :-( so I
> guess
> > the choice is to put 'em here. Here's a list I came up with...
> >
> > 1) I'd like to strongly second an earlier wish to have Java clients
> support
> > channel tables. I need this and I need it badly.
> >
> > 2) Also a Java thing. First, understand I'm not a Java programmer, but
the
> > impression I've gotten from reading others' postings (and I may be wrong
> > here) is that if you're using the Java client, you must specify the
userid
> > and that Java won't pick up the userid from the task issuing the MQ
calls.
> > OK, if it's possible within the constructs and constraints of the
> language,
> > please make a change so that the userid is picked up from the task's
> userid
> > automatically, similar to the situation with the regular C client on an
NT
> > box.
> >
> > 3) I think many of us have seen the problem of not being able to start a
> > channel when there are duplicates in the channel SYNCQ. The fix is to
get
> a
> > utility from IBM (CSQ4SYNC on OS/390 and I'd guess there's something
> similar
> > on the distributed qmgrs). It would be nice if that utility were
> distributed
> > as part of the product. And, after all, what harm is there? If it's not
> the
> > problem and there are no duplicates, nothing will be deleted.
> >
> > 4) Sure would be nice to be able to easily restart the CICS trigger
> monitor
> > and end up with the address space userid, the same a
AW: AW: Help needed regarding Deadletter queue
Vinay, if you do not want to spend time to install supportpacs (like MO71) then the fastes way to check why the messages are on the dead letter queue is to use the IBM supplied browse sample program amqsbcg: /usr/mqm/samp/bin/amqsbcg SYSTEM.DEAD.LETTER.QUEUE YOURQMGR > dlq.browse the dlq.browse then looks like this: AMQSBCG0 - starts here ** MQOPEN - 'SYSTEM.DEAD.LETTER.QUEUE' MQGET of message number 1 Message descriptor StrucId : 'MD ' Version : 2 Report : 0 MsgType : 8 Expiry : -1 Feedback : 0 Encoding : 273 CodedCharSetId : 819 Format : 'MQDEAD ' Priority : 0 Persistence : 0 MsgId : X'414D51204D5141444D494E3420202020C713033E12F0' CorrelId : X'' BackoutCount : 0 ReplyToQ : '' ReplyToQMgr: '' ** Identity Context UserIdentifier : '*** ' AccountingToken : X'16010515009F3C2D05AC5FFA16ED7C36243D3C0B' ApplIdentityData : '' ** Origin Context PutApplType: '11' PutApplName: 'MQSeries\pgm\bin\amqsput.exe' PutDate : '20030109'PutTime : '08580248' ApplOriginData : '' GroupId : X'' MsgSeqNumber : '1' Offset : '0' MsgFlags : '0' OriginalLength : '-1' Message length - 184 bytes : 444C 4820 0001 0825 4153 4446 'DLH ...%ASDF' 0010: 3220 2020 2020 2020 2020 2020 2020 2020 '2 ' 0020: 2020 2020 2020 2020 2020 2020 2020 2020 '' 0030: 2020 2020 2020 2020 2020 2020 '' 0040: 2020 2020 2020 2020 2020 2020 '*** ' 0050: 2020 2020 2020 2020 2020 2020 2020 2020 '' 0060: 2020 2020 2020 2020 2020 2020 0222 '..."' 0070: 0352 4D51 5354 5220 2020 0006 '...RMQSTR ' 0080: 616D 7163 7273 7461 5F6E 6420 2020 2020 'amqcrsta_nd ' 0090: 2020 2020 2020 2020 2020 2020 3230 3033 '2003' 00A0: 3031 3039 3038 3536 3236 3937 6173 6466 '010908562697asdf' 00B0: 6173 6466 6173 6466 'asdfasdf' in the message dump you can see the "DLH" identifying the dead letter header, now check from byte 9 to 12 - the value is 0825 (hex) which is 2085 dezimal Now you can check API Return and Reason Codes in the "messages and Codes" manual or use "mqrc 2085" which should return 2085 0x0825 MQRC_UNKNOWN_OBJECT_NAME In this case you also see the Object name that is missing (ASDF). Because of our security policies i had to wipe out some fields like user ids and queuemanager names. Hope that helps Stefan -Ursprüngliche Nachricht- Von: vinay_tiwari [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 9. Januar 2003 06:00 An: [EMAIL PROTECTED] Betreff: Re: AW: Help needed regarding Deadletter queue Sorry for not specifying the environment. The environment is UNIX and MQSeries version 5.2. TIA. Vinay -Original Message- From: Raabe, Stefan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 4:34 PM To: [EMAIL PROTECTED] Subject: AW: Help needed regarding Deadletter queue Hello unfortunately you dont tell us what platform you are on (win/nt, unix, os/390, ...), there are different tools for each platform available to browse a queue. if mq puts a message to the dlq a dlh (dead letter headder) is added. the structure is described in the application programmers reference (MQDLH), the reason is at bytes 9 -12. So browse the queue, check for "DLH" as the start of the dead letter header. In the sample below you will see reason code 07F3 hex -> 2035 decimal "not authorized" (check with api reason codes in messages and codes manual). DLH ...3 CDC4000F 43810073 If you do not know how to browse the DLQ please tell us what platform you are on. For OS/390, there are ispf utilities available containing a DLQ utility (MA10 on IBM supportpac page). Other Tools (MQ Explorer, MO71) are available depending what platform you are using. Regards Stefan -Ursprüngliche Nachricht- Von: vinay_tiwari [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 8. Januar 2003 11:28 An: [EMAIL PROTECTED] Betreff: Help needed regarding Deadletter queue On my queue manager messages are piling up in the dead letter queue.Is there a way to browse these messages and findout the
AW: Help needed regarding Deadletter queue
Hello unfortunately you dont tell us what platform you are on (win/nt, unix, os/390, ...), there are different tools for each platform available to browse a queue. if mq puts a message to the dlq a dlh (dead letter headder) is added. the structure is described in the application programmers reference (MQDLH), the reason is at bytes 9 -12. So browse the queue, check for "DLH" as the start of the dead letter header. In the sample below you will see reason code 07F3 hex -> 2035 decimal "not authorized" (check with api reason codes in messages and codes manual). DLH ...3 CDC4000F 43810073 If you do not know how to browse the DLQ please tell us what platform you are on. For OS/390, there are ispf utilities available containing a DLQ utility (MA10 on IBM supportpac page). Other Tools (MQ Explorer, MO71) are available depending what platform you are using. Regards Stefan -Ursprüngliche Nachricht- Von: vinay_tiwari [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 8. Januar 2003 11:28 An: [EMAIL PROTECTED] Betreff: Help needed regarding Deadletter queue On my queue manager messages are piling up in the dead letter queue.Is there a way to browse these messages and findout the reason. TIA. Vinay 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
AW: No Subject
hey, we are computer technicians... why does nobody uses .. cancel -Ursprüngliche Nachricht- Von: Tryggve Johannesson [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 8. Januar 2003 11:14 An: [EMAIL PROTECTED] Betreff: Re: No Subject desist On Tue, 2003-01-07 at 19:55, Dawson, John wrote: > cease > > > -Original Message- > From: Saar, Andrew [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 07, 2003 12:36 PM > To: [EMAIL PROTECTED] > Subject: > > halt > > -Original Message- > From: Robert Broderick [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 07, 2003 1:11 PM > To: [EMAIL PROTECTED] > Subject: > > > stop > > > > > > > >From: COHEN David <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Date: Tue, 7 Jan 2003 18:31:50 +0100 > > > >quit > > > >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 > > > _ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > 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 -- - SchlumbergerSema AB Ebbe Lieberaths gatan 10-12 412 97 GÖTEBORG Mobil +46-708-51 44 59 Tel +46-31-751 44 59 (Q 46 00) Fax +46-31-751 47 74 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
AW: log 'problem', MQ5.2, MQSI on AIX
Stefan, I do not really know if this is by error or - as you described - caused by application design. Beside of any APAR you may increase the number of logs by changing the mqs.ini file located at /var/mqm/qmgrs/YOURQMGR/mqs.ini and add the LogPrimaryFiles (up to 62) and LogSecondaryFiles (up to 61) keywords as described in the System Administration Guide. Example: [.] Log: LogPrimaryFiles=62 LogSecondaryFiles=61 LogFilePages=1024 LogType=CIRCULAR LogBufferPages=17 [..] The queuemanager has to be restarted after that. Do not expect the logs to be created immediately, they are created when needed. Hope that helps. Regards Stefan -Ursprungliche Nachricht- Von: Stefan Sievert [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 6. Januar 2003 22:48 An: [EMAIL PROTECTED] Betreff: log 'problem', MQ5.2, MQSI on AIX Hello and a Happy New Year to everyone! We are running MQ5.2 and the current MQSI version on AIX and have encountered the following message twice in the last couple of weeks: AMQ7469: Transactions rolled back to release log space The queue manager uses circular logging and when the message occurs, primary and secondary log space is exhausted. The problem is resolved only by restarting the queue manager. I am not exactly sure about what CSD levels we are on, but I can find out. Now, this can be caused by any of our subscriber applications not doing frequent commits (we don't know yet), by an MQSI message flow or by a bug in MQ/MQSI. We are still investigating the exact message/UOW that keeps the queue manager from releasing log space. The question I have is: I think I have recently seen a posting on the listserver that described a similar situation, which was fixed by applying an APAR fix. I can't find it in the archives or my memory may play tricks on me so I was hoping that someone has a better memory. Does the above error situation ring anybody's bell and can somebody point me in the right direction if it actually is a known problem with MQSI? As I said, we are investgating other potential causes and we are in touch with IBM, so far to no avail. Any help is greatly appreciated. TIA, Stefan _ The new MSN 8 is here: Try it free* for 2 months http://join.msn.com/?page=dept/dialup 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
AW: Triggering when CKTI comes up
No :-) After CKTI startup there is an immediate trigger as explained by others some messages before trigger interval works different. its not a time interval after that queues are scanned if they should be triggered again, its a time interval that has to be expirered after the last trigger message was generated and a new message that is put to the queue. read system application programmers guide for details. regards stefan -Ursprüngliche Nachricht- Von: Chan, Ian M [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 26. November 2002 01:45 An: [EMAIL PROTECTED] Betreff: Re: Triggering when CKTI comes up I think it also depends on the trigger interval. Once the CKTI is up and running, the trigger message will be generated within the trigger interval period. Ian -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 26 November 2002 8:02 AM To: [EMAIL PROTECTED] Subject: Re: Triggering when CKTI comes up One of the times that the QM checks to see if a trigger message should be generated is when the INIT queue IPROCS count goes from 0 to 1. I would think that when CKT1 is brought up, it opens the INIT queue, and if no other app had the init queue open, the IPROCS would then go from 0 to 1. The queue manager would check to see if any queues meet trigger criteria, and would see that your triggered on first queue had more than zero messages on it, and would thus trigger. I tested this behaviour on distributed and it does exactly that. Don't know if CICS would be different. The triggering manual doesn't say so. http://publibfp.boulder.ibm.com/epubs/html/csqzal06/csqzal06tfrm.htm Chapter 14, Section 13.D Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: MCSHEFFREY, MICHELLE (AIT) [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 3:38 PM To: [EMAIL PROTECTED] Subject: Triggering when CKTI comes up If there are messages on a queue that is set to trigger a CICS transaction on FIRST, and the CICS region is down, will a trigger message be generated when the CICS region and CKTI trigger monitor first come up? I thought yes, but IBM support just told me no. I don't want to spend a lot of time looking at the wrong problem (we're getting a trigger when CICS comes up in production but not in test), so please someone tell me which is correct. Thanks. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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
AW: Cluster Question (remote defs in overlapping clusters)
Peter, i get a little bit confused by the mix of your remotequeues and qmgr aliases, and the setup you described in this mail sounds different from the setup you described before, but both setups look like a "works as designed" to me. see my comments (>>) below. regards stefan -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 22. November 2002 23:44 An: [EMAIL PROTECTED] Betreff: Re: Cluster Question (remote defs in overlapping clusters) I deleted the QM Alias on QMB. The set up is as follows now: *** QMA and QMB are in ClusterAB. QMA has a remote queue def called RequestQueue (RemoteQName=RequestQueue, RemoteQMname=QM1, XMITQ= blank) QM1 and QM2 are in Cluster12. Each has a local queue called RequestQueue, and each one is clustered under Cluster12. ClusterAB and Cluster 12 overlap. QMB is in both. * If I put messages to the remote queue def on QMA, they all go to QM1. Cool. >> why? because there is a REMOTEQ(QM1) RNAME() RQMNAME(QM1) XMITQ(QM1.XMIT) CLUSTER(CLUSTERAB) >> defined on QMB. Thats correct. If I change the properties of the remote queue def to be (RemoteQName=RequestQueue, RemoteQMname=QM2, XMITQ= blank), they all go to QM2. >> no. this cant be true. i get a 2087 because QMA does not know about QM2 >> QMA asks QMB (if this one is repository) "do you know something with the >> name QM2 in cluster CLUSTERAB"? and QMB says "no" (he only knows QM2 as >> a member of CLUSTER12). >> if you created a QMGR Alias named QM2 on QMB like you did for QM1 >> then this will work the same way it worked with QM1. if you did not >> create that alias for QM2 then there is more in CLUSTERAB that you >> think it is. (sounds linke QM2 is member of CLUSTERAB too). If I delete the remote queue def on QMA, and recreate it on QMB, the messages round robin. That I cant figure out. Why doesn't the RemoteQMname parameter in the remote queue def hold it to one QM like it did when the remote def was on QMA? >> how exactly does this remoteq looks like? >> my tests are (all definitions on QMB): >> rq(RequestQueue) rname(RequestQueue) rqmname(QM1) CLUSTER(CLUSTERAB) >> --> will route to QM1 >> rq(RequestQueue) rname(RequestQueue) rqmname(QM2) CLUSTER(CLUSTERAB) >> --> will route to QM2 >> rq(RequestQueue) rname(RequestQueue) rqmname(QMB) CLUSTER(CLUSTERAB) >> --> will route to DLQ on QMB >> rq(RequestQueue) rname(RequestQueue) rqmname() CLUSTER(CLUSTERAB) >> --> will route to DLQ on QMB Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Raabe, Stefan [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 4:41 AM To: [EMAIL PROTECTED] Subject: AW: Cluster Question (remote defs in overlapping clusters) Peter, i rebuilt the situation and it worked fine here. (all queuemanagers on win/nt version 5.2) messages are sent from QMA to QMB using TO.QMB clustersenderchannel, and then from QMB to QM1 using QM1.XMIT and QMB.TO.QM1 senderchannel. I tried to create the error by applying some changes to the QM1 QmgrAlias on QMB but no gain. If doing bad things here, messages are put to QMB dead letter queue. Its hard to guess why. Maybe - you did a definition error somehow (most likely on QMB, because if QMA is not member of CLUSTER12 it is only up to QMB to do the round-robin distribution. if the messages really flow from QMA to QMB first, then QMB msut think that they are destined for QMB and not for QM1). check all definitions if they exaclty match what you described. - does QMA knows about the RequestQueue Cluster entries? does QMA knows about Clusterqueuemanagers QM1 and QM2? - maybe a cluster error (what version are you running?) - verify the channel status after sending messages to check which way the messages took (QMA to QM1/2 directly or via QMB) - maybe the application is running with QMB instead of QMA? - maybe all of the above is nonsense :-) regards stefan -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 21. November 2002 23:19 An: [EMAIL PROTECTED] Betreff: Cluster Question (remote defs in overlapping clusters) Man, what a mess. Try and draw this one 1st before attempting to solve it! QMA and QMB are in ClusterAB. QMA has a remote queue def called RequestQueue (RemoteQName=RequestQueue, RemoteQMname=QM1, XMITQ= blank) QM1 and QM2 are in Cluster12. Each has a local queue called RequestQueue, and each one is clustered under Cluster12. ClusterAB and Cluster 12 overlap. QMB is in both. There is a QMAlias called QM1 on QMB. QM1 has QM1 as the RemoteQMname, and QM1.XMIT queue as the t
AW: Cluster Question (remote defs in overlapping clusters)
Peter, i rebuilt the situation and it worked fine here. (all queuemanagers on win/nt version 5.2) messages are sent from QMA to QMB using TO.QMB clustersenderchannel, and then from QMB to QM1 using QM1.XMIT and QMB.TO.QM1 senderchannel. I tried to create the error by applying some changes to the QM1 QmgrAlias on QMB but no gain. If doing bad things here, messages are put to QMB dead letter queue. Its hard to guess why. Maybe - you did a definition error somehow (most likely on QMB, because if QMA is not member of CLUSTER12 it is only up to QMB to do the round-robin distribution. if the messages really flow from QMA to QMB first, then QMB msut think that they are destined for QMB and not for QM1). check all definitions if they exaclty match what you described. - does QMA knows about the RequestQueue Cluster entries? does QMA knows about Clusterqueuemanagers QM1 and QM2? - maybe a cluster error (what version are you running?) - verify the channel status after sending messages to check which way the messages took (QMA to QM1/2 directly or via QMB) - maybe the application is running with QMB instead of QMA? - maybe all of the above is nonsense :-) regards stefan -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 21. November 2002 23:19 An: [EMAIL PROTECTED] Betreff: Cluster Question (remote defs in overlapping clusters) Man, what a mess. Try and draw this one 1st before attempting to solve it! QMA and QMB are in ClusterAB. QMA has a remote queue def called RequestQueue (RemoteQName=RequestQueue, RemoteQMname=QM1, XMITQ= blank) QM1 and QM2 are in Cluster12. Each has a local queue called RequestQueue, and each one is clustered under Cluster12. ClusterAB and Cluster 12 overlap. QMB is in both. There is a QMAlias called QM1 on QMB. QM1 has QM1 as the RemoteQMname, and QM1.XMIT queue as the transmit queue. That transmit queue goes directly to QM1. If an App on QMA puts to RequestQueue, wouldn't it's definition cause all the messages to go to QM1, via the QM1 Alias definition on QMB? Instead I see them round robin between QM1 and QM2. Why? Is there anyway the App on QMA can get all of its messages to QM1 consistently (without disabling the queue on QM2)? I thought the QMAlias along with the remote queue def would force that behavior. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Clustering on OS/390
hello, make sure objectqmgrname in the MQOD is empty sounds like it holds the name of your local queuemanager. (some programmers use the same mqod storage for the connect and the open and miss to wipe out the qmgr name after the connect call). hth regards stefan -Ursprungliche Nachricht- Von: Kevin Ferguson [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 22. November 2002 00:20 An: [EMAIL PROTECTED] Betreff: Clustering on OS/390 Please stop me from going mad here. I am trying to PUT a message onto a Cluster Queue from an assembler program. The Queue (call it NT.Queue1) is defined locally on an NT Qmgr and clustered to an MVS QMgr. I can see the queue on MVS using a display of cluster queues. My program connects to the local MVS QMgr OK but when I try to issue the MQOPEN for the queue (NT.Queue1) it coughs with a 2085. What am I missing here? The program works fine on queues locally defined to the MVS Qmgr but fails on the NT queue. Any help appreciated. Kevin Ferguson _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Detecting MQ subsystem shutdown
Hello, why dont you shutdown mq "normal" giving all application that honors the "fail-if-quiescing" the chance to end its work, and, after a given period of time, issue stop qmgr mode(FORCE) to have mq stop/end whats still on the fly? 1. stop qmgr 2. applications currently issuing mq calls (get-wait) get "fail-if-quiescing" (if specified in the option) and end 3. wait 05 minutes 4. stop qmgr mode force 5 applications that do not specify fail-if-quiescing or applications currently not processing mq calls (but still having a connection) will be abended/backed in mq 6. qmgr stops regards stefan -Ursprungliche Nachricht- Von: Miller, Dennis [mailto:DMiller@;SNOPUD.COM] Gesendet: Donnerstag, 14. November 2002 18:34 An: [EMAIL PROTECTED] Betreff: Re: Detecting MQ subsystem shutdown What's the rationale for hanging the qmgr just because there's an app with open connection is not currently in the midst of an API request? I mean, it COULD be a long time before the app needs MQ services. Or it COULD be a long time before the app cooperates and closes the connection. So, it appears we have this: 1. Qmgr shutdown is issued 2. Qmgr hangs because of open connection 3. Application eventually issues an MQ call 4. Call fails with MQ quiescing 5. Application closes connection 6. Qmgr shutsdown When this seems much more sensible: 1. Qmgr shutdown is issued 2. Qmgr abandons the connection and shutsdown 3. Application eventually issues an MQ call 4. Call fails with Qmgr not available I'm with bobee--I still find it funny that the QMGR doesn't just drop the connection! In fact, that should happen even if there is uncommitted work because there is no way to actually commit at that point. > -Original Message- > From: John Scott [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, November 13, 2002 3:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Detecting MQ subsystem shutdown > > >From: Robert Broderick [mailto:robertbroderick@;HOTMAIL.COM] said... > > >I still find it funny that the QMGR doesn't drop the connection if you > don't > >have any uncommited work going on!! > > If he's not got an MQI call in progress (he's doing something else) then > it > won't fail because he's not waiting on MQ which can fail his call. I would > assume the call would fail the next time an MQI call is performed. > > Cos' it's OS/390, I am not to sure how you would get it to stop > immediately > (endmqm -i on distributed) which would get it to stop and leave the > connected app behind to fail on the next MQI call. > > John. > > > ** > > Click here to visit the Argos home page http://www.argos.co.uk > > The information contained in this message or any of its attachments may be > privileged and confidential, and is intended exclusively for the > addressee. > The views expressed may not be official policy, but the personal views of > the originator. > If you are not the intended addressee, any disclosure, reproduction, > distribution, dissemination or use of this communication is not > authorised. > If you have received this message in error, please advise the sender by > using your reply facility in youe e-mail software. > All messages sent and received by Argos Ltd are monitored for virus, high > risk file extensions, and inappropriate content. As a result users should > be aware that mail maybe accessed. > > ** > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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
AW: Shutting down long running GETters on OS/390
Bill, if your job sits on a get-wait, why dont you use the "fail if quiescing" - option to recognize the mq shutdown directly? regards stefan -Ursprüngliche Nachricht- Von: Beinert, William [mailto:BEINERTW@;CONED.COM] Gesendet: Donnerstag, 14. November 2002 20:17 An: [EMAIL PROTECTED] Betreff: Shutting down long running GETters on OS/390 We are just beginning to implement some long running production jobs which wait on a queue. I need a way for our operators to shut down these jobs gracefully. Sending a QUIT REPORT message seems to be the best way, but the issue is operator usability. The operator just knows that job P1234567 is running, not about queues... I'd like for the operator to enter a command like S MQENDJOB,JOB=P1234567. I could create a table that mapped the job name to the queue it is waiting on, so that MQENDJOB could send the quit message to the right queue, but I am concerned about keeping that table current, especially in the test and development environment. Is there a PCF facility that will tell me what queue a job is waiting on? How are other folks handling this process? Bill Beinert Systems Programming Con Edison (212) 460-4853 When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE 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
AW: Repository queue
Hi, there are no (official or known to me) docs that describe the cluster layout or the format of the messages in the repository queue. the supportpac you refer to was written by a mq developer who probably knew about the format (he really should). the mq explorer itself does not manipulate the repository queue, you can issue commands or create definitions using the explorer that result in changes in the repository entries, but thats all. some areas of the repository messages are in "readable" format like queuenames and qmgr names, channel names and so on, but no information about the rest of the bits and bytes that do not only store information about the objects itself but also control information about the cluster, e.g. which objects where distributed to which queuemanager and when and ... and and ... afaik messages get also blocked from time to time (restart or shutdown time ?!? ). so good luck with experimenting... i do not know what you are trying to do with the repository, but i recommend not to "zap" messages in the repository without knowing the internals. if you do, you zap local, but how will the information get distributed to the other queuemanagers? i would rather try to use proper cluster definitions and the known cluster commands to set up what i need or to fix errors. regards stefan -Ursprüngliche Nachricht- Von: Wyatt, T. Rob [mailto:t.rob.wyatt@;BANKOFAMERICA.COM] Gesendet: Donnerstag, 7. November 2002 21:12 An: [EMAIL PROTECTED] Betreff: Repository queue Are there any docs (official or otherwise) for the Repository Queue message formats? The cluster utilities pack seems to manipulate these queues directly, as does MQ Explorer. Various people on the list have also mentioned direct manipulation of these messages for cluster management so I'm guessing some of you have already broken ground on this. We have a cluster caged up in our lab and I'd like to perform some experiments on it. Thanks -- T.Rob 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
AW: CSQOREXX in Websphere MQ 5.3 for z/OS
No, panel works fine here. you may check with isrddn whether your file allocations are all to 530 datasets. use pfshow on to check whether pf8 is really "fwd" od the first object type screen (after pressing pf4) regards stefan -Ursprüngliche Nachricht- Von: Dye, Janet E [mailto:Janet.Dye@;UMB.COM] Gesendet: Freitag, 8. November 2002 00:36 An: [EMAIL PROTECTED] Betreff: CSQOREXX in Websphere MQ 5.3 for z/OS We are in the process of installing Websphere MQ 5.3 for z/OS and we faced the following while using IBM Supplied MQ admin Utility (CSQOREXX). Off the MAINMENU, if you hit 'F4', it displays the possible options to enter for 'Object type'. It you hit F8, it should go to the second page of options, but instead, goes back to the MAINMENU. On MQ 5.2, there was only one page of options, but with 5.3, they have split the options into 3 pages, but I can't get past the first page. Has anyone who have installed Websphere MQ for z/OS encountered the same problem. I have searched IBMLINK for any reported issues, but have not found a hit. I would be surprised if we were the only ones experiencing it. Thanks Janet E. Dye Sr. Systems Programmer UMB Mainframe Technical Services email: [EMAIL PROTECTED] voice: 816-860-1109 fax : 816-860-3934 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
AW: Context Security on OS/390 - solved
Hello, the issue is solved, the useridentifier was not specified within the message descriptor. here is the explaination from the problem record: I see from the RACF message that the problem revolves round the Reply Queue receiving the Expired messages. The RACF messages show the Queue Manager Job Name, no Userid is shown which means RACF had been passed a BLANK USERID. SET_ALL_CONTEXT is used to tell MQ that certain MD fields have been pre-set by the caller and they are not to be overriden, this includes the UserIdentifier field. When the message expires and the the Report Options indicate message generation MQ will use the Userid as held in the UserIdentifier field of the Expired messages MD. As this is not being set a blank Userid is passed to RACF hence the error. To remove this error they need to put a valid userid into the UserIdentifier field. thanks to everyone for help, hints and tips regards stefan -Ursprüngliche Nachricht- Von: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Gesendet: Donnerstag, 31. Oktober 2002 15:21 An: [EMAIL PROTECTED] Betreff: AW: Context Security on OS/390 Tim, thanks for the answer, here is the command output: TSO RLIST MQADMIN .CONTEXT AUTHUSER ICH13003I .CONTEXT NOT FOUND, ***, TSO RLIST MQQUEUE .B* AUTHUSER CLASS NAME, - , MQQUEUE.B* (G), GROUP CLASS NAME, - - , GMQQUEUE, , LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING, - --- ---, 00$ZADMIN NONE NONENO, , [some stuff skipped] , , ,USER ACCESS, , --, [some stuff skipped] MSTR UPDATE, I know I do not have a .CONTEXT profile, but - remember - i have ".NO.CONTEXT.CHECKS" so context checking should be off. if i remove the context options in the application program then everything works fine. so it is really a matter of the context options, but no context checking should be performed. in my opinion, this is an error, and i raised a record for it (962, if you are able to see it in dial ibm). regards stefan -Ursprüngliche Nachricht- Von: Tim Clarke [mailto:mqsupport@;NETSCAPE.NET] Gesendet: Donnerstag, 31. Oktober 2002 08:34 An: [EMAIL PROTECTED] Betreff: Re: Context Security on OS/390 Hi Again Stefan, I just realised that you wanted the commands here they are :- TSO RDEFINE MQADMIN .CONTEXT TSO RDEFINE MQQUEUE .B* TSO PERMIT MQADMIN .CONTEXT CLASS(MQADMIN) ID(MSTR) ACCESS(CONTROL) TSO PERMIT MQQUEUE .B* CLASS(MQQUEUE) ID(MSTR) ACCESS(UPDATE) The documentation is in the System Setup Guide for MQSeries for OS/390, Chapter 13. Profiles used to control access to MQSeries resources. Cheers, Tim Clarke, MQSupport Pty. Ltd., Australia. -Original Message----- From: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Sent: Tuesday, October 29, 2002 11:50 PM Subject: AW: Context Security on OS/390 Hello, i do not understand this (sorry, i am not a racf specialist). the job has definitly granted access (alter) to the ressource profile of the queue. and it is also not a matter of "refresh security" i would like to try the hint with the MQADMIN class, but i do not know how to grant alter access to the MQADMIN Class. i can only grant access to a ressource defined in MQADMIN class, but which one? i checked application programmers guide / reference, security documentation etc. that comes with mq but no much information about context security in that case. any other hints or pointers to documentation? regards stefan __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Context Security on OS/390
Tim, thanks for the answer, here is the command output: TSO RLIST MQADMIN .CONTEXT AUTHUSER ICH13003I .CONTEXT NOT FOUND, ***, TSO RLIST MQQUEUE .B* AUTHUSER CLASS NAME, - , MQQUEUE.B* (G), GROUP CLASS NAME, - - , GMQQUEUE, , LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING, - --- ---, 00$ZADMIN NONE NONENO, , [some stuff skipped] , , ,USER ACCESS, , --, [some stuff skipped] MSTR UPDATE, I know I do not have a .CONTEXT profile, but - remember - i have ".NO.CONTEXT.CHECKS" so context checking should be off. if i remove the context options in the application program then everything works fine. so it is really a matter of the context options, but no context checking should be performed. in my opinion, this is an error, and i raised a record for it (962, if you are able to see it in dial ibm). regards stefan -Ursprüngliche Nachricht- Von: Tim Clarke [mailto:mqsupport@;NETSCAPE.NET] Gesendet: Donnerstag, 31. Oktober 2002 08:34 An: [EMAIL PROTECTED] Betreff: Re: Context Security on OS/390 Hi Again Stefan, I just realised that you wanted the commands here they are :- TSO RDEFINE MQADMIN .CONTEXT TSO RDEFINE MQQUEUE .B* TSO PERMIT MQADMIN .CONTEXT CLASS(MQADMIN) ID(MSTR) ACCESS(CONTROL) TSO PERMIT MQQUEUE .B* CLASS(MQQUEUE) ID(MSTR) ACCESS(UPDATE) The documentation is in the System Setup Guide for MQSeries for OS/390, Chapter 13. Profiles used to control access to MQSeries resources. Cheers, Tim Clarke, MQSupport Pty. Ltd., Australia. -Original Message----- From: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Sent: Tuesday, October 29, 2002 11:50 PM Subject: AW: Context Security on OS/390 Hello, i do not understand this (sorry, i am not a racf specialist). the job has definitly granted access (alter) to the ressource profile of the queue. and it is also not a matter of "refresh security" i would like to try the hint with the MQADMIN class, but i do not know how to grant alter access to the MQADMIN Class. i can only grant access to a ressource defined in MQADMIN class, but which one? i checked application programmers guide / reference, security documentation etc. that comes with mq but no much information about context security in that case. any other hints or pointers to documentation? regards stefan __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Queue Name Resolution and Cluster Channel selection
Andrea, this is a design issue. Because the "local" MQSeries knows that the target queue is not local, it does not care for the queuename. it is only interested how to route the message to the target queuemanager. its up to the target queuemanager to look for a "local definition" of the queue. thats the way it works when opening a queue with objectqmgrname specified. (lets assume you have 100 requesters and 1 server application, then this is a big advantage because you do not need remoteq definitions on the server machine for the reply messages and each reply message is routet to the destination the request came from (when xmitq name equals qmgr name ) ) if you define multiple objects to do some workload balancing, all objects should be the same (or almost the same), but channels with conversion and without conversion differ too much to be used for this (ftp and workload) and that (reply messages). anyway, i think the "data" and "trigger" you mentioned in your mail are related to your ftp applications (not the request-reply application), and i do not know exactly how this ftp is designed. there have been a lot of threads related to message order in this group, so you may like to search the archives. at least - when using distributed queueing - a message sequence can only be granted under very very special conditions. and - if in addition - there is workload balancing, it may be harder to assure the message sequence (trigger after data). but thats a different story. good luck with the qmgr alias, let us know if it worked. regards stefan -Ursprüngliche Nachricht- Von: Dorsey, Andrea L. [mailto:dorsey@;TIMKEN.COM] Gesendet: Mittwoch, 30. Oktober 2002 20:40 An: [EMAIL PROTECTED] Betreff: Re: Queue Name Resolution and Cluster Channel selection This makes sense from what I am seeing. But does not make sense from an implementation standpoint for allowing multiple channels between queue managers. If it is going to look at the cluster information to see if this is a cluster queue manager, why not look at the queue name to determine the cluster channel to use? The cluster manual says you can have multiple clusters between platforms to allow work to be balanced between the channels. And this is what I have attempted to do for our file transfers. I need the data and the trigger messages to both use the same cluster channel to make sure the trigger message arrives after all the data is sent. So far, I have not had any cases where the trigger arrived before all the data. I will try your suggestion about the queue manager alias and see if I can get it to select the proper channel. Andrea -Original Message- From: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Sent: Wednesday, October 30, 2002 9:18 AM To: [EMAIL PROTECTED] Subject: AW: Queue Name Resolution and Cluster Channel selection Hello, I think your problem is not primarily related to clustering. In Section "4" you wrote: "OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue." If a queue is opened with queuename and queuemanagername specified in the object descriptor and the local queuemanagername is not equal to the queuemanagername specified in the object descriptor then the queuename is ignored and mqseries looks for "something" that has the same name as the queuemanager specified in the object descriptor. This could be an xmitq, a qmgr alias, and if mq does not find any of these it will look whether this queuemanager is known as a cluster queuemanager. Check with "Name Resolution" in Chapter "opening and closing objects" in Application Programming Guide. In your enviromnent the OS390 application - when putting to the reply queue - uses the queuemanager name, so the queuename is ignored. i assume, there is no xmitq nor a qmgr alias that has the same name as the replytoqmgr field, so mq on os/390 checks the cluster and recognises that the replytoqmgr is known as a cluster queuemanager. any cluster is fine in this situation because the queuename is ignored (and only the queuename holds the cluster CNTRRN that you try to use). its just random (or maybe "first-found" which cluster is picked and in your case a cluster with "convert no" in the proper cluster sender channel is picked. mhhh... how to solve this - the application on os/390 may stop to use the queuemanagername when putting the reply message. then the cluster queue is found during name resolution and the proper cluster channel should be selected. but this should only be used if all reply messages should be routed to the same destination (a matter of your applicaiton design) - use "normal" channels and make sure, that the xmitq name matches the replytoqmgr name and that the putting application uses the replytoqmgr when opening the reply queue - use a "virtual"
AW: CSQC101D can't open the init queue
Hi, have a look at the "display qstatus" command (version 5.2 or higher ?!?) regards Stefam -Ursprüngliche Nachricht-Von: moshe moran [mailto:[EMAIL PROTECTED]]Gesendet: Mittwoch, 30. Oktober 2002 16:07An: [EMAIL PROTECTED]Betreff: CSQC101D can't open the init queue Hi, when I am trying to initiate mq via plt in cics I got the message +CSQC101D SQA4025A CSQCTASK Cannot open the initiation queue. MQCC=2 MQRC=2042+CSQC110I SQA4025A CSQCTASK Queue name = CICS02.INITQ My question is: Is there any mqm command that can show me which applid(connection-id) opened this queue. I tried DIS Q(CICS02.INITQ) and DIS THREADS(*) but I can;t get the answer to my question. It Moist Moran
AW: Queue Name Resolution and Cluster Channel selection
Hello, I think your problem is not primarily related to clustering. In Section "4" you wrote: "OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue." If a queue is opened with queuename and queuemanagername specified in the object descriptor and the local queuemanagername is not equal to the queuemanagername specified in the object descriptor then the queuename is ignored and mqseries looks for "something" that has the same name as the queuemanager specified in the object descriptor. This could be an xmitq, a qmgr alias, and if mq does not find any of these it will look whether this queuemanager is known as a cluster queuemanager. Check with "Name Resolution" in Chapter "opening and closing objects" in Application Programming Guide. In your enviromnent the OS390 application - when putting to the reply queue - uses the queuemanager name, so the queuename is ignored. i assume, there is no xmitq nor a qmgr alias that has the same name as the replytoqmgr field, so mq on os/390 checks the cluster and recognises that the replytoqmgr is known as a cluster queuemanager. any cluster is fine in this situation because the queuename is ignored (and only the queuename holds the cluster CNTRRN that you try to use). its just random (or maybe "first-found" which cluster is picked and in your case a cluster with "convert no" in the proper cluster sender channel is picked. mhhh... how to solve this - the application on os/390 may stop to use the queuemanagername when putting the reply message. then the cluster queue is found during name resolution and the proper cluster channel should be selected. but this should only be used if all reply messages should be routed to the same destination (a matter of your applicaiton design) - use "normal" channels and make sure, that the xmitq name matches the replytoqmgr name and that the putting application uses the replytoqmgr when opening the reply queue - use a "virtual" replytoqmgr and define a qmgr alias in the proper cluster on the hpux machine so this virtual queuemanager is only found in a specific cluster. resolve the queuemanageralias to the local queuemanager on the hpux machine. maybe other thinks will work too, but i once read that - when there are multiple connections (channels) defined between two queuemanagers - it is sometimes not predictable which route a message will take. but i do not remember the exact context for this except that clustering was also a part of it. hope that helps, please let us know how you solved this issue. regards stefan -Ursprüngliche Nachricht- Von: Dorsey, Andrea L. [mailto:dorsey@;TIMKEN.COM] Gesendet: Dienstag, 29. Oktober 2002 23:55 An: [EMAIL PROTECTED] Betreff: Queue Name Resolution and Cluster Channel selection Background: 1) We are running MQS 2.1 on OS390 and MQS 5.2 on HP-UX. Between these two queue managers, we have defined multiple clusters, each with cluster channel-pairs. This is done to separate work - we use MQSeries for many file transfer functions and for request/reply and do not want the data intermixed or one channel pair overloaded. 2) Queue REQUEST is defined as local on OS390 in cluster CANTONRR. Queue REPLY is defined as local on HP-UX in cluster CANTONRRN. Cluster channel TO.HPUX.CNTRRN is the cluster sender for cluster CANTONRRN and had CONVERT BY SENDER equal to N. 3) OS390 program to send the REPLY message includes logic to build the MQMDE, including moving the MQMD Format to the MQMDE Format and setting the MQMD Format to indicate MQFMT_MD_EXTENSION. Because MQMDE is not supported by OS390 MQSeries Channel Init, message must be sent on a channel with CONVERT BY SENDER equal to N. 4) OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue. This should resolve the queue definition to the cluster queue and use cluster CANTONRRN. For some reason, the REPLY message is trying to be sent using one of the other cluster sender channels to the HP-UX server. Since they have CONVERT BY SENDER = Y, Channel Init is sending the message to the local dead letter queue on OS390 for error code MQRC_FORMAT_ERROR. Why would the message not be sent using the cluster queue definition and related cluster channel? Is there any buffering of MQSeries information by the CICS regions which would prevent it from picking up changes made to the queue definition - even when I converted the REPLY queue to a remote definition on OS390, with related sender channel, MQSeries Channel Init still tried to use one of the cluster channels. Any ideas or explanations would be greatly appreciated, Andrea Dorsey MQSeries Support ** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communi
AW: Context Security on OS/390
Hello, i do not understand this (sorry, i am not a racf specialist). the job has definitly granted access (alter) to the ressource profile of the queue. and it is also not a matter of "refresh security" i would like to try the hint with the MQADMIN class, but i do not know how to grant alter access to the MQADMIN Class. i can only grant access to a ressource defined in MQADMIN class, but which one? i checked application programmers guide / reference, security documentation etc. that comes with mq but no much information about context security in that case. any other hints or pointers to documentation? regards stefan -Ursprüngliche Nachricht- Von: Miller, Dennis [mailto:DMiller@;SNOPUD.COM] Gesendet: Montag, 28. Oktober 2002 16:53 An: [EMAIL PROTECTED] Betreff: Re: Context Security on OS/390 According to the error message you posted, that's not the case: > ICH408I,JOB(MSTR) STEP(MSTR) >.B.EXPIRY CL(MQQUEUE ) >INSUFFICIENT ACCESS AUTHORITY >FROM .B* (G) > ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) means that you need UPDATE access, but have NO access. I'm guessing that you have granted ALTER access in the ADMIN class. You also need to grant UPDATE in the MQQUEUE class. > -----Original Message- > From: Raabe, Stefan [SMTP:[EMAIL PROTECTED]] > Sent: Monday, October 28, 2002 3:45 AM > To: [EMAIL PROTECTED] > Subject: AW: Context Security on OS/390 > > Dennis, > > thanks for the anser. > > the stc (the user) has ALTER to MQF1.B* profile. > > any other ideas? > > regards > stefan > > > -Ursprungliche Nachricht- > Von: Miller, Dennis [mailto:DMiller@;SNOPUD.COM] > Gesendet: Donnerstag, 24. Oktober 2002 21:55 > An: [EMAIL PROTECTED] > Betreff: Re: Context Security on OS/390 > > > Context security exists in both the MQADMIN and MQQUEUE classes. The > MQADMIN > class controls whether you're allowed to save/set/pass the context > information and applies across all queues. The MQQUEUE class is > queue-specific and controls what context options are allowed on the open. > > PMO-SET-ALL-CONTEXT is subject the the MQQUEUE class, therefore, I do not > believe you can turn it off with sssi.NO.CONTEXT.CHECKS. > > In your case, I believe the error occurs when the qmgr attempts to open > the > replytoq for the expiry report message. It wants to pass context to the > report message. > > I think your stc needs update authority to MQF1.B* profile in the MQQUEUE > class > > > > -Original Message- > > From: Raabe, Stefan [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, October 24, 2002 5:40 AM > > To: [EMAIL PROTECTED] > > Subject: Context Security on OS/390 > > > > Hello Group, > > > > I only have very little experience with context security, > > so I hope someone of you can put some light on this one. > > > > Here is the saga: > > > > There is an application that puts messages to a queue > > with these options: > > > > MQRO-EXPIRATION-WITH-FULL-DATA in MQMD-REPORT > > MQFMT-STRING in MQMD-FORMAT > > 10 in MQMD-EXPIRY > > "B.EXPIRY" in MQMD-REPLYTOQ > > "qmgrname" in MQMD-REPLYTOQMGR > > MQPMO-SET-ALL-CONTEXT > > > > Messages are put to Queue A, and if they expire and are > > removed during get/browse operation a report message with full > > data will be put to queue B.EXPIRY. Queues A and B.EXPIRY > > reside on the same Queuemanager. > > > > This works fine on a queuemanager with "NO.SUBSYS.SECURITY" > > profile defined. > > > > It does not work on a queuemanager that has queue security ON and > > context security OFF even though the queuemanager (the stc userid) > > has proper security defined to put messages on queue B.EXPIRY. > > The MSTR joblog shows this error: > > > > ICH408I,JOB(MSTR) STEP(MSTR) > >.B.EXPIRY CL(MQQUEUE ) > >INSUFFICIENT ACCESS AUTHORITY > >FROM .B* (G) > > ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) > > > > and messages are put to the DLQ with reason 2035. > > > > The RACF group the MSTR user is assigned to > > has ALTER access to MQF1.B* profile. > > The userid is equal to the jobname (MSTR). > > > > If I remove the PMO-SET-ALL-CONTEXT within the application program > > and try again, it works. > > > > So I think it is a matter of the context information in the message, > > but context security is OFF for this queuemanager. So I would > > expect it to work anyway. > > > > what am I missing here? > > What security definitions do I ne
AW: Context Security on OS/390
Dennis, thanks for the anser. the stc (the user) has ALTER to MQF1.B* profile. any other ideas? regards stefan -Ursprungliche Nachricht- Von: Miller, Dennis [mailto:DMiller@;SNOPUD.COM] Gesendet: Donnerstag, 24. Oktober 2002 21:55 An: [EMAIL PROTECTED] Betreff: Re: Context Security on OS/390 Context security exists in both the MQADMIN and MQQUEUE classes. The MQADMIN class controls whether you're allowed to save/set/pass the context information and applies across all queues. The MQQUEUE class is queue-specific and controls what context options are allowed on the open. PMO-SET-ALL-CONTEXT is subject the the MQQUEUE class, therefore, I do not believe you can turn it off with sssi.NO.CONTEXT.CHECKS. In your case, I believe the error occurs when the qmgr attempts to open the replytoq for the expiry report message. It wants to pass context to the report message. I think your stc needs update authority to MQF1.B* profile in the MQQUEUE class > -Original Message- > From: Raabe, Stefan [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, October 24, 2002 5:40 AM > To: [EMAIL PROTECTED] > Subject: Context Security on OS/390 > > Hello Group, > > I only have very little experience with context security, > so I hope someone of you can put some light on this one. > > Here is the saga: > > There is an application that puts messages to a queue > with these options: > > MQRO-EXPIRATION-WITH-FULL-DATA in MQMD-REPORT > MQFMT-STRING in MQMD-FORMAT > 10 in MQMD-EXPIRY > "B.EXPIRY" in MQMD-REPLYTOQ > "qmgrname" in MQMD-REPLYTOQMGR > MQPMO-SET-ALL-CONTEXT > > Messages are put to Queue A, and if they expire and are > removed during get/browse operation a report message with full > data will be put to queue B.EXPIRY. Queues A and B.EXPIRY > reside on the same Queuemanager. > > This works fine on a queuemanager with "NO.SUBSYS.SECURITY" > profile defined. > > It does not work on a queuemanager that has queue security ON and > context security OFF even though the queuemanager (the stc userid) > has proper security defined to put messages on queue B.EXPIRY. > The MSTR joblog shows this error: > > ICH408I,JOB(MSTR) STEP(MSTR) >.B.EXPIRY CL(MQQUEUE ) >INSUFFICIENT ACCESS AUTHORITY >FROM .B* (G) > ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) > > and messages are put to the DLQ with reason 2035. > > The RACF group the MSTR user is assigned to > has ALTER access to MQF1.B* profile. > The userid is equal to the jobname (MSTR). > > If I remove the PMO-SET-ALL-CONTEXT within the application program > and try again, it works. > > So I think it is a matter of the context information in the message, > but context security is OFF for this queuemanager. So I would > expect it to work anyway. > > what am I missing here? > What security definitions do I need to make it work? > Is there a difference between the JOB(MSTR) and > the the USER(MSTR) in this "context"? > > Regards > > Stefan > > 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
Context Security on OS/390
Hello Group, I only have very little experience with context security, so I hope someone of you can put some light on this one. Here is the saga: There is an application that puts messages to a queue with these options: MQRO-EXPIRATION-WITH-FULL-DATA in MQMD-REPORT MQFMT-STRING in MQMD-FORMAT 10 in MQMD-EXPIRY "B.EXPIRY" in MQMD-REPLYTOQ "qmgrname" in MQMD-REPLYTOQMGR MQPMO-SET-ALL-CONTEXT Messages are put to Queue A, and if they expire and are removed during get/browse operation a report message with full data will be put to queue B.EXPIRY. Queues A and B.EXPIRY reside on the same Queuemanager. This works fine on a queuemanager with "NO.SUBSYS.SECURITY" profile defined. It does not work on a queuemanager that has queue security ON and context security OFF even though the queuemanager (the stc userid) has proper security defined to put messages on queue B.EXPIRY. The MSTR joblog shows this error: ICH408I,JOB(MSTR) STEP(MSTR) .B.EXPIRY CL(MQQUEUE ) INSUFFICIENT ACCESS AUTHORITY FROM .B* (G) ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) and messages are put to the DLQ with reason 2035. The RACF group the MSTR user is assigned to has ALTER access to MQF1.B* profile. The userid is equal to the jobname (MSTR). If I remove the PMO-SET-ALL-CONTEXT within the application program and try again, it works. So I think it is a matter of the context information in the message, but context security is OFF for this queuemanager. So I would expect it to work anyway. what am I missing here? What security definitions do I need to make it work? Is there a difference between the JOB(MSTR) and the the USER(MSTR) in this "context"? Regards Stefan 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: AW: AW: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conna me] inst ead of Rep QMGR
Well, then its up to IBM i think. Regared Stefan -Ursprungliche Nachricht- Von: Yonny Serrano [mailto:YSerrano@;GBM.NET] Gesendet: Donnerstag, 17. Oktober 2002 15:43 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] inst ead of Rep QMGR Stefan, Follows an explanation about QMPROENG and QMTRACE. I have normal sender and reciever channels between MQSI2 and QMPROENG, in fact I had to define remote queues and xmit queues to implement a temporary solution that allow applications to return to production. I had not done any more changes on QMPROENG since monday. The two repositories of the cluster are MQSI1 and MQSI2. IBM asked me for a trace (of the join cluster procedure) so I didnt try to rejoin QMPROENG and created a new (test) qmgr QMTRACE, generated the trace and sent it to IBM. There are no clues in the log files, and we dont have security exits. Yonny R. Serrano Stefan.Raabe@D REGIS.COMTo: [EMAIL PROTECTED] Sent by: cc: MQSERIES@AKH-W Subject: AW: AW: AW: QMGR cannot join a cluster, ien.AC.AT SYSTEM.TEMPQMGR[conname] inst ead of Rep QMGR 17/10/2002 04:23 a.m. Please respond to MQSERIES mhhh, i do not find any configuration mistakes or typing-errors... so... what now. what i would do is to define normal sender / receiver channel between MQTRACE and MQSI2 (both directions) to make sure that the connection itself is working. it still looks like a communication problem to me. do you use any security exits? what about the QMPROENG QMGR? i do not find any reference to that one in the definitions. you said, that QMPROENG is twice within the cluster. an "old" and a "new" one, is that correct? the log you posted below showing the 2059 errors related to QMPROENG, is this log from MQTRACE? is QMPROENG a repository queuemanager? if so, maybe MQTRACE also tries to connect to QMPROENG but finds an old definition and can not connect... but this is only a guess if the 2059 errors occur on MQTRACE and QMPROENG is a cluster qmgr, try to define the TO.QMPROENG cluster sender channel on MQTRACE explicit. are there messages in the system.cluster.transmit.queue on MQTRACE? do a refresh cluster(MQENG1) on MQTRACE, do the messagenumber increase or does the TO.MQSI2 channel starts and the messages get transmitted? is there another repository queuemanager except MQSI2 (and except of QMPROENG in case this one is a repository qmgr)? if so, define a clustersender TO.XXX to this one and retry to connect to the cluster. this is all fiddeling around with mq, no clue what it may be right now. i am running out of hints :D, maybe you should check all the amq logs on all participating queuemanagers again for error messages. you should also consider to update the repository to a higher level of mqseries. good luck stefan -Ursprungliche Nachricht- Von: Yonny Serrano [mailto:YSerrano@;GBM.NET] Gesendet: Mittwoch, 16. Oktober 2002 21:06 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] inst ead of Rep QMGR Stefan, the information that you ask for INETD.CONF QM_MQSI2 stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta -m MQSI2 QM_QMAS2 stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta -m QMAS2 SERVICES QM_MQSI2 1416/tcp QM_QMAS2 1417/tcp This information above is only for one of the repositories. Notice that there are two queue managers on that box, the repo qmgr and a qmgr that we use for some MQSI rulengines. The information below is for the Repo qmgr and the Win Qmgr that Im trying to add. The repo qmgr is working and the channel initiator too, the cluster ENG1 is also working with about 8 qmgrs (including the repo qmgrs). I tail the system objects information and the information about some qmgrs that are working in the cluster. Thanks again. 1 : display qmgr all AMQ8408: Display Queue Manager details. DESCR( )DEADQ(SYSTEM.DEAD.LETTER.QUEUE) DEFXMITQ( ) CHADEXIT( ) CLWLEXIT( ) CLWLDATA( ) REPOS(ENG1) REPOSNL( ) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)QMNAME(MQSI2) CRDATE(2001-08-01) CRTIME(17.51.39) ALTDATE(2001-08-02) ALTTIME(12.40.47) QMID(MQSI2_2001-08-01_17.51.39) TRIGINT(9) MAXHANDS(256) MAXUMSGS(1) AUTHOREV(DISABLED) INHIBTEV(DISABLED) LOCALEV(DISABLED) REMOTEEV(DISABLED) PERFMEV(DISABLED) STRSTPEV(ENABLED) CHAD(DISABLED) CHADEV(DISABLED) CLWLLEN(100)MAXMSGL(4194304
AW: AW: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] inst ead of Rep QMGR
mhhh, i do not find any configuration mistakes or typing-errors... so... what now. what i would do is to define normal sender / receiver channel between MQTRACE and MQSI2 (both directions) to make sure that the connection itself is working. it still looks like a communication problem to me. do you use any security exits? what about the QMPROENG QMGR? i do not find any reference to that one in the definitions. you said, that QMPROENG is twice within the cluster. an "old" and a "new" one, is that correct? the log you posted below showing the 2059 errors related to QMPROENG, is this log from MQTRACE? is QMPROENG a repository queuemanager? if so, maybe MQTRACE also tries to connect to QMPROENG but finds an old definition and can not connect... but this is only a guess if the 2059 errors occur on MQTRACE and QMPROENG is a cluster qmgr, try to define the TO.QMPROENG cluster sender channel on MQTRACE explicit. are there messages in the system.cluster.transmit.queue on MQTRACE? do a refresh cluster(MQENG1) on MQTRACE, do the messagenumber increase or does the TO.MQSI2 channel starts and the messages get transmitted? is there another repository queuemanager except MQSI2 (and except of QMPROENG in case this one is a repository qmgr)? if so, define a clustersender TO.XXX to this one and retry to connect to the cluster. this is all fiddeling around with mq, no clue what it may be right now. i am running out of hints :D, maybe you should check all the amq logs on all participating queuemanagers again for error messages. you should also consider to update the repository to a higher level of mqseries. good luck stefan -Ursprungliche Nachricht- Von: Yonny Serrano [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 16. Oktober 2002 21:06 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] inst ead of Rep QMGR Stefan, the information that you ask for INETD.CONF QM_MQSI2 stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta -m MQSI2 QM_QMAS2 stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta -m QMAS2 SERVICES QM_MQSI2 1416/tcp QM_QMAS2 1417/tcp This information above is only for one of the repositories. Notice that there are two queue managers on that box, the repo qmgr and a qmgr that we use for some MQSI rulengines. The information below is for the Repo qmgr and the Win Qmgr that Im trying to add. The repo qmgr is working and the channel initiator too, the cluster ENG1 is also working with about 8 qmgrs (including the repo qmgrs). I tail the system objects information and the information about some qmgrs that are working in the cluster. Thanks again. 1 : display qmgr all AMQ8408: Display Queue Manager details. DESCR( )DEADQ(SYSTEM.DEAD.LETTER.QUEUE) DEFXMITQ( ) CHADEXIT( ) CLWLEXIT( ) CLWLDATA( ) REPOS(ENG1) REPOSNL( ) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)QMNAME(MQSI2) CRDATE(2001-08-01) CRTIME(17.51.39) ALTDATE(2001-08-02) ALTTIME(12.40.47) QMID(MQSI2_2001-08-01_17.51.39) TRIGINT(9) MAXHANDS(256) MAXUMSGS(1) AUTHOREV(DISABLED) INHIBTEV(DISABLED) LOCALEV(DISABLED) REMOTEEV(DISABLED) PERFMEV(DISABLED) STRSTPEV(ENABLED) CHAD(DISABLED) CHADEV(DISABLED) CLWLLEN(100)MAXMSGL(4194304) CCSID(819) MAXPRTY(9) CMDLEVEL(510) PLATFORM(UNIX) SYNCPT DISTL(YES) 2 : display clusqmgr(*) all AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(MQSI1) CLUSTER(ENG1) CHANNEL(TO.MQSI1) CONNAME(130.1.9.203(1416)) QMID(MQSI1_2001-08-02_12.06.45) DESCR( ) CLUSTIME(21.19.32) CLUSDATE(2002-10-01) ALTTIME(06.55.53) ALTDATE(2001-10-05) TRPTYPE(TCP)DEFTYPE(CLUSSDRB) QMTYPE(REPOS) MCANAME( ) MODENAME( ) TPNAME( ) BATCHSZ(50) DISCINT(0) SHORTRTY(10)SHORTTMR(60) LONGRTY(9) LONGTMR(1200) SCYEXIT( ) SCYDATA( ) SEQWRAP(9) MAXMSGL(4194304) CONVERT(NO) USERID( ) PASSWORD( ) MCAUSER( ) MCATYPE(THREAD) HBINT(300) BATCHINT(0) NPMSPEED(FAST) NETPRTY(0) SUSPEND(NO) STATUS(RUNNING) SENDEXIT( ) SENDDATA( ) MSGEXIT( ) MSGDATA( ) RCVEXIT( ) RCVDATA( ) AMQ8441: Display Cluster Queue Manager d
AW: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] inst ead of Rep QMGR
Hi, clustering works by queuemanager-id not by queuemanager-name. if a qmgr is created it will be given a qmgr-id (qmgrname, date, time) which is used to identify the queuemanager within the mqseries cluster. if you purge that queuemanager (or if it is gone because of machine failures, disk crashes,) and create a new one with the same name the qmgr-id will differ. in that case you will see the queuemanager twice in the repository, and you will also see the cluster queues twice. but this should not prevent the new (or any other) queuemanager to join the cluster. you can force the "old" queuemanager out of the cluster before the new one joins, because with version 5.2 or lower you can only force by qmgrname, not by id (this hase been changed with version 5.3). before you do all that work collecting display-outputs make sure that you can ping the explicit defined cluster sender channel from the joining qmgr to the repository qmgr and that you can ping the implicit defined cluster sender channel from the repository qmgr to the joining qmgr. make also sure you did not miss any error messages in the various amqerrxx.log files (var/mqm/errors var/mqm/qmgrs/@system/errors var/mqm/qmgrs/yourqmgrname/errors) or fdc files that may indicate an error. make sure the repository manager is working on the aix box (i do not know the process name right now, but you can check whether the system.cluster.command queue is open for input). check that the channel initiator is running on the aix box (dont know the process name too, but check if system.channel.initq is open for input) at least, it still can be a software bug. mq 5.1 for the aix machine is somehow outdated. I would recommend to use at least 5.2 because there have been a lot of changes and bugfixes to clustering. good luck.. regards stefan -Ursprungliche Nachricht- Von: Yonny Serrano [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 15. Oktober 2002 18:33 An: [EMAIL PROTECTED] Betreff: Re: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] instead of Rep QMGR Sorry, my previous note was incomplete. The two full repositories qmgrs are running on separate aix boxes. The qmgr that Im trying to join is on a Win2K machine. That is the QMPROENG qmgr that you saw in the log files. QMPROENG was previously attached to the cluster but the customer had to reinstall everything on the Win2K machine (even the operating system) because of a low performance issue of some applications. The problem started when we redefined the qmgr QMPROENG and tried to rejoin it to the cluster. It seems that the repositories qmgrs have information about the original QMPROENG qmgr and do not recognize the new QMPROENG. But, there is a weird behaviour of the cluster: I am unable to add any other queue manager to the cluser, even with a completly different name in a different machine. I always see (on the new qmgrs) the repositories as SYSTEM.TEMPQMGR[conname] with the suspend attribute on YES. Because there was a production application down, I had to set up mqseries communication with sender and reciever channels, remote queues and transmition queues as a temporary solution. I need now to found a better solution for the problem. I'll try, today's afternoon, to join a new qmgr to the cluster. I'll send you then the information that you required (inet.conf, services, qmgrs, channels, clusqmgrs, etc). Any ideas will be apreciated, thank you, Yonny R. Serrano Stefan.Raabe@D REGIS.COMTo: [EMAIL PROTECTED] Sent by: cc: MQSERIES@AKH-W Subject: AW: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] ien.AC.AT instead of Rep QMGR 15/10/2002 03:18 a.m. Please respond to MQSERIES Hello, from my experience, the system.tempqmgr occured when - the queuemanager that tried to join the cluster was not able to connect to the repository queuemanager or - the repository queuemanager is not able to send an answer to the connecting queuemanager to resolve that name. this may be because of network issues or because of a mismatch in the definitions. use a ping channel for both directions to make sure its not the communication itself make sure that you specified the correct ip addresses and ports in the proper channel definitions one guess do you use the inetd to handle incoming regests? maybe you got the wrong queuemanagername in the inetd.conf, so the inetd starts the mca but the mca can not connect to the queuemanager because the name is not correct (this may be the 2059 error you showed us in the log). if all that seems to be okay, please show for every machine: - ip address and qmgr name - /etc/services and /etc/inetd.conf (mqseries entries only, i do not want to spy on your machine) :-) - display qmgr all - d
AW: channel triggering with MQ v5.2 on OS/390
Hello, one reason may be that the trigger header is missing. Browse the messages in the dlq to check whether they are really trigger messages or (maybe) application messages. we ran into that situation one day because "someone" with only little mq knowledge did some bad definitions so that application messages where put to the initq. hth stefan -Ursprungliche Nachricht- Von: Didi Dotan [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 15. Oktober 2002 15:35 An: [EMAIL PROTECTED] Betreff: channel triggering with MQ v5.2 on OS/390 Hello All, We have an MQSeries V 5.2 for OS/390 working on OS390 V2.8. We seem to encounter the following problem when trying to start the channels via triggering, the trigger message appear on the dead letter queue with MQFB_TM_ERROR. This means that the TM is incorrect, I checked the definitions for the trigger application and all seem to be in order. Has anybody seen this before (I actually did in 1998 but it has been a while... and the problem was fixed by PTF) Any Ideas? TIA, D. Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 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
AW: MQ v5.2 on os/390
Hi, check the 5.2 System Setup Guide, there are some notes related to the migration from version 2.1 to 5.2 make also sure that you use the proper (5.2) version of the ispf administration panels. you may try csqutil in batch mode too. what error do you get? regards stefan -Ursprungliche Nachricht- Von: N Vinodh [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 15. Oktober 2002 09:08 An: [EMAIL PROTECTED] Betreff: MQ v5.2 on os/390 Hi all I have installed MQSeries v5.2 for os/390. I created a subsystem. It is working fine. The problem is : Earlier I was using MQSeries V2.10. I had 2 queue managers in that version. The problem is I am not able to open objects in my older queue manager ( those created with MQ 2.1) using MQ 5.2. Can any suggest the way to make to the queuemanager in the older version compatible with mq5.2. Thanks in advance. Rgds * * * The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. Thank you. * * * Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] instead of Rep QMGR
Hello, from my experience, the system.tempqmgr occured when - the queuemanager that tried to join the cluster was not able to connect to the repository queuemanager or - the repository queuemanager is not able to send an answer to the connecting queuemanager to resolve that name. this may be because of network issues or because of a mismatch in the definitions. use a ping channel for both directions to make sure its not the communication itself make sure that you specified the correct ip addresses and ports in the proper channel definitions one guess do you use the inetd to handle incoming regests? maybe you got the wrong queuemanagername in the inetd.conf, so the inetd starts the mca but the mca can not connect to the queuemanager because the name is not correct (this may be the 2059 error you showed us in the log). if all that seems to be okay, please show for every machine: - ip address and qmgr name - /etc/services and /etc/inetd.conf (mqseries entries only, i do not want to spy on your machine) :-) - display qmgr all - display clusqmgr(*) all - display channel all hth stefan -Ursprungliche Nachricht- Von: Yonny Serrano [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 14. Oktober 2002 22:04 An: [EMAIL PROTECTED] Betreff: Re: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] instead of Rep QMGR The error log that I sent you is from de local installation (@system/errors) where the queue manager QMPROENG is defined. QMPROENG is the local queue manager. I displayed the atributes for the SYSTEM.TEMPQMGR, it appears as a suspend queue manager. The following command was execute in the local queue manager QMPROENG, the one that I cannot join to the cluster. You could see also that the channel is running. Let me know what you think about it, thank you again. YS. dis clusqmgr(system*) all 2 : dis clusqmgr(system*) all AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(SYSTEM.TEMPQMGR.130.1.9.205(1416)) CLUSTER(ENG1) CHANNEL(TO.MQSI2) CONNAME(130.1.9.205(1416)) QMID(SYSTEM.TEMPUUID.130.1.9.205(1416)) DESCR( )CLUSTIME(15.39.59) CLUSDATE(2002-10-14)ALTTIME(15.39.59) ALTDATE(2002-10-14) TRPTYPE(TCP) DEFTYPE(CLUSSDR)QMTYPE(REPOS) MCANAME( ) MODENAME( ) TPNAME( ) BATCHSZ(50) DISCINT(6000) SHORTRTY(10) SHORTTMR(60)LONGRTY(9) LONGTMR(1200) SCYEXIT( ) SCYDATA( ) SEQWRAP(9) MAXMSGL(4194304)CONVERT(NO) USERID( ) PASSWORD( ) MCAUSER( ) MCATYPE(THREAD) HBINT(300) BATCHINT(0) NPMSPEED(FAST) NETPRTY(0) SUSPEND(YES)STATUS(RUNNING) SSLCIPH( ) SSLCAUTH(REQUIRED) BATCHHB(0) LOCLADDR( ) ALTTIME( ) ALTDATE( ) SSLPEER() SENDEXIT( ) SENDDATA( ) MSGEXIT( ) MSGDATA( ) RCVEXIT( ) RCVDATA( ) adiraju.s.rao@ AEXP.COM To: [EMAIL PROTECTED] Sent by: cc: MQSERIES@AKH-W Subject: Re: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] ien.AC.AT instead of Rep QMGR 14/10/2002 01:59 p.m. Please respond to MQSERIES Hi Yonny, >From the error logs i can see that the remote queue manager is not started for some reason. Make sure that the Queue manager QMPROENG is available or not. One more way to test is by pinging the channel. First stop the channel TO.QMPROENG channel and try to ping and note the errors, you will get some kinda message basically the result of the ping channel command. This should give you a closest reason for why its failing. If it fails due to tcp/ip error make sure that remote queue manager is running on the right port and if is says remote queue manager is unavailable, try starting the QM. Let me know how it goes. Adi From: "Yonny Serrano" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 10/14/2002 01:22 PM AST Please respond to "MQSeries List" <[EMAIL PROTECTED]> Sent by:"MQSeries List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: QMGR cannot join a cluster, SYSTEM.TEMPQMGR[conname] instead of Rep QMGR Hello Adi, thanks for your response, Attached is a fragment of the file \@SYSTEM\errors\AMQERR01.LOG. I am able to start the cluster sender channels on both ends (Repo qmgr and new qmgr), and I see them running. What else do I have to check about the network configuration? Could it be
AW: AW: RQMNAME if sending to a queue sharing group
yeah, thanks russell. that was what i read but i did not find again because i scanned the manual for "rqmname" thanks again. regards stefan -Ursprungliche Nachricht- Von: Russell Finn [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 8. Oktober 2002 13:00 An: [EMAIL PROTECTED] Betreff: Re: AW: RQMNAME if sending to a queue sharing group When you MQOPEN a queue, and supply the name of a remote queue definition, the fields RNAME and RQMNAME are used in the same way as when you MQOPEN a queue and supply od.ObjectName and od.ObjectQMgrName. As such, if you want to find out how RQMNAME fits with Qsg, try seeing how the MQOD.ObjectQMgrName fields fits with Qsg... MQOD ObjectName field If ObjectName is the name of a shared queue that is owned by a remote queue-sharing group (that is, a queue-sharing group to which the local queue manger does not belong), ObjectQMgrName should be the name of the queue-sharing group. The name of a queue manager that belongs to that group is also valid, but this is not recommended as it may cause the message to be delayed if that particular queue manager is not available when the message arrives at the queue-sharing group. Russell Russell Finn MQSeries System Test [EMAIL PROTECTED] |-+--> | | Tom| | | Schneider/Schaumbur| | | g/IBM@IBMUS| | | Sent by: MQSeries | | | List | | || | | | | | | | | 07/10/02 19:02 | | | Please respond to | | | MQSeries List | | | | |-+--> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: AW: RQMNAME if sending to a queue sharing group | | | | | >--- ---| Stefan, Thanks for the information. What we are interesting in is the high availability solution you described in the last paragraph of your note. Just curious, have you found anywhere in the documentation where it describes how to code RQMNAME for the scenarios you outlined, or is this all information which you've figured out by yourself through experience? Regards, Tom == Tom Schneider / IBM Global Services (513) 533-3644 [EMAIL PROTECTED] == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: RQMNAME if sending to a queue sharing group
Tom, i read it and i tried it. but i can not remember where i read it. i searched again but did not find it again. but i found an example in the intercommunication guide where the qsg name is used in the rqmname field when adressing a qsg from outside. see intercommunication guide chapter 36 (5.3 version). i am sure i found it somewhere else too, but its hidden very pretty. regards stefan -Ursprungliche Nachricht- Von: Tom Schneider [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 7. Oktober 2002 20:03 An: [EMAIL PROTECTED] Betreff: AW: RQMNAME if sending to a queue sharing group Stefan, Thanks for the information. What we are interesting in is the high availability solution you described in the last paragraph of your note. Just curious, have you found anywhere in the documentation where it describes how to code RQMNAME for the scenarios you outlined, or is this all information which you've figured out by yourself through experience? Regards, Tom == Tom Schneider / IBM Global Services (513) 533-3644 [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
AW: RQMNAME if sending to a queue sharing group
Hello, i wrote at the end of the last section in my last mail: "... and using a shared inbound channel if sending from outside the qsg so your messages will always be received by an active qsg-queuemanager and processed by "his" application or - if target queue is a shared queue - by one of the applications on any qmgr within the qsg." of course if it is a shared queue not only one of the applications can process the queue, but multiple or all applications that are connected to the qsg queuemanagers, depending on application design (e.g. open exclusive ). regards stefan -Ursprüngliche Nachricht- Von: Raabe, Stefan [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 7. Oktober 2002 10:51 An: [EMAIL PROTECTED] Betreff: AW: RQMNAME if sending to a queue sharing group Hello Tom, it depends on you setup. i try to give some explanation. - a message is only available for each queuemanager within a queue sharing group if it resides in a shared queue. so it does not matter on your remoteq definition or the way you set up your connection to the qsg, its a matter how you define the target queue. - rqmname in remoteq definition: 1. if you specify the qsg name in the rqmname field, then the message is accepted by every queuemanager within the qsg, so the receiving qsg-qmgr will search for a local definition of rname. (qalias, qremote, qlocal, clusterq, sharedq) 2. if you specify a qmgrname then it is will follow the known rules for distributed queueing. the receiving qsg-queuemanager will check if his qmgrname is the target qmgrname, if yes check for local queue definitions, if no check if the rqmname is known (xmitqname, clusterqmgr, qmgralias, ...) whether to use version 1 or 2 within the remoteq definition depends on how you setup your channels and where your target queue resides. if your channel is a channel to a single qmgr within the qsg then there is no need to specify the qsg in rqmname, you cold also specifiy the qmgr name at the receiving end. the receiving queuemanager will then put the message to the proper queue, no matter what kind of queue (local queue, shared queue, ...). If the receiving queuemanager fails, then there will be no message transfer to the qsg. anyway, of your target queue is a shared queue the other qsg queuemanager are still able to process messages from that queue, but no new messages will arrive. if your channel is a channel to a shared port of the qsg (every qsg queuemanager can be chosen to be the receiver end) then - if the queue is a shared queue or if there is an instance of the queue on every qmgr within the qsg - you should specify the qsg name in the rqmname field. no matter which qmgr is selected to handle the receiving end of the channel, it will put the message to the shared queue or to his local instance of the queue. if shared queue, every queuemanager within the qsg is able to process the message (the application connected to the qmgr, not the qmgr itself). if the receiving queuemanager fails, one of the other queuemanagers within the qsg will be chosen to resume the connection. (check shared inbound channels in the concepts and planing guide) if the target queue is not a shared queue and if there is only one instance of the target queue (on one of the qmgrs within the qsg) you could still use the shared inbound channel instead of a direct sender - receiver definition, but its of no big help because you still need connections between the qsg queuemanagers to route the message to the target queuemanager (check intra group queueing). if the target qmgr is not available then the messages can not be processed anyway, so there is no big difference whether the messages reside on the sending queuemanager or on one of the qsg queuemanagers waiting for the target qmgr to become active. The best setup (availiability) is to use a shared queue or one instance of the target queue on every queuemanager (this also means to have at least one instance of the application running on every queuemanager within the qsg) and using a shared inbound channel if sending from outside the qsg so your messages will always be received by an active qsg-queuemanager and processed by "his" application or - if target queue is a shared queue - by one of the applications on any qmgr within the qsg. hth regards stefan -Ursprüngliche Nachricht- Von: Tom Schneider [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Oktober 2002 15:15 An: [EMAIL PROTECTED] Betreff: RQMNAME if sending to a queue sharing group If a queue manager that is not part of an MVS queue sharing group (QSG) needs a QREMOTE definition to send to the QSG, what needs to be specified in the RQMNAME parameter? There is an example in the Intercommunication manual in Chapter 36 "Message channel planning example for z/OS using queue-sharing groups" under the heading "Remaining definitions" that looks like this (QSG1 is the name of the qu
AW: RQMNAME if sending to a queue sharing group
Hello Tom,
it depends on you setup. i try to give some explanation.
- a message is only available for each queuemanager within
a queue sharing group if it resides in a shared queue. so
it does not matter on your remoteq definition or the way
you set up your connection to the qsg, its a matter
how you define the target queue.
- rqmname in remoteq definition:
1.
if you specify the qsg name in the rqmname field, then the message
is accepted by every queuemanager within the qsg, so the receiving qsg-qmgr
will search for a local definition of rname. (qalias, qremote, qlocal,
clusterq, sharedq)
2.
if you specify a qmgrname then it is will follow the known rules
for distributed queueing. the receiving qsg-queuemanager will check if
his qmgrname is the target qmgrname, if yes check for local queue
definitions, if no check if the rqmname is known (xmitqname, clusterqmgr,
qmgralias, ...)
whether to use version 1 or 2 within the remoteq definition depends
on how you setup your channels and where your target queue resides.
if your channel is a channel to a single qmgr within the qsg then there
is no need to specify the qsg in rqmname, you cold also specifiy the
qmgr name at the receiving end. the receiving queuemanager will then
put the message to the proper queue, no matter what kind of queue
(local queue, shared queue, ...).
If the receiving queuemanager fails, then there will be no message
transfer to the qsg. anyway, of your target queue is a shared queue
the other qsg queuemanager are still able to process messages from
that queue, but no new messages will arrive.
if your channel is a channel to a shared port of the qsg (every qsg
queuemanager can be chosen to be the receiver end) then - if the
queue is a shared queue or if there is an instance of the queue on
every qmgr within the qsg - you should specify the qsg name in the
rqmname field. no matter which qmgr is selected to handle the
receiving end of the channel, it will put the message to the
shared queue or to his local instance of the queue.
if shared queue, every queuemanager within the qsg is able to
process the message (the application connected to the qmgr, not
the qmgr itself).
if the receiving queuemanager fails, one of the other queuemanagers
within the qsg will be chosen to resume the connection.
(check shared inbound channels in the concepts and planing guide)
if the target queue is not a shared queue and if there is only one
instance of the target queue (on one of the qmgrs within the qsg)
you could still use the shared inbound channel instead of a direct
sender - receiver definition, but its of no big help because
you still need connections between the qsg queuemanagers to route
the message to the target queuemanager (check intra group queueing).
if the target qmgr is not available then the messages can not be
processed anyway, so there is no big difference whether the
messages reside on the sending queuemanager or on one of the
qsg queuemanagers waiting for the target qmgr to become active.
The best setup (availiability) is to use a shared queue or one
instance of the target queue on every queuemanager (this also
means to have at least one instance of the application running on
every queuemanager within the qsg) and using a shared inbound
channel if sending from outside the qsg so your messages will
always be received by an active qsg-queuemanager and processed by "his"
application or - if target queue is a shared queue - by one of
the applications on any qmgr within the qsg.
hth
regards
stefan
-Ursprüngliche Nachricht-
Von: Tom Schneider [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 4. Oktober 2002 15:15
An: [EMAIL PROTECTED]
Betreff: RQMNAME if sending to a queue sharing group
If a queue manager that is not part of an MVS queue sharing group (QSG)
needs a QREMOTE definition to send to the QSG, what needs to be specified
in the RQMNAME parameter?
There is an example in the Intercommunication manual in Chapter 36
"Message channel planning example for z/OS using queue-sharing groups"
under the heading "Remaining definitions" that looks like this (QSG1 is
the name of the queue sharing group in the example):
DEFINE QREMOTE(PAYROLL.QUERY)DESCR('Remote queue for QSG1 ')REPLACE +
PUT(ENABLED)XMITQ(QSG1)RNAME(APPL)RQMNAME(QSG1)
Does RQMNAME have to be the name of the queue sharing group? If the
RQMNAME was instead the name of one of the queue managers in the queue
sharing group, would the messages sent to this remote queue (assuming it
is shared) still be available to any of the queue managers in the QSG, or
only to the queue manager named in RQMNAME?I have not been able to
find anyplace in the documentation where it explicitly says what needs to
be coded for RQMNAME when sending to a QSG.
-Tom
==
Tom Schneider / IBM Global Services
(513) 533-3644
[EMAIL PROTECTED]
==
Instructions f
AW: Messages stuck in System.Cluster.Transmit.Queue
i do get this error too, but i have never found out why
(i did not spent many time on it). it is wrong in 99
percent (in my case), so i just ignore it.
regards
stefan
-Ursprüngliche Nachricht-
Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 25. September 2002 15:05
An: [EMAIL PROTECTED]
Betreff: Re: Messages stuck in System.Cluster.Transmit.Queue
One more clue. If I use the MQExplorer to look at the QM Alias in my
original setup, (before I moved the remote queue def to the gateway) to
click on the Cluster Tab, I see that the queue is part of my Cluster. When I
click on say the general tab, as I am leaving the cluster tab, I get the
following error:
The queue manager is not member of the cluster 'Cluster1'. The object which
you have shared is in the cluster will no be made available to other members
of the cluster until you make this queue manager a member of the cluster
(AMQ4514).
I get this on the gateway QM. In fact I get it for any clustered queue if I
do a properties check on it on QM1. But it IS part of the cluster, since
messages are using QM1 to get into the cluster and messages that don't use
remote queue defs are leaving the cluster via this single gateway. Its like
QM2 doesn't know about the QM Aliases on QM1, so the messages stack up???
Also this error doesn't show up on my teammates MQExplorer, which is newer
than mine. Is the error even valid?
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 10:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages stuck in System.Cluster.Transmit.Queue
Yeah that was a typo in the email (QM3.XMIT vs. QM3.XMITQ).
I don't understand why yours works and mine don't.
?
I deleted the remote queue def from QM2. I then added the remote queue def
to QM1, but this time also specified the XMIT queue in the remote queue def,
and it works.
Before I saw your email, I concluded that if you are going to create a
remote queue def in a cluster, it needs to be on the gateway queue manager,
since that is where the XMIT queue lives. Since I can't cluster the XMIT
queue, I can't refer to it in a remote queue def on a clustered QM that
doesn't house that XMIT queue. I didn't feel to confident though, since I
don't see any docs that say you can or can't define a remote queue def
anywhere in a cluster.
I did find an example of exactly what I am trying to achieve in this years
Cluster Handout from the Tech Conference in Dallas. In this example, they
define the remote queue def on the gateway QM, and the putting app is
connected to another clustered QM. It doesn't say you HAVE to do it this
way, but since it was the only example I found, I assume this was the case,
until you came along and debunked that theory!
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-Original Message-
From: Tony Devitt [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 7:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages stuck in System.Cluster.Transmit.Queue
**
Note: This e-mail is subject to the disclaimer contained at the bottom
of this message.
**
:
Peter,
I assume(?) that 'QM3.XMIT' is a typo, or is there a reason to have it as
well as 'QM3.XMITQ'. Anyway I set up the definitions as you have on three
test queue managers, and see on:
1. QM1: FINALQ ( a cluster queue owned by QM2)
QM3 (a remote def with no RNAME pointing to RQMNAME(QM3) using
XMITQ(QM3.XMITQ) belonging to cluster (CLUS1))
QM3.XMITQ ( a local XMITQ, which I have associated with a sdr/rcvr
channel 'QM1.QM3')
2. QM2: FINALQ (a remote def with RNAME(FINALQ) at RQMNAME(QM3) using
XMITQ (' ') belonging to cluster (CLUS1))
QM3 (a cluster queue owned by QM1)
3. QM3: FINALQ (a local queue)
With this set of definitions, messages that I place in FINALQ at QM2 travel
from QM2 to QM1 on the cluster channel and then via the channel QM1.QM3 to
the final destination FINALQ on QM3. This seems to be what you are trying
to achieve. Did your remote QDef for cluster queue QM3 get propagated from
QM1 to QM2?
:
The information transmitted in this message and attachments (if any)
is intended only for the person or entity to which it is addressed.
The message may contain confidential and/or privileged material.
Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon this information, by persons or entities
other than the intended recipient is prohibited.
If you have received this in error, please contact the sender and delete
this
e-mail and associated material from any computer.
The intended reci
AW: Messages stuck in System.Cluster.Transmit.Queue
Peter,
i am not quite sure, but you should remove the qremote definition for
FinalQ from QM2 and create it on QM1 with
DEFINE QREMOTE(FinalQ) RNAME(FinalQ) RQMNAME(QM3) XMITQ(QM3.XMIT)
CLUSTER(ClusterA)
If you try to put on QM2 then it will find the cluster queue which belongs
to QM1 so
it will route the Message to QM1 using clustering, and QM1 will put it to
the
QM3.XMIT. The QMGR Alias QM3 is obsolete then and can be deleted.
Only QM1 has to know about the location of the queue because it works as a
gateway,
so it is much more clear to define the object in QM1 rather then in QM2,
which is
only interested in the queue name.
If messages still stuck in the cluster xmitq then you should check if your
cluster
channels are set up properly.
hth
Stefan
-Ursprüngliche Nachricht-
Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 24. September 2002 18:39
An: [EMAIL PROTECTED]
Betreff: Messages stuck in System.Cluster.Transmit.Queue
QM1 and QM2 are in ClusterA.
QM3 is not in any cluster, and has a local queue called FinalQ.
QM1 is the gateway to QM3. QM1 has an XMIT queue called QM3.XMIT. It has a
QM Alias called QM3, which maps to QM3.XMIT. I did the following on QM1:
DEFINE QREMOTE('QM3') RNAME(' ') RQMNAME(QM3) XMITQ(QM3.XMITQ)
CLUSTER(ClusterA)
DEFINE QLOCAL(QM3.XMIT) USAGE(XMIT)
An app connected to QM2 needs to get messages to FinalQ / QM3. In its open
of FinalQ, it cannot specify the QM name, so I want to create a remote queue
definition on QM2 that points to FinalQ / QM3. So I did the following on
QM2:
DEFINE QREMOTE(FinalQ) RNAME('FinalQ') RQMNAME(QM3) XMITQ(' ')
CLUSTER(ClusterA)
But any messages I put to FinalQ on QM2 just sit in the
SYSTEM.CLUSTER.TRANSMIT.QUEUE.
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: MQS on Win/NT
Hello, have a look at MS03 supportpac at http://www-3.ibm.com/software/ts/mqseries/txppacs/txpm1.html Regards Stefan -Ursprüngliche Nachricht- Von: Schmidt, Reiner [IRZ-01] [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 24. September 2002 12:27 An: [EMAIL PROTECTED] Betreff: MQS on Win/NT Dear Listeners, is it possible to save definitions in a text file (txt) which where made in the MQ-explorer. If yes, how? Thanks in advance ReinerSchmidt 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
AW: CSQUDLQH on MQSeries for OS/390 Version 2.1
Hello, CSQUDLQH was introduces with version 5.2, so it is not included on os/390 2.1 and lower versions. If you have a version 5.2 available, you may use the 520.scsqload and the 520.scsqanle (or whatever language you use) as steplib for CSQUDLQH and use it for a 2.1 queuemanager. I did that and it worked, although I did not test it for all possible situations and reason codes (which means use at your own risk) Regards Stefan -Ursprüngliche Nachricht-Von: Sathaporn [mailto:[EMAIL PROTECTED]]Gesendet: Dienstag, 24. September 2002 08:53An: [EMAIL PROTECTED]Betreff: CSQUDLQH on MQSeries for OS/390 Version 2.1 Hello All Does anyone know where can we find CSQUDLQH on MQSeries for OS/390 Version 2.1 ? Any suggestion will be appreciate. Regards, Sathaporn
AW: AW: Remote Queue Def in a Cluster
David, workload balancing does not rely on qlocal. you can also use the workload balancing (the round-robin mechanism) with qalias or qremote queues. same name, same type. why defining remote queues as cluster queues? at least its the same why you make a qlocal or a qalias a cluster queue: all qmgrs within the cluster will know about the queue (full repository only, partial if they try to use the queue) so messages can be routed without any other queues defined. one example could be something like gateway function. if you have a destination queue on a qmgr outside the cluster (QMGRA), and there is one queuemanager within the cluster (QMGRB) that has connection to QMGRA and a remoteq that points to the destination queue, then - by making the remoteq a cluster queue - all queuemanagers within the cluster are able to put messages to this remoteq on QMGRB by using clustering, and QMGRB will send the messages to QMGRA using conventional channels. So every queuemanager within the cluster is able to send Messages to QMGRA outside the cluster by using QMGRB as a gateway (for this specific queue). it can also be used for qmgr alias within the cluster. Check section "Auto-definition of remote queues" and "Using aliases and remote-queue definitions with clusters" in the "Queue Manager Clusters" manual. Regards Stefan -Ursprungliche Nachricht- Von: David Yu [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 17. September 2002 16:45 An: [EMAIL PROTECTED] Betreff: Re: AW: Remote Queue Def in a Cluster Stefan, Thanks you for all your useful information. I have one question needs to ask you. What is the purpose of defining a remote queue with cluster attribute ? Defining a local queue of cluster have advantage of having multiple MQ's shares a cluster queue and does workload balance. But I don't see any reason to have remote defining as cluster. Thanks David --- "Raabe, Stefan" <[EMAIL PROTECTED]> wrote: > Hello Group, > > yes, messages will sit in the > SYSTEM.CLUSTER.TRANSMIT.QUEUE. > > There is no different behavior with message > persistence. If messages are > non persistence, they will be purged during > queuemanager restart, no matter > wheter they are in a qlocal, xmitq or cluster-xmitq. > > But you should be aware of the cluster-rerouting > mechanism: > > If there are messages on the > SYSTEM.CLUSTER.TRANSMIT.QUEUE and > they are not indoubt, then - at every retry interval > of the > channel - the messages are "get" and "put" again by > the cluster > rerouting mechanism. This is done because the > assigned destination > may be not available (thats why its in retry), and > the put will select > an alternate available destination queue if there is > one. > This is done with syncpoint control, so it will use > a lot of logging > depending on the amout of messages and your cluster > channel retry interval. > > We once filled up many cartridges with archive logs > (during some days / > weeks) > because a testsystem was not available for a long > period of time and there > where some thousands of messages in the > SYSTEM.CLUSTER.TRANSMIT.QUEUE. > > I do not know if this rerouting mechanism is > included in all MQ versions > that > support clustering, at least its in 5.2 on OS/390. > > Regards > > Stefan > > > -Ursprungliche Nachricht- > Von: Stefan Sievert > [mailto:[EMAIL PROTECTED]] > Gesendet: Dienstag, 17. September 2002 01:03 > An: [EMAIL PROTECTED] > Betreff: Re: Remote Queue Def in a Cluster > > > I would assume that the message will remain on the > cluster transmission > queue until QM1 is back up running. There might be a > difference in behavior > depending on whether the log messages are persistent > or not, but I'll leave > that for somebody who has more real life experience > with clustering than I > have. > Stefan > > >From: "Potkay, Peter M (PLC, IT)" > <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Remote Queue Def in a Cluster > >Date: Mon, 16 Sep 2002 17:34:09 -0400 > > > >You are correct Stefan. (long day) > > > >I will need a XMIT queue, a remote queue def and a > Channel between QM2 and > >QM3, just like between QM1 and QM3. > > > >Next question that I need verification on is as > follows: > > > >Lets say I create a clustered local queue on QM1 > called LOGQUEUE. For the > >sake of discussion, we are only concerned with > putting to this queue. We > >want to insure that messages get there, because > once a week we run a batch > >job to look at that queue. > > >
AW: Remote Queue Def in a Cluster
Hello Group, yes, messages will sit in the SYSTEM.CLUSTER.TRANSMIT.QUEUE. There is no different behavior with message persistence. If messages are non persistence, they will be purged during queuemanager restart, no matter wheter they are in a qlocal, xmitq or cluster-xmitq. But you should be aware of the cluster-rerouting mechanism: If there are messages on the SYSTEM.CLUSTER.TRANSMIT.QUEUE and they are not indoubt, then - at every retry interval of the channel - the messages are "get" and "put" again by the cluster rerouting mechanism. This is done because the assigned destination may be not available (thats why its in retry), and the put will select an alternate available destination queue if there is one. This is done with syncpoint control, so it will use a lot of logging depending on the amout of messages and your cluster channel retry interval. We once filled up many cartridges with archive logs (during some days / weeks) because a testsystem was not available for a long period of time and there where some thousands of messages in the SYSTEM.CLUSTER.TRANSMIT.QUEUE. I do not know if this rerouting mechanism is included in all MQ versions that support clustering, at least its in 5.2 on OS/390. Regards Stefan -Ursprungliche Nachricht- Von: Stefan Sievert [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 17. September 2002 01:03 An: [EMAIL PROTECTED] Betreff: Re: Remote Queue Def in a Cluster I would assume that the message will remain on the cluster transmission queue until QM1 is back up running. There might be a difference in behavior depending on whether the log messages are persistent or not, but I'll leave that for somebody who has more real life experience with clustering than I have. Stefan >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Remote Queue Def in a Cluster >Date: Mon, 16 Sep 2002 17:34:09 -0400 > >You are correct Stefan. (long day) > >I will need a XMIT queue, a remote queue def and a Channel between QM2 and >QM3, just like between QM1 and QM3. > >Next question that I need verification on is as follows: > >Lets say I create a clustered local queue on QM1 called LOGQUEUE. For the >sake of discussion, we are only concerned with putting to this queue. We >want to insure that messages get there, because once a week we run a batch >job to look at that queue. > >When QM1 and QM2 are both up, an app on QM2 can put to LOGQUEUE and the >messages will end up on the local instance of LOGQUEUE on QM1, because >LOGQUEUE is advertised to the cluster. > >IF QM1 goes down, an app on QM2 that puts to LOGQUEUE will have what >happen? >I assume the put will fail, right? And if so, I really should create a >LOGQUEUE on both QM1 and QM2. > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > >-Original Message- >From: Stefan Sievert [mailto:[EMAIL PROTECTED]] >Sent: Monday, September 16, 2002 4:58 PM >To: [EMAIL PROTECTED] >Subject: Re: Remote Queue Def in a Cluster > > >Peter, >this sounds more like a channel question than a QR def question. If you >only >have a channel from QM1 to QM3 and QM1 goes down, messages can't travel to >QM3 unless you also have a channel from QM2 to QM3. Correct or am I missing >the point? >Cheers, >Stefan > > > >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Remote Queue Def in a Cluster > >Date: Mon, 16 Sep 2002 16:20:35 -0400 > > > >Maybe an obvious question... > > > >QM1 and QM2 are both full repositories of ClusterA. > >QM3 is not part of the cluster. > > > >QM1 has a remote queue def to QueueC on QM3. The remote queue def is a > >clustered queue in ClusterA. > > > >An app on either QM1 or QM2 can now put to QueueC. > > > >What if QM1 goes down? Is the app on QM2 now not able to get a message to > >QueueC? Do I need to make the remote queue def on both QM1 and QM2? > > > > > > > >Peter Potkay > >IBM MQSeries Certified Specialist, Developer > >[EMAIL PROTECTED] > >X 77906 > > > > > > > >This communication, including attachments, is for the exclusive use of > >addressee and may contain proprietary, confidential or privileged > >information. If you are not the intended recipient, any use, copying, > >disclosure, dissemination or distribution is strictly prohibited. If > >you are not the intended recipient, please notify the sender > >immediately by return email and delete this communication and destroy all > >copies. > > > >Instructions for managing your mailing list subscription are provided in > >the Listserv General Users Guide available at http://www.lsoft.com > >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > >_ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > >Instructions for managing your mailing list subscription are provide
AW: MQSeries Cluster Problem
hello
kritsana,
if a
cluster queue is defined it will be visible on all repository
queuemanagers
because they exchange the cluster information, but not
on the partial
repository queuemanagers("members") (unless the
definition is local
to
this queuemanager).
these
"members" will only know what they have used within the last 30 (i
think
it was
30) days.
try to
put a message to the cluster queue from the win2000 queuemanager, from
that
moment
on also this machine will know that queue.
amongst other things the "refresh cluster" makes the
"member" forget
about
what it has used.
just
try it after the cluster queue is visible on the win2000
machine.
it
will then forget this queue (should be invisible
again).
put a
message again, and it will be visible again.
I
recommend reading "queue manager clusters" manual.
Regards
Stefan
-Urspr|ngliche Nachricht-Von: Kritsana
[mailto:[EMAIL PROTECTED]]Gesendet: Donnerstag, 5. September 2002
19:55An: [EMAIL PROTECTED]Betreff: MQSeries
Cluster Problem
Hi All,
I encounter a problem when I try to make
a cluster from 2 AIX machines and 1 windows 2000 machine.
Note: MQSeries on AIX is version
5.2.0.2
MQSeries
on Win 2000 is version 5.2
I choose 2 AIX to be repository of
cluster. Both of them are working properly.
I mean when I add a new local queue on
one of them and make it shares in cluster.
Another one also see that queue.
But when I add 1 Win 2000 in
cluster. Strangely, it does not see that cluster queue.
Eventhough, I try to refresh cluster
information on all of them.
Any help will be
appreciated.
Kritsana Loaboonsup
System Programmer
AW: Free MQ management tool
it looks like a "try before you buy" version anyway. limited features in the express version (had a look at the docs). the instalation procedure seems to be buggy, i have both client and server installed on my machine (mq 5.2.1) but the installation process says "client not installed" and terminates the installation. but maybe this is only related to my installation you also have to fill a form with personal and company data before you are allowed to download. regards stefan -Ursprungliche Nachricht- Von: Sam Garforth [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 28. August 2002 17:29 An: [EMAIL PROTECTED] Betreff: Re: Free MQ management tool Hi Bob, Thanks for the suggestion ;-) Sam -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Sloper Sent: 28 August 2002 16:19 To: [EMAIL PROTECTED] Subject: Re: Free MQ management tool Sam; I hope this is not like PQEdit which was free until everyone was hooked then CANDLE started to charge for it! Sorry I asked really, as I know you wouldn't do that to us - would you? Sam GarforthTo: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: > Subject: Free MQ management tool Sent by: MQSeries List <[EMAIL PROTECTED] .AT> 08/28/2002 10:49 AM Please respond to MQSeries List I hope you won't mind this rare advert from me as it should be of interest to you. Free! All new MQControl Express -- an amazing new tool for MQSeries Administrators and Developers And it's yours, absolutely free. Just download it, and within minutes you'll have more control over your MQSeries middleware processes than you ever imagined. MQControl Express gives you the power to configure, monitor and effectively manage your MQSeries objects and MQSeries messages. It simplifies and centralizes the entire monitoring task, giving you instant access to MQSeries objects on a number of platforms from a single control point. MQControl Express can establish, monitor and control connections to NT, UNIX, AS400 and VMS, in fact almost any MQ server platform - without the need for a local installation of MQSeries or the complexity of installing and managing agents. Among its many powerful capabilities are: * Message Management that allows for copy, move, delete, edit and reroute * Automatic discovery of all MQSeries objects * Graphical displays of MQSeries events in real time * Automatic fault detection So why are we giving it away for free? Because we want you to experience the power that comes with being in control. And because it's just the tip of the iceberg. It's just one of many Nastel products designed to work together to give you complete end-to-end application and business process monitoring control. Download your free copy of MQControl Express today from www.nastel.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive --This email has been scanned for viruses by Plugit.com --This email has been scanned for viruses by Plugit.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Message persistence
Sundari, non persistent messages are purged at queuemanager restart, so this is exactly what you saw (only 10 messages left on the xmitq). the problem (after starting the channel) looks like a configuration problem. mq tries to deliver the messages to the aix mq, but this one does not seem to be able to store the messages, thats why they stay on your mqseries (whats the channel status? retry?) check the receiving end (aix) for error messages. maybe the destination queue does not exist, and no dead letter queue is defined in the queuemanager. regards stefan -Ursprüngliche Nachricht- Von: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 29. Juli 2002 13:17 An: [EMAIL PROTECTED] Betreff: Message persistence Hi, My COBOL application running on OS/390 places messages in remote queues on an AIX box. I am facing a rather vague problem when I set the persistence of messages through my COBOL code. ( This is what I do to set the persistence : MOVE MQPER-PERSISTENT TO MQMD-PERSISTENCE ) In order to test the persistence I did the following: 1. I stopped the sender channel so that messages will remain in the XMITQ. 2. Ran my application to place 10 persistent messages and 10 non-persistent messages in the queue. 3. I confirmed that the messages were available in the XMITQ. 4. Stopped the queue manager on OS/390. 5. Restarted the queue manager. Now I found that only 10 messages were available in the XMITQ. Then I restarted the channel, but now not all the messages were delivered to the queues residing on the AIX. Some3 messages remained on the XMITQ. I could not clear the XMITQ and faced a number of other such vague problems. What happens to persistent messages when the queue manager goes down ? Thanks in advance. Any help is appreciated. Regards Sundari 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: Is it possible to "timout" an "MQPUT"???
Roque, it is most likely that only ibm can tell you what the "timeout" value in the pmo is used for. i try to answer your questions... 1. until control is returned from mqseries or connection is broken 2. no, there is no mqseries - put - timeout value 3. if persistent, mq has to make sure that the message is not lost in any case. therefore messages are written to storage and to the mqseries log first (rather than to a queue). if the message is on the log, then control returns to the program with proper cc and rc values. the message remains in storage and is written to pagesets later depending on buffer usage and checkpoint frequency. remember, this is all on your "local" mqseries queuemanager your application is connected with. in logic, messages are put into a local queue ( either "normal" or "xmit" ) managed by the queuemanager your program is connected to, and then control is returned to your program. 4. no timeout, no default. if the message is "save", you get control back, or if the message can not be stored by mq (put disabled, queue full, ...) you will get proper condition and reason codes 5. i dont have much experience with mq clients, so i better should not try to guess something, but i do not think so. maybe just because of an error. hth Stefan Raabe -Ursprüngliche Nachricht- Von: Roque Solis [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 24. Juli 2002 04:55 An: [EMAIL PROTECTED] Betreff: Is it possible to "timout" an "MQPUT"??? Hi, I have plans to enhance a mission critical, transaction processing, application. This enhancement would consist of a client application running on a Stratus machine (fault-tolerant mid-range, high-availability machine), and connecting to a Queue Manager running on ZOS (OS 390) mainframe. One of our architects has raised a concern over how long the client application would have to wait while doing an MQPUT if the Queue Manager on the mainframe was taking too long to write the message to the designated queue we are talking about a "persistant" queue) here. I noticed that the there is a variable in the MQ Put Message Options structure which implies that it can be used as a "timeout". In face, this variable is called "timeout". Using the variable of the same name "timeout" in the Get Message Options (GMO) structure, allows a client application to return control to the application when attempting to get a message out of an empty queue, allowing it to do other work. Basically, I would like to allow my Client application to gain control from the MQPUT if it is taking longer than a desired amount of time. The thing is, that the all of the reference manuals say that the "timeout" variable in the PMO structure is "reserved". What does this mean?? This situation has raised a couple of questions: 1) How long does an application wait for an MQPUT to complete on persistant queues? 2) Does it ever timeout? 3) When does the Client application get confirmation (again on persistant queues) that the message was received by the Queue Manager and written to a queue? When the message actually is written to disk? Or when the message is received by the Channel? When does the Queue manager actually confirm to the client application that the message was received? 4) What is the "default" timeout value for an MQPUT to receive confirmation from the Queue Manager that a message was received? 5) This is the biggest question of all: Will there ever be a situation when a Client application calling MQPUT "block" for ever and never gain control back from the MQPUT call? I would appreciate any help on this. Thanks, Roque Solis [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
Channel Autodefinition Exit - any samples?
Hello, I like to use a channel autodefinition exit in Windows and Unix environment but i am not a C guru and all my searches for a sample or skeleton failed. can anyone point me to a sample or maybe someone has an exit and is willing to share it ?!? i like to remove the security exit on cluster receiver channels (that are used to build the automatically defined cluster sender channels). tia stefan 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
Shared Queue and Shared InitQ using Trigtype Every
Hello Group, the "Concepts and Planing" manual reads oN page 24/25 : "If you have a shared application queue that has trigger type EVERY, use a shared initiation queue or you will lose trigger messages." Uhm can someone answer the "why"?!? Regards Stefan 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
