Hubert, There is a very ugly solution (but works): when messages arriving into the dead-letter-queue, runmqdlq can re-route these with mqm authority.
entry in rules table for runmqdlq: reason(2035) msgtype(MQMT_REPORT) action(retry) Tibor ---- > 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 would have used to generate a reply; this should normally be the >> authority of the user identifier in the original message. >> >> So, if this is a remote QM to the originator, then this should be being > PUT >> with the authority of the MCA the originally put it onto the input Q. >> Whether this authority is enough to write to the TQ to go back depends on >> the platform and what user was running the MCA. For distributed > platforms >> the user running the MCA will almost always be mqm or equivalent so it >> should work, but for the 390 system, the authority is defined by the RACF >> permissions and the value of the setting of PUTAUT on the receiver > channel. >> This is discussed in chapter 15 and 17 of the z/OS System Setup Guide. >> >> So my guess is that the receiving system is 390 and that you are running >> your receiver channels with ALTMCA and that the CHIN is writing OK to the >> output Q, but when the getter gets the message the only authority left is >> the ALT part of ALTMCA. Perhaps someone with more experience of 390 > access >> control for MQ can comment it this is a 390 system. >> >> Dave >> -----Original Message----- >> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of >> Kleinmanns, Hubert >> Sent: 22 September 2004 08:14 >> To: [EMAIL PROTECTED] >> Subject: Creating report messages ends with reason 2035 >> >> >> MQ-Guys, >> >> I have the following situation: >> >> 1. An application "APP1" on qmgr "MQ1", running as a user "mqusr1", > creates >> a message and sends it to a qmgr "MQ2". "APP1" sets the report options to >> "MQRO_COD" + "MQRO_EXCEPTION" + "MQRO_PASS_MSG_ID" + > "MQRO_PASS_CORREL_ID" >> (I think, relevant in my case is only "MQRO_COD" ). >> >> 2. Application "APP2" on qmgr "MQ2", running as a user "mqusr2", reads > the >> message successfully. But when "APP2" tries to put the report message, it >> fails with the reason code 2035 and the message is put to the local DLQ. >> >> 3. The user "mqusr1" does not exist on system 2, but the MD contains the >> user "mqusr1" in the field "UserIdentifier". >> >> 4. When I create the user "mqusr1" on system 2 with appropriate > permissions, >> the report message is delivered successfully. >> >> Now the question: How can I enable the user "mqusr1" to write to a queue > on >> system 2 without creating this account. Nevertheless the field >> "UserIdentifier" has to contain this user, so that the system 1accepts > the >> message? >> >> In fact, it is not only one user on system 1, which may send a message > and I >> do not want at all create a dozen or more users, just to enable the > report >> messages. >> >> Thanks in advance. >> >> Mit freundlichen Gr|_en / With kind regards >> Hubert Kleinmanns (N-Tuition Business Solutions AG) >> im Auftrag von / on behalf of >> AGIS Allianz Dresdner Informationssysteme GmbH >> GB2 Engineering >> AG2HDB02 - Host-DC-Systeme und Middleware (Bank) >> Windm|hlstra_e 14 / F 2.417 >> D-60627 Frankfurt / Main >> >> Telefon: +49-69-263-53262 >> Telefax: +49-69-263-11375 >> E-Mail: [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 >> >> >> 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 >> >> >> This communication, including attachments, is for the exclusive use of >> addressee and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, any use, copying, >> disclosure, dissemination or distribution is strictly prohibited. If >> you are not the intended recipient, please notify the sender >> immediately by return email and delete this communication and destroy all >> copies. >> >> Instructions for managing your mailing list subscription are provided in >> the Listserv General Users Guide available at http://www.lsoft.com >> Archive: http://vm.akh-wien.ac.at/MQSeries.archive >> >> Instructions for managing your mailing list subscription are provided in >> the Listserv General Users Guide available at http://www.lsoft.com >> Archive: http://vm.akh-wien.ac.at/MQSeries.archive > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
