Re: Permission on unix platform
Interesting article: http://www-1.ibm.com/support/docview.wss?rs=171context=SSFKSJq=IY39090uid =swg1IY39090loc=en_UScs=utf-8lang=en+en -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: 29 July 2003 05:55 To: [EMAIL PROTECTED] Subject: Re: Permission on unix platform I think you will find that without these permissions, MQSeries users who are not members of the mqm group will fail. Some sites don't seem to worry about security, and just put any user of MQ into the mqm group. If you do that, then you won't notice a change to these permissions. If you correctly grant access to other groups via setmqaut (don't grant access using setmqaut -p, but that is another issue), then those users need to have access to the shared memory and other resources so that they can communicate with the amqzlaa0 agent processes (or the queue manager itself if using fastpath bindings). You will also find that there are possible problems with writing FDC and LOG files in error situations if world does not have write access to those directories. Regards... Neil Casey. |-+- | | Smith, Christopher N.| | | (MDCH) | | | [EMAIL PROTECTED]| | | ICACMG.COM | | | Sent by: MQSeries List| | | [EMAIL PROTECTED]| | | AT | | | | | | | | | 28/07/2003 23:58 | | | Please respond to | | | MQSeries List | | | | |-+- --- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Permission on unix platform | --- ---| I think this is just an artifact of either your UMASK entry in the MQM account's shell settings or the global UMASK setting set by the system administrator. As long as MQM can read and write to the file, I don't think you'll have a problem; however, you would be better off trying this in a test environment first. -Chris -- Christopher Smith Logica Lead Operator Energy Utilities 617-476-8139 [EMAIL PROTECTED] North America -Original Message- From: Kritsana [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 6:34 AM To: [EMAIL PROTECTED] Subject: Permission on unix platform Dear all, I notice that there are some files within path /var/mqm such as AMQERR*.LOG, /var/mqm/qmgrs/qmgr name/@ipcc/shmem have been set permission to -rw-rw-rw. I wonder if I set to its permission to -rw-rw---. What is matter happend? Thank you, Kritsana Loaboonsup This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. 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 For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. II 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: Environment Variables within MQSI
Hi, Belinda is using the Environment variable. This variable is passed to the next nodes without specifying anything. Troy got confused with LocalEnvironment, as he said in his email. About Belinda´s question. Are you using the attributes from your XML messages copied to the Environment variable? If this is your case there is a topic in the following link which might help you. http://www.mqseries.net/phpBB2/viewtopic.php?t=3450 Cheers, Manuel -Mensaje original- De: Troy Wells [SMTP:[EMAIL PROTECTED] Enviado el: Monday, July 28, 2003 6:32 PM Para: [EMAIL PROTECTED] Asunto: Re: Environment Variables within MQSI Hey Belinda. Just a guess, but are you properly setting the nodes to maintain your environment data. For example, within a compute node, are you setting the Compute Mode to 'LocalEnvironment And Message'. Regards, Troy Belinda Edwards [EMAIL PROTECTED] wrote: I've copied an XML message into an Environment variable Environment.NewMsg. When using this variable within a DB2 Insert statement, if only contains a space. The readlog/formatlog command shows a spaces being assigned to the variable, however, when I look at it's contents within a trace file, the environment variable contains the XML message. Has anyone experienced this before? How did you resolve the problem? Was a work around necessary? Thanks for the information. Belinda 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 _ Do you Yahoo!? Yahoo! SiteBuilder http://us.rd.yahoo.com/evt=10469/*http://sitebuilder.yahoo.com - Free, easy-to-use web site design software 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: Single Receiver for Multiple Senders
BDY.RTF Description: RTF file
Re: Sending unsolicited messages from IMS
Ronald/Neil I agree with both of you completely, unfortunately the customer does not I rather use the MQI as well, but they want to have the choice, in the mean time we are using MQI calls... Thanks. D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Neil Casey [EMAIL PROTECTED]To: [EMAIL PROTECTED] NAL.COM.AU cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/27/2003 11:48 PM Please respond to MQSeries List Hi Didi, my site are major IMS users, and we use OTMA for messages where IMS is the back end (server) application. When IMS is sending datagram or request messages, we use the MQI rather than DL/I calls so as to avoid the IMS exits. This gives us a compromise which we are hapy with. We can use existing applications (which were written for LU0) unchanged by using OTMA, and we can send messages explicitly to other systems via the MQI, which makes our IMS exit environment simpler. It also makes the code much easier to understand, because it is clear when a request messages is going to hit MQ, rather than someone reading the code needing to understand that some exit in IMS is going to redirect a special destination to an MQ queue. Regards, Neil Casey. |-+ | | Didi Dotan | | | [EMAIL PROTECTED]| | | COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | n.AC.AT | | || | || | | 27/07/2003 23:09 | | | Please respond to| | | MQSeries List| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Sending unsolicited messages from IMS | --| Thanks Art, I am aware of these samples, but the customer we are working with wants to see something more detailed, they will develop such exits eventually but they are kind of press for time... Cheers, D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Art Schanz [EMAIL PROTECTED]To: [EMAIL PROTECTED] IT.FRB.ORG cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/24/2003 07:26 PM Please respond to MQSeries List Didi, You can find samples of these exits in 'WebSphere MQ for z/OS - System Setup Guide - V5R3', in Appendix B. I used the samples to develop my own copies of both of these exits. They have been functioning in our shop for more than 5 years in both non-Production Production environments, without any problems. I suggest spending some time on the initial development, as it will be time well spent! Cheers, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 (804) 697-3889 [EMAIL PROTECTED] Didi Dotan [EMAIL PROTECTED] Sent by: MQSeries List To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Sending 07/24/2003 02:07 PM unsolicited messages from IMS Please respond to MQSeries List Hello all, I the book it says the following To send messages from IMS to a WebSphere MQ queue, you need to invoke an IMS transaction that ISRTs to an ALTPCB. You need to write pre-routing and destination resolution exits to route unsolicited messages from IMS and build the OTMA user data, so that the MQMD of the message can be built correctly Does someone have such an exit? TIA Didi Didi
Re: Sending unsolicited messages from IMS
Didi, If they want a choice between a BMW and a Mercedes there may be room to argue, but not between a BMW and a FIAT. Did you try explaining the cost benefit in pounds and lirot? With less moving parts the MQ API is much less expensive to maintain. If you gather all the MQ manuals that reference IMS and follow the small pirnt with someone who understands IMS application programming, and everything is standard IMS, it is not hard to do. Be aware of the assumptions made if the IIH header is not used. Working with conversational transactions can be tricky and nothing is ever transparent, but it is all in the manuals.. Didi Dotan [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: Subject: Re: Sending unsolicited messages from IMS MQSeries List [EMAIL PROTECTED] n.AC.AT 07/29/2003 05:29 AM Please respond to MQSeries List Ronald/Neil I agree with both of you completely, unfortunately the customer does not I rather use the MQI as well, but they want to have the choice, in the mean time we are using MQI calls... Thanks. D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Neil Casey [EMAIL PROTECTED]To: [EMAIL PROTECTED] NAL.COM.AU cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/27/2003 11:48 PM Please respond to MQSeries List Hi Didi, my site are major IMS users, and we use OTMA for messages where IMS is the back end (server) application. When IMS is sending datagram or request messages, we use the MQI rather than DL/I calls so as to avoid the IMS exits. This gives us a compromise which we are hapy with. We can use existing applications (which were written for LU0) unchanged by using OTMA, and we can send messages explicitly to other systems via the MQI, which makes our IMS exit environment simpler. It also makes the code much easier to understand, because it is clear when a request messages is going to hit MQ, rather than someone reading the code needing to understand that some exit in IMS is going to redirect a special destination to an MQ queue. Regards, Neil Casey. |-+ | | Didi Dotan | | | [EMAIL PROTECTED]| | | COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | n.AC.AT | | || | || | | 27/07/2003 23:09 | | | Please respond to| | | MQSeries List| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Sending unsolicited messages from IMS | --| Thanks Art, I am aware of these samples, but the customer we are working with wants to see something more detailed, they will develop such exits eventually but they are kind of press for time... Cheers, D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Art Schanz [EMAIL PROTECTED]To: [EMAIL PROTECTED] IT.FRB.ORG cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/24/2003 07:26 PM Please respond to MQSeries List Didi, You can find samples of these exits in 'WebSphere MQ for z/OS - System Setup Guide - V5R3', in Appendix B. I used the samples to develop my own copies of both of these exits. They have been functioning in our shop for more than 5 years in both non-Production Production environments, without any problems. I suggest
Re: Fixed vs. Variable
Obviously fixed wins out on processing time vs variable when the equiptment is substandard. Variable wins out in the bandwidth arena when you client is cheap and doesn't pour money into the network infrastructure. BUT if you are sending the, ALMOST, same message in variable with very little change. Think Fixed. A true ariable message example would be a SWIFT message. Where fields (TAGS) appear depending on the content of a field. But if you are sending variable data because the last element in a message is variable by +/- 100 characters you might want to consider fixed with a length modifier preceeding the last field. Again as everyone has been either implying or specifically pointing out. IT is yoou choise because you are the one behind the wheel and the oncoming turck is geting closer!!! bobbee From: Williams, Dave (Systems Management) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Fixed vs. Variable Date: Mon, 28 Jul 2003 10:35:28 -0400 A quick question - as a rule, is it significantly more efficient to specify variable messages as opposed to fixed - in one app, even though we are moving variable length messages, we're specifying fixed. Just looking for some quick opinions. Thanks in advance, DW _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail 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: Sending unsolicited messages from IMS
Ronald, We don't have a problem with IIH, because we don't use it! We use the IMS bridge as a form of RPC... They have quite a few secondary transactions and we call them, and for this purpose the IMS bridge is very good, we got things moving there in less then a day's work we had over 10 transactions sending data via MQ not something easily done via MQI... Cheers, D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Ronald Weinger [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/29/2003 01:43 PM Please respond to MQSeries List Didi, If they want a choice between a BMW and a Mercedes there may be room to argue, but not between a BMW and a FIAT. Did you try explaining the cost benefit in pounds and lirot? With less moving parts the MQ API is much less expensive to maintain. If you gather all the MQ manuals that reference IMS and follow the small pirnt with someone who understands IMS application programming, and everything is standard IMS, it is not hard to do. Be aware of the assumptions made if the IIH header is not used. Working with conversational transactions can be tricky and nothing is ever transparent, but it is all in the manuals.. Didi Dotan [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: Subject: Re: Sending unsolicited messages from IMS MQSeries List [EMAIL PROTECTED] n.AC.AT 07/29/2003 05:29 AM Please respond to MQSeries List Ronald/Neil I agree with both of you completely, unfortunately the customer does not I rather use the MQI as well, but they want to have the choice, in the mean time we are using MQI calls... Thanks. D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Neil Casey [EMAIL PROTECTED]To: [EMAIL PROTECTED] NAL.COM.AU cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/27/2003 11:48 PM Please respond to MQSeries List Hi Didi, my site are major IMS users, and we use OTMA for messages where IMS is the back end (server) application. When IMS is sending datagram or request messages, we use the MQI rather than DL/I calls so as to avoid the IMS exits. This gives us a compromise which we are hapy with. We can use existing applications (which were written for LU0) unchanged by using OTMA, and we can send messages explicitly to other systems via the MQI, which makes our IMS exit environment simpler. It also makes the code much easier to understand, because it is clear when a request messages is going to hit MQ, rather than someone reading the code needing to understand that some exit in IMS is going to redirect a special destination to an MQ queue. Regards, Neil Casey. |-+ | | Didi Dotan | | | [EMAIL PROTECTED]| | | COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | n.AC.AT | | || | || | | 27/07/2003 23:09 | | | Please respond to| | | MQSeries List| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Sending unsolicited messages from IMS | --| Thanks Art, I am aware of these samples, but the customer we are working with wants to see something more detailed, they will develop such exits eventually
MQ Triggering
Hi All Any idea about this.Query:Can MQ be used to trigger (submit) JCL on mainframe?Scenario:CICS GUI will take parameters for a batch job which wouldgenerate huge report based on some parameters.Following steps would be used to submit an batch job.1. User will interact with CICS GUI to fill-in parameters for a report2. After collecting parameters, CICS COBOL program put a message into MQQueue 3. MQ trigger program will submit a JCL which will execute COBOL reportprogram4. CICS GUI will display a message saying, 'Report Job has beensubmitted' Please give me some suggestions as how to do this scenario? Thanks in advance Regards, Raj
Re: Sending unsolicited messages from IMS
Didi, We chose to use the IMS Bridge because it allowed our development staff to use their existing transactions w/o making any changes. Using the MQI required that new programs be written...and if your developers are anything like ours, they would rather see the technicians do the work (i.e., coding OTMA exits) than have to do it themselves! As for the IIH, we require it because we also require a password (authenticator) on each transaction we send to IMS. We therefore get an IIH on the replies, or build our own for the unsolicited messages from IMS. Our Audit / Security folks saw the input from OTMA (MQ) as no different than that coming from a terminal - which is exactly the way IMS sees the input! Therefore, the requirement for the password. Also, because we are passing both a userid password on every message, we needed to code a set of encryption/decryption programs (w/ the help of IBMGS) to 'hide' the password in the message flow. I must say, it is really pretty neat set-up. Cheers, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 (804) 697-3889 [EMAIL PROTECTED] Didi Dotan [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/29/2003 09:07 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: Sending unsolicited messages from IMS Ronald, We don't have a problem with IIH, because we don't use it! We use the IMS bridge as a form of RPC... They have quite a few secondary transactions and we call them, and for this purpose the IMS bridge is very good, we got things moving there in less then a day's work we had over 10 transactions sending data via MQ not something easily done via MQI... Cheers, D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Ronald Weinger [EMAIL PROTECTED]To:[EMAIL PROTECTED] .COM cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/29/2003 01:43 PM Please respond to MQSeries List Didi, If they want a choice between a BMW and a Mercedes there may be room to argue, but not between a BMW and a FIAT. Did you try explaining the cost benefit in pounds and lirot? With less moving parts the MQ API is much less expensive to maintain. If you gather all the MQ manuals that reference IMS and follow the small pirnt with someone who understands IMS application programming, and everything is standard IMS, it is not hard to do. Be aware of the assumptions made if the IIH header is not used. Working with conversational transactions can be tricky and nothing is ever transparent, but it is all in the manuals.. Didi Dotan [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: Subject: Re: Sending unsolicited messages from IMS MQSeries List [EMAIL PROTECTED] n.AC.AT 07/29/2003 05:29 AM Please respond to MQSeries List Ronald/Neil I agree with both of you completely, unfortunately the customer does not I rather use the MQI as well, but they want to have the choice, in the mean time we are using MQI calls... Thanks. D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Neil Casey [EMAIL PROTECTED]To: [EMAIL PROTECTED] NAL.COM.AU cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/27/2003 11:48 PM Please respond to MQSeries List Hi Didi, my site are major IMS users, and we use OTMA for messages where IMS is the back end (server) application. When IMS is sending datagram or request messages, we use the MQI rather than DL/I calls so as to avoid the IMS exits. This gives us a compromise which we are hapy with. We can use existing applications (which were written for LU0) unchanged by using OTMA, and we can send messages explicitly to other systems via the MQI, which makes our IMS exit environment simpler. It also makes the code much easier to understand, because it is clear when a request messages is going to hit MQ, rather than someone reading the code needing to understand that some exit in IMS is going to redirect a special destination to an MQ queue. Regards, Neil Casey. |-+ | |
API_EXIT / return codes hazards / amqzfuma running wild / Any ide a why?
It seems that setting the return codes to 0 in an API_Exit causes disastrous results: In the attached skeleton API exit code null_exits.c works fine (doing nothing, but not doing any damage...) The 2nd example null_exits_rc.c does nothing, but before exiting it sets returned codes to 0: pExitParms-ExitResponse = MQXDR_OK; pExitParms-ExitResponse2 = MQXDR_OK; pExitParms-ExitReason= MQRC_NONE; *pCompCode = MQRC_NONE; *pReason = MQRC_NONE; When I ran this on NT (and on Linux), a process named amqzfuma started using all the available memory and in few moments the machine become unusable (Memory usage 100% on NT, and kswapd taking 99% CPU on Linux, forcing me to use hardware reset). OK. I know what is wrong (I hope I helped someone out there) Any reasons why, and what return codes should I be using? -- #include standard.disclaimer.txt [EMAIL PROTECTED] null_exits.c Description: Binary data null_exits_rc.c Description: Binary data
Re: Sending unsolicited messages from IMS
Thank you all for your comments, They were very helpful in placing some recommendation in place Cheers D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Art Schanz [EMAIL PROTECTED]To: [EMAIL PROTECTED] IT.FRB.ORG cc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/29/2003 03:57 PM Please respond to MQSeries List Didi, We chose to use the IMS Bridge because it allowed our development staff to use their existing transactions w/o making any changes. Using the MQI required that new programs be written...and if your developers are anything like ours, they would rather see the technicians do the work (i.e., coding OTMA exits) than have to do it themselves! As for the IIH, we require it because we also require a password (authenticator) on each transaction we send to IMS. We therefore get an IIH on the replies, or build our own for the unsolicited messages from IMS. Our Audit / Security folks saw the input from OTMA (MQ) as no different than that coming from a terminal - which is exactly the way IMS sees the input! Therefore, the requirement for the password. Also, because we are passing both a userid password on every message, we needed to code a set of encryption/decryption programs (w/ the help of IBMGS) to 'hide' the password in the message flow. I must say, it is really pretty neat set-up. Cheers, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 (804) 697-3889 [EMAIL PROTECTED] Didi Dotan [EMAIL PROTECTED] Sent by: MQSeries List To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re: Sending 07/29/2003 09:07 AMunsolicited messages from IMS Please respond to MQSeries List Ronald, We don't have a problem with IIH, because we don't use it! We use the IMS bridge as a form of RPC... They have quite a few secondary transactions and we call them, and for this purpose the IMS bridge is very good, we got things moving there in less then a day's work we had over 10 transactions sending data via MQ not something easily done via MQI... Cheers, D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010 Mobile:(972) 53 803908 Email:[EMAIL PROTECTED] Ronald Weinger [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Re: Sending unsolicited messages from IMS List [EMAIL PROTECTED] n.AC.AT 07/29/2003 01:43 PM Please respond to MQSeries List Didi, If they want a choice between a BMW and a Mercedes there may be room to argue, but not between a BMW and a FIAT. Did you try explaining the cost benefit in pounds and lirot? With less moving parts the MQ API is much less expensive to maintain. If you gather all the MQ manuals that reference IMS and follow the small pirnt with someone who understands IMS application programming, and everything is standard IMS, it is not hard to do. Be aware of the assumptions made if the IIH header is not used. Working with conversational transactions can be tricky and nothing is ever transparent, but it is all in the manuals.. Didi Dotan [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: Subject: Re: Sending unsolicited messages from IMS MQSeries List [EMAIL PROTECTED] n.AC.AT 07/29/2003 05:29 AM Please respond to MQSeries List Ronald/Neil I agree with both of you completely, unfortunately the customer does not I rather use the MQI as well, but they want to have the choice, in the mean time we are using MQI calls... Thanks. D Didi Dotan, Multiconn International Ltd. 43 Ha' Aliya Hashniya St., Azor 55003 ISRAEL Tel: (972) 3 556 4415 Fax: (972) 3 556 3010
Re: ReplyToQ/ReplyToQMgr from JMS app w/o destination object
Take a look at the mqjmsreq.java and mqjmssrv.java programs out on: http://www.developer.ibm.com/tech/sampmq.html I think they might be doing what you want. Ron --- McCarty, Brian [EMAIL PROTECTED] wrote: I have a JMS request/reply program where I am sending a message that is a request...but I want to the reply sent to a queue/queue manager that I am not actually connected to. Meaning that if I was to use a MQ program I would just code a specific reply-to-queue-manager and reply-to-queue in the MQMD so they are sent to an alternate destination automatically. However, the problem is that when you use: outMessage.setJMSReplyTo(destx); you have to pass a valid qReceiver/destination object (at least I think so). However, since I don't actually want to create a receiver, just pass the reply-to-queue/reply-to-queue manager from the JMS header to the MQMD...I'm stuck! Do you know how I can set the MQMD fields manually without passing through the setJMSReplyTo method? Any help would be appreciated. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist 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 __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.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: MQ Triggering
Take a look at support pack MA12: MQSeries for MVS/ESA - Batch trigger monitor http://www-3.ibm.com/software/integration/support/supportpacs/individual/ma1 2.html Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: API_EXIT / return codes hazards / amqzfuma running wild / Any idea why?
1) You should *never* set pExitParms-ExitReason. That is an input field to tell your exit why it was invoked. I would not be surprised if setting this in your exit is what caused everything to pear shaped. 2) pExitParms-ExitResponse will have the value MQXCC_OK when your exit is called. You may only set it to one to the following: MQXCC_OK The exit function completed successfully. Continue normally. This value can be set by all MQXR_* exit functions. ExitResponse2 is used to decide whether exit functions later in the chain should be invoked. MQXCC_FAILED The exit function failed because of some error. This value can be set by all MQXR_* exit functions. The queue manager sets CompCode to MQCC_FAILED, and Reason to: MQRC_API_EXIT_INIT_ERROR if the function is MQ_INIT_EXIT MQRC_API_EXIT_TERM_ERROR if the function is MQ_TERM_EXIT MQRC_API_EXIT_ERROR for all other exit functions The values set can be altered by an exit function later in the chain. ExitResponse2 is ignored; the queue manager continues processing as though MQXR2_SUPPRESS_CHAIN had been returned. MQXCC_SUPPRESS_FUNCTION Suppress WebSphere MQ API function. This value can be set only by an MQXR_BEFORE exit function. It bypasses the API call. If it is returned by the MQ_DATA_CONV_ON_GET_EXIT, data conversion is bypassed. The queue manager sets CompCode to MQCC_FAILED, and Reason to MQRC_SUPPRESSED_BY_EXIT, but the values set can be altered by an exit function later in the chain. Other parameters for the call remain as the exit left them. ExitResponse2 is used to decide whether exit functions later in the chain should be invoked. If this value is set by an MQXR_AFTER or MQXR_CONNECTION exit function, the queue manager continues processing as though MQXCC_FAILED had been returned. MQXCC_SKIP_FUNCTION Skip WebSphere MQ API function. This value can be set only by an MQXR_BEFORE exit function. It bypasses the API call. If it is returned by the MQ_DATA_CONV_ON_GET_EXIT, data conversion is bypassed. The exit function must set CompCode and Reason to the values to be returned to the application, but the values set can be altered by an exit function later in the chain. Other parameters for the call remain as the exit left them. ExitResponse2 is used to decide whether exit functions later in the chain should be invoked. If this value is set by an MQXR_AFTER or MQXR_CONNECTION exit function, the queue manager continues processing as though MQXCC_FAILED had been returned. MQXCC_SUPPRESS_EXIT Suppress all exit functions belonging to the set of exits. This value can be set only by the MQXR_BEFORE and MQXR_AFTER exit functions. It bypasses all subsequent invocations of exit functions belonging to this set of exits for this logical connection. This bypassing continues until the logical disconnect request occurs, when MQ_TERM_EXIT function is invoked with an ExitReason of MQXR_CONNECTION. The exit function must set CompCode and Reason to the values to be returned to the application, but the values set can be altered by an exit function later in the chain. Other parameters for the call remain as the exit left them. ExitResponse2 is ignored. If this value is set by an MQXR_CONNECTION exit function, the queue manager continues processing as though MQXCC_FAILED had been returned. 3) pExitParms-ExitResponse2 will have the value MQXR2_DEFAULT_CONTINUATION when your exit is called. You may only set it to one to the following: MQXR2_DEFAULT_CONTINUATION Whether to continue with the next exit in the chain, depending on the value of ExitResponse. If ExitResponse is MQXCC_SUPPRESS_FUNCTION or MQXCC_SKIP_FUNCTION, bypass exit functions later in the MQXR_BEFORE chain and the matching exit functions in the MQXR_AFTER chain. Invoke exit functions in the MQXR_AFTER chain that match exit functions earlier in the MQXR_BEFORE chain. Otherwise, invoke the next exit in the chain. MQXR2_SUPPRESS_CHAIN Suppress the chain. Bypass exit functions later in the MQXR_BEFORE chain and the matching exit functions in the MQXR_AFTER chain for this API call invocation. Invoke exit functions in the MQXR_AFTER chain that match exit functions earlier in the MQXR_BEFORE chain. MQXR2_CONTINUE_CHAIN Continue with the next exit in the chain. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Standard format doc to capture MQ Objects Design
Hi , Is there a standard format for a document that is usually used or recommended by IBM to capture all configuration details of various Mq objects like the MQ objects like queue managers, cluster info ,queues processdef etc, especially for complex design and setup. May be something similar to the one in intercomm , but that is only for channels. Thank u in advance! Suchi Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: MQ Triggering
Raj, You can do thisbut you'll need a batch trigger monitor. I seem to remember there's a sample or support pac. You will probably need tocustomise it for your needs. However, isn't a better way just to get CICS to submit the job through the internal reader ? Steve. -Original Message-From: Rajkumar Bagavathiappan [mailto:[EMAIL PROTECTED]Sent: 29 July 2003 13:21To: [EMAIL PROTECTED]Subject: MQ Triggering Hi All Any idea about this.Query:Can MQ be used to trigger (submit) JCL on mainframe?Scenario:CICS GUI will take parameters for a batch job which wouldgenerate huge report based on some parameters.Following steps would be used to submit an batch job.1. User will interact with CICS GUI to fill-in parameters for a report2. After collecting parameters, CICS COBOL program put a message into MQQueue 3. MQ trigger program will submit a JCL which will execute COBOL reportprogram4. CICS GUI will display a message saying, 'Report Job has beensubmitted' Please give me some suggestions as how to do this scenario? Thanks in advance Regards, Raj
Re: Standard format doc to capture MQ Objects Design
Try these: http://www-3.ibm.com/software/integration/support/supportpacs/individual/md04.html http://www-3.ibm.com/software/integration/support/supportpacs/individual/md08.html [EMAIL PROTECTED] 7/29/2003 10:29:18 AM Hi , Is there a standard format for a document that is usually used or recommended by IBM to capture all configuration details of various Mq objects like the MQ objects like queue managers, cluster info ,queues processdef etc, especially for complex design and setup. May be something similar to the one in intercomm , but that is only for channels. Thank u in advance! Suchi - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software 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
Design Review - custom trigger monitor vs triggered program
Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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: Channel Exit Structure def...
Right you are Paul. Sorry, will be more discrete next time. Cheers, Howard 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: API_EXIT / return codes hazards / amqzfuma running wild / Any idea why?
And why change the Reason or CompCode? (unless exit has some special reason). If the exit was called BEFORE the API execution, I think it's meaningless. But if exit was called AFTER API execution -- before appl gets control back -- there may be a failure code that the appl should see when the exit completes and appl gets control again. Howard Cinamon Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Design Review - custom trigger monitor vs triggered program
Peter, after the trigger monitor has started xyz, xyz will also listen to the initq. so you have 2 programs listening to the initq, which one will get the next trigger message? (quote on) Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. (quote off) This is wrong in my opinion. an open application queue (open for input) will prevent mq to create another trigger message. but you wrote you close the application queue. so mq will create a trigger message if the trigger conditions are fullfilled. if the trigger monitor will get it, it will start another xyz program. if you trigger and stay alive, why do you trigger? 1. no triggering at all start xyz to listen on the application queue. if a message arrives, it will get processed. use fail if quiescing (and maybe get-disable) to end your application, or use a special kind of message content (a stop message that will make your program to end. 2. use triggering and end trigger monitor will start xyz, xyz will process all messages and wait a specific amount of time for more messages to arrive (get-wait). if nothing arrives, then xyz ends and will be triggered again if messages arrive on the queue. 3. use triggering and stay alive trigger monitor will start xyz, xyz will process all messages and wait infinite for mor messages to arrive. no need to read the initq if you have the application queue open for input (trigger first will not be fired because of this). check how frequent messages arrive in the queue and pick up the best and less-complex solution. seperate business and technics, application programs perform application work, trigger monitor does the technical stuff. I would not use the triggered application program to do the work of the trigger monitor. Regards, Stefan -Ursprungliche Nachricht- Von: Heggie, Peter [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 17:17 An: [EMAIL PROTECTED] Betreff: Design Review - custom trigger monitor vs triggered program Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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: Design Review - custom trigger monitor vs triggered program
Hi Pete ! Long time... After the program processes the Queue named in MQTMC2, does it close the queue ? If not, then MQ will not issue a new trigger message. Is the program multi-threaded? if not, then you're causing a bottle neck for other trigger messages for other queues. It might be more efficient since MQ doesn't have to load a program to process the queues, but depends upon how frequently it gets scheduled. I assume it's TRIGGER FIRST. Phil Heggie, Peter [EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM cc: Sent by: MQSeriesSubject: Design Review - custom trigger monitor vs triggered program List [EMAIL PROTECTED] n.AC.AT 07/29/2003 11:16 AM Please respond to MQSeries List Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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 for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. 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: Design Review - custom trigger monitor vs triggered program
-Original Message- From: Heggie, Peter [SMTP:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 8:17 AM To: [EMAIL PROTECTED] Subject: Design Review - custom trigger monitor vs triggered program Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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: Design Review - custom trigger monitor vs triggered program
Hi Phil.. I'm buried in ERP implementation. Thanks for reply - Actually the program does close the application queue after it gets a message, so it behaves nicely but does more opens and closes. The actual usage is light, about 100 a day (initially). The program is not multi-threaded, but the design was to call for more trigger monitors (to monitor other initiation queues..). The recommendation was to set the application queue triggering to EVERY, but I think FIRST would be better. And Stefan, thank you also, I agree that triggering while already triggered does not make sense, and somehow that must be a waste of resources. In the past I have used the 'regular' triggering (ON FIRST). Peter Heggie (315) 428 - 3193 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Hi Pete ! Long time... After the program processes the Queue named in MQTMC2, does it close the queue ? If not, then MQ will not issue a new trigger message. Is the program multi-threaded? if not, then you're causing a bottle neck for other trigger messages for other queues. It might be more efficient since MQ doesn't have to load a program to process the queues, but depends upon how frequently it gets scheduled. I assume it's TRIGGER FIRST. Phil Heggie, Peter [EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM cc: Sent by: MQSeriesSubject: Design Review - custom trigger monitor vs triggered program List [EMAIL PROTECTED] n.AC.AT 07/29/2003 11:16 AM Please respond to MQSeries List Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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 for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide
MQSeries 5.3 Client and SSL
Hello If a certificate is issued for a Client Connection using MQ 5.3 is there a way to guarantee that that Cert may only be used for connectivity from a single client. In other words is it possible to prohibit copying an identical Cert to multiple MQ Clients running on multiple platforms all connecting to the same queue manager and using the same Server Connection channel? Thanks! Steve 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 V5.3 vs V5.2 Resource Utilization Comparison
Title: Message We are about to start our V5.3.1 upgrade project for ourOS/390 Qmanagers. However, before we start has anyone done a comparison on before/after resource utilization statisticsbetween V5.2 and V5.3.1 ? We would like to get feedback onMIPS and memory utilization and are wondering if anyone could share their experiences (good or bad). Thank you Bob Ofeldt 201-269-4076 This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
Re: Design Review - custom trigger monitor vs triggered program
Peter, what is your design rationale for having multiple initiation queues? Stefan From: Heggie, Peter [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Date: Tue, 29 Jul 2003 13:01:11 -0400 Hi Phil.. I'm buried in ERP implementation. Thanks for reply - Actually the program does close the application queue after it gets a message, so it behaves nicely but does more opens and closes. The actual usage is light, about 100 a day (initially). The program is not multi-threaded, but the design was to call for more trigger monitors (to monitor other initiation queues..). The recommendation was to set the application queue triggering to EVERY, but I think FIRST would be better. And Stefan, thank you also, I agree that triggering while already triggered does not make sense, and somehow that must be a waste of resources. In the past I have used the 'regular' triggering (ON FIRST). Peter Heggie (315) 428 - 3193 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Hi Pete ! Long time... After the program processes the Queue named in MQTMC2, does it close the queue ? If not, then MQ will not issue a new trigger message. Is the program multi-threaded? if not, then you're causing a bottle neck for other trigger messages for other queues. It might be more efficient since MQ doesn't have to load a program to process the queues, but depends upon how frequently it gets scheduled. I assume it's TRIGGER FIRST. Phil Heggie, Peter [EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM cc: Sent by: MQSeriesSubject: Design Review - custom trigger monitor vs triggered program List [EMAIL PROTECTED] n.AC.AT 07/29/2003 11:16 AM Please respond to MQSeries List Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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 for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are
Re: Design Review - custom trigger monitor vs triggered program
Sorry about the blank response(s); I seem to have fat fingers today. First, assuming your design would work, I cannot tell that it accomplishes anything useful. What is your customer's aim? You said Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Not true. An open initq is a triggering requirement; it does not suppress trigger messages. You said Every time another message arrives on the application queue, program XYZ will get another trigger message. If you trigger on EVERY, the INITQ will indeed receive another trigger message. But, you have the native trigger monitor (NTV) and XYZ competing for trigger messages. At first, most of them will be captured by NTV because XYZ has other work to do. Each time NTV will spawn a new instance of XYZ, adding to the contention. Even if you could somehow quiesce NTV after XYZ takes over, the design of XYZ does not scale. While XYZ is processing the INITQ it cannot process the application queue(s) and visa versa. That may be tolerable for a single application, but consider what happens when your second triggered application comes along. You have a design where one triggered application (XYZ) is processing all triggered queues. Not only is that a processing bottleneck, but it's forced to an inefficent programming model--open q, read msg, process msg, close q--because each TM has the potential to reference a different application queue. Need I even mention the maintenance implications of having XYZ process every different kind of message that flows through every triggered queue. If you are intending that your custom trigger monitor be dedicated to a single application queue, then you have you have missed the point of triggering. The idea of monitoring an INITQ is so that you don't need a long running task for each application queue. If you restrict your INITQ to a single application, you gain nothing--might as well just monitor the application queue. You should also take care not to fall in the trap that trigtype EVERY gives a one-to-one relationship between trigger messages and application messages. The triggered EVERY app generally needs to loop on the triggered queue until empty in order to pick up orphan messages. Given that, as XYZ is emptying the triggered queue, more trigger messages will appear. Those that are picked up by NTM will invoke another XYZ. Those picked up by one of the XYZ's will have no messages to process. Now, if trigtype=FIRST, then XYZ will fire only once while app queue is open. In that case, I see no useful purpose for XYZ going after the INITQ. regards, Dennis -Original Message- From: Heggie, Peter [SMTP:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 8:17 AM To: [EMAIL PROTECTED] Subject: Design Review - custom trigger monitor vs triggered program Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY This e-mail and any files
Re: Design Review - custom trigger monitor vs triggered program
Peter Heggie (315) 428 - 3193 -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 2:51 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Peter, what is your design rationale for having multiple initiation queues? Stefan From: Heggie, Peter [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Date: Tue, 29 Jul 2003 13:01:11 -0400 Hi Phil.. I'm buried in ERP implementation. Thanks for reply - Actually the program does close the application queue after it gets a message, so it behaves nicely but does more opens and closes. The actual usage is light, about 100 a day (initially). The program is not multi-threaded, but the design was to call for more trigger monitors (to monitor other initiation queues..). The recommendation was to set the application queue triggering to EVERY, but I think FIRST would be better. And Stefan, thank you also, I agree that triggering while already triggered does not make sense, and somehow that must be a waste of resources. In the past I have used the 'regular' triggering (ON FIRST). Peter Heggie (315) 428 - 3193 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Hi Pete ! Long time... After the program processes the Queue named in MQTMC2, does it close the queue ? If not, then MQ will not issue a new trigger message. Is the program multi-threaded? if not, then you're causing a bottle neck for other trigger messages for other queues. It might be more efficient since MQ doesn't have to load a program to process the queues, but depends upon how frequently it gets scheduled. I assume it's TRIGGER FIRST. Phil Heggie, Peter [EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM cc: Sent by: MQSeriesSubject: Design Review - custom trigger monitor vs triggered program List [EMAIL PROTECTED] n.AC.AT 07/29/2003 11:16 AM Please respond to MQSeries List Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive:
Re: Design Review - custom trigger monitor vs triggered program
Sorry for blank reply. The rationale is that it was delivered by a consultant. And I need something strong and obvious to change it... Peter Heggie (315) 428 - 3193 -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 2:51 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Peter, what is your design rationale for having multiple initiation queues? Stefan From: Heggie, Peter [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Date: Tue, 29 Jul 2003 13:01:11 -0400 Hi Phil.. I'm buried in ERP implementation. Thanks for reply - Actually the program does close the application queue after it gets a message, so it behaves nicely but does more opens and closes. The actual usage is light, about 100 a day (initially). The program is not multi-threaded, but the design was to call for more trigger monitors (to monitor other initiation queues..). The recommendation was to set the application queue triggering to EVERY, but I think FIRST would be better. And Stefan, thank you also, I agree that triggering while already triggered does not make sense, and somehow that must be a waste of resources. In the past I have used the 'regular' triggering (ON FIRST). Peter Heggie (315) 428 - 3193 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Hi Pete ! Long time... After the program processes the Queue named in MQTMC2, does it close the queue ? If not, then MQ will not issue a new trigger message. Is the program multi-threaded? if not, then you're causing a bottle neck for other trigger messages for other queues. It might be more efficient since MQ doesn't have to load a program to process the queues, but depends upon how frequently it gets scheduled. I assume it's TRIGGER FIRST. Phil Heggie, Peter [EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM cc: Sent by: MQSeriesSubject: Design Review - custom trigger monitor vs triggered program List [EMAIL PROTECTED] n.AC.AT 07/29/2003 11:16 AM Please respond to MQSeries List Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY 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 contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. Instructions for managing your mailing list
Re: MQSeries 5.3 Client and SSL
Hello Steve, Certificate cannot be used by an SSL client without it having an access to the correspondent private key. The private key is usually encrypted with the password although for unattended applications both password and private key are usually stored somewhere on the disk. Unless private key (together with its respective password, if applicable) is compromised, other clients cannot impersonate the correct one; otherwise, i.e. if the key is compromised, they can and nothing can prevent an illegal connection (at least I am not aware of anything in Websphere MQ that could). Note: In order for queue manager receiving a connection to verify a client identity at all, specify SSLPEER *and* set SSLAUTH to REQUIRED in the respective channel definition (well, this is just my guess, the documentation is silent about the effect of some combinations of values of these two attributes). Hope this will help, Pavel Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQSeries 5.3 Client and SSL List [EMAIL PROTECTED] n.AC.AT 07/29/2003 02:29 PM Please respond to MQSeries List Hello If a certificate is issued for a Client Connection using MQ 5.3 is there a way to guarantee that that Cert may only be used for connectivity from a single client. In other words is it possible to prohibit copying an identical Cert to multiple MQ Clients running on multiple platforms all connecting to the same queue manager and using the same Server Connection channel? Thanks! Steve 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 may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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: Standard format Worksheet to capture MQ Objects Configuration
Also, besides what I sent you. MO71 can extract information in two formats. One is RUNMQSC and the other is report. The report is a good base for cols in your spread sheet. Also. once you get it to sheet format I would think a PERL pgm could be done to convert it to a RUNMQSC command. You then would have a marketable product bobbee From: eai grp [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Standard format Worksheet to capture MQ Objects Configuration Date: Tue, 29 Jul 2003 08:39:35 -0700 Hello Jason , What i was looking for was more like a Worksheet to capture configuration information. I see something like that in MC67.Is there something like these for a complex setup? Jason Cornell [EMAIL PROTECTED] wrote: Try these: http://www-3.ibm.com/software/integration/support/supportpacs/individual/md04.html http://www-3.ibm.com/software/integration/support/supportpacs/individual/md08.html [EMAIL PROTECTED] 7/29/2003 10:29:18 AM Hi , Is there a standard format for a document that is usually used or recommended by IBM to capture all configuration details of various Mq objects like the MQ objects like queue managers, cluster info ,queues processdef etc, especially for complex design and setup. May be something similar to the one in intercomm , but that is only for channels. Thank u in advance! Suchi - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software 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 - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail 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
