Re: Query on compatibility of MQSI2.0.2 with MQ5.3
> On Windows we had problems upgrading, had to apply CSD01 to overcome We had, too, but a specific upgrade problem was discovered: if I start the official v5.3 pack (e.g. MQ53Server_Win32.exe) this unpack itself and start the MSI file. And Installer roll back often the upgrade process at the end of upgrade process. BUT when I run the unpacked installer package, it is working fine :-) OK, that wasn't ordinary (so 30%) but very interesting Tibor > On Windows we had problems upgrading, had to apply CSD01 to overcome > -Original Message- > From: Seshasayee Nalamati , Tidel Park - Chennai >[mailto:[EMAIL PROTECTED]] > Sent: Friday, 21 February 2003 4:27 PM > To: [EMAIL PROTECTED] > Subject: Query on compatibility of MQSI2.0.2 with MQ5.3 > Dear MQers > A quick question for all . > I am trying to migrate the MQ on our box from 5.2 to 5.3 > We are running MQSI 2.0.2 and MQ Series WorkFlow (which will be upgraded to WMQI >soon afterwards) > Has anyone experienced any issues with MQSI2.0.2 over MQ5.3 or is it really >worthwhile to do it . > Are all the libraries for MQ5.2 still available in 5.3 (The readme for 5.3 doesnt >give all these changes) > Any help is greatly appreciated > Best Regards > Sesha 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
Allen Mayer/PSG/Prudential is out of the office.
I will be out of the office starting 02/21/2003 and will not return until 03/03/2003. I will respond to your message when I return. 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: Query on compatibility of MQSI2.0.2 with MQ5.3
Title: Query on compatibility of MQSI2.0.2 with MQ5.3 On Windows we had problems upgrading, had to apply CSD01 to overcome -Original Message-From: Seshasayee Nalamati , Tidel Park - Chennai [mailto:[EMAIL PROTECTED]]Sent: Friday, 21 February 2003 4:27 PMTo: [EMAIL PROTECTED]Subject: Query on compatibility of MQSI2.0.2 with MQ5.3 Dear MQers A quick question for all . I am trying to migrate the MQ on our box from 5.2 to 5.3 We are running MQSI 2.0.2 and MQ Series WorkFlow (which will be upgraded to WMQI soon afterwards) Has anyone experienced any issues with MQSI2.0.2 over MQ5.3 or is it really worthwhile to do it . Are all the libraries for MQ5.2 still available in 5.3 (The readme for 5.3 doesnt give all these changes) Any help is greatly appreciated Best Regards Sesha
Query on compatibility of MQSI2.0.2 with MQ5.3
Title: Query on compatibility of MQSI2.0.2 with MQ5.3 Dear MQers A quick question for all . I am trying to migrate the MQ on our box from 5.2 to 5.3 We are running MQSI 2.0.2 and MQ Series WorkFlow (which will be upgraded to WMQI soon afterwards) Has anyone experienced any issues with MQSI2.0.2 over MQ5.3 or is it really worthwhile to do it . Are all the libraries for MQ5.2 still available in 5.3 (The readme for 5.3 doesnt give all these changes) Any help is greatly appreciated Best Regards Sesha
Re: Maximum size of defined message
Strong spirited debate by all - that's what I like to see this type of forum provide. Thank you all for sharing your thoughts and experiences to the MQSeries community. Solid points were made by both sides of the equation. And I second the motion of Robert's closing - this was fun. Job well done by all who participated... Stephan C. Moen VP of Sales and Business Development The Preferred Solutions Group, Inc. 630.820.5963 (work) 630.721-8861 (cell) [EMAIL PROTECTED] www.webspherecommunity.com -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message So...now that we have heard the Choir sing let me put my final two cents in and stop playing devils advocate. I have the XMIT queues, QMRG, queues and what-not set to MAX. I set the SYSTEM.DEFAULT.LOCAL.QUEUE to MAX which gets all the defined queues afterwoods set to MAX. The application, when I can get my hands on them will check for specific msg lengths imed and dump the message with an ack where necessary. The limitation on message size is an old design statement. The receiving application usually will handle the message in a maner I have just described. What I do find is that when the sending application calls and asks "why did you dump my message and nack", the Tower of Bable rule imed applies and a situation that would have been quickly fixed had the message stayed where it was will quickly turn into a formal tennis match of EMAILs between the respective parties. But then the managers need to have somethng to do!! This was fun!! bee-oh-dubble-bee-dubble-eegghh _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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 your protection, this e-mail has been scanned for known viruses and damaging content by http://GATEWAYDEFENDER.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: MQMD setup by a non-MQ sender???!!!
Thanks for the insight, Frank. I still have no further info on the project. Steve --- Christopher Frank <[EMAIL PROTECTED]> wrote: > Steve, > > >>>I don't have all the details but I think I soon > may > >>>be involved in a project where, I hear that the > >>>messages would be sent to WMQI from AIX (in a > >>>send-and-forget fashion)without the involment of > >>>MQSeries. In other words, a program (not an MQ > >>>program) or a 3rd-party file sending software > will > >>>send the messages after setting all the required > MQMD > >>>header and concatinating that with the App. data. > >>>This approach makes me a bit nervous. Has anyone > every > >>>done this? What are the things to watch for? > > Hmmm. By this, do they mean on the AIX box they > would be using an MQ > client? That would not require any MQSeries server > code on the AIX box in > question. > > If not, simply creating a data object prepended with > the equivelent of an > MQMD will not cause it to magically appear on an MQ > queue. You can't > (legally) put something on an MQ queue without using > the services of a > queue manager, which requires following a strict set > of formats and > protocols (which is what an MQ Client does). > However, I believe the FAP for > MQ is proprietary and would have to be licensed (I'm > sure > reverse-engineering the FAP is prohibited by the > license agreement). And > the effort would be non-trivial (especially given > that an MQ Client could > be used on AIX for no additional charge). > > If they are not planning to use an MQ Client, I > wonder if what they are > looking at doing is writing (or expecting someone to > write) a custom input > node to accept data for input from somewhere other > than an MQSeries queue. > This is certainly possible with WMQI V2.1. You could > write an input node to > accept input from a file, or HTTP, etc. However, > this would not be sent > through MQSeries and would not be retrieved using an > MQInput node. By > prepending a file with a pseudo-MQMD and using a > file-oriented custom WMQI > input node, in theory the remainder of the message > flow could be built to > operate exactly as it would if an MQInput node had > been used. > > However, if this is the intent, the biggest thing to > watch out for would > be, How would transactionalization be maintained > (you mentioned this would > be sent "in a fire-and-forget fashion")? By not > using an MQInput node, the > substitute node would be responsible for persisting > the data somewhere and > retrying in the event the message flow could not > successfully process it. > > It's hard to be more specific until you have the > additional details you > currently lack. > > Regards, > > Christopher Frank > Sr. I/T Specialist - IBM Software Group > 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 __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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
S/390 MQS V2.1 to V5.3
We are currently running MQS V2.1 on a S/390 using z/OS V1.2 (soon to be V1.4). I plan to go from MQS V2.1 to Websphere MQ V5.3. Anyone have any experiences doing that? Am interested in ideas about the best way to complete the task. Thank you. Carol Criscione CICS/MQSeries Technical Support State of Washington, DIS [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: amqrdbgm
I think this is a program for debugging internal MQ things and you should probably only use it if you are directed to by IBM support. Ron --- Jerzy Pierscinski <[EMAIL PROTECTED]> wrote: > Mqers, > > on one of SunSolaris boxes amqrdbgm process takes > about ~50% of CPU > time. > > I'm running MQ v5.2 with CSD05 on SunSolaris 8, > 64-bit mode. Strange > thing is that this process runs only on one server ( > we have over 40 AIX > and Sun boxes with Qmgrs ). > > I couldn't find any reference of this process in MQ > manuals. > > Does anyone know what this process is for and when > does it start? > > thnx, -jerry > > 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! Tax Center - forms, calculators, tips, more http://taxes.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
amqrdbgm
Mqers, on one of SunSolaris boxes amqrdbgm process takes about ~50% of CPU time. I'm running MQ v5.2 with CSD05 on SunSolaris 8, 64-bit mode. Strange thing is that this process runs only on one server ( we have over 40 AIX and Sun boxes with Qmgrs ). I couldn't find any reference of this process in MQ manuals. Does anyone know what this process is for and when does it start? thnx, -jerry 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: CICS Adapter Userid Question
Return Receipt Your Re: CICS Adapter Userid Question document : was Ernest Roberts/171/DCAG/DCX received by: at: 02/20/2003 04:26:14 PM 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: PCF Commands on OS/390
www.candle.com www.bmc.com hope this helps -Original Message-From: Long, Matthew Jr. (Inland) [mailto:[EMAIL PROTECTED]]Sent: Thursday, 20 February 2003 5:34 AMTo: [EMAIL PROTECTED]Subject: Re: PCF Commands on OS/390 What is the web address, where I can find these products. Matt -Original Message-From: Crupi, Margherita [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 18, 2003 10:00 PMTo: [EMAIL PROTECTED]Subject: Re: PCF Commands on OS/390 There are several products that do monitoring of MQ on mainframe and distributed systems including channel monitoring such as:- Candle Command Centre for MQ Monitoring - We have this installed and it's ok once you finally get it working BMC Patrol suite of products - I know a few companies in Australia have this and they seem happy with this. Hope this helps... -Original Message-From: Long, Matthew Jr. (Inland) [mailto:[EMAIL PROTECTED]]Sent: Wednesday, 19 February 2003 1:40 PMTo: [EMAIL PROTECTED]Subject: Re: PCF Commands on OS/390 1. In other words, I can't run PCF commands on OS/390? Where did you get this? 2. Any ideas on how to monitor channels on OS/390, to see if they are down? If they are down I would like to automatically restart with a program or job. 3. By any chance is there some software I can buy that will monitor channels on OS/390? Thanks! -Original Message-From: Beardsley, Bridgette [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 18, 2003 5:52 PMTo: [EMAIL PROTECTED]Subject: Re: PCF Commands on OS/390 The following table lists each WebSphere MQ platform that supports PCFs. Platform WebSphere MQ for Short name Compaq OpenVMS Alpha Compaq OpenVMS Alpha Compaq NonStop Kernel Compaq NSK iSeries OS/400(R) OS/2 OS/2 UNIX(R)(R) systems see Note below UNIX systems Windows NT(R) Windows -Original Message-From: Long, Matthew Jr. (Inland) [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 18, 2003 4:38 PMTo: [EMAIL PROTECTED]Subject: PCF Commands on OS/390 I'm successful at making a connection from Win2K to a OS/390 Mainframe using MQCONNX, but I can't run any PCF commands. These PCF Commands work fine on UNIX, VMS, NT, and Win2K, but not the Mainframe. Any ideas why this is? Thanks! ---Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003 ---Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003 ---Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003
Re: CICS Adapter Userid Question
Architecturally, a triggered program needs to process a queue, not a message. To transition to processing just one message you need a Service Initiation Layer. The SIL can perform numerous functions, including establishing transaction boundries and effecting message-level security. The CICS Bridge is an exemplary example of an SIL--you may want to model your application after it. Said another way, triggering does not start a transaction for each message--it just starts one or more transactions to process the queue. That is true of the bridge monitor, as well. The bridge monitor then starts per-message transactions. And that's what your SIL program should also do. When starting per-message transactions, you have the option to supply whatever userid you like. You do not need to give the CKTI userid access to all transactions that the SIL is going to start, but you do need to give it surrogate authority for the userid's you want it to engage. A custom trigger monitor, as one person suggested, will not solve this problem as there is no relationship between a trigger message and the application message that caused it. A trigger monitor's duty is to process the INITQ and it has no idea what application message caused a given trigger. To know that, you need to monitor the application queue. That's what an SIL, like the bridge monitor, does. BTW, I said above that the SIL starts per-message transactions. Of course, that's a simplification. In determining transaction boundries, the SIL can also start one transaction for a series of related messages. That's up to how you design the SIL. The bridge monitor uses MQCI_NEW_SESSION as a signal for the start of a new transaction. > -Original Message- > From: Gary P. Klos [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, February 20, 2003 8:41 AM > To: [EMAIL PROTECTED] > Subject: CICS Adapter Userid Question > > I guess I'm just looking for some clarification here. When I use the CICS > Adapter and place a message on a queue which is triggered on in cics. Now > CKTI starts the transaction I specified in the "Process" definition. > However it starts the transaction with the userid that started the CKTI > transaction. That is well and good except for the fact if I want to start > various transactions for various applications, I have to give the userid > which started CKTI access to all the transactions that CICS is going to > start. Is this correct? So if I have 15 application transactions to run, > the same CKTI starting userid has to have access to all of them. Why isn't > the Useridentifier of the Mqseries message just passed in, and then CICS > will use that userid to start the transaction. You can set the CICS Bridge > up this way, but why not the adapter? Am I missing something or is there > an alternative way to do this? > > Thanks, > > Gary > > === > Gary Klos > Online Systems - PSC > United States Steel Corporation > 412-433-1225 > > 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: MQMD setup by a non-MQ sender???!!!
At what point is a message placed on an MQ queue so WMQI can process it? Or are you writing you own input node for files? Regards Tim A Steve Muller <[EMAIL PROTECTED]>To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: MQMD setup by a non-MQ sender???!!! 21/02/2003 03:48 Please respond to MQSeries List Hi all, I don't have all the details but I think I soon may be involved in a project where, I hear that the messages would be sent to WMQI from AIX (in a send-and-forget fashion)without the involment of MQSeries. In other words, a program (not an MQ program) or a 3rd-party file sending software will send the messages after setting all the required MQMD header and concatinating that with the App. data. This approach makes me a bit nervous. Has anyone every done this? What are the things to watch for? Thanks for all of your input, Steve __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: Maximum size of defined message
So...now that we have heard the Choir sing let me put my final two cents in and stop playing devils advocate. I have the XMIT queues, QMRG, queues and what-not set to MAX. I set the SYSTEM.DEFAULT.LOCAL.QUEUE to MAX which gets all the defined queues afterwoods set to MAX. The application, when I can get my hands on them will check for specific msg lengths imed and dump the message with an ack where necessary. The limitation on message size is an old design statement. The receiving application usually will handle the message in a maner I have just described. What I do find is that when the sending application calls and asks "why did you dump my message and nack", the Tower of Bable rule imed applies and a situation that would have been quickly fixed had the message stayed where it was will quickly turn into a formal tennis match of EMAILs between the respective parties. But then the managers need to have somethng to do!! This was fun!! bee-oh-dubble-bee-dubble-eegghh _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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: Maximum size of defined message
Interesting points all around, but to answer your question, I don't think the reasons you presented to arbitrarily set the max message size are comprehensive enough. You seem to assume that just because it's easy to properly design applications to handle arbitrary message sizes that designers should, would and could. In reality, this is rarely the case. In addition, applications rarely handle failures properly that may be due to message anomalies, e.g. poison messages. Also, when applications are ready to come online, in all likelihood they requested the max message size limit to protect themselves. By raising the limit, without their say so, is not good idea. Lastly, as an MQ admin, your job is to ensure the messages flow properly and to handle any problems that impact the infrastructure, e.g. DLQ messages. By raising the max message size, you're passing the responsibility of handling oversized messages to the applications which could prove disasterous. By letting oversized messages go the DLQ, you are at least insuring the proper sized messages reach the applications. The bad ones get shunted elsewhere, and don't introduce problems unnecessarily. "Stephan C. Moen"To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: Re: Maximum size of defined message Sent by: MQSeries List 02/20/2003 10:01 AM Please respond to MQSeries List You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world "s-h-i-t" travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst", see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere..."You fight the battles you can win!" >From: "Stephan C. Moen" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Maximum size of defined message >Date: Thu, 20 Feb 2003 00:14:13 -0600 > >Bobbee, > >I guess I take a different tack. I look for consistency, continuity, and >simplicity in my operational environment. I don't want to create >artificial >limits for my technology stack because I know eventually, those limits will >be tested and require changes; that has been proven over time. So why not >start out by taking those limits off the table. Why should I place >artificial limits on my infrastructure if I don't have to. Isn't that a >primary goal of MQSeries - reliability, availability and scalability (RAS)? >If the message size is raised ABOVE the maximum limit, the probl
Re: CICS Adapter Userid Question
I believe you are correct. Have you seen the new support pac MA1J yet? It provides source for a CICS trigger monitor program. Perhaps you could use this and modify it to add an appropriate userid on the exec cics start command. If that doesn't work, you could have CKTI trigger a front-end transaction that you could write which issues a start for the real application transactions with appropriate userids. -Original Message- From: Gary P. Klos [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 10:41 AM To: [EMAIL PROTECTED] Subject: CICS Adapter Userid Question I guess I'm just looking for some clarification here. When I use the CICS Adapter and place a message on a queue which is triggered on in cics. Now CKTI starts the transaction I specified in the "Process" definition. However it starts the transaction with the userid that started the CKTI transaction. That is well and good except for the fact if I want to start various transactions for various applications, I have to give the userid which started CKTI access to all the transactions that CICS is going to start. Is this correct? So if I have 15 application transactions to run, the same CKTI starting userid has to have access to all of them. Why isn't the Useridentifier of the Mqseries message just passed in, and then CICS will use that userid to start the transaction. You can set the CICS Bridge up this way, but why not the adapter? Am I missing something or is there an alternative way to do this? Thanks, Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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: CICS Adapter Userid Question
Yup, that's the way it works. What you're asking for couldn't really be implemented since a CICS transaction could be triggered once and then potentially read multiple messages. These may have differing userids in the message descriptor. What you could do is have your own transaction triggered and then have this transaction start a separate instance of the application transaction for each message. It could start each instance under the userid in the message descriptor. This has its own issues though. It requires that the userid starting your transaction, which is the same userid that started CKTI, needs authority to start transactions under each different userid. I agree that this is a common problem that IBM should address in some fashion. I think a good solution though would require changes not just in MQSeries but in CICS as well. - Bruce Giordano "Gary P. Klos" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeries List cc: <[EMAIL PROTECTED]> Subject: CICS Adapter Userid Question Thursday February 20, 2003 11:41 AM Please respond to MQSeries List I guess I'm just looking for some clarification here. When I use the CICS Adapter and place a message on a queue which is triggered on in cics. Now CKTI starts the transaction I specified in the "Process" definition. However it starts the transaction with the userid that started the CKTI transaction. That is well and good except for the fact if I want to start various transactions for various applications, I have to give the userid which started CKTI access to all the transactions that CICS is going to start. Is this correct? So if I have 15 application transactions to run, the same CKTI starting userid has to have access to all of them. Why isn't the Useridentifier of the Mqseries message just passed in, and then CICS will use that userid to start the transaction. You can set the CICS Bridge up this way, but why not the adapter? Am I missing something or is there an alternative way to do this? Thanks, Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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: Maximum size of defined message
I am not sure this will do anything other than add to the 'me too' count, but I usually leave the maximum message length at the platform default for the Queue Manager. My experience is that, unless you have a damn good reason not to, you should not artificially constrict. Now there may very well be a good arguement to restrict the maximum message length on platforms that need to talk to other platforms with a smaller maximum allowed, but even then I would set it to the maximum allowed on the smaller of the two. Resource usage may well factor into the equation if you have lots and lots of lovely messages, but my finding is that DB2..whoops sorry MQSeries is pretty efficient when it comes to disk space usage. :) Kevin Ferguson _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus 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: Maximum size of defined message
Title: RE: Maximum size of defined message I think another ways to ask is "is there overhead or resource waste to set queue to it's maximum architectural limit?" -Original Message- From: Stephan C. Moen [SMTP:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 07:02 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world "s-h-i-t" travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst", see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere..."You fight the battles you can win!" >From: "Stephan C. Moen" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Maximum size of defined message >Date: Thu, 20 Feb 2003 00:14:13 -0600 > >Bobbee, > >I guess I take a different tack. I look for consistency, continuity, and >simplicity in my operational environment. I don't want to create >artificial >limits for my technology stack because I know eventually, those limits will >be tested and require changes; that has been proven over time. So why not >start out by taking those limits off the table. Why should I place >artificial limits on my infrastructure if I don't have to. Isn't that a >primary goal of MQSeries - reliability, availability and scalability (RAS)? >If the message size is raised ABOVE the maximum limit, the problem will be >caught at the application ISSUING the call, which is where it should be; >just following your viewpoint of determining where the BLAME should go. > >Lastly, the application can easily be coded to handle large message sizes. >As we all know, the MQGET call will return the size of the message is has >or >tried to retrieve. If your application buffer is too small to accept the >read message, there are several options that can be done. Following anyone >of the steps listed below, will prevent you from waking up at 3AM. > >1) perform another MQGET with a dynamically allocated buffer set to the >message size from the first call >2) have the application automatically move the message into an ERROR queue; >keep the workflow moving.. >3) allow MQGET to truncate the message (not the best option), so a >poison-loop condition doesn't exist >4) You can always have your application determine the max message size of >the queue manager it is connecting to. This will GUARANTEE that the >application will NEVER receive a message it can't handle because of message >size. > >To address your point about a good architect, isn't the architect's job to >MINIMIZE outages and not point fingers. If anything, it's the architect's >fault for not designing the application to handle this t
Re: Maximum size of defined message
Unless you absolutely need to lock it down don't. Leave the queue definition at max and let the application run as its wants. No politics just responsibility. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 10:02 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world "s-h-i-t" travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst", see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere..."You fight the battles you can win!" >From: "Stephan C. Moen" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Maximum size of defined message >Date: Thu, 20 Feb 2003 00:14:13 -0600 > >Bobbee, > >I guess I take a different tack. I look for consistency, continuity, and >simplicity in my operational environment. I don't want to create >artificial >limits for my technology stack because I know eventually, those limits will >be tested and require changes; that has been proven over time. So why not >start out by taking those limits off the table. Why should I place >artificial limits on my infrastructure if I don't have to. Isn't that a >primary goal of MQSeries - reliability, availability and scalability (RAS)? >If the message size is raised ABOVE the maximum limit, the problem will be >caught at the application ISSUING the call, which is where it should be; >just following your viewpoint of determining where the BLAME should go. > >Lastly, the application can easily be coded to handle large message sizes. >As we all know, the MQGET call will return the size of the message is has >or >tried to retrieve. If your application buffer is too small to accept the >read message, there are several options that can be done. Following anyone >of the steps listed below, will prevent you from waking up at 3AM. > >1) perform another MQGET with a dynamically allocated buffer set to the >message size from the first call >2) have the application automatically move the message into an ERROR queue; >keep the workflow moving.. >3) allow MQGET to truncate the message (not the best option), so a >poison-loop condition doesn't exist >4) You can always have your application determine the max message size of >the queue manager it is connecting to. This will GUARANTEE that the >application will NEVER receive a message it can't handle because of message >size. > >To address your point about a good architect, isn't the architect's job to >MINIMIZE outages and not point fingers. If anything, it's the architect's >fault for not designing the application to handle this type of situation. >That's
Re: Maximum size of defined message
You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world "s-h-i-t" travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst", see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere..."You fight the battles you can win!" >From: "Stephan C. Moen" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Maximum size of defined message >Date: Thu, 20 Feb 2003 00:14:13 -0600 > >Bobbee, > >I guess I take a different tack. I look for consistency, continuity, and >simplicity in my operational environment. I don't want to create >artificial >limits for my technology stack because I know eventually, those limits will >be tested and require changes; that has been proven over time. So why not >start out by taking those limits off the table. Why should I place >artificial limits on my infrastructure if I don't have to. Isn't that a >primary goal of MQSeries - reliability, availability and scalability (RAS)? >If the message size is raised ABOVE the maximum limit, the problem will be >caught at the application ISSUING the call, which is where it should be; >just following your viewpoint of determining where the BLAME should go. > >Lastly, the application can easily be coded to handle large message sizes. >As we all know, the MQGET call will return the size of the message is has >or >tried to retrieve. If your application buffer is too small to accept the >read message, there are several options that can be done. Following anyone >of the steps listed below, will prevent you from waking up at 3AM. > >1) perform another MQGET with a dynamically allocated buffer set to the >message size from the first call >2) have the application automatically move the message into an ERROR queue; >keep the workflow moving.. >3) allow MQGET to truncate the message (not the best option), so a >poison-loop condition doesn't exist >4) You can always have your application determine the max message size of >the queue manager it is connecting to. This will GUARANTEE that the >application will NEVER receive a message it can't handle because of message >size. > >To address your point about a good architect, isn't the architect's job to >MINIMIZE outages and not point fingers. If anything, it's the architect's >fault for not designing the application to handle this type of situation. >That's what a GOOD architect would do; eliminate POTENTIAL problems before >they have a chance to surface. I would assume that is a line-item in every >MQSeries Architect's Best Practices Binder. > >So I will post the question again, what are the issues? I have yet to hear >a reason why this wouldn't be a good idea. And Bobbee, please proof-read >your
AMQZLAA0 question
AIX 4.3.3 MQSeries 5.2 CSD04 When an MQCONN is issued from an application the amqzma0 process (execution controller) picks this up and contacts amqzlaa0 (agent process) to start a thread for the connection. When the agent process reaches 62 threads a second amqzlaa0 process is started and so on. Well, I currently have about 60 amqzlaa0 processes running with timestamps dating back to November. When the execution controller contacts the agent to start a new thread does it automatically go to the most recent amqzlaa0 process and look for less then 62 threads or does it start at the first amqzlaa0 and search for open "slots" to start the thread? If disconnects were issued and the threads ended, there should be less then 62 threads in previous amqzlaa0 processes. Are these "slots" reused throughout the amqzlaa0 processes or does the execution controller automatically start at the end and if 62 threads have been started, start a new anqzlaa0 processes, disregarding all previous amqzlaa0 processes? Polly Siegman Unix System Administrator PerotSystems @ Owens&Minor Ph. (804)935-4290 Pager (800)Page-MCI pin #1576939
Re: MQMD setup by a non-MQ sender???!!!
Steve, >>>I don't have all the details but I think I soon may >>>be involved in a project where, I hear that the >>>messages would be sent to WMQI from AIX (in a >>>send-and-forget fashion)without the involment of >>>MQSeries. In other words, a program (not an MQ >>>program) or a 3rd-party file sending software will >>>send the messages after setting all the required MQMD >>>header and concatinating that with the App. data. >>>This approach makes me a bit nervous. Has anyone every >>>done this? What are the things to watch for? Hmmm. By this, do they mean on the AIX box they would be using an MQ client? That would not require any MQSeries server code on the AIX box in question. If not, simply creating a data object prepended with the equivelent of an MQMD will not cause it to magically appear on an MQ queue. You can't (legally) put something on an MQ queue without using the services of a queue manager, which requires following a strict set of formats and protocols (which is what an MQ Client does). However, I believe the FAP for MQ is proprietary and would have to be licensed (I'm sure reverse-engineering the FAP is prohibited by the license agreement). And the effort would be non-trivial (especially given that an MQ Client could be used on AIX for no additional charge). If they are not planning to use an MQ Client, I wonder if what they are looking at doing is writing (or expecting someone to write) a custom input node to accept data for input from somewhere other than an MQSeries queue. This is certainly possible with WMQI V2.1. You could write an input node to accept input from a file, or HTTP, etc. However, this would not be sent through MQSeries and would not be retrieved using an MQInput node. By prepending a file with a pseudo-MQMD and using a file-oriented custom WMQI input node, in theory the remainder of the message flow could be built to operate exactly as it would if an MQInput node had been used. However, if this is the intent, the biggest thing to watch out for would be, How would transactionalization be maintained (you mentioned this would be sent "in a fire-and-forget fashion")? By not using an MQInput node, the substitute node would be responsible for persisting the data somewhere and retrying in the event the message flow could not successfully process it. It's hard to be more specific until you have the additional details you currently lack. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group 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: WMQI 2.1 and Java 1.3.1 on AIX - NOT SUPPORTED
I find that IBM are not alone in doing that a lot... Even between differing version of their own product portfolio. IMHO it undermines things such as open standards like Java, J2EE et al if vendors require a specific version of a product. John. -Original Message- From: Paul Meekin [mailto:[EMAIL PROTECTED]] Sent: 20 February 2003 13:12 To: [EMAIL PROTECTED] Subject: Re: WMQI 2.1 and Java 1.3.1 on AIX - NOT SUPPORTED Just in case anyone else tries this, IBM have told me that there are currently no plans to support Java 1.3.1 on AIX with WMQI 2.1. It seems that it's Java 1.3.0.10 or nothing. Is it just me or does it seem unreasonable to specify a particular level of pre-requisite software rather than "or higher". Cheers, Paul This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy +or forward all or any of it in any form. 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 ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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
MQMD setup by a non-MQ sender???!!!
Hi all, I don't have all the details but I think I soon may be involved in a project where, I hear that the messages would be sent to WMQI from AIX (in a send-and-forget fashion)without the involment of MQSeries. In other words, a program (not an MQ program) or a 3rd-party file sending software will send the messages after setting all the required MQMD header and concatinating that with the App. data. This approach makes me a bit nervous. Has anyone every done this? What are the things to watch for? Thanks for all of your input, Steve __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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
CICS Adapter Userid Question
I guess I'm just looking for some clarification here. When I use the CICS Adapter and place a message on a queue which is triggered on in cics. Now CKTI starts the transaction I specified in the "Process" definition. However it starts the transaction with the userid that started the CKTI transaction. That is well and good except for the fact if I want to start various transactions for various applications, I have to give the userid which started CKTI access to all the transactions that CICS is going to start. Is this correct? So if I have 15 application transactions to run, the same CKTI starting userid has to have access to all of them. Why isn't the Useridentifier of the Mqseries message just passed in, and then CICS will use that userid to start the transaction. You can set the CICS Bridge up this way, but why not the adapter? Am I missing something or is there an alternative way to do this? Thanks, Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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: WMQI- Beginner's questions
Thank you very much, CF, for an excellent explanation!!! Steve --- Christopher Frank <[EMAIL PROTECTED]> wrote: > Hi Steve, > > >>>1- Can someone please explain what this > "cardinality" > >>> is all aboout (with an example). > > In set theory, cardinality refers to the number of > members in the set. For > example, the cardinality of the set of people in the > United States is > approximately 270,000,000. Use of this term (as > opposed to "count" or some > more intuitive term) doubtless has its origins in > the fact that eSQL is a > variant of SQL. When specifically applied to > database theory, the > cardinality of a table refers to the number of rows > (or tuples) contained > in a table. In WMQI, cardinality is used to refer to > the number of elements > at a given level in the message tree. Thus you can > use the CARDINALITY > function to, for example, determine how many > instances of a repeating > element there are. For example, the following eSQL > statement: > > set I = CARDINALITY(InputBody.data.item[]) DO > > ...run against a message tree generated from the > following XML: > > >x >y >z > > > ...will count all instances of the item element and > set the variable I to > 3. Similarly, the following eSQL: > > WHILE I <=CARDINALITY(InputBody.data.item[]) > DO > SET OutputRoot.XML.mytag.unit[I] = > InputBody.data.item[I]; > SET I = I + 1; > END WHILE; > > ...will iterate through each item element and create > an output XML message > like so: > > >x >y >z > > > >>>2- If there is a RFH in a message would the > message > >>> look like this: > >>> MQMD-MQRFH-ApplicationData > >>> Or, is the whole ApplicationData specified > within > >>> the name/value pairs? > > Yes, the message would look like > MQMD-MQRFH-ApplicationData. > > >>>In this example, the MQMD.Format is set to = > MQMD_RF_Header. > >>>Where would I specify the format as MQFMT_STRING > for the > >>>application data? In the MQRFH.Format field? Does > this format > >>>apply to both the name/value fields and > ApplicationData? > > You would specify MQFMT_STRING in the MQRFH.Format > field to indicate that > the application data is all string (character) data. > It would only apply to > the ApplicationData, as I believe the name/value > pairs that make up the RFH > must be strings. > > Note that with WMQI, you do not need to use the RFH > header, as the values > it contains can be specified as properties of the > MQInput node or a > ResetContentDescriptor node of a message flow. An > RFH header can be used, > but this is not required. > > Regards, > > Christopher Frank > Sr. I/T Specialist - IBM Software Group > 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 __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: MQSI- Is it possible to associate messages in msg groups?
Thanks, bobbee... I'll try when I have a chance. Steve --- Robert Broderick <[EMAIL PROTECTED]> wrote: > Well.you can process the different messages > within the same flow. One > way is to have your app format an RFH header then > the message will have it's > identification comming into the the queue on the > message and will be parsed > appropriatly. Another trick is to accept the message > as a BLOB and do some > mild byte extracton and figure out what message it > is an use a RCD nod to > set the message identification appropriatley.. > > Then you could use a compute node to set up the > situation where you will > follow up with a 'Route To Label'. You can then have > each of your seperate > mesage flows designed to handle each type of message > with a default one for > 'ALIEN MESSAGE TYPE". > > This is just one way of doing this. I sure there are > otheres. > > >bobbee > > > > > > > >From: Steve Muller <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: MQSI- Is it possible to associate messages > in msg groups? > >Date: Tue, 18 Feb 2003 12:17:48 -0800 > > > >Hi all, > > > >We will be receiving, into the MQSI input queues, > >messages that are logically grouped. I don't know > yet > >whether the messages will come in as grouped using > >MQSeries grouping or application constructed (i.e. > >using msgid/correlid and certain fields of the > >application data). > > > >Question: > > > >Since the layouts of each message will be > different, > >is it possible at all to manupilate these messages > in > >MQSI-- by receiving them all on the same input > queue? > >I don't personally think it is. Maybe these logical > >messages will have to be put on different MQSI > input > >queues each of which will have a message layout > >specific for that message. No? Or, they can be put > on > >the same MQSI input queue. And once in MQSI, based > on > >message content, they can be output to different > >output queues, which would be used as input queues > for > >separare message flows??? How else could it be > done? > > > > > >Thanks for all the input in advance. > > > >Best regards, > > > >Steve > > > > > >__ > >Do you Yahoo!? > >Yahoo! Shopping - Send Flowers for Valentine's Day > >http://shopping.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 > > > _ > Add photos to your e-mail with MSN 8. Get 2 months > FREE*. > http://join.msn.com/?page=features/featuredemail > > 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! Tax Center - forms, calculators, tips, more http://taxes.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: WMQI 2.1 and Java 1.3.1 on AIX - NOT SUPPORTED
Just in case anyone else tries this, IBM have told me that there are currently no plans to support Java 1.3.1 on AIX with WMQI 2.1. It seems that it's Java 1.3.0.10 or nothing. Is it just me or does it seem unreasonable to specify a particular level of pre-requisite software rather than "or higher". Cheers, Paul This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy or forward all or any of it in any form. 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: Maximum size of defined message
You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world "s-h-i-t" travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst", see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere..."You fight the battles you can win!" From: "Stephan C. Moen" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message Date: Thu, 20 Feb 2003 00:14:13 -0600 Bobbee, I guess I take a different tack. I look for consistency, continuity, and simplicity in my operational environment. I don't want to create artificial limits for my technology stack because I know eventually, those limits will be tested and require changes; that has been proven over time. So why not start out by taking those limits off the table. Why should I place artificial limits on my infrastructure if I don't have to. Isn't that a primary goal of MQSeries - reliability, availability and scalability (RAS)? If the message size is raised ABOVE the maximum limit, the problem will be caught at the application ISSUING the call, which is where it should be; just following your viewpoint of determining where the BLAME should go. Lastly, the application can easily be coded to handle large message sizes. As we all know, the MQGET call will return the size of the message is has or tried to retrieve. If your application buffer is too small to accept the read message, there are several options that can be done. Following anyone of the steps listed below, will prevent you from waking up at 3AM. 1) perform another MQGET with a dynamically allocated buffer set to the message size from the first call 2) have the application automatically move the message into an ERROR queue; keep the workflow moving.. 3) allow MQGET to truncate the message (not the best option), so a poison-loop condition doesn't exist 4) You can always have your application determine the max message size of the queue manager it is connecting to. This will GUARANTEE that the application will NEVER receive a message it can't handle because of message size. To address your point about a good architect, isn't the architect's job to MINIMIZE outages and not point fingers. If anything, it's the architect's fault for not designing the application to handle this type of situation. That's what a GOOD architect would do; eliminate POTENTIAL problems before they have a chance to surface. I would assume that is a line-item in every MQSeries Architect's Best Practices Binder. So I will post the question again, what are the issues? I have yet to hear a reason why this wouldn't be a good idea. And Bobbee, please proof-read your reply. I'm not totally sure what you were trying to say on your first reply ( but I responded to what I 'thought' you were saying ) but I'm sure your second one will be crystal clear. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Wednesday, February 19, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message Well if you think about itWhat if a distributed application send you a normal size message of 100 bytes. You application processes messages from many suppliers that give you messages of the same size. You go ahead and set the MAX Queue size for a message at 100Meg. Now the distributed application send you a message that is larger than the 100 bytes, actually it send you MANY of shuch messages. Two things come to mind Fist of all prior to setting the max size. The problem is theres. now it is yours. Second. Your application cannot handle the message so it backs up on the queue and all your other suppling systems begin to get constipated t. This problem is now also yours!! As I always teach in my design classes. A good architect will design a system so that everybody else is to BLAME and you never get awaken at 3AM for stupid reasons that could have been avoided by blaming someone else! bobbee >From: "Stephan C. Moen" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Maximum size of defined message >Date:
Re: PCF Commands on OS/390
Hi, You can inquire channel status or another MQ command send a message to the OS/390 queue called SYSTEM.COMMAND.INPUT. In this message you must write the command (like Display chstatus(channel.Name)) and specify a reply queue and in this local queue of the WNT you receive a group of message than describe the response. You can analyse them. The command server in OS/390 must be started I hope this help Kind Regards -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. 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: Backing up MQSeries for DR.
amqoamd -m -s Tibor > I appologize for the time difference between threads dates... > Thought I had this DR stuff down until thinking about security and OAM. All > of this stuff is persisted on the QMgr. Has anyone thought about how one > would save the queue backing the OAM... I believe the > "SYSTEM.AUTH.DATA.QUEUE". I recall asking IBM for the structure of this > queue and was promptly told that it was proprietary. I don't think the > message format is "rocket science"... > Any thoughts? > Maybe an RFE to the MS03 support pack to save some queue stuff. > Thanks in advance, > -B > Brian Bumpass > Wachovia Bank > E-Channels > [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 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: Backing up MQSeries for DR.
You can dump the contents of the queue as setmqaut statements with the following command: amqoamd -m QMGRNAME -s|grep -v mqm The "grep -v mqm" filter stops the output containing all the mqm group authorities which get created automatically. You could probably leave that out if required. Regards John. -Original Message- From: Bumpass, Brian [mailto:[EMAIL PROTECTED]] Sent: 19 February 2003 22:51 To: [EMAIL PROTECTED] Subject: Re: Backing up MQSeries for DR. I appologize for the time difference between threads dates... Thought I had this DR stuff down until thinking about security and OAM. All of this stuff is persisted on the QMgr. Has anyone thought about how one would save the queue backing the OAM... I believe the "SYSTEM.AUTH.DATA.QUEUE". I recall asking IBM for the structure of this queue and was promptly told that it was proprietary. I don't think the message format is "rocket science"... Any thoughts? Maybe an RFE to the MS03 support pack to save some queue stuff. Thanks in advance, -B Brian Bumpass Wachovia Bank E-Channels [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 ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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: Backing up MQSeries for DR.
Or maybe this one: MS63: MQSeries - Save authorities script http://www-3.ibm.com/software/ts/mqseries/txppacs/ms63.html Emile Kearns Office telephone no: +27(0)114586756 SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Bumpass, Brian [mailto:[EMAIL PROTECTED]] Sent: 20 February 2003 12:51 To: [EMAIL PROTECTED] Subject: Re: Backing up MQSeries for DR. I appologize for the time difference between threads dates... Thought I had this DR stuff down until thinking about security and OAM. All of this stuff is persisted on the QMgr. Has anyone thought about how one would save the queue backing the OAM... I believe the "SYSTEM.AUTH.DATA.QUEUE". I recall asking IBM for the structure of this queue and was promptly told that it was proprietary. I don't think the message format is "rocket science"... Any thoughts? Maybe an RFE to the MS03 support pack to save some queue stuff. Thanks in advance, -B Brian Bumpass Wachovia Bank E-Channels [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 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: Backing up MQSeries for DR.
Hi Brian, Could the following support pack be of help? MS0I: MQSeries - OAM authorities utility http://www-3.ibm.com/software/ts/mqseries/txppacs/ms0i.html Emile Kearns Office telephone no: +27(0)114586756 SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Bumpass, Brian [mailto:[EMAIL PROTECTED]] Sent: 20 February 2003 12:51 To: [EMAIL PROTECTED] Subject: Re: Backing up MQSeries for DR. I appologize for the time difference between threads dates... Thought I had this DR stuff down until thinking about security and OAM. All of this stuff is persisted on the QMgr. Has anyone thought about how one would save the queue backing the OAM... I believe the "SYSTEM.AUTH.DATA.QUEUE". I recall asking IBM for the structure of this queue and was promptly told that it was proprietary. I don't think the message format is "rocket science"... Any thoughts? Maybe an RFE to the MS03 support pack to save some queue stuff. Thanks in advance, -B Brian Bumpass Wachovia Bank E-Channels [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 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
