Re: MQ Triggering in CICS
Title: Message We have a cross-platform environment, and it is currently not practical to define everyones userid on all platforms, for testing. And for production, users are even more limited. Therefore we are using proxy ids. We have an audit requirement to track transactions across platforms, and we have an architecture requirement to allow for restriction of certain transactions or services to certain userids. Therefore we must have the capability to secure individual transactions, and associated resources, to specified userids. Im not sure we need to define a separate userid for each transaction; more reasonable is for an application-specific proxy id to have access to a set of transactions. However we still have the ability to limit a transaction to a specific userid. The model of CKTI triggering ABCD, a SIL, works for us because ABCD will browse each message and start a new transaction, not only under a specific userid, but also passing the new transaction the message ID and queue name. Whether the new transaction only processes the single message, or whether it reads the queue until no more messages, is a design choice, but it is a choice. Single message processing allows parallel/multi-thread processing, and of course the other method of reading until no more messages is the most efficient from an MQ API point of view. How do we enforce the reading of only one message by the new transaction? We cant, technically. But we dont have that requirement. Our functionality and security is grouped by queue. So the userid specified on the EXEC CICS START will have to be granted RACF access to that queue, and all messages on it are available. How do we choose the right userid for a transaction? In our first iteration, before our company agrees on a standard for security certificates, LDPA, etc., we will specify the proxy ID on the process definition. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Thursday, March 04, 2004 11:00 PM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Dennis Sorry to be pedantic BUT 1) if the first transaction browse the message and decide the user-id, start the second transaction - how do you make sure that the second transaction is reading the exact message that first transaction has in mind for that user-id.In ME we don't have any Unique identifier/keyconcept that identifies a message for subsequent retrieval. Correct me if I am wrong. In absence of it, second transaction may read totally different message and process it under wrong user-id. Unless of course, you are assuming that either message-id,correlation-id or group-id uniquely identifies an user (and not the identity context). Becauseonly these three attributes can be used as filters or indexes on MQ-GET. Else the first application has to pass the identity context as a commarea to the second transaction and then the second transaction also has to do the browse first until it finds the matching identity context and then issue a GET at the current cursor .Is this what you have done in your design ?? 2) Secondly how does oneset the main-frame user-id -by retrievingfrom ACF2 / RACF databases or build another database in parallel to these security systems (with ongoing parallel maintenance with these external security systems whenever an employee joins and leaves). Or are you talking of a handful of proxy user-ids set by front-ends in user-id field of the message. I amasking these detailedquestions tolearn from others experiences - so that next time I can use these solutions. Cheers Rao ps: I have seen some clients - where they keep handful ofmainframe proxy user-ids on the internet servers, and when the client comes with digital certificate, translate it to one of proxy user-ids and pump the data through MQ.On the main-frame CICS runs the transactions underthese proxy user-ids. If that's scenario, one is talking about - I can see some point of it. Even there, the front end systems keep changing their digital certifies to user-id combinations left and right. So if some one has to track the real user - who has done a particular transaction say three monthsback - good luck. From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: 5 March 2004 3:25 PM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS 1). The design I've found most effective is for ABCD to browse the queue and START the transaction with the desired userid. The transaction thenreads the message, callsa program toservice the messageand commits the whole sha-bang aftersending the reply. 3). Primarily it's to allow CICS security to control who is allowed to do what. Often times we are using legacy apps that are already designed around the CICS security model. Other times, it's just more convenientthanbuilding a more sophisticated security scheme into the application. I do agree thatit only
Re: MQ Triggering in CICS
Title: Message 1).Fundamental principals that I follow are that no two qmgrs have the same name and no two msgs have the same msg id. 2). The simplest method is to use the same useridsacross systems. But sometimes that method is not practical or not secure enough.There are many alternatives--everything from proxies to elaborate login screens and exchange of security tokens to establish who is sending requests. One scheme does not fit all and figuring out a satisfactory solution is one of the most difficult parts of an implementation. So much so, that it is often given lip service and swept under the rug. Not allapplications have the requirementto discriminate userids atthe message level. But some do--and not to lose sight of my original point--when that's the case, it simply does not work to switch userids in the trigger monitor (as we know it). regards, Dennis -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 8:00 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS Dennis Sorry to be pedantic BUT 1) if the first transaction "browse" the message and decide the user-id, start the second transaction - how do you make sure that the second transaction is reading the "exact" message that first transaction has in mind for that user-id.In ME we don't have any Unique identifier/keyconcept that identifies a message for subsequent retrieval. Correct me if I am wrong. In absence of it, second transaction may read totally different message and process it under "wrong" user-id. Unless of course, you are assuming that either message-id,correlation-id or group-id uniquely identifies an user (and not the identity context). Becauseonly these three attributes can be used as filters or indexes on MQ-GET. Else the first application has to pass the identity context as a commarea to the second transaction and then the second transaction also has to do the browse first until it finds the matching identity context and then issue a GET at the current cursor .Is this what you have done in your design ?? 2) Secondly how does oneset the main-frame user-id -by retrievingfrom ACF2 / RACF databases or build another database in parallel to these security systems (with ongoing parallel maintenance with these external security systems whenever an employee joins and leaves). Or are you talking of a handful of proxy user-ids set by front-ends in user-id field of the message. I amasking these detailedquestions tolearn from others experiences - so that next time I can use these solutions. Cheers Rao ps: I have seen some clients - where they keep handful ofmainframe proxy user-ids on the internet servers, and when the client comes with digital certificate, translate it to one of proxy user-ids and pump the data through MQ.On the main-frame CICS runs the transactions underthese proxy user-ids. If that's scenario, one is talking about - I can see some point of it. Even there, the front end systems keep changing their digital certifies to user-id combinations left and right. So if some one has to track the "real user" - who has done a particular transaction say three monthsback - good luck. From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: 5 March 2004 3:25 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS 1). The design I've found most effective is for ABCD to browse the queue and START the transaction with the desired userid. The transaction thenreads the message, callsa program toservice the messageand commits the whole sha-bang aftersending the reply. 3). Primarily it's to allow CICS security to control who is allowed to do what. Often times we are using legacy apps that are already designed around the CICS security model. Other times, it's just more convenientthanbuilding a more sophisticated security scheme into the application. I do agree thatit only provides a mediocre level of security and is not suitable for alloccasions. But sometimes the show fits. regards, Dennis -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 12:53 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS 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 da
Re: MQ Triggering in CICS
CORRECTION: -Original Message- From: Chase, John Sent: Wednesday, March 03, 2004 10:50 AM [ snip ] If you run CICS with surrogate user security checking active (i.e., SIT parm XUSER=YES), the user ID of the task issuing the START command must have READ or higher permission to a profile of the form ( DFHSTART.target_userid ) in the SURROGAT class. That SHOULD have said: ... ( target_userid.DFHSTART ) Apologies for any confusion my original post may have caused. -jc- 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: MQ Triggering in CICS
Hi JXrgen, Your point is well taken. However, I have seen this design a long time ago and I don't remember the details now. The program had been running in production for over 4 years without any problems. But there is always a chance...but don't you agree that since the MQCLOSE and EXEC CICS DEC are issued without anything else in between, there is an extremely small window in which another message may land on the trig queue. And if the message traffic is not too high this would be a very very rare occurance, which could be be handled by adjusting the TRIGINT of the queue manager... It was just a thought. Most importanlty: I think that I misundrstood the original question. I thought the question was how can I tell (in a second program) that my triggerable CICS transaction has started. Just too little time to read messages and respond... Sorry... Regards, Ruzi --- Jxrgen Pedersen [EMAIL PROTECTED] wrote: Hi Ruzi, It's quite dangerous to use ENQ/DEQ in conjunction with WebSphere MQ/CICS triggered applications (If you don't know the consequences). It requires a good program design. The reason to get me up of the chair is the fact that you might lose triggers due to the triggering rules. Let's have a small example, based on trigger-FIRST: EXEC CICS ENQ rc 0 then exec cics return MQOPEN INPUT MQGET w. wait do while rc=0 process data MQGET w. wait End MQCLOSE EXEC CICS DEC EXEC CICS RETURN This design will with 99% lose a trigger now and then, the reason is you get the trigger message (MQTM) when the queue depth changes from 0-1, and the queue is not open for input. Why ? Because there is a time gab between I'm issuing the MQCLOSE and EC DEQ. If WebSphere MQ fires the trigger and a new program gets started, it might issue the EC ENQ before the first incarnation have issed the EC DEC. My second incarnation will therefore terminate after it's EC ENQ, and therefore we've lost the MQTM, and will wait until the TRIGINT() expires, which typicly never occurs the configurations I've seen. Just my $0.02 ;o) Kind regards Jxrgen PS: No hard feelings, I did spend about a month tracking down such a situation with a missing MQTM.. From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Date: Tue, 2 Mar 2004 04:18:14 -0800 By using EXEC CICS ENQ/DEQ. If the triggered progam A is ENQed, you will get a non-zero return code in the program B that issued the ENQ for Program A. You have to make sure that you DEQ the triggered program A when it is finished processing. Regards, Ruzi --- Dawson, John [EMAIL PROTECTED] wrote: 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 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: MQ Triggering in CICS
Hi Ruzi, I agree with you. Anyway when there are a posibillty, there are no gurantee for other statements between DEQ and MQCLOSE... and maybe another EXEC CICS.. I would prefer that the EXEC CICS DEQ was done before the MQCLOSE to make it fool proof, because the new trigger first can occur after MQCLOSE. Another thing on Triggered CICS transactions is to issue the MQCLOSE call and not rely on CICS to issue the MQCLOSE on cleanup/task terminiation. If we forget to issue MQCLOSE MQ will think the queue is open until the CICS finds time to do the cleanup. You don't see this in testing environments because the CICS systems normally are not stressed. And it's too late to find it in production and in this situation will TRIGINT() not help, because the queue is open seen from MQ. This was one of the main reasone to participate in this thread. No hard feelings! Just my $0.02 ;o) Kind regards Jxrgen From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Date: Thu, 4 Mar 2004 06:09:55 -0800 MIME-Version: 1.0 Received: from AKH-Wien.AC.AT ([149.148.150.3]) by mc2-f31.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 4 Mar 2004 06:23:33 -0800 Received: by AKH-Wien.AC.AT (IBM VM SMTP Level 310) via spool with SMTP id 4328 ; Thu, 04 Mar 2004 15:13:46 MEZ Received: from AKH-WIEN.AC.AT (NJE origin [EMAIL PROTECTED]) by AKH-WIEN.AC.AT (LMail V1.2d/1.8d) with BSMTP id 7666; Thu, 4 Mar 2004 15:11:19 +0100 Received: from AKH-WIEN.AC.AT by AKH-WIEN.AC.AT (LISTSERV-TCP/IP release 1.8d) with spool id 9021 for [EMAIL PROTECTED]; Thu, 4 Mar 2004 15:11:09 +0100 Received: from AWIIMC12 (NJE origin [EMAIL PROTECTED]) by AKH-WIEN.AC.AT (LMail V1.2d/1.8d) with BSMTP id 7624 for [EMAIL PROTECTED]; Thu, 4 Mar 2004 15:11:09 +0100 Received: from web106.biz.mail.yahoo.com [216.136.174.208] by AKH-Wien.AC.AT (IBM VM SMTP Level 310) via TCP with SMTP ; Thu, 04 Mar 2004 15:10:37 MEZ Received: from [204.225.30.94] by web106.biz.mail.yahoo.com via HTTP; Thu, 04 Mar 2004 06:09:55 PST X-Message-Info: yilqo4+6kc78XxFhPvV7OhSVkocX7Pyv X-Comment: AKH-Wien.AC.AT: Mail was sent by web106.biz.mail.yahoo.com Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 04 Mar 2004 14:23:35.0357 (UTC) FILETIME=[475446D0:01C401F4] Hi JXrgen, Your point is well taken. However, I have seen this design a long time ago and I don't remember the details now. The program had been running in production for over 4 years without any problems. But there is always a chance...but don't you agree that since the MQCLOSE and EXEC CICS DEC are issued without anything else in between, there is an extremely small window in which another message may land on the trig queue. And if the message traffic is not too high this would be a very very rare occurance, which could be be handled by adjusting the TRIGINT of the queue manager... It was just a thought. Most importanlty: I think that I misundrstood the original question. I thought the question was how can I tell (in a second program) that my triggerable CICS transaction has started. Just too little time to read messages and respond... Sorry... Regards, Ruzi --- Jxrgen Pedersen [EMAIL PROTECTED] wrote: Hi Ruzi, It's quite dangerous to use ENQ/DEQ in conjunction with WebSphere MQ/CICS triggered applications (If you don't know the consequences). It requires a good program design. The reason to get me up of the chair is the fact that you might lose triggers due to the triggering rules. Let's have a small example, based on trigger-FIRST: EXEC CICS ENQ rc 0 then exec cics return MQOPEN INPUT MQGET w. wait do while rc=0 process data MQGET w. wait End MQCLOSE EXEC CICS DEC EXEC CICS RETURN This design will with 99% lose a trigger now and then, the reason is you get the trigger message (MQTM) when the queue depth changes from 0-1, and the queue is not open for input. Why ? Because there is a time gab between I'm issuing the MQCLOSE and EC DEQ. If WebSphere MQ fires the trigger and a new program gets started, it might issue the EC ENQ before the first incarnation have issed the EC DEC. My second incarnation will therefore terminate after it's EC ENQ, and therefore we've lost the MQTM, and will wait until the TRIGINT() expires, which typicly never occurs the configurations I've seen. Just my $0.02 ;o) Kind regards Jxrgen PS: No hard feelings, I did spend about a month tracking down such a situation with a missing MQTM.. From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Date: Tue, 2 Mar 2004 04:18:14 -0800 By using EXEC CICS ENQ/DEQ. If the triggered progam A is ENQed, you will get a non-zero return code in the program B that issued the ENQ for Program A. You have
Re: MQ Triggering in CICS
Title: Message 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 respecttooption 2,the role of the TM is to start program ABCD.Once ABCD gets started, the TM has been consumed and no longerhas 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 PMTo: [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() 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 AMTo: [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, RaoSent: Tuesday, March 02, 2004 3:11 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS Few more points to add: (I was quickin pressing the send button): As a design principle the CICS program always should issue a EXEC CICS RETRIEVE - 1) asJoe 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 watchout for your security rules. Cheers Rao From: Adiraju, Rao Sent: 3 March 2004 8:59 AMTo: 'MQSeries List'Subject: RE: MQ Triggering in CICS John Additional point towhat 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 AMTo: [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,
Re: MQ Triggering in CICS
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 putthe message backbefore it starts another application transaction. This "somehow" mayresult 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 ofCKTI / ABCDshould 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 useris 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 tobreak downthe 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 anEnterprise Architect and didn't get any satisfactory solutions andI 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 AMTo: [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 respecttooption 2,the role of the TM is to start program ABCD.Once ABCD gets started, the TM has been consumed and no longerhas 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 PMTo: [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() 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 AMTo: [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, RaoSent: Tuesday, March 02, 2004 3:11 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS Few more points to add: (I was quickin pressing the send button): As a design principle the CICS program always should issue a EXEC CICS RETRIEVE - 1) asJoe mentioned, to determine whether this transaction has triggered b
Re: MQ Triggering in CICS
Title: Message 1). The design I've found most effective is for ABCD to browse the queue and START the transaction with the desired userid. The transaction thenreads the message, callsa program toservice the messageand commits the whole sha-bang aftersending the reply. 3). Primarily it's to allow CICS security to control who is allowed to do what. Often times we are using legacy apps that are already designed around the CICS security model. Other times, it's just more convenientthanbuilding a more sophisticated security scheme into the application. I do agree thatit only provides a mediocre level of security and is not suitable for alloccasions. But sometimes the show fits. regards, Dennis -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 12:53 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS 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 putthe message backbefore it starts another application transaction. This "somehow" mayresult 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 ofCKTI / ABCDshould 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 useris 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 tobreak downthe 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 anEnterprise Architect and didn't get any satisfactory solutions andI 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 AMTo: [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 respecttooption 2,the role of the TM is to start program ABCD.Once ABCD gets started, the TM has been consumed and no longerhas 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 PMTo: [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() 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 transact
Re: MQ Triggering in CICS
Title: Message Dennis Sorry to be pedantic BUT 1) if the first transaction "browse" the message and decide the user-id, start the second transaction - how do you make sure that the second transaction is reading the "exact" message that first transaction has in mind for that user-id.In ME we don't have any Unique identifier/keyconcept that identifies a message for subsequent retrieval. Correct me if I am wrong. In absence of it, second transaction may read totally different message and process it under "wrong" user-id. Unless of course, you are assuming that either message-id,correlation-id or group-id uniquely identifies an user (and not the identity context). Becauseonly these three attributes can be used as filters or indexes on MQ-GET. Else the first application has to pass the identity context as a commarea to the second transaction and then the second transaction also has to do the browse first until it finds the matching identity context and then issue a GET at the current cursor .Is this what you have done in your design ?? 2) Secondly how does oneset the main-frame user-id -by retrievingfrom ACF2 / RACF databases or build another database in parallel to these security systems (with ongoing parallel maintenance with these external security systems whenever an employee joins and leaves). Or are you talking of a handful of proxy user-ids set by front-ends in user-id field of the message. I amasking these detailedquestions tolearn from others experiences - so that next time I can use these solutions. Cheers Rao ps: I have seen some clients - where they keep handful ofmainframe proxy user-ids on the internet servers, and when the client comes with digital certificate, translate it to one of proxy user-ids and pump the data through MQ.On the main-frame CICS runs the transactions underthese proxy user-ids. If that's scenario, one is talking about - I can see some point of it. Even there, the front end systems keep changing their digital certifies to user-id combinations left and right. So if some one has to track the "real user" - who has done a particular transaction say three monthsback - good luck. From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: 5 March 2004 3:25 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS 1). The design I've found most effective is for ABCD to browse the queue and START the transaction with the desired userid. The transaction thenreads the message, callsa program toservice the messageand commits the whole sha-bang aftersending the reply. 3). Primarily it's to allow CICS security to control who is allowed to do what. Often times we are using legacy apps that are already designed around the CICS security model. Other times, it's just more convenientthanbuilding a more sophisticated security scheme into the application. I do agree thatit only provides a mediocre level of security and is not suitable for alloccasions. But sometimes the show fits. regards, Dennis -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 12:53 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS 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 putthe message backbefore it starts another application transaction. This "somehow" mayresult 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 ofCKTI / ABCDshould 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 useris 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 tobreak downthe 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 anEnterprise Architect and didn
Re: MQ Triggering in CICS
Hi John, take a look here: http://www.mqseries.net/phpBB2/viewtopic.php?t=13836 Just ask the question in one forum please. Just my $0.02 ;o) Kind regards Jxrgen From: Dawson, John [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MQ Triggering in CICS Date: Mon, 1 Mar 2004 14:18:31 -0600 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: MQ Triggering in CICS
Dear John, EXEC CICS ASSIGN STARTCODE(start-code) IF start-code == SD EXEC CICS RECEIVE INTO(this-should-be-an-MQ-trigger-message) II whatever-you-need-to-test-to-validate-that-it-really-is-a-trigger-message here-you-are... Cheers, Jantje. -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: dinsdag 2 maart 2004 15:35 To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Assuming the program can only be started from an MQ trigger, take a look at the usecount for the program. If the program can be started from other means, then you'll probably have to run a trace. Dawson, John [EMAIL PROTECTED] To: [EMAIL PROTECTED] IGROUP.COMcc: Sent by: MQSeries Subject: MQ Triggering in CICS List [EMAIL PROTECTED] .AC.AT 03/01/2004 03:18 PM Please respond to MQSeries List 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 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: MQ Triggering in CICS
'One should check all the angles' 'Fast' Eddie Felson -Original Message- From: Jxrgen Pedersen [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 9:34 AM To: [EMAIL PROTECTED] Subject:Re: MQ Triggering in CICS Hi John, take a look here: http://www.mqseries.net/phpBB2/viewtopic.php?t=13836 Just ask the question in one forum please. Just my $0.02 ;o) Kind regards Jxrgen From: Dawson, John [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MQ Triggering in CICS Date: Mon, 1 Mar 2004 14:18:31 -0600 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 _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk 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: MQ Triggering in CICS
-Original Message- From: Heggie, Peter 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 ? == Yes; specify the USERID( ) keyword on the E C START command. If you run CICS with surrogate user security checking active (i.e., SIT parm XUSER=YES), the user ID of the task issuing the START command must have READ or higher permission to a profile of the form ( DFHSTART.target_userid ) in the SURROGAT class. -jc- == 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: MQ Triggering in CICS
Thanks.. just what I am looking for.. I've seen SURROGAT before, for submitting batch jobs with the USER= parameter. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Wednesday, March 03, 2004 11:50 AM To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS -Original Message- From: Heggie, Peter 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 ? == Yes; specify the USERID( ) keyword on the E C START command. If you run CICS with surrogate user security checking active (i.e., SIT parm XUSER=YES), the user ID of the task issuing the START command must have READ or higher permission to a profile of the form ( DFHSTART.target_userid ) in the SURROGAT class. -jc- == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail 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. 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: MQ Triggering in CICS [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems: Virus checked]
John, From the Application Programmers Reference Manual: Chapter 14. Starting WebSphere MQ applications using triggers CKTI You need to start one instance of CKTI for each initiation queue (see WebSphere MQ for z/OS System Administration Guide for information on how to do this). CKTI passes the MQTM structure of the trigger message to the program it starts by EXEC CICS START TRANSID. The started program gets this information by using the EXEC CICS RETRIEVE command. A program can use the EXEC CICS RETRIEVE command with the RTRANSID option to determine how the program was started; if the value returned is CKTI, the program was started by WebSphere MQ for z/OS. For an example of how to use CKTI, see the source code supplied for module CSQ4CVB2 in the Credit Check sample application supplied with WebSphere MQ for z/OS. See The Credit Check sample on page 506 for a full description. HTH Stefan you can check if you have been started with data Dawson, John [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 01.03.2004 21:18 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject:MQ Triggering in CICS [Deutsche Boerse Systems:Virus checked] . 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 (See attached file: C.htm) John, From the Application Programmers Reference Manual: Chapter 14. Starting WebSphere MQ applications using triggers CKTI You need to start one instance of CKTI for each initiation queue (see WebSphere MQ for z/OS System Administration Guide for information on how to do this). CKTI passes the MQTM structure of the trigger message to the program it starts by EXEC CICS START TRANSID. The started program gets this information by using the EXEC CICS RETRIEVE command. A program can use the EXEC CICS RETRIEVE command with the RTRANSID option to determine how the program was started; if the value returned is CKTI, the program was started by WebSphere MQ for z/OS. For an example of how to use CKTI, see the source code supplied for module CSQ4CVB2 in the Credit Check sample application supplied with WebSphere MQ for z/OS. See "The Credit Check sample" on page 506 for a full description. HTH Stefan you can check if you have been started with data Dawson, John [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 01.03.2004 21:18 Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Stefan Raabe/DBS/GDB) Subject:MQ Triggering in CICS [Deutsche Boerse Systems:Virus checked] . 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
Re: MQ Triggering in CICS
Title: 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() 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 AMTo: [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, RaoSent: Tuesday, March 02, 2004 3:11 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Triggering in CICS Few more points to add: (I was quickin pressing the send button): As a design principle the CICS program always should issue a EXEC CICS RETRIEVE - 1) asJoe 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 watchout for your security rules. Cheers Rao From: Adiraju, Rao Sent: 3 March 2004 8:59 AMTo: 'MQSeries List'Subject: RE: MQ Triggering in CICS John Additional point towhat 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 AMTo: [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.
Re: MQ Triggering in CICS
Title: RE: MQ Triggering in CICS Thank you.. the two options help.. I agree that option 1 is better (better integrity and efficiency). Im not sure we will change the IBM-delivered process, but I can see the advantage. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Wednesday, March 03, 2004 3: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() 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 quickin pressing the send button): As a design principle the CICS program always should issue a EXEC CICS RETRIEVE - 1) asJoe 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 watchout 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 towhat 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
Re: MQ Triggering in CICS
Quite simple. until the next idea opens, running the CICS transaction under the auth of the issueing userid. This can require some design changes in both the applications and in the adopted CKTI. Just a case to emphesize. Just my $0.02 ;o) Kind regards Jxrgen From: Heggie, Peter [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ Triggering in CICS Thank you.. the two options help.. I agree that option 1 is better (better integrity and efficiency). I'm not sure we will change the IBM-delivered process, but I can see the advantage. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Wednesday, March 03, 2004 3: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() 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
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
Re: MQ Triggering in CICS
Title: RE: MQ Triggering in CICS I'm not a CICS person, but I suspect there are things you can check in the program. But from an infrastucture point of view, you can check the queue it reads to see if it's configured to trigger the program. -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED]] Sent: Monday, March 01, 2004 10: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 email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version.
Re: MQ Triggering in CICS
By using EXEC CICS ENQ/DEQ. If the triggered progam A is ENQed, you will get a non-zero return code in the program B that issued the ENQ for Program A. You have to make sure that you DEQ the triggered program A when it is finished processing. Regards, Ruzi --- Dawson, John [EMAIL PROTECTED] wrote: 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 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: MQ Triggering in CICS
Title: 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
Re: MQ Triggering in CICS
Did you check all the fields in the eib block it seems to me there should be a clue or two in there. I'd look in the EIBTRNID or EIBTRMID first. DeBlassio, Joe [EMAIL PROTECTED]To: [EMAIL PROTECTED] -MINOR.COM cc: Sent by: MQSeries Subject: Re: MQ Triggering in CICS List [EMAIL PROTECTED] C.AT 03/02/2004 05:56 AM Please respond to MQSeries List 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 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: MQ Triggering in CICS
John, If your site is using the supplied default trigger monitor, I believe that it makes the entire trigger message available via the EXEC CICS START TRANSID() FROM(TRIGGER-MSG) ... All you have to do to verify this is to perform an EXEC CICS RETRIEVE INTO(TRIGGER-MSG) in your triggered application. The format of the trigger message maybe found in the WebSphere MQ delivered source, for Cobol copy in CMQTMV. Dawson, John wrote: 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 -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000 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: MQ Triggering in CICS
Title: RE: MQ Triggering in CICS John Additional point towhat 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 AMTo: [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.
Re: MQ Triggering in CICS
Title: RE: MQ Triggering in CICS Few more points to add: (I was quickin pressing the send button): As a design principle the CICS program always should issue a EXEC CICS RETRIEVE - 1) asJoe 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 watchout for your security rules. Cheers Rao From: Adiraju, Rao Sent: 3 March 2004 8:59 AMTo: 'MQSeries List'Subject: RE: MQ Triggering in CICS John Additional point towhat 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 AMTo: [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.
Re: MQ Triggering in CICS
Use the EXEC CICS STARTCODE command. If you were triggered, you will be started-with-data (which is the trigger message in temp storage. Cheers... Jim Nuckolls Dawson, John wrote: 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 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: MQ Triggering in CICS
Oops, Should have been EXEC CICS ASSIGN STARTCODE Cheers... Jim Nuckolls Jim Nuckolls wrote: Use the EXEC CICS STARTCODE command. If you were triggered, you will be started-with-data (which is the trigger message in temp storage. Cheers... Jim Nuckolls Dawson, John wrote: 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 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
