| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IMS Transactions that are started by the IMS MQ Trigger Moni |
View previous topic :: View next topic |
| Author |
Message
|
| PeterPotkay |
 Posted: Fri Mar 08, 2013 10:38 am Post subject: IMS Transactions that are started by the IMS MQ Trigger Moni |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This link in the info center:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqsaw.doc%2Fza11730_.htm
Says
| Quote: |
“Because the trigger monitor is a batch-oriented BMP, IMS transactions that are started by the trigger monitor contain the following:
•Blanks in the LTERM field of the IOPCB
•The PSB name of the trigger monitor BMP in the Userid field of the IOPCB” |
The transaction in IMS thus shows a UserID of CSQQTRMN.
A new app on the mainframe is testing in DEV and has come to us on the MQ team and said they want the UserID from the MQMD of the application MQ Message to show up as the ID of the triggered transaction. The User Identifier field in the MQMD of the MQ message is being set by the hard coded MCAUSER of the SVRCONN channel on the mid tier MQ Queue Manager than then forwards the message to the mainframe QM.
Googling only got me a couple of posts where others had the same question, but no solution:
http://www.tek-tips.com/viewthread.cfm?qid=774081
http://www.mqseries.net/phpBB2/viewtopic.php?t=43684&highlight=csqqtrmn
This thread here along with the Info Center link leads me to beleive this is impossible:
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=331796
That we are stuck with the transactions that are triggered by the IMS Trigger Monitor to have an ID of CSQQTRMN.
This is the first time an app area has brought this up to me, and we have quite a few other apps that are being triggered by the IMS Trigger Monitor for years (many set up before I even heard of this MQ thing). We do also have some apps being kicked off by the OTMA Bridge, and those do inherit the MQMD.UserIdentifier value from the incoming message – apparently a feature of the OTMA Bridge that is not there in the IMS Trigger Monitor.
So how do others handle this, do you just grant access for CSQQTRMN to resources on the mainframe that have tight access? That seems wrong as the same trigger monitor is handling lots of different queues for different apps and different TCODEs to be kicked off, so if you grant it for CSQQTRMN you grant it for any and every other TCODE that gets started by that trigger monitor.
Or if this is the requirement our hand is forced to use the OTMA Bridge and not MQ Triggering?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Mar 12, 2013 4:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
No replies when I posted this same question on the List Server Forum as well.
I opened a PMR.
Comparing it to distributed, I've dealt with this before where the triggered process runs under the same ID that the Trigger Monitor runs as. We've had some good discussions on this board on what ID to run runmqtrm as, using sudo to switch the started process to the actuall ID you need/want it running as once triggered (if on Unix.)
So I guess its no surprise that the mainframe trigger monitor acts kinda the same way - the triggered process (the IMS TCODE) runs under the same 'ID' as the the IMS Trigger Monitor. But that still seems a bit restrictive -
triggered TCODEs by that one Trigger Monitor have to run under that same ID? C'mon man, its z/OS! Surely there must be some sophisticated solution developed over the years to deal with this - other than having to go the OTMA route.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 12, 2013 4:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I assume that there's no specific reason you have to use the presupplied IMS Trigger Monitor, and that like on distributed, you could write your own? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Mar 12, 2013 4:20 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
| ...Comparing it to distributed, I've dealt with this before where the triggered process runs under the same ID that the Trigger Monitor runs as. We've had some good discussions on this board on what ID to run runmqtrm as, using sudo to switch the started process to the actuall ID you need/want it running as once triggered (if on Unix.)... |
FYI, the new WMQ security Redbook http://www.redbooks.ibm.com/abstracts/sg248069.html
has a section 6.3.9 on application trigger monitors and suggests that it should be run from a low privileged userid that starts the triggered process and has limited access to objects.
Its a thorny issue to allow a trigger monitor to switch userids to start processes. How is the userid authenticated? How is it authorized? How does it handle rogue trigger messages?
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 26, 2013 4:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
After a couple of emails from the list server and the results of my PMR, it is confirmed. There is no way to carry forward the ID from the incoming MQ message to be used as the ID running the IMS transaction if you use the IBM supplied mainframe IMS/MQ trigger monitor. You can change the ID from CSQQTRMN with some config changes, but all you accomplish there is going from one generic common ID to another.
If you need this functionality, use the OTMA Bridge. Or roll your own IMS/MQ Trigger monitor.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
