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
Re: Creating report messages ends with reason 2035
Hubert your 'problem' is that COD reports are automatically generated by the qmgr under the authority of the userid that is contained in the MQMD. The userid that is running the getting application does not get a look in. Exception / expiration reports are also generated using this ID. The only reports that generally get created cleanly are COAs - they are generated under the authority of the application that delivers the message onto a queue - most often the channel agent. Regards Darren - Original Message - From: "Kleinmanns, Hubert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 22, 2004 8:13 AM 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
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
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 G
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 Busine
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 "UserIde
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 "mqus
Re: Creating report messages ends with reason 2035
I'm afraid to say that as far as I know, there's no other way to make this work. I bow to greater expertise if someone can provide the scoop on how it can work without defining the sending user on the receiving system. Dave 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: Creating report messages ends with reason 2035
Hubert, I think you are almost there. We know that the ID being used for COA is from the message context. So I think the message context rules apply here and you might need to grant "nobody" some additional authorities as described in the SYS Admin Guide here: http://publibfp.boulder.ibm.com/epubs/html/amqzag04/amqzag0429.htm#IDX3617 This section of the manual deals with channel PUTAUT(CTX). Although you are not using this, the COA apparently behaves like PUTAUT(CTX). From the manual "If you use the user ID associated with the message, it is likely that this is a user ID from a remote system. This remote system user ID must be recognized by the target system and have the authority to connect to the queue manager, make inquiries, set attributes, and set context options (+connect, +inq, +set, and +setall). It must also have authority to put messages and set context information (+put and +setall) for the destination and dead-letter queues." So if you have a lot of IDs and don't want to create local accounts for all of them, it seems granting "nobody" all the access described above might work. If the messages flow back using QMgr resolution (instead of through a QRemote), be sure you grant the access to the XMitQ (if your XMitQ has the name of the Reply-To QMgr) or the QMgr alias so that the resolution does not fail. Not sure if this will work but it's easy to back out if it does not. Be aware though that this allows anybody to connect to the QMgr. Although your local queues are safe, anonymous users who connect can send messages to any queue on the remote system - including the command queue. If the channel back uses PUTAUT(DEF), the messages will arrive at the remote QMgr with full admin authority. The way around this is to go through the exercise of creating the local IDs. Not much middle ground here. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert 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 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Creating report messages ends with reason 2035
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, bu
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 reaso
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 AL
Re: AW: Creating report messages ends with reason 2035
I would try to set MQPMO_SET_IDENTITY_CONTEXT in your app1 and set UserIdentifier to the one of the app2. Just a blind shot -- I have never done this trick before. If it works, it sounds as another MQ security hole to me though :-). Pavel "Kleinmanns, Hubert"To: [EMAIL PROTECTED] Subject: AW: Creating report messages ends with reason 2035 Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 09/22/2004 05:57 AM Please respond to MQSeries List 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 chann
Re: AW: Creating report messages ends with reason 2035
Perhaps someone from MQ Dev could comment on the reasoning behind the decision to send the COD with the authority of the userid in the MQMD (even though the user probably won't exist on the receiving system in a DQM environment). >From my naive view of the world it would seem more logical to use either a) The userid under which the receiving app is running, or b) Send the COD with the authority of the QM. However it's my experience that (in general) IBM don't make this sort of decision without thought, and if we understood the logic we could at least understand where they were coming from. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: AW: Creating report messages ends with reason 2035
Darren, PAN may be an option. I will discuss this with the other guys. Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Darren Douch Gesendet: Mittwoch, 22. September 2004 14:38 An: [EMAIL PROTECTED] Betreff: 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 par
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 authorit
Re: AW: Creating report messages ends with reason 2035
PAN simply tell the app to send back some response. You can just code that automated response (reply) yourself, without checking for the PAN flag. But I bet the other side wants the COD as proof your app got the message. If your app got the message, and ignored the PAN request, or just didn't send a reply, you could say you never picked up the message off the queue, and they would have no way to prove otherwise, hence their desire for COD. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: AW: AW: Creating report messages ends with reason 2035 Darren, PAN may be an option. I will discuss this with the other guys. Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Darren Douch Gesendet: Mittwoch, 22. September 2004 14:38 An: [EMAIL PROTECTED] Betreff: 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 au
Re: AW: Creating report messages ends with reason 2035
Some of the Java client applications I have seen can optionally leave the MQMD.userid blank. On zOS & OS/390, the checking of one or more Userids is based on the RESLEVEL settings for the Chinit address space when going in remotely. I have not checked this on distributed side yet to see the effects of passing a blank Userid. I was hoping someone else had already done this, so we could all know. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Miller, Dennis Sent: Wednesday, September 22, 2004 12:00 PM To: [EMAIL PROTECTED] 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&#x
Re: AW: Creating report messages ends with reason 2035
No. When the MCA puts the msg onto the destination queue, the msg MQMD will still have the blank userid. - Original Message - From: "Bright, Frank" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 22, 2004 2:49 PM 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
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 PutAuthorit
Re: AW: Creating report messages ends with reason 2035
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. >> >>
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 th
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 i
AW: AW: Creating report messages ends with reason 2035
Frank, on distributed side messages with blank user IDs are put to a queue with the priority of the MCA. 1. Attribute MCAUSER is not blank -> permissions of the defined MCAUSER. 2. Attribute MCAUSER is blank -> permissions of the listener process (normally 'mqm'!). Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Bright, Frank Gesendet: Mittwoch, 22. September 2004 19:47 An: [EMAIL PROTECTED] Betreff: Re: AW: Creating report messages ends with reason 2035 Some of the Java client applications I have seen can optionally leave the MQMD.userid blank. On zOS & OS/390, the checking of one or more Userids is based on the RESLEVEL settings for the Chinit address space when going in remotely. I have not checked this on distributed side yet to see the effects of passing a blank Userid. I was hoping someone else had already done this, so we could all know. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Miller, Dennis Sent: Wednesday, September 22, 2004 12:00 PM To: [EMAIL PROTECTED] 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
Re: AW: Creating report messages ends with reason 2035
Nice follow up. Thanks Hubert -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Kleinmanns, Hubert Sent: Friday, September 24, 2004 2:19 AM To: [EMAIL PROTECTED] Subject: AW: AW: Creating report messages ends with reason 2035 Frank, on distributed side messages with blank user IDs are put to a queue with the priority of the MCA. 1. Attribute MCAUSER is not blank -> permissions of the defined MCAUSER. 2. Attribute MCAUSER is blank -> permissions of the listener process (normally 'mqm'!). Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Bright, Frank Gesendet: Mittwoch, 22. September 2004 19:47 An: [EMAIL PROTECTED] Betreff: Re: AW: Creating report messages ends with reason 2035 Some of the Java client applications I have seen can optionally leave the MQMD.userid blank. On zOS & OS/390, the checking of one or more Userids is based on the RESLEVEL settings for the Chinit address space when going in remotely. I have not checked this on distributed side yet to see the effects of passing a blank Userid. I was hoping someone else had already done this, so we could all know. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Miller, Dennis Sent: Wednesday, September 22, 2004 12:00 PM To: [EMAIL PROTECTED] 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] Bet
