validating incoming XML MSG against Schema..
Hi all, If out incoming message is XML it has to be validated against XML Schema... how to go abt.. it.. Thnaks Regards catchkrec Do you Yahoo!? Yahoo! Search - Find what you re looking for faster.
Re: validating incoming XML MSG against Schema..
Simple.!! Import an XML Schema into the Message Set. There is a Support pac called IO01 for XML Schema Import. Check it out. Be careful during Importing the Schemayou will end up crashing your Control Center. Regards, _ Chandra Sekhar Infosys Technologies | Bangalore | 080-5117 4669 | or 8520261@ 54669 -Original Message- From: Indira Muppanna [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 04, 2004 2:17 PM To: [EMAIL PROTECTED] Subject: validating incoming XML MSG against Schema.. Hi all, If out incoming message is XML it has to be validated against XML Schema... how to go abt.. it.. Thnaks Regards catchkrec Do you Yahoo!? Yahoo! Search - Find what you re looking for faster.
Re: MQ Message statistics
Title: MQ Message statistics Thanks for all theideas. I think that the best would be to purchase some lightweight WMQ monitoring tool, else if 100% accuracy is not an issue, one can simply look at channel / queue stats figures at regular intervals to compile the required information as required. Andre -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED]Sent: 02 March 2004 11:03To: [EMAIL PROTECTED]Subject: Re: MQ Message statistics One simple option I can think off, is gathering the statistics from "Channel Status". Channel status will give you the number of messages and number of bytes transmitted. In absence of monitoring tools, I suggest to run a query every night to take a snap shot of channel status and analyse the figures from there (either through a script or program). I do know that channel sequence number gets reset after reaching it's maximum defined on the channel definition and you have to factorthis in counting the messages. However, I am not sure how big are the other fields and when do they get reset - you have to give a go at them and see (unless somebody add some info from this forum). The fields of interest are: LSTSEQNO, BYTSSENT, BYTSRCVD, BUFSSENT, BUFSRCVD (and of course buffer size if you need). Let us know, how it goes. Cheers Rao From: van Zyl, Andre [mailto:[EMAIL PROTECTED] Sent: 2 March 2004 10:19 PMTo: [EMAIL PROTECTED]Subject: MQ Message statisticsImportance: High My client has requested that I give them statistics on MQSeries messages ( volumes etc) on a monthly basis. There is no MQ monitoring / admin software installed other than the standard MQ. We have a hub and spoke architecture, and all mq messages currently flow through the central windows 2000 server and use circular logging. No clustering or MQclients are involved at this stage. On the hub we have WMQI flows for message transformation and distribution purposes. I would like to find out what the most optimal way would be to gather statistics on message volumes passing through our central HUB server. The 2 options I am considering at the moment is to either use channel exits or to actually modify the message flows to add another destination for each message flow. This additional queue will trigger a program which will collect stats for monthly reporting. Any advice will be much appreciated! (WMQI version 2.1 and WMQ version 5.3) Andre van Zyl = Disclaimer This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like. Director Names A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/home.asp?pid=644 = 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. = Disclaimer This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like. Director Names A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/home.asp?pid=644 =
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 Message statistics
Hello Andre, Do the messages you're counting always traverse a channel? If any are put locally then you'll miss them with the channel status technique. You'll likely miss some anyway, especially if you have clients, depending how often you check and how long the channels live. Plus you need to determine if you're looking at new or pre-existing channel instances to determine how to increment your values. Using a channel message exit you shouldn't miss any messages traversing non-client channels but it is a bit on the complex side. You can count client messages using send/rcv exit(s) but that's a bit more complicated. I've used those methods and they do work well though. If all you need to do is count messages, i.e. don't need a byte count, then the ResetQueueStatistics PCF command is generally the ticket. It's very easy to do using perl, and not difficult in java, etc. If you do need a byte count and don't mind writing exits you might take a look at capturing relevant information from MQPUT[1]/MQGET calls in an API exit. Buying something works too. HTH, Marty van Zyl, Andre wrote: Thanks for all the ideas. I think that the best would be to purchase some lightweight WMQ monitoring tool, else if 100% accuracy is not an issue, one can simply look at channel / queue stats figures at regular intervals to compile the required information as required. Andre -Original Message- *From:* Adiraju, Rao [mailto:[EMAIL PROTECTED] *Sent:* 02 March 2004 11:03 *To:* [EMAIL PROTECTED] *Subject:* Re: MQ Message statistics One simple option I can think off, is gathering the statistics from Channel Status. Channel status will give you the number of messages and number of bytes transmitted. In absence of monitoring tools, I suggest to run a query every night to take a snap shot of channel status and analyse the figures from there (either through a script or program). I do know that channel sequence number gets reset after reaching it's maximum defined on the channel definition and you have to factor this in counting the messages. However, I am not sure how big are the other fields and when do they get reset - you have to give a go at them and see (unless somebody add some info from this forum). The fields of interest are: LSTSEQNO, BYTSSENT, BYTSRCVD, BUFSSENT, BUFSRCVD (and of course buffer size if you need). Let us know, how it goes. Cheers Rao *From:* van Zyl, Andre [mailto:[EMAIL PROTECTED] *Sent:* 2 March 2004 10:19 PM *To:* [EMAIL PROTECTED] *Subject:* MQ Message statistics *Importance:* High My client has requested that I give them statistics on MQSeries messages ( volumes etc) on a monthly basis. There is no MQ monitoring / admin software installed other than the standard MQ. We have a hub and spoke architecture, and all mq messages currently flow through the central windows 2000 server and use circular logging. No clustering or MQclients are involved at this stage. On the hub we have WMQI flows for message transformation and distribution purposes. I would like to find out what the most optimal way would be to gather statistics on message volumes passing through our central HUB server. The 2 options I am considering at the moment is to either use channel exits or to actually modify the message flows to add another destination for each message flow. This additional queue will trigger a program which will collect stats for monthly reporting. Any advice will be much appreciated! (WMQI version 2.1 and WMQ version 5.3) Andre van Zyl *=* *Disclaimer * *This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like.* *Director Names* * A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/home.asp?pid=644* *=* 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
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
MO71 alarm via email possible?
Hi, can the alarm in MO71 be configured to send out email when there is a problem with a listed qmgr? I think it has the capability since no one will sit there the whole day looking at the green light. Has anyone done this? thanks, Paul _ One-click access to Hotmail from any Web page download MSN Toolbar now! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/ 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
Shared queues and batch jobs on zOS
Title: Shared queues and batch jobs on zOS I have an application group that wants to be able to run their batch jobs on any processor in our SYSPLEX system. With Shared Queues we can get to a queue from any of the processors but we still think we need to put the QMGR id into the connection in the batch job. Does anyone know if we can use the GROUP id instead of the QMGR id. Thanks, Walter H. Blanding
default data conversion on iSeries
Hi, I'm looking for an exact documentation about MQSeries data conversion on iSeries (OS/400) My problem descriotion is the following: My MQmessage contains some headers in chain like MQDLH, MQRFH2s, with different CCSID for examle MQMD.ccsid=37 QDLH.ccsid=912, MQRFH2.ccsid=852. In this case getting this message with conversion (target ccsid=912) will fail. The reason is there is no supported conversion beetwen 37-912. this is a normal situation because this code pages are not compatible (not a same carakter page id different representation) In this case the default data conversion takes place... on unix and windows platforms ccsid.tbl file could hel me... and my application works well... I'm looking for a similar parameter or how can I do this on MQSereis v 5.3 on iSeres. Best regards, Ferenc Door ** This e-mail and any attached files are confidential and/or covered by legal, professional or other privilege. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify Kereskedelmi es Hitelbank (K) immediately. K does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information. All e-mail messages addressed to, received or sent by K or K employees are deemed to be professional in nature. Accordingly, the sender or recipient of these messages agrees that they may be read by other K employees than the official recipient or sender in order to ensure the continuity of work-related activities and allow supervision thereof. **
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 to
Re: Shared queues and batch jobs on zOS [Deutsche Boerse Systems :Virus checked] [Deutsche Boerse Systems: Virus checked]
Walter, yes, you can use the GROUP name when connecting from batch. AFAIK, it does not work from CICS (but thats some time ago, maybe it has changed). Regards, Stefan Blanding, Walter [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04.03.2004 16:11 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject:Shared queues and batch jobs on zOS [Deutsche Boerse Systems:Virus checked] . I have an application group that wants to be able to run their batch jobs on any processor in our SYSPLEX system. With Shared Queues we can get to a queue from any of the processors but we still think we need to put the QMGR id into the connection in the batch job. Does anyone know if we can use the GROUP id instead of the QMGR id. Thanks, Walter H. Blanding (See attached file: C.htm) Walter, yes, you can use the GROUP name when connecting from batch. AFAIK, it does not work from CICS (but thats some time ago, maybe it has changed). Regards, Stefan Blanding, Walter [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04.03.2004 16:11 Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Stefan Raabe/DBS/GDB) Subject:Shared queues and batch jobs on zOS [Deutsche Boerse Systems:Virus checked] . I have an application group that wants to be able to run their batch jobs on any processor in our SYSPLEX system. With Shared Queues we can get to a queue from any of the processors but we still think we need to put the QMGR id into the connection in the batch job. Does anyone know if we can use the GROUP id instead of the QMGR id. Thanks, Walter H. Blanding
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, John [mailto:[EMAIL
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 by CKTI (or one of the equivalents) and secondly to retrieve the trigger message. Trigger message
[no subject]
Hi There, Is it possible to have an 30 days evalation copy of Seebeyond software so that I can try test it with MQ Thanx in advance __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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
Receiving SPAM
Has anyone else received what I call unwanted email from CCSS USA Ltd? If not I will resolve the problem myself, otherwise I figured I would do one of my ranting and raving emails since they probably are listening on this list ;-) Chris 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
[no subject]
Wow is this ever a shot gun approach. Blindfold in place? Check. Then ready, aim, fire! Hashim Khan [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: MQSeriesSubject: List [EMAIL PROTECTED] N.AC.AT 03/04/2004 01:56 PM Please respond to MQSeries List Hi There, Is it possible to have an 30 days evalation copy of Seebeyond software so that I can try test it with MQ Thanx in advance __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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: Receiving SPAM
I haven't gotten anything from them. -Original Message- From: Christopher Fryett [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:02 PM To: [EMAIL PROTECTED] Subject: Receiving SPAM Has anyone else received what I call unwanted email from CCSS USA Ltd? If not I will resolve the problem myself, otherwise I figured I would do one of my ranting and raving emails since they probably are listening on this list ;-) Chris Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQIPT
Hi There, I'm trying to understand the sender channel setup going from my qmgr to IPT. Q Mgr and IPT both are on the same server. Thanx in advance for your precious time and suggestions --- Darren Douch [EMAIL PROTECTED] wrote: Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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: Shared queues and batch jobs on zOS
Walter, I have an application group that wants to be able to run their batch jobs on anyprocessor in our SYSPLEX system.With Shared Queues we can get to a queue from any of the processors but we still think we need to put the QMGR id into the connection in the batch job. Does anyone know if we can use the GROUP id instead of the QMGR id. Yes, you can. Regards, Christopher Frank Certified I/T Specialist - WebSphere Software IBM Certified Solutions Expert - Websphere MQ MQ Integrator -- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 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: MQIPT
QM1 and MQIPT are both running on ServerA QM1 is listening on port 1414, perhaps for channels coming from QM2 on ServerB. The MQIPT service is listening on (pick a number) port 1418. The MQIPT config file says that any MQ traffic that comes in on this port gets forwarded over to some other server/port combo, lets say ServerX/port. ServerX has either a QM listening on port, or perhaps there is another MQIPT on port. QM1 then has a SENDER channel to QM99. But the conname for channel QM1.QM99 is not ServerX(port). It is Server1(port1418). The channel will then go from QM1 on ServerA to MQIPT on ServerA(1418) to whatever is listening on ServerX(). -Original Message- From: Hashim Khan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:20 PM To: [EMAIL PROTECTED] Subject: Re: MQIPT Hi There, I'm trying to understand the sender channel setup going from my qmgr to IPT. Q Mgr and IPT both are on the same server. Thanx in advance for your precious time and suggestions --- Darren Douch [EMAIL PROTECTED] wrote: Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
What happens if I put-disable a cluster queue?
QM1, QM2 and QM3 are in CLUSTER1. QM1 hosts a local queue called MyQueue. MyQueue is clustered to CLUSTER1. MyQueue exists only on QM1. It is MQOO_BIND_NOT_FIXED. QM4 has regular SNDR/RCVR channels to and from QM3. QM3 is the gateway. QM4 has a remote queue def to MyQueue, specifying the Remote Queue Manager name as CLUSTER1. I can put messages to the remote queue def on QM4, and they arrive on MyQueue on QM1. I then Put Inhibit MyQueue, and try to send more messages. They all land in the DLQ on the gateway, QM3. So far so good. I close all the queues, and change the remote queue def on QM4 to have Remote Queue Manager name of QM1. MyQueue on QM1 does not change. It is still clustered. It is still put inhibited. I put more messages into the remote queue def on QM4, and they all go to MyQueue on QM1, even though the queue is put inhibited! If I try and put messages to MyQueue by connecting directly to QM1, I get the Put_Inhibited error as expected. I then decluster MyQueue. The remote queue def on QM4 still points to MyQueue/QM1. MyQueue on QM1 is still put inhibited. I try and put more messages to the remote queue def, and they all go to the DLQ on QM1. This is normal. How/why do the messages get into a queue that is Put-Inhibited if the queue is clustered, but the sender specifically points to the QM? I did find the following in the Cluster Manual, but still can't make sense of it. The puts should fail if the queue is Put Inhibited! QUOTE When a cluster queue is put-disabled, this situation is reflected in the full repository of each queue manager that is interested in that queue. The workload management algorithm tries to send messages to destinations that are put-enabled. If there are no put-enabled destinations and no local instance of a queue, an MQOPEN call that specified MQOO_BIND_ON_OPEN returns a return code of MQRC_CLUSTER_PUT_INHIBITED to the application. If MQOO_BIND_NOT_FIXED is specified, or there is a local instance of the queue, an MQOPEN call succeeds but subsequent MQPUT calls fail with return code MQRC_PUT_INHIBITED. You can write a user exit program to modify the workload management routines so that messages can be routed to a destination that is put-disabled. If a message arrives at a destination that is put-disabled (because it was in flight at the time the queue became disabled or because a workload exit chose the destination explicitly), the workload management routine at the queue manager can choose another appropriate destination if there is one, or place the message on the dead-letter queue, or if there is no dead-letter queue, return the message to the originator. ENDQUOTE Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
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 transaction has to pass the trigger message to the next transaction and in the process it has all ready
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't get any satisfactory solutions andI did as we "normally" do in I.T industry -just ignore the core problem and
