Thanks (was Creating report messages ends with reason 2035)
Thanks to all, who shared their knowledge with me. I think, I have now several options to check and hopefully there is at least one, which will satisfy my customer and me. Best wishes Hubert Kleinmanns Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: AW: Creating report messages ends with reason 2035
Hubert, With regard to second bit. By default MO71 uses SET_ALL_CONTEXT. In other words it tries to maintain the origin and identity context of the source message. Obviously you need greater authority to use SET_ALL_CONTEXT. There are options in the copy/move message screens to allow you to reduce the context levels. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List [EMAIL PROTECTED] wrote on 22/09/2004 14:51:36: Peter, it is not very satisfying to me. At the moment we require one single user id from the sender application. We created this user and it works so far. But the sender application - from an internal customer - requires itself, to be able to use their personal user accounts. They also want to use COD instead of COA, because they are a little bit paranoid. Another strange thing happens, when I use MQMON (MO71) to move the messages from the DLQ back to the original queue. Now the messages are transmitted to the original sender and they still have the original user id in the MQMD. Why that? Would a DLQ handler work in the same way? Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Potkay, Peter M (ISD, IT) Gesendet: Mittwoch, 22. September 2004 14:13 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 Adequate security never is easy. Your other option is to enforce that all messages coming over have XYZ in the user field, and you only need to grant authority for that one ID. But the problem (maybe its not a problem) is that all the messages have the same ID. The sending app can be modified to do that, or, if the app is an MQClient, then setting the MCAUSER of the SVRCONN channel will tag all the messages with the same ID, assuming nothing like a security exit overrides. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 7:41 AM To: [EMAIL PROTECTED] Subject: AW: Creating report messages ends with reason 2035 Peter, that's what I do NOT want to do. The reason for that is, that the sending side has more than one user, which may be used in the MQMD. I do not now, how many, and if they will change in the future. I want not to be forced to administrate users on my side in order to enable COD reports. Using COA may be an option, but I fear, that the sending side will insist upon using COD. Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Potkay, Peter M (ISD, IT) Gesendet: Mittwoch, 22. September 2004 12:47 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 The solution is you have to define the userID (the one in the MQMD) on the server where the QM that is generating the COD report is running. Or just get by with COA reports. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 5:57 AM To: [EMAIL PROTECTED] Subject: AW: Creating report messages ends with reason 2035 Dave, thanks for your answer (and also Darren). My MQB runs on Solaris, but the put authority of the receiver MCA is set to DEF. So the UserIdentifier in the message is not checked, when the MCA puts the message to the queue. I now understand my problem, but is there a solution? I found some Put Message Options (e. g. MQPMO_ALTERNATE_USER_AUTHORITY, MQPMO_PASS_IDENTITY_CONTEXT). May I use one of these options, to write the report option using another user id than this one, in the message descriptor? I was told, that unknown users are mapped to user and group nobody. To enable this user for the queue shuld solve the problem (described in the System Administration Guide). I tried it, but this did not work. Any other ideas? Thanks in advance. Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von David C. Partridge Gesendet: Mittwoch, 22. September 2004 10:03 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report, except in the following cases: Exception reports generated by a receiving MCA are put with whatever authority the MCA used when it tried to put the message causing the report. The PutAuthority channel attribute determines the user identifier used. COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA's user identifier, the queue manager puts the COA report using the MCA's user identifier. Applications generating reports should normally use the same authority as they
Re: Full userid in channel exits
Hi T.Rob, Thanks very much - as usual! I was poring through the Intercommunication manual so much that I forgot all about the Clients one. Ok - if the answer is NO then so be it and for Java, yes I know but it's only really to stop people creating local versions of system accounts and connecting with those. But I am still a little confused by some of this. In the MQ Clients manual it says: For clients on UNIX systems, Windows 2000, Windows NT, and Windows XP, the user ID that is passed to the server is the currently logged-on user ID on the client. In addition, a client on Windows 2000, Windows NT, or Windows XP passes the security ID of the currently logged-on user. This suggests to me that something other than the userid alone is being passed somehow for WinNT/2000/XP clients. If this is the SID then maybe I could use that (from Unix???). Also from the Clients manual: If the WebSphere MQ client is on Windows 2000, Windows NT, or Windows XP, and the WebSphere MQ server is also on one of these platforms and has access to the domain on which the client user ID is defined, WebSphere MQ supports user IDs of up to 20 characters. : On all other platforms and configurations, the maximum length for user IDs is 12 characters. Now if the Channel agent doesn't receive the Windows user's domain, how does it know whether or not it has access to the client's domain to determine how many characters the userid can be? Cheers, Paul -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T Rob Sent: 22 September 2004 17:22 To: [EMAIL PROTECTED] Subject: Re: Full userid in channel exits Paul, Short answer...no. For the detailed answer, go here: http://publibfp.boulder.ibm.com/epubs/html/csqzaf07/csqzaf071l.htm#Header_331 Basically, this section boils down to this - you can pass the ID as [EMAIL PROTECTED] only by using environment variables. The hitch is that if a connection originates from a Win2k, NT or XP client, IDs in this format are rejected. Presumably this is to enforce validation by the OS on Win platforms where strong domain authentication is supported. Also, the ID does not necessarily need to be a local account or a locally logged on user. The ID presented will be checked against the local SAM database, primary domain or, lastly, any trusted domains. You just don't know which one is matched, if any. And duplicate account names in different domains resolve on a first-matched basis so you may get different results depending on which one matches. Finally, it is possible for a Java client or one using environment variables to present any arbitrary ID. So any scheme you come up with for validating IDs is easily bypassed by an attacker. If your intent is to provide basic authorization among trusted users, perhaps this is sufficient. If you are guarding against external attacks, you may want to consider something stronger. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin, Paul Sent: Wednesday, September 22, 2004 9:37 AM To: [EMAIL PROTECTED] Subject: Full userid in channel exits Hi all, I am writing a channel security exit and would like to be able to determine the Windows domain as well as the userid of an incoming Svrconn connection. Is this possible? All of the fields I've seen only contain the userid itself - even the 'LongUserid' type fields. If this isn't possible, it raises a question about MQ security. Under Windows, the OAM stores principals in the form domain\userid. But does this mean it only checks the userid part for client connections? This would seem to greatly reduce the usefulness of storing the domain since it would only apply to users who are actually logged on and connecting locally to the QMgr. Any help or insight would, as ever, be greatly appreciated. Cheers, Paul Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Disappearing cluster queues
A partial repository will publish information (about it's queues and channels) to two full repositories. A partial repository will subscribe for information (e.g. who hosts the queue called FRED) from two full repositories. The two full repositories used for each subscription will not necessarily be the same two if you have more than two full repositories available. The choice of which full repository used will be, by preference, any that have a manual cluster-sender definition to them and then the standard workload balancing applies to choose between equal choices. So you can control which two full repositories any particular partial uses by defining two manual cluster-sender channels. If you have more than two full repositories, you still should not take more than one off-line at a time, since you could take the only two full repositories that one particular partial is using off-line and therefore that particular partial repository would not receive any updates. If you have a need to take more than one full repository off-line at the same time and your have numerous full repositories, you are advised to alter them to be partial repositories first, which forces the partial repositories using them to remake subscriptions with another full repository, thus ensuring the continued receipt of updates to the resources they are interested in. Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] Potkay, Peter M (ISD, IT) [EMAIL PROTECTED] To HARTFORD.COM [EMAIL PROTECTED] Sent by: MQSeries cc List [EMAIL PROTECTED] Subject N.AC.AT Re: Disappearing cluster queues 22/09/2004 20:44 Please respond to MQSeries List So given FR#1 and FR#2 and FR#3 and FR#4, which FRs get the updates (directly) from PR#1 if PR#1 has a manually defined CLUSSNDR to FR#1, which is all PR#1 needs? Is it random? How does PR#1 decide what other FR it should send its info to? -Original Message- From: Wyatt, T Rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 3:21 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Peter, The full repositories publish to as many other full repositories as they have explicit CLUSSDR definitions for but a partial publishes to only two full repositories no matter how many you have. Once the full repository receives information from a partial, it then republishes to all the other full repositories. So the assertion that the partials only publish to two fulls is correct. So is the notion that you can have more than two full repositories and they are all in synch - assuming you have properly defined CLUSSDR channels between all the repositories. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (ISD, IT) Sent: Wednesday, September 22, 2004 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Hmmm, I think all these statements were written with the assumption that you followed IBM's recommendation that you use only 2 FRs. But I can certainly see why someone would think the info only goes to 2 FRs. I think it would go to all FRs if you had more than 2 because IBM's manuals also state you can have more than 2 FRs, and so do the Conference sessions, and nowhere in them does it say if you have 3 or more FRs, that only 2 would have the info. If FR #3 didn't have all the info, then it wouldn't be a FR. I think you when you define the manual CLUSSNDR to one of your FRs, that FR sends back info to the new QM telling it how to make Automatic CLUSSNDRs to itself, as well as info on how to make Automatic CLUSSNDRs to every other FR it know about, whether it is just FR #2, or FR #2, #3 and #4. But the assumption is that all the FR know about each other, and the only way that can happen is if there is some route between all of them via manual CLUSSNDRs, be it AnyToAny or a Ring connection. Not 100% sure though -Original Message- From: Mike Davidson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 12:58 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I pulled it straight from the MQ conference
Re: Why DEF.CLNTCONN won't get created?
I have seen this behavior as well and I could replicate the conditions that cause it. How to fix it afterwards I do not know. I find that sometimes when you install MQ on the windows platform and you did not allow the installation to create a default queue manager for you, then this situation sometimes arise. So, my solution for this is to ALWAYS allow the installation to create the default queue manager. My first step after installation is then to go in explorer and delete the brand new default queue manager. After this I never experienced any problems with the DEF.* channels. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED], yahoo messenger fmerwe2001 MQSeries [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: MQSeriesSubject: Why DEF.CLNTCONN won't get created? List [EMAIL PROTECTED] N.AC.AT 18/08/2004 15:41 Please respond to MQSeries List I am reposting this problem; your response would be much appreciated Windows2000 servers with WMQ CSD06 (with the fix). After installing WMQ on the server (and BEFORE setting the MQCHL* env. Variables) I created the queue manager using MQExplorer. I have noticed that SYSTEM.DEF.CLNTCONN channel did not get created; and no errors were produced to indicate that. Any ideas why? I deleted the queue manager and re-created it using crtmqm. SYSTEM.DEF.CLNTCONN did not get created this time either-- still no errors in the AMQERR01 file Also, as far as I know if the MQCHL* are specified and they point to a valid path/file, this SYSTEM.DEF.CLNTCONN channel should be created without any probs. But it gives me an error if I use crtmqm (when these variables are set). I does not produce an error if I use MQExplorer to create the qmgr. In either case, the channel won t get created. Anybody has any ideas what might be happening? 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
Re: Disappearing cluster queues
Morag, Owing the following reason that cluster exit can choose repository it like, when we define cluster queue (from a member QM in the cluster), we may not see the cluster queue defined immediately. Is it true? Can REFRESH CLUSTER or other means help to make the cluster queue effective immediately. In some case, we found that we may need to put some test message into the new cluster queue to make it effective. However, this approach is not feasible in a production environment. K K --- Morag Hughson [EMAIL PROTECTED] $:.e!G A partial repository will publish information (about it's queues and channels) to two full repositories. A partial repository will subscribe for information (e.g. who hosts the queue called FRED) from two full repositories. The two full repositories used for each subscription will not necessarily be the same two if you have more than two full repositories available. The choice of which full repository used will be, by preference, any that have a manual cluster-sender definition to them and then the standard workload balancing applies to choose between equal choices. So you can control which two full repositories any particular partial uses by defining two manual cluster-sender channels. If you have more than two full repositories, you still should not take more than one off-line at a time, since you could take the only two full repositories that one particular partial is using off-line and therefore that particular partial repository would not receive any updates. If you have a need to take more than one full repository off-line at the same time and your have numerous full repositories, you are advised to alter them to be partial repositories first, which forces the partial repositories using them to remake subscriptions with another full repository, thus ensuring the continued receipt of updates to the resources they are interested in. Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] Potkay, Peter M (ISD, IT) [EMAIL PROTECTED] To HARTFORD.COM [EMAIL PROTECTED] Sent by: MQSeries cc List [EMAIL PROTECTED] Subject N.AC.AT Re: Disappearing cluster queues 22/09/2004 20:44 Please respond to MQSeries List So given FR#1 and FR#2 and FR#3 and FR#4, which FRs get the updates (directly) from PR#1 if PR#1 has a manually defined CLUSSNDR to FR#1, which is all PR#1 needs? Is it random? How does PR#1 decide what other FR it should send its info to? -Original Message- From: Wyatt, T Rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 3:21 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Peter, The full repositories publish to as many other full repositories as they have explicit CLUSSDR definitions for but a partial publishes to only two full repositories no matter how many you have. Once the full repository receives information from a partial, it then republishes to all the other full repositories. So the assertion that the partials only publish to two fulls is correct. So is the notion that you can have more than two full repositories and they are all in synch - assuming you have properly defined CLUSSDR channels between all the repositories. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (ISD, IT) Sent: Wednesday, September 22, 2004 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Hmmm, I think all these statements were written with the assumption that you followed IBM's recommendation that you use only 2 FRs. But I can certainly see why someone would think the info only goes to 2 FRs. I think it would go to all FRs if you had more than 2 because IBM's manuals also state you can have more than 2 FRs, and so do the Conference sessions, and nowhere in them does it say if you have 3 or more FRs, that only 2 would have the info. If FR #3 didn't have all the info, then it wouldn't be a FR. I think you when you define the manual CLUSSNDR to one of your FRs, that FR sends back info to the new QM telling it how to make Automatic CLUSSNDRs to itself, as well as info on how to make Automatic CLUSSNDRs to every other FR it know about, whether it is just FR #2, or FR #2, #3 and #4. But the
MQFB_APPL_CANNOT_BE_STARTED
Running 5 trigger monitors in the foreground (to limit the amount of triggered applications to max 5 - is there an easier way to do this?). Often see MQFB_APPL_CANNOT_BE_STARTED in the dead-letter queue, but there are no messages in triggered queue that is not handled. Trigger on every. Any ideas? Thanks Francois van der Merwe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: RCVR versus RQSTR channels
Peter, I had the same question and Paul Clarke clarified this in a prior thread. http://www.mail-archive.com/[EMAIL PROTECTED]/msg17173.html Short answer - RQSTR not supported. But Paul provided some hope: I suggest that if this is a problem for anyone that they raise a requirement (if it's a big problem then a PMR although the code is working as designed (and documented) ). The code is easily fixable and wouldn't not take long. Perhaps you will join me in raising this as a requirement? Would be nice to see this in V6 if not CSD08. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (ISD, IT) Sent: Wednesday, September 22, 2004 11:18 PM To: [EMAIL PROTECTED] Subject: Re: RCVR versus RQSTR channels T.Rob wrote(in another thread): ...(AdoptNewMCA not supported on RQSTR channels comes to mind). The SAG says this: AdoptNewMCA=NO|SVR|SDR|RCVR|CLUSRCVR|ALL|FASTPATH Specify one or more values, separated by commas or blanks, from the following list: NO The AdoptNewMCA feature is not required. This is the default. SVR Adopt server channels. SDR Adopt sender channels. RCVR Adopt receiver channels. CLUSRCVR Adopt cluster receiver channels. ALL Adopt all channel types except FASTPATH channels. FASTPATH Adopt the channel if it is a FASTPATH channel. This happens only if the appropriate channel type is also specified, for example, AdoptNewMCA=RCVR,SVR,FASTPATH. Does ALL really mean ALL, or just ALL OF THE ABOVE? If RQSTRs really don't support this, to me, that strongly swings the favor back to RCVRs if it is true. I think AdoptNewMCA is gonna save me more headaches than being able to start a channel originating from another company, no? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Full userid in channel exits
Paul, Yes, they are talking about the SID but I don't know how you might look that up from Unix. I raised a requirement a while back to add PCF commands to display authorities specifically for that reason. I was able to parse the format of the AUTH DATA messages and created a Unix client to display them from a central web server. This worked fine for Unix servers where the group name is human-readable, but on a Windows box, the AUTH.DATA queue contains SIDs. I never found a way for my Unix machine to parse the SIDs that didn't violate one security policy or another so I raised a requirement that MQ do it for me. Obviously, the Windows QMgr has the ability to do this translation because AMQOAMD does it. As to your second question about how the client and server know whether they have a domain in common, I don't know. I assume this is part of the SVRCONN channel negotiation but frankly, this is just a guess. I know that SIDs are variable length and range from a small hash of an ID to a longer field where the ID is fully qualified by the domain. So based on that, I would think the channel would pass your fully-qualified SID to the QMgr first and fall back to more and more generic versions until the QMgr accepted one. Of course, this is all conjecture. Maybe one of our friendly neighborhood IBM wizards will provide more (or at least more accurate) detail. :-) -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin, Paul Sent: Thursday, September 23, 2004 5:13 AM To: [EMAIL PROTECTED] Subject: Re: Full userid in channel exits Hi T.Rob, Thanks very much - as usual! I was poring through the Intercommunication manual so much that I forgot all about the Clients one. Ok - if the answer is NO then so be it and for Java, yes I know but it's only really to stop people creating local versions of system accounts and connecting with those. But I am still a little confused by some of this. In the MQ Clients manual it says: For clients on UNIX systems, Windows 2000, Windows NT, and Windows XP, the user ID that is passed to the server is the currently logged-on user ID on the client. In addition, a client on Windows 2000, Windows NT, or Windows XP passes the security ID of the currently logged-on user. This suggests to me that something other than the userid alone is being passed somehow for WinNT/2000/XP clients. If this is the SID then maybe I could use that (from Unix???). Also from the Clients manual: If the WebSphere MQ client is on Windows 2000, Windows NT, or Windows XP, and the WebSphere MQ server is also on one of these platforms and has access to the domain on which the client user ID is defined, WebSphere MQ supports user IDs of up to 20 characters. : On all other platforms and configurations, the maximum length for user IDs is 12 characters. Now if the Channel agent doesn't receive the Windows user's domain, how does it know whether or not it has access to the client's domain to determine how many characters the userid can be? Cheers, Paul Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQFB_APPL_CANNOT_BE_STARTED
We had a similar issue that was answered by placing the following environmental variable in .profile and any crontab scripts doing a start of the triggers: # Defect 72854 - APAR IY39949 - trigger mesg X109 - MQFB_APPL_CANNON_BE_STARTED export AMQ_SIGCHLD_SIGACTION=YES Good Luck Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Francois Van der Merwe1 Sent: Thursday, September 23, 2004 7:58 AM To: [EMAIL PROTECTED] Subject: MQFB_APPL_CANNOT_BE_STARTED Running 5 trigger monitors in the foreground (to limit the amount of triggered applications to max 5 - is there an easier way to do this?). Often see MQFB_APPL_CANNOT_BE_STARTED in the dead-letter queue, but there are no messages in triggered queue that is not handled. Trigger on every. Any ideas? Thanks Francois van der Merwe Instructions for managing your mailing list 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 message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Smalltalk to MQ 5.3 with SSL
Has anyone looked into whether Smalltalk (IBM VA Smalltalk 6.0.x specifically) can be used to connect to a SVRCONN with SSL setup? Regards, -tom
ERROR Message AMQ5529
Morning, We are getting error message AMQ5529 in our AMQERR01.LOG file. We are running MQ 5.3 csd5 on a Sun Solaris 5.02 server. The 5529 error message began appearing after we applied fix patches to the operating system. This error seems to be generated when we attempt a client connection from WebSphere release 5.02. Is there anyone out there experiencing a similar problem? 09/22/04 05:15:48 PM AMQ5529: The Remote OAM Service is not available. EXPLANATION: The Remote OAM service is not available. The '-1' call returned -1, errno 146 : 'connect'. The context string is 'ECONNREFUSED' ACTION: To extend access to this object use the setmqaut command, see the WebSphere MQ System Administration documentation for details. Thanks Louis Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
FW: ERROR Message AMQ5529
-Original Message- From: Louis.Commodore Sent: Thursday, September 23, 2004 9:29 AM To: 'MQSeries List' Subject: ERROR Message AMQ5529 Morning, We are getting error message AMQ5529 in our AMQERR01.LOG file. We are running MQ 5.3 csd5 on a Sun Solaris 5.02 server. The 5529 error message began appearing after we applied fix patches to the operating system. This error seems to be generated when we attempt a client connection from WebSphere release 5.02. Is there anyone out there experiencing a similar problem? 09/22/04 05:15:48 PM AMQ5529: The Remote OAM Service is not available. EXPLANATION: The Remote OAM service is not available. The '-1' call returned -1, errno 146 : 'connect'. The context string is 'ECONNREFUSED' ACTION: To extend access to this object use the setmqaut command, see the WebSphere MQ System Administration documentation for details. Thanks Louis Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: AW: Creating report messages ends with reason 2035
I hesitate to contradict Dennis because he is usually rightbut I don't think so in this case. An app could set a blank userid with MQPMO_SET_IDENTITY_CONTEXT (no put failure because the authority of the userid which is running the app is used). The MCA then puts to the destination queue (under the authority of the ID running the MCA, so no failure). I'll have to try it out in the morning though. Most likely way for a userid to become blank in transit - a message exit on the channel tinkering with it... Regards Darren - Original Message - From: Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 4:59 PM Subject: Re: AW: Creating report messages ends with reason 2035 If you put blank in MD.userid, the qmgr fills it in on the MQ put. If somehow, it became blank in transit (how?), I think the MCA would have difficulty accepting the message and would pop it to the DLQ. -Original Message- From: Bright, Frank [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 6:49 AM To: [EMAIL PROTECTED] Subject: Re: AW: Creating report messages ends with reason 2035 What happens if the Userid is blank in the MQMD? Does it inherit the Userid of the MCA? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Darren Douch Sent: Wednesday, September 22, 2004 8:38 AM To: [EMAIL PROTECTED] Subject: Re: AW: Creating report messages ends with reason 2035 I don't believe there is a way to get around the COD being generated under the ID in the MQMD. You need to authorise all those userids, or implement some scheme (exits, other software products) to modify the userid field before it hits the queue. Another alternative would be to use PAN report instead of COD, and get your application to generate the acknowledgement (you could even get your application to label its PAN as a COD if you've got no purists breathing down your neck), and this would be done under the authority of the user running the getting application. Regards Darren - Original Message - From: Kleinmanns, Hubert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 12:40 PM Subject: AW: Creating report messages ends with reason 2035 Peter, that's what I do NOT want to do. The reason for that is, that the sending side has more than one user, which may be used in the MQMD. I do not now, how many, and if they will change in the future. I want not to be forced to administrate users on my side in order to enable COD reports. Using COA may be an option, but I fear, that the sending side will insist upon using COD. Regards Hubert -Urspr|ngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Potkay, Peter M (ISD, IT) Gesendet: Mittwoch, 22. September 2004 12:47 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 The solution is you have to define the userID (the one in the MQMD) on the server where the QM that is generating the COD report is running. Or just get by with COA reports. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 5:57 AM To: [EMAIL PROTECTED] Subject: AW: Creating report messages ends with reason 2035 Dave, thanks for your answer (and also Darren). My MQB runs on Solaris, but the put authority of the receiver MCA is set to DEF. So the UserIdentifier in the message is not checked, when the MCA puts the message to the queue. I now understand my problem, but is there a solution? I found some Put Message Options (e. g. MQPMO_ALTERNATE_USER_AUTHORITY, MQPMO_PASS_IDENTITY_CONTEXT). May I use one of these options, to write the report option using another user id than this one, in the message descriptor? I was told, that unknown users are mapped to user and group nobody. To enable this user for the queue shuld solve the problem (described in the System Administration Guide). I tried it, but this did not work. Any other ideas? Thanks in advance. Hubert -Urspr|ngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von David C. Partridge Gesendet: Mittwoch, 22. September 2004 10:03 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report, except in the following cases: Exception reports generated by a receiving MCA are put with whatever authority the MCA used when it tried to put the message causing the report. The PutAuthority channel attribute determines the user identifier used. COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA's user identifier, the queue manager puts the
Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING
Hello, I have set 'OFFLOAD' parm to 'YES'' in CSQ6LOGP macro (ZPARM). But I am getting the following error: See below: 11.04.48 STC30845 CSQJ073E S1* LOG ARCHIVE UNIT ALLOCATION FAILURE 980 980 DETECTED, RETURN CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA ARCHIVE 980 SET MAY FAIL CSQJ073E and CODE=008 means 8 ( X'08') Unit name has incorrect units assigned Which unit is invalid? And what do I need to do to have the ARCHIVE LOG MODE QUIESCE works and quiesce for 40 seconds? Thanks. 11.04.48 STC30845 CSQJ309I S1* SYNCHRONOUS ARCHIVE LOG COMMAND QUIESCE 967 967 PROCESSING STARTING FOR MAXIMUM OF 40 SECONDS 11.04.48 STC30845 CSQJ002I S1* END OF ACTIVE LOG DATA SET 968 968 DSNAME=T33V.MQS1.LOGCOPY1.DS05, STARTRBA=0002E000 968 ENDRBA=00031FFF 11.04.48 STC30845 CSQJ001I S1* CURRENT COPY 1 ACTIVE LOG DATA SET IS 969 969 DSNAME=T33V.MQS1.LOGCOPY1.DS01, STARTRBA=00032000 969 ENDRBA=00469FFF 11.04.48 STC30845 CSQJ002I S1* END OF ACTIVE LOG DATA SET 970 970 DSNAME=T33V.MQS1.LOGCOPY2.DS05, STARTRBA=0002E000 970 ENDRBA=00031FFF 11.04.48 STC30845 CSQJ001I S1* CURRENT COPY 2 ACTIVE LOG DATA SET IS 971 971 DSNAME=T33V.MQS1.LOGCOPY2.DS01, STARTRBA=00032000 971 ENDRBA=00469FFF 11.04.48 STC30845 CSQJ311I S1* ASYNCHRONOUS LOG ARCHIVE (OFFLOAD) TASK INITIATE 11.04.48 STC30845 CSQP018I S1* CSQPBCKW CHECKPOINT STARTED FOR ALL BUFFER POOLS 11.04.48 STC30845 CSQJ312I S1* ARCHIVE LOG QUIESCE ENDED, UPDATE ACTIVITY IS NO 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 975 11.04.48 STC30845 CSQ9022I S1* CSQJC001 ' ARCHIVE LOG' NORMAL COMPLETION 11.04.48 STC30845 S1* DISPLAY THREAD(*) TYPE(INDOUBT) 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 978 978 POOL 3, 0 PAGES WRITTEN 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 979 979 POOL 1, 5 PAGES WRITTEN 11.04.48 STC30845 CSQJ073E S1* LOG ARCHIVE UNIT ALLOCATION FAILURE 980 980 DETECTED, RETURN CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA ARCHIVE 980 SET MAY FAIL 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 981 981 POOL 0, 14 PAGES WRITTEN 11.04.48 STC30845 IEF233D M 5014,PRIVAT,SL,MQS1MSTR,MQS1MSTR,T33.MQS1.ARC1.B000 982 OR RESPOND TO IEF455D MESSAGE 11.04.48 STC30845 CSQV401I S1* DISPLAY THREAD REPORT FOLLOWS - 11.04.48 STC30845 CSQP021I S1* Page set 0 new media recovery 984 11.04.48 STC30845 CSQV420I S1* NO INDOUBT THREADS FOUND 984 RBA=000335BD, checkpoint RBA=000335BD 11.04.48 STC30845 CSQ9022I S1* CSQVDT ' DISPLAY THREAD' NORMAL COMPLETION 11.04.48 STC30845 CSQP021I S1* Page set 1 new media recovery 987 987 RBA=000335BD, checkpoint RBA=000335BD 11.04.48 STC30845 CSQP021I S1* Page set 2 new media recovery 988 988 RBA=0002FB74, checkpoint RBA=0002FB74 11.04.48 STC30845 CSQP021I S1* Page set 3 new media recovery 989 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Art Schanz Sent: Tuesday, September 21, 2004 12:37 AM To: [EMAIL PROTECTED] Subject: Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING MAC, You have the 'OFFLOAD' parm set to 'NO' in your CSQ6LOGP macro (ZPARM). That gives you the 'ARCHIVING IS OFF' msg (CSQJ308I). Also, the 'TIME(40)' is the amount of time that MQ can use to reach a system-wide quiesce point. It does not stop MQ for 40 seconds, rather it can take up to 40 seconds to quiesce all update activity in the subsystem. Cheers, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology AIMS - WebSphere MQ Support IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 [EMAIL PROTECTED] Middleware Group Mailbox [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 09/20/2004 08:53 PM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING Hello MQers, This is about the ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) The command above is supposed to quiesce the queue manager for 40 seconds but the quiesce is ending in the first second. 19.32.34 STC30221 CSQJ308I S1* LOG NOT OFFLOADED FOR ARCHIVE LOG 442 442 COMMAND, ARCHIVING IS OFF 19.32.34 STC30221 CSQJ312I S1* ARCHIVE LOG QUIESCE ENDED, UPDATE ACTIVITY IS NO Why it is not quiescing for 40 seconds? Can someone shed some light on that? Thanks,... MAC This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited.
Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING
Mac, I suggest you read the message from the manual, there is something wrong with your ZPARM definitions (unit name) Good luck. Regards,Rabofacet Erik DijkermanPIM/OS390Infra Services+31 30-2154878The only real mistake is the one from which we learn nothing. -- John Powell -Oorspronkelijk bericht-Van: MQSeries List [mailto:[EMAIL PROTECTED]namens Middleware Group MailboxVerzonden: donderdag 23 september 2004 17:22Aan: [EMAIL PROTECTED]Onderwerp: Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING Hello, I have set 'OFFLOAD' parm to 'YES'' in CSQ6LOGP macro (ZPARM). But I am getting the following error: See below: 11.04.48 STC30845 CSQJ073E S1* LOG ARCHIVE UNIT ALLOCATION FAILURE 980 980 DETECTED, RETURN CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA ARCHIVE 980 SET MAY FAIL CSQJ073E and CODE=008 means 8 ( X'08') Unit name has incorrect units assigned Which unit is invalid? And what do I need to do to have the ARCHIVE LOG MODE QUIESCE works and quiesce for 40 seconds? Thanks. 11.04.48 STC30845 CSQJ309I S1* SYNCHRONOUS ARCHIVE LOG COMMAND QUIESCE 967 967 PROCESSING STARTING FOR MAXIMUM OF 40 SECONDS 11.04.48 STC30845 CSQJ002I S1* END OF ACTIVE LOG DATA SET 968 968 DSNAME=T33V.MQS1.LOGCOPY1.DS05, STARTRBA=0002E000 968 ENDRBA=00031FFF 11.04.48 STC30845 CSQJ001I S1* CURRENT COPY 1 ACTIVE LOG DATA SET IS 969 969 DSNAME=T33V.MQS1.LOGCOPY1.DS01, STARTRBA=00032000 969 ENDRBA=00469FFF 11.04.48 STC30845 CSQJ002I S1* END OF ACTIVE LOG DATA SET 970 970 DSNAME=T33V.MQS1.LOGCOPY2.DS05, STARTRBA=0002E000 970 ENDRBA=00031FFF 11.04.48 STC30845 CSQJ001I S1* CURRENT COPY 2 ACTIVE LOG DATA SET IS 971 971 DSNAME=T33V.MQS1.LOGCOPY2.DS01, STARTRBA=00032000 971 ENDRBA=00469FFF 11.04.48 STC30845 CSQJ311I S1* ASYNCHRONOUS LOG ARCHIVE (OFFLOAD) TASK INITIATE 11.04.48 STC30845 CSQP018I S1* CSQPBCKW CHECKPOINT STARTED FOR ALL BUFFER POOLS 11.04.48 STC30845 CSQJ312I S1* ARCHIVE LOG QUIESCE ENDED, UPDATE ACTIVITY IS NO 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 975 11.04.48 STC30845 CSQ9022I S1* CSQJC001 ' ARCHIVE LOG' NORMAL COMPLETION 11.04.48 STC30845 S1* DISPLAY THREAD(*) TYPE(INDOUBT) 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 978 978 POOL 3, 0 PAGES WRITTEN 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 979 979 POOL 1, 5 PAGES WRITTEN 11.04.48 STC30845 CSQJ073E S1* LOG ARCHIVE UNIT ALLOCATION FAILURE 980 980 DETECTED, RETURN CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA ARCHIVE 980 SET MAY FAIL 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 981 981 POOL 0, 14 PAGES WRITTEN 11.04.48 STC30845 IEF233D M 5014,PRIVAT,SL,MQS1MSTR,MQS1MSTR,T33.MQS1.ARC1.B000 982 OR RESPOND TO IEF455D MESSAGE 11.04.48 STC30845 CSQV401I S1* DISPLAY THREAD REPORT FOLLOWS - 11.04.48 STC30845 CSQP021I S1* Page set 0 new media recovery 984 11.04.48 STC30845 CSQV420I S1* NO INDOUBT THREADS FOUND 984 RBA=000335BD, checkpoint RBA=000335BD 11.04.48 STC30845 CSQ9022I S1* CSQVDT ' DISPLAY THREAD' NORMAL COMPLETION 11.04.48 STC30845 CSQP021I S1* Page set 1 new media recovery 987 987 RBA=000335BD, checkpoint RBA=000335BD 11.04.48 STC30845 CSQP021I S1* Page set 2 new media recovery 988 988 RBA=0002FB74, checkpoint RBA=0002FB74 11.04.48 STC30845 CSQP021I S1* Page set 3 new media recovery 989 -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Art SchanzSent: Tuesday, September 21, 2004 12:37 AMTo: [EMAIL PROTECTED]Subject: Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING MAC, You have the 'OFFLOAD' parm set to 'NO' in your CSQ6LOGP macro (ZPARM). That gives you the 'ARCHIVING IS OFF' msg (CSQJ308I). Also, the 'TIME(40)' is the amount of time that MQ can use to reach a system-wide quiesce point. It does not stop MQ for 40 seconds, rather it can take up to 40 seconds to quiesce all update activity in the subsystem. Cheers, ArtArthur C. SchanzOperating Systems Programmer I. - SpecialistFederal Reserve Information TechnologyAIMS - WebSphere MQ SupportIBM Certified System Administrator - WebSphere MQ V5.3IBM Certified Solution Designer - WebSphere MQ V5.3[EMAIL PROTECTED] Middleware
Re: MQFB_APPL_CANNOT_BE_STARTED
Second question: The trigger monitor reads the trigger message, starts the triggered application it specifies, and waits for it to complete. If the triggered application processes a message successfully, but then exits with non-zero return code, the trigger monitor will think something went wrong and place the trigger message in the DLQ with that feedback code. First question: Yes, start 5 instances of a long-running program to read the application queue and be done with it. I don't have time right now to re-hash the drawbacks of your triggering design, but let me say this. The sole point of triggering is to minimize the number of long-running tasks. With triggering designs, a single long-running task can respond to conditions on many queues and dynamically invoke processes as needed. Running 5 trigger monitors for a single queue defeats that purpose. What do you think of this idea? In your email application, create two special mailboxes for messages from the listserv. Establish an automated response to direct any listserv mail to mailbox 1. At the same time, have the automated response generate an additional email in mailbox 2, saying something like listserv mail has arrived in mailbox 1. Then, just read mailbox 2 to know when you have mail in mailbox 1. -Original Message- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 4:58 AM To: [EMAIL PROTECTED] Subject: MQFB_APPL_CANNOT_BE_STARTED Running 5 trigger monitors in the foreground (to limit the amount of triggered applications to max 5 - is there an easier way to do this?). Often see MQFB_APPL_CANNOT_BE_STARTED in the dead-letter queue, but there are no messages in triggered queue that is not handled. Trigger on every. Any ideas? Thanks Francois van der Merwe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING
Thanks for the suggestion I fixed the UNIT problem in the ZPARM. I submitted the ARCHIVE command: OC C(S1* ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) I have no error now in the LOG. But although I am setting TIME(40) seconds, the QUIESCE last less than a second. Is this possible, since I am testing in a testing Qmanager where there is no activity? Thanks, MAC. 13.28.56 STC30928 CSQJ309I S1* SYNCHRONOUS ARCHIVE LOG COMMAND QUIESCE 770 770 PROCESSING STARTING FOR MAXIMUM OF 40 SECONDS 13.28.56 STC30928 CSQJ002I S1* END OF ACTIVE LOG DATA SET 771 771 DSNAME=T33V.MQS1.LOGCOPY1.DS03, STARTRBA=00048000 771 ENDRBA=00052FFF . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.28.56 STC30928 CSQJ311I S1* ASYNCHRONOUS LOG ARCHIVE (OFFLOAD) TASK INITIATE 13.28.56 STC30928 CSQP018I S1* CSQPBCKW CHECKPOINT STARTED FOR ALL BUFFER POOLS 13.28.56 STC30928 CSQJ312I S1* ARCHIVE LOG QUIESCE ENDED, UPDATE ACTIVITY IS NOW RESUMED 13.28.56 STC30928 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 778 13.28.56 STC30928 S1* DISPLAY THREAD(*) TYPE(INDOUBT) 778 POOL 0, 0 PAGES WRITTEN 13.28.56 STC30928 CSQ9022I S1* CSQJC001 ' ARCHIVE LOG' NORMAL COMPLETION 13.28.56 STC30928 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 781 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Dijkerman, E (Erik) Sent: Thursday, September 23, 2004 11:28 AM To: [EMAIL PROTECTED] Subject: Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING Mac, I suggest you read the message from the manual, there is something wrong with your ZPARM definitions (unit name) Good luck. Regards, Rabofacet Erik Dijkerman PIM/OS390 Infra Services +31 30-2154878 The only real mistake is the one from which we learn nothing. -- John Powell -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED]namens Middleware Group Mailbox Verzonden: donderdag 23 september 2004 17:22 Aan: [EMAIL PROTECTED] Onderwerp: Re: z/OS ARCHIVE LOG MODE(QUIESCE) TIME(40) WAIT(YES)) is nOT QUIESC ING Hello, I have set 'OFFLOAD' parm to 'YES'' in CSQ6LOGP macro (ZPARM). But I am getting the following error: See below: 11.04.48 STC30845 CSQJ073E S1* LOG ARCHIVE UNIT ALLOCATION FAILURE 980 980 DETECTED, RETURN CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA ARCHIVE 980 SET MAY FAIL CSQJ073E and CODE=008 means 8 ( X'08') Unit name has incorrect units assigned Which unit is invalid? And what do I need to do to have the ARCHIVE LOG MODE QUIESCE works and quiesce for 40 seconds? Thanks. 11.04.48 STC30845 CSQJ309I S1* SYNCHRONOUS ARCHIVE LOG COMMAND QUIESCE 967 967 PROCESSING STARTING FOR MAXIMUM OF 40 SECONDS 11.04.48 STC30845 CSQJ002I S1* END OF ACTIVE LOG DATA SET 968 968 DSNAME=T33V.MQS1.LOGCOPY1.DS05, STARTRBA=0002E000 968 ENDRBA=00031FFF 11.04.48 STC30845 CSQJ001I S1* CURRENT COPY 1 ACTIVE LOG DATA SET IS 969 969 DSNAME=T33V.MQS1.LOGCOPY1.DS01, STARTRBA=00032000 969 ENDRBA=00469FFF 11.04.48 STC30845 CSQJ002I S1* END OF ACTIVE LOG DATA SET 970 970 DSNAME=T33V.MQS1.LOGCOPY2.DS05, STARTRBA=0002E000 970 ENDRBA=00031FFF 11.04.48 STC30845 CSQJ001I S1* CURRENT COPY 2 ACTIVE LOG DATA SET IS 971 971 DSNAME=T33V.MQS1.LOGCOPY2.DS01, STARTRBA=00032000 971 ENDRBA=00469FFF 11.04.48 STC30845 CSQJ311I S1* ASYNCHRONOUS LOG ARCHIVE (OFFLOAD) TASK INITIATE 11.04.48 STC30845 CSQP018I S1* CSQPBCKW CHECKPOINT STARTED FOR ALL BUFFER POOLS 11.04.48 STC30845 CSQJ312I S1* ARCHIVE LOG QUIESCE ENDED, UPDATE ACTIVITY IS NO 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 975 11.04.48 STC30845 CSQ9022I S1* CSQJC001 ' ARCHIVE LOG' NORMAL COMPLETION 11.04.48 STC30845 S1* DISPLAY THREAD(*) TYPE(INDOUBT) 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 978 978 POOL 3, 0 PAGES WRITTEN 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 979 979 POOL 1, 5 PAGES WRITTEN 11.04.48 STC30845 CSQJ073E S1* LOG ARCHIVE UNIT ALLOCATION FAILURE 980 980 DETECTED, RETURN CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA ARCHIVE 980 SET MAY FAIL 11.04.48 STC30845 CSQP019I S1* CSQP1DWP CHECKPOINT COMPLETED FOR BUFFER 981 981 POOL 0, 14 PAGES WRITTEN 11.04.48 STC30845 IEF233D M 5014,PRIVAT,SL,MQS1MSTR,MQS1MSTR,T33.MQS1.ARC1.B000 982 OR RESPOND TO IEF455D MESSAGE 11.04.48 STC30845 CSQV401I S1* DISPLAY THREAD REPORT FOLLOWS - 11.04.48 STC30845 CSQP021I S1* Page set 0 new media recovery 984 11.04.48 STC30845 CSQV420I S1* NO INDOUBT THREADS FOUND 984 RBA=000335BD, checkpoint RBA=000335BD 11.04.48 STC30845 CSQ9022I S1* CSQVDT ' DISPLAY THREAD' NORMAL COMPLETION 11.04.48 STC30845 CSQP021I S1* Page set 1 new media recovery 987 987 RBA=000335BD, checkpoint RBA=000335BD 11.04.48 STC30845 CSQP021I S1* Page set 2 new
mqseries layout
I am new to mqseries and would like to know where I could find some information on designing the layout of mqseries eg. if it is a distributed system can the queues be on a different machine than the queue manager is on, if using a cross platform implementation are there extra considerations for z/os to unix etc. In a nutshell I would like to know if there are any documents that describes high level architectural considerations when designing a layout of an mqseries project. Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers!
Re: AW: Creating report messages ends with reason 2035
You are right, so fire away. I wasn't sure how to get a blank userid, but it does appear PMO_SET_IDENTITY_CONTEXT or PMO_NO_CONTEXT would do the trick. The authority used by the receiving MCA depends on the PUTAUT option of the channel definition. I have no way to test it right now, but I expect whether a blank userid gets through depends on that. -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 3:45 PM To: [EMAIL PROTECTED] Subject: Re: AW: Creating report messages ends with reason 2035 I hesitate to contradict Dennis because he is usually rightbut I don't think so in this case. An app could set a blank userid with MQPMO_SET_IDENTITY_CONTEXT (no put failure because the authority of the userid which is running the app is used). The MCA then puts to the destination queue (under the authority of the ID running the MCA, so no failure). I'll have to try it out in the morning though. Most likely way for a userid to become blank in transit - a message exit on the channel tinkering with it... Regards Darren - Original Message - From: Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 4:59 PM Subject: Re: AW: Creating report messages ends with reason 2035 If you put blank in MD.userid, the qmgr fills it in on the MQ put. If somehow, it became blank in transit (how?), I think the MCA would have difficulty accepting the message and would pop it to the DLQ. -Original Message- From: Bright, Frank [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 6:49 AM To: [EMAIL PROTECTED] Subject: Re: AW: Creating report messages ends with reason 2035 What happens if the Userid is blank in the MQMD? Does it inherit the Userid of the MCA? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Darren Douch Sent: Wednesday, September 22, 2004 8:38 AM To: [EMAIL PROTECTED] Subject: Re: AW: Creating report messages ends with reason 2035 I don't believe there is a way to get around the COD being generated under the ID in the MQMD. You need to authorise all those userids, or implement some scheme (exits, other software products) to modify the userid field before it hits the queue. Another alternative would be to use PAN report instead of COD, and get your application to generate the acknowledgement (you could even get your application to label its PAN as a COD if you've got no purists breathing down your neck), and this would be done under the authority of the user running the getting application. Regards Darren - Original Message - From: Kleinmanns, Hubert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 12:40 PM Subject: AW: Creating report messages ends with reason 2035 Peter, that's what I do NOT want to do. The reason for that is, that the sending side has more than one user, which may be used in the MQMD. I do not now, how many, and if they will change in the future. I want not to be forced to administrate users on my side in order to enable COD reports. Using COA may be an option, but I fear, that the sending side will insist upon using COD. Regards Hubert -Urspr|ngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Potkay, Peter M (ISD, IT) Gesendet: Mittwoch, 22. September 2004 12:47 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 The solution is you have to define the userID (the one in the MQMD) on the server where the QM that is generating the COD report is running. Or just get by with COA reports. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 5:57 AM To: [EMAIL PROTECTED] Subject: AW: Creating report messages ends with reason 2035 Dave, thanks for your answer (and also Darren). My MQB runs on Solaris, but the put authority of the receiver MCA is set to DEF. So the UserIdentifier in the message is not checked, when the MCA puts the message to the queue. I now understand my problem, but is there a solution? I found some Put Message Options (e. g. MQPMO_ALTERNATE_USER_AUTHORITY, MQPMO_PASS_IDENTITY_CONTEXT). May I use one of these options, to write the report option using another user id than this one, in the message descriptor? I was told, that unknown users are mapped to user and group nobody. To enable this user for the queue shuld solve the problem (described in the System Administration Guide). I tried it, but this did not work. Any other ideas? Thanks in advance. Hubert -Urspr|ngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von David C. Partridge Gesendet: Mittwoch, 22. September 2004 10:03 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the
Re: Disappearing cluster queues
Each subscription made will only be made to two full repositories. That doesn't mean every publication/subscription is made to only the same two full repositories. The choice of full repositories is made using the usual workload balancing algorithm with a preference for manual defined cluster-senders. If a number are equal choices, then the subscriptions will be round robin-ed. A partial repository is told when it first connects to the cluster, what the route to all full repositories are so that it can use it for the above choice of subscriptions. I attach a small pdf of the relevant pages from the Administering Clusters presentation that gets given at the various conferences which is a very good source of information about this. (See attached file: S1133_Part.pdf) Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] Potkay, Peter M (ISD, IT) [EMAIL PROTECTED] To HARTFORD.COM [EMAIL PROTECTED] Sent by: MQSeries cc List [EMAIL PROTECTED] Subject N.AC.AT Re: Disappearing cluster queues 23/09/2004 16:36 Please respond to MQSeries List Morag, the below testing contradicts your post that says a PR only talks to 2 FR directly. ??? I just issued a REFRESH CLUSTER(CLUSTER1) command from PR1, and the channels to FR1, FR2 and FR3 all started up. 5.3 CSD04 Windows XP SP1 All testing done via MO71. When I added FR4 to the FR ring after PR1 was introduced, PR1 did made an Auto CLUSSNDR channels to FR4 immediately. When I added PR2 to the cluster, it made Auto CLUSSNDR channels to all 4 FRs immediatly. -Original Message- From: Potkay, Peter M (ISD, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 11:57 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I did the following in the order listed: Create queue manager FR1, FR2 and FR3 Define CLUSRCVRs on FR1 called TO.FR1, on FR2 called TO.FR2 and on FR3 called TO.FR3, all with the CLUSTER attribute set to CLUSTER1 Alter each QM to be a Full Repository for CLUSTER1 Manually define CLUSSNDRs on each FR to both other FRs (on FR1 create CLUSSNDRs TO.FR2 and TO.FR3, on FR2 create CLUSSNDRs TO.FR1 and TO.FR3, on FR3 create CLUSSNDRs TO.FR1 and TO.FR1) I have a ring of three FRs. Now I create queue manager PR1, define a CLUSRCVR called TO.PR1 clustered to CLUSTER1, and then define one and only one CLUSSNDR to FR1. Without doing anything else, PR1 immediately had Automatic CLUSSNDRs to all 3 FRs. Looks like a PR defines Auto CLUSSNDRs to every FR in the cluster. I check the Sequence Numbers of the channels leaving PR1 TO.FR1=6 TO.FR2=5 TO.FR3=2 Now I create 1 local queue called PR1.LOCAL.QUEUE on PR1, and cluster it to CLUSTER1. All 3 Auto CLUSSNDRs start running. Looking at the sequence numbers again, I see: TO.FR1=8 TO.FR2=6 TO.FR3=3 To me, this indicates that a partial repository QM in a cluster sends its info directly to ALL full repositories in a cluster, regardless of how many there are. As for the question about overlapping clusters, I have 1 Gateway QM that is a partial repository for four overlapping clusters. Each of the clusters has only 2 other QMs, and those are the Full Repositories for their respective clusters. If a create a queue on the Gateway QM, and cluster it to the Cluster Namelist, all 8 FRs know about the new queue right away, and they get that info directly from the Gateway QM. -Original Message- From: Wyatt, T Rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 4:14 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Peter, FR#1 gets an update (or at least an attempt) every time. If I remember correctly, the secondary FR is chosen using cluster workload balancing - PUT-enabled cluster command queue, FR#_ is not suspended, NETPRTY on the channels, etc. I know Jill covered this in class but I can't remember for sure. If you were to define two explicit CLUSSDRs to two FRs however, then those two are always used. What is not clear to me is what happens if you advertise a queue in two different overlapping clusters with two distinct full repositories each (4 FRs in 2 clusters). Does the partial repository publish to two fulls *per cluster* or two fulls
Re: mqseries layout
MQ series planning guide provided by IBM should give you a fair picture on the framework architecture. Cheers, Bharath GP [EMAIL PROTECTED]To: [EMAIL PROTECTED] O.COM cc: (bcc: bharathram.s/Polaris) Sent by: Subject: mqseries layout MQSeries List [EMAIL PROTECTED] ien.AC.AT 09/23/04 03:16 PM Please respond to MQSeries List I am new to mqseries and would like to know where I could find some information on designing the layout of mqseries eg. if it is a distributed system can the queues be on a different machine than the queue manager is on, if using a cross platform implementation are there extra considerations for z/os to unix etc. In a nutshell I would like to know if there are any documents that describes high level architectural considerations when designing a layout of an mqseries project. Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in
