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
