Re: MQ Triggering in CICS

[Adiraju, Rao]

Title: Message

Yes agreed - if the logic is based on Message (message-id or user-id) what you are saying is perfectly correct.   But from my experience the whole saga of setting a user-id is a "can of worms" and frankly speaking I don't know what it achieves. Don't take me wrong I did this in few sites but we lost the track of "final" objective.    1) First of all in your scenario, ABCD transaction has to "read"  the message to interpret the message descriptor or data, determine the user-id and then  "somehow" has to put the message back before it starts another application transaction. This "somehow" may result into another trigger and so on.   Or secondly, move the message from MQ for good but save it in either DB2 or CICS CMDT/UMDT tables, so that next transaction will have somewhere to look for in case of recovery.    2) Most of important thing is to set any user-id the current user-id of CKTI / ABCD should be "authorised" to do so.     3) Critical question is what is this all for - is it for accounting or security and audit trail on your databases. If you are translating that to a real user-ids, there is NO non-repudiation and it is not easy to "prove" the actual user is logged-on somewhere sometime to put the original message.  Unless one has a tight securities across entire MQ middleware (not even allowing set identity context). If it is for accounting - how on earth one is going to break down the CPU cost for CKTI and ABCD transactions across various projects in the organisation.     So if this does NOT stand for any security audit and NOT for any accounting - why does it need to be done.    This dilemma I have gone through as an Enterprise Architect and didn't get any satisfactory solutions and I did as we "normally" do in I.T industry - just ignore the core problem and continue building some beautiful solutions.     I am interested to hear others experiences.   Cheers   Rao   ps: my apologies if it offends any "beautiful" solution developers           From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: 5 March 2004 6:48 AM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Wait...there's a very important distinction between those two approaches that is being overlooked. CKTI processes the INITQ while ABCD processes the triggered queue.  Therefore, unless you radically alter the CKTI design, CKTI can only change the userid on a per-queue basis, whereas ABCD can change userid on a per-message basis.    Also, with respect to option 2, the role of the TM is to start program ABCD.  Once ABCD gets started, the TM has been consumed and no longer has a purpose; "losing it", if you want to call it that, is inconsequential.  Perhaps you mean to be concerned about losing a task that was intended to process one of the messages on the triggered queue.  Depending on how robust you want the ABCD SIL to be, you may want to provide a contingency for that. (Remember, a SIL is supposed to process the queue until EMPTY).  But even in the worst case scenario, if the SIL quits prematurely, it would just re-trigger again and eventually find the stranded message.   -----Original Message----- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 12:04 PM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Peter   Yes - either you can customise CKTI transaction (the sample code is provided by the IBM as part of WebSphere MQ)  and plug in your own logic to determine the user-id and issue a        EXEC CICS START TRNID(ABCD) USERID(xxxxxxxx)    Or alternatively       CKTI starts application ABCD by default. In ABCD transaction issues another start for actual application transaction with appropriate user-id similar to as shown above.    My personal preference is for option-1. In option-2, ABCD transaction has to pass the trigger message to the next transaction and in the process it has all ready cleaned up the trigger message from initiation queue. If for some reason, second transaction doesn't start or fails half way through, then you would have lost one trigger message.    Apart from that both are same.   Cheers   Rao      From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: 4 March 2004 2:12 AM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Is there a way to dynamically set the userid? As long as we are creating a SIL in CICS, is there a way for the SIL to specify the userid when issuing the EXEC CICS START ?   Peter Heggie -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Tuesday, March 02, 2004 3:11 PM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS   Few more points to add: (I was quick in pressing the send button):    As a design principle the CICS program always should issue a EXEC CICS RETRIEVE  - 1) as Joe mentioned, to determine whether this transaction has triggered by CKTI (or one of the equivalents) and secondly to retrieve the trigger message. Trigger message gives you the information about which queue has resulted the trigger, trigger data (that is defined on the base queue), Process name, application data and user data that was put in the PROCESS definitions etc..  Usually the program should determine the queue that it is supposed to read from this trigger message (which is more reliable) rather than hard-coding / soft-coding in the program.    Also, most of the times CKTI starts with a default user-id (or CICS userid) and hence your transaction also runs under the same user-id. So watch out for your security rules.      Cheers   Rao    From: Adiraju, Rao Sent: 3 March 2004 8:59 AM To: 'MQSeries List' Subject: RE: MQ Triggering in CICS John   Additional point to what Joe mentioned - yes, the default you look for is "CKTI" in Rtransid field. But check with your CICS guys as well - because it is possible one CICS region to have multiple initiators and/or different transaction codes (for various reasons).   If that's  case you need to check for those codes as well (or instead).   Cheers   Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel:  +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116   From: DeBlassio, Joe [mailto:[EMAIL PROTECTED] Sent: 3 March 2004 2:56 AM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS John, Perform the following CICS RETRIEVE at the beginning of your program and check the RTRANSID.  If it contains the value CKTI, then you know that the trigger monitor started your program. EXEC CICS RETRIEVE                          SET (ADDRESS OF MQTM)         LENGTH (LENGTH  OF MQTM)       RTRANSID (VARIABLE-RTRANSID)                RESP (VARIABLE-EIBRESP)        END-EXEC. Make sure you include copybook CMQTML in your linkage section. And define the variables in working storage. Good luck, Joe -----Original Message----- From: Dawson, John [mailto:[EMAIL PROTECTED]] Sent: Monday, March 01, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: MQ Triggering in CICS   Folks, In a CICS program, how can I tell that the CICS program was started from a MQ trigger?   Thanks, John Dawson Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is confidential and may contain privileged material.  If you are not the intended recipient you must not use, disclose, copy or retain it.  If you have received it in error please immediately notify me by return email and delete the emails. Thank you. This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. This communication is confidential and may contain privileged material.  If you are not the intended recipient you must not use, disclose, copy or retain it.  If you have received it in error please immediately notify me by return email and delete the emails. Thank you. This communication is confidential and may contain privileged material.  If you are not the intended recipient you must not use, disclose, copy or retain it.  If you have received it in error please immediately notify me by return email and delete the emails. Thank you.