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 right....but 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 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
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
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
