Re: Large record size
Thanks for the reply. The apps group decided to go with fewer records and they will not be persistent. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 7:11 AM To: [EMAIL PROTECTED] Subject: Re: Large record size Lissette, We had an application that sent about 8,000 2k-4k MT942 reports from the MF to an Windows frontend server farm where the data was parsed and applied to a data warehouse. When we were sending those messages persistent and one at a time the amount of time was substantial. Granted there may have been network considerations. BUTwe blocked those messages into 4mb blocks and the destination dissasembled them. When we switched to blocking the messages the time to deliver was reduced SUBSTANTIALLY!!! This option is not always available. But if it is you may want to consider using it. Try to run some performance test of the throughput. This could be done without a sweat by modifing one of the supplied example programs (amqsput) to do a loop and changing the message size. bobbee >From: Stefan Sievert <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Large record size >Date: Tue, 3 Dec 2002 16:20:07 -0800 > >Hi Lizette, >what exactly is your concern? Is it amount of data or number of messages? >Or >both...? >Generally speaking, 1k is not really a big message. If you add the message >descriptor and transmission header (roughly 450 bytes), you are talking >about approc. 1500 bytes per message. If you look at the performance >support >pacs you will see that this is the average message size at which MQ >throughput peaks, so I wouldn't worry about the size (it doesn't matter >anyway, they say). ;-) >Assuming you have enough disk space everywhere the messages touch a disk >(XMITQ on /390, target queue on Win2K) and your log files are sufficiently >defined, you should be fine. The real challenge will be to convince your >programmer not to try to send all 900.000 messages in ONE unit of work, but >to do frequent commits ;-) >There is a queue manager parameter that limits the number of uncommited >messages (I think on 390 its called MAXSMSGS), that will limit how many >messages the application can put within a syncpoint. It is a good practice >to design applications so that they can make use of 'reasonable' batch >sizes >(preferably configurable) so this limit is not reached (it causes an >MQCC_FAILED with MQRC_BACKED_OUT, I think). Remember, the MCA on the >mainframe will not even see the messages (and start transmitting them) >until >the application calls MQCMIT. I am assuming that they are put using >MQPM_SYNCPOINT; first of all because they are persistent, secondly because >it's the default on /390. >Bottom line: I would be more concerned about a tunable design, using a >configurable application batch size, than about sheer volume. Other >opinions/aspects/remarks out there? >Hope it helps a bit, >Stefan > >>From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> >>Reply-To: MQSeries List <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Subject: Large record size >>Date: Tue, 3 Dec 2002 17:22:39 -0600 >> >>I have a programmer currently designing an MQ application who would like >>to >>send 900,000 persistent messages through MQ. The bytes per record is >>1012. >>It will run on OS/390 to a Window 2000 server both running 5.2 MQ. Are >>there any negative affects to sending this many records? It is by far the >>largest record size we have defined and I am concerned. >> >> >>--- Legal Disclaimer: The information contained in this communication may >>be >>confidential, is intended only for the use of the recipient named above, >>and >>may be legally privileged. If the reader of this message is not the >>intended recipient, you are hereby notified that any dissemination, >>distribution, or copying of this communication, or any of its contents, is >>strictly prohibited. If you have received this communication in error, >>please re-send this communication to the sender and delete the original >>message and any copy of it from your computer system. 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 > > >_ >STOP MORE 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 _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 Instructions for managing your mail
Re: How to use subscription point
Gaurav, >>>We are trying to use subscription points in our publish subscribe. >>>But i was not able to find any JMS api through which we can pass >>>subscription point at the time of registering the subscriber. I >>>am not sure whether we pass it at the time of registry or through >>>some other way. If anyone has used subscription points then pls >>>help me know how to implement it. Subscription points are not supported by the JMS spec. They are available using the base MQ Java API or the AMI. 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
How to use subscription point
We are trying to use subscription points in our publish subscribe.But i was not able to find any JMS api through which we can pass subscription point at the time of registering the subscriber.I am not sure whether we pass it at the time of registry or through some other way. If anyone has used subscription points then pls help me know how to implement it. Regds Gaurav Sai Mittal Wipro-EAI Consultant 952-324-0243(w) 952-941-5658(h) 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: WMQIv2 shutdown problem CSD update
Hi, I may have been mislead a little the latest on the Website says it is CSD03, but once you apply it and you do a lslpp -l it will give a display of 2.1.0.4 as they started with level 0. (Does that make sense?) http://www-3.ibm.com/software/ts/mqseries/support/summary/mqsi.html Rgs John Abbott >>> <[EMAIL PROTECTED]> 05/12/2002 7:53:37 pm >>>Yes please, can you provide the link? "John Abbott" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 05-Dec-2002 03:14 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: WMQIv2 shutdown problemKulbir, we downloaded it from the web site do you want me to provide a link? Regards John Abbott >>> [EMAIL PROTECTED] 04/12/2002 7:18:28 pm >>> John, Are you on WMQSI 2.1 CSD04? Where did you get CSD04 from? Regards, Kulbir. "John Abbott" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 04-Dec-2002 00:22 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: WMQIv2 shutdown problemHi, We have just upgraded an our MQSi system to WMQSI and have noticed a small problem which has stumped us a little. We have a broker and it just won't shut down the 1st execution Group (ie the default execution group). It will shut down all the others but never that one. All we get is an error in the syslog saying: WMQIv210[4270]: (TEST_BROKER)[772]BIP2804E: The broker has detected that Execution Group Services, process ID 41542, has not shutdown. : TEST_BROKER.agent: /build/S210_P/src/AdminAgent/ImbAdminStore.cpp: 606: ImbAdminStore::FindAndReportAllLongRunningProcesses: : " Once we issue a kill command on this process the broker shuts down not a problem and the mqsistop command returns the normal message: "BIP8061I: Successful comamnd completion." The software revisions are WMQSI 2.1 csd04 MQ 5.2 csd 05 DB2 UDB 7.2 AIX 4.3.3.0 RML 10 Hardware is IBM RS/6000 pSeries 6C1 Any help would be greatly apreciated. Regards John Abbott PS: your list was very helpful with another similar problem on MQSeries. Many thanks to all that provided solutions. ** * IMPORTANT INFORMATION * This document should be read only by those persons to whom it is addressed and its content is not intended for use by any other persons. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Any unauthorised form of reproduction of this message is strictly prohibited. St.George is not liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt. **
Re: AW: Client conversion from Windows to OS/390
There is no overhead if gmo_convert is requested, but not required. That's one of the reasons it's preferred over channel conversion. > -Original Message- > From: Kevin Ferguson [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, December 05, 2002 2:10 PM > To: [EMAIL PROTECTED] > Subject: Re: AW: Client conversion from Windows to OS/390 > > True, but I still maintain that the 'getting' application (or organisation) > is behaving badly (or at best short sightedly)it is no big deal to code > the convert on the get and by doing so the organisation is able to accept MQ > messages from anywhere making the application much more flexible (and > saleable). > > I am not sure of what (if any) overhead is associated with doing a convert > on a get, but I can't imagine it is high enough to warrant not setting the > option 'just in case'. My understanding was that if no conversion was > required it (MQSeries) wouldn't do any and that only those messages coming > from unlike platforms would go through conversion. Or am I misguided here? > > Kevin Ferguson > > >His problem may be that he can't influence the 'get'-Application, for it's > >in another company or something else. > > > >So he does have to convert before leaving his company. > > > > _ > The new MSN 8: smart spam protection and 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 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: AW: Client conversion from Windows to OS/390
True, but I still maintain that the 'getting' application (or organisation) is behaving badly (or at best short sightedly)it is no big deal to code the convert on the get and by doing so the organisation is able to accept MQ messages from anywhere making the application much more flexible (and saleable). I am not sure of what (if any) overhead is associated with doing a convert on a get, but I can't imagine it is high enough to warrant not setting the option 'just in case'. My understanding was that if no conversion was required it (MQSeries) wouldn't do any and that only those messages coming from unlike platforms would go through conversion. Or am I misguided here? Kevin Ferguson His problem may be that he can't influence the 'get'-Application, for it's in another company or something else. So he does have to convert before leaving his company. _ The new MSN 8: smart spam protection and 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
Re: Client conversion from Windows to OS/390
If the msg is string format, the channel should convert it. You do have to stop/start the channel if it is running when you change the conversion option. -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Client conversion from Windows to OS/390 Peter, Thanks for your reply. The channel from the Windows client to the first OS/390 is a svrconn, so there is no conversion parameter to turn on. I have tried to turn on conversion for the channel between the first OS/390 and the second OS/390, but that does not help. Regards, John -Original Message- From: Peter Heggie [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 12:34 PM To: [EMAIL PROTECTED] Subject:Re: Client conversion from Windows to OS/390 You could dedicate a pair of channels for this application and perform the conversion on the channel.. From: "Dawson, John" <[EMAIL PROTECTED]> on 12/05/2002 01:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Client conversion from Windows to OS/390
>The application on the second OS/390 platform does not do a 'get' with >convert and thus the message is still in ascii code. > His problem may be that he can't influence the 'get'-Application, for it's in another company or something else. So he does have to convert before leaving his company. Norbert Pfister IT DB/DC-Systemtechnik ITELLIUM Systems & Services GmbH N - Bau V, Zi. 113 Fürther Strasse 205 D-90429 Nürnberg, Germany Tel.: (+49) 0911/14-26548 Fax: (+49) 0911/14-23390 Mobil: (+49) 0151/14265011 mailto:[EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Robert C Fruncillo [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 5. Dezember 2002 21:58 An: [EMAIL PROTECTED] Betreff: Re: Client conversion from Windows to OS/390 John, Kevin is right. The data conversion is done on the get. The conversion on the get will not take place if the message descriptor format field on the put is set to MQFMT_NONE. Make sure it is set to MQFMT_STRING. The data conversion also does not automatically take place and must be requested on the get. Bob Kevin Ferguson To: [EMAIL PROTECTED] Subject: Re: Client conversion from Windows to OS/390 Sent by: MQSeries List From: "Dawson, John" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Client conversion from Windows to OS/390 >Date: Thu, 5 Dec 2002 12:14:35 -0600 > >Hello, > >I have a client on a Windows NT platform that is putting a message onto a >remote queue defined on a OS/390 platform, which in turn sends the message >to a second OS/390 platform. > >The application on the second OS/390 platform does not do a 'get' with >convert and thus the message is still in ascii code. > >What do I need to do to convert the message to EBCIDC before the message is >'put' from the client. > > >Thanks, > >John > >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 _ MSN 8 helps eliminate e-mail viruses. Get 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 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
MSMQ-MQSeries Bridge - Transactional?
My client implemented a custom written bridge between MSMQ and MQSeries Client on Windows NT. The machine with MSMQ does not have a local Queue Manager, only MQSeries Client. This design has been scrapped since MQSeries Client cannot participate in a distributed transaction with MSMQ. Does anyone know if the Microsoft supplied MSMQ-MQSeries bridge supplies some transactional control when using MQSeries Client? There is a brief mention of "Transactions Through the Bridge" in a MSDN article I read, but it didn't specify working with MQ Client. I've pasted that into the bottom of this post. We've also looked at MQe, but it also doesn't support transactions. Is a full-blown Queue Manager the only way to manage a transaction between MSMQ and the MQSeries Family? Unfortunately, it's not an option here. I really don't want to roll my own transaction manager if I don't have to. Thanks for your help, Jason Snippet from MSDN article: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/host/reskit/part3/hisrkc12.asp Transactions through the Bridge MSMQ and MQSeries applications that send messages in a transaction through the MSMQ-MQSeries Bridge can expect the same semantics and notifications that would be received if the application were sending messages to native queues. When an MSMQ application commits, sending a message, the message is placed in the source xact dead letter queue and routed to the transactional connector queue for processing by the Bridge. The Bridge will read the message within a transaction, convert and send the MQSeries message also within a transaction. The smaller of the two MSMQ timeout values PROPID_M_TIME_TO_REACH_QUEUE and PROPID_M_TIME_TO_BE_RECEIVED is used to set the MQSeries Expiry value as MQSeries only supports a single expiration field. Acknowledgement messages (reports) sent from MQSeries are routed to the transmission queues used by the MSMQ-MQSeries Bridge. The Bridge reads and converts the acknowledgement messages to equivalent MSMQ acknowledgements and then sends the acknowledgement to the MSMQ queue specified by the sending application. In the MQSeries to MSMQ direction, similar processing occurs. The MQSeries Expiry value is converted to the MSMQ PROPID_M_TIME_TO_BE_RECEIVED timeout value. The MSMQ timeout value PROPID_M_TIME_TO_REACH_QUEUE is not set. 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
Copybook TAFRIT for Sample Application
The redbook "CICS Transaction Server for OS/390 Version 1 Release 3: Web Support and 3270 Bridge" (pause for breath) has been a great resource. However, I wanted to set up the test application for their Psuedo Conversational task, transaction TCHP, in order to walk thru the panels, etc., in the doc. Almost all the source could be downloaded from the web, except for a critical copybook called TCAFRIT. Has anyone else found this copybook? TIA, Jill Grine alias MQ Rookie 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: Client conversion from Windows to OS/390
John, Kevin is right. The data conversion is done on the get. The conversion on the get will not take place if the message descriptor format field on the put is set to MQFMT_NONE. Make sure it is set to MQFMT_STRING. The data conversion also does not automatically take place and must be requested on the get. Bob Kevin Ferguson To: [EMAIL PROTECTED] Subject: Re: Client conversion from Windows to OS/390 Sent by: MQSeries List From: "Dawson, John" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Client conversion from Windows to OS/390 >Date: Thu, 5 Dec 2002 12:14:35 -0600 > >Hello, > >I have a client on a Windows NT platform that is putting a message onto a >remote queue defined on a OS/390 platform, which in turn sends the message >to a second OS/390 platform. > >The application on the second OS/390 platform does not do a 'get' with >convert and thus the message is still in ascii code. > >What do I need to do to convert the message to EBCIDC before the message is >'put' from the client. > > >Thanks, > >John > >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 _ MSN 8 helps eliminate e-mail viruses. Get 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 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
WebSphere MQ 5.3 on Win2K
I just installed IBM WebSphere MQ 5.3 on Windows 2000. How can I tell if I installed the client version? Is there a support pac available for this version, if so where? Thanks! Matt
PID that has a queue open.
BDY.RTF Description: RTF file
Re: Client conversion from Windows to OS/390
John, Make sure the message descriptor format field on your MQPUT is set to MQFMT_STRING and not MQFMT_NONE. I don't believe data conversion can take place with it set to MQFMT_NONE. We have the same set up client - os/390 and it works great. No problems. Thanks, Bob "Dawson, John"To: [EMAIL PROTECTED] Sent by: MQSeries List mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 12:34 PM To: [EMAIL PROTECTED] Subject:Re: Client conversion from Windows to OS/390 You could dedicate a pair of channels for this application and perform the conversion on the channel.. From: "Dawson, John" <[EMAIL PROTECTED]> on 12/05/2002 01:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Client conversion from Windows to OS/390
John I believe that there is no such thing as a PMO of Convert. The 'getting' application should do the convert. Havign the 'getting' application do the conversion makes much more sense as the 'putting' application has no idea where the message will end up (platform wise) If the final destination application isn't behaving and converting then a channel between the 2 OS/390 Qmgrs could do it.but it may be easier to change the applicaton so that it behaves itself. :) Failing that, maybe you could write an application that sat in the middle that did the conversion for it? Kevin Ferguson From: "Dawson, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Client conversion from Windows to OS/390 Date: Thu, 5 Dec 2002 12:14:35 -0600 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John 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 _ MSN 8 helps eliminate e-mail viruses. Get 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: Client conversion from Windows to OS/390
Check the Convert Option of the GMO... Nii-Boi Kotei "Dawson, John" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 12/05/2002 01:14:35 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John 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
MQ Event Broker VS Websphere MQ Integrator(mqsi)
Hi, In our organisation we are thinking of replacing Websphere MQ Integrator(mqsi) 2.1 with MQ Event Broker.I wanted to know if anyone has any experiences with event broker.Is there something that mqsi support that event broker doesn't support.Our requirements are basically for simple PU-SUB and with some message routing logics in message flows.We are using JMS.Also what changes we need to make to do this shift. Regds Gaurav Sai Mittal Wipro-EAI Consultant 952-324-0243(w) 952-941-5658(h) 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: Client conversion from Windows to OS/390
Hi John, you should put the message on the client with the CCSID of the server on OS/390. The default CCSID is the one of the client . See http://www-3.ibm.com/software/ts/mqseries/library/manuals/csqzaf/CSQZAF2N.HT M#Header_256 in "MQSeries Clients" . Norbert Pfister IT DB/DC-Systemtechnik ITELLIUM Systems & Services GmbH N - Bau V, Zi. 113 Fürther Strasse 205 D-90429 Nürnberg, Germany Tel.: (+49) 0911/14-26548 Fax: (+49) 0911/14-23390 Mobil: (+49) 0151/14265011 mailto:[EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Dawson, John [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 5. Dezember 2002 19:41 An: [EMAIL PROTECTED] Betreff: Re: Client conversion from Windows to OS/390 Peter, Thanks for your reply. The channel from the Windows client to the first OS/390 is a svrconn, so there is no conversion parameter to turn on. I have tried to turn on conversion for the channel between the first OS/390 and the second OS/390, but that does not help. Regards, John -Original Message- From: Peter Heggie [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 12:34 PM To: [EMAIL PROTECTED] Subject:Re: Client conversion from Windows to OS/390 You could dedicate a pair of channels for this application and perform the conversion on the channel.. From: "Dawson, John" <[EMAIL PROTECTED]> on 12/05/2002 01:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Client conversion from Windows to OS/390
Peter, Thanks for your reply. The channel from the Windows client to the first OS/390 is a svrconn, so there is no conversion parameter to turn on. I have tried to turn on conversion for the channel between the first OS/390 and the second OS/390, but that does not help. Regards, John -Original Message- From: Peter Heggie [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 12:34 PM To: [EMAIL PROTECTED] Subject:Re: Client conversion from Windows to OS/390 You could dedicate a pair of channels for this application and perform the conversion on the channel.. From: "Dawson, John" <[EMAIL PROTECTED]> on 12/05/2002 01:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client conversion from Windows to OS/390
You could dedicate a pair of channels for this application and perform the conversion on the channel.. From: "Dawson, John" <[EMAIL PROTECTED]> on 12/05/2002 01:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Client conversion from Windows to OS/390 Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John 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
Client conversion from Windows to OS/390
Hello, I have a client on a Windows NT platform that is putting a message onto a remote queue defined on a OS/390 platform, which in turn sends the message to a second OS/390 platform. The application on the second OS/390 platform does not do a 'get' with convert and thus the message is still in ascii code. What do I need to do to convert the message to EBCIDC before the message is 'put' from the client. Thanks, John 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: Workflow & Clustering
Been there, fought that battle and eventually lost it to the 'well we won't support it' mindset. I was not happy with depth of the MQ knowledge of the consulting firm that came in to implement the workflow application and even less happy with their z/OS experience. The clustering doesn't really give us any problems, however we ran definately ran into the IBM wants it done this way or we won't support it approach. You have to remember that Workflow wasn't developed by IBM and that it didn't come from the mainframe end...consequently the scripts that define the queues etc are not at all mainframe friendly. They are generated on a work station and then defined in a batch run on z/OS. We agrued long and hard that we didn't see the need for more than one Qmgr on MVS too and lost that one because the consulting firm didn't understand the concept of one Qmgr being able to handle lots of applications and the IBM rep. supported them. If you would like to see some of the emails that were fired around I will send them to you but outside of this forum. Kevin Ferguson American National Insurance _ The new MSN 8: smart spam protection and 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
Re: file systems
Tim, Having WMQ and WMQI on different filesystems is not going to make much improvement on performance, but will make life easier from an administrative point of view. Having WMQ and WMQI on different physical drives will. Regards, Chris Tim Crossland cc: Sent by: Subject: file systems MQSeries List 12/05/2002 06:16 AM Please respond to tim_crossland One of the system administrators at my client has insisted that there is not a requirement for separate file systems for MQ and MQ Integrator. We are now suffering performance problems. I have been unable to find any documentation that specifies that the performance problems may be caused by using one shared filesystem on a Solaris server. Also, as this is a development machine, there is only one physical disk. Can anybody point me to any evidence that using multiple filesystems will improve performance? Thanks, Tim Crossland http://www.solent-consultancy.com _ 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 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 Bridge Start
Jill, We found the easiest way to start the bridge transaction (CKBR) is to start it with a Process defined to the REQUESTQ. Use a trigger on FIRST on the requestq to start the transaction the first time a message is put on the queue. This way no terminal is tied to the transaction. Refer to IBM's Systems Administration Guide for os390/zos - Operating the CICS Bridge. I hope this helps. Gary --- Original Message -- >>Date:Wed, 4 Dec 2002 10:01:27 -0500 >>From:Jill Grine <[EMAIL PROTECTED]> >>Subject: CICS Bridge Start >>MIME-Version: 1.0 >>Content-Type: text/plain; charset="iso-8859-1" >> >>Hello MQ Listers, >> >>Well, I'm verturing into another new subsystem and wondered if anyone is >>using the MQ-CICS 3270 Bridge? If so, how are >>you starting it? If the CKBR transaction ties up a terminal until the >>monitor ends, sounds like a bad choice. I prefer not to >>have an operator have to issue a transaction to start it, and we don't have >>automated operator-type software. Just curious >>to know what others are doing. Thanks! >> >>Jill Grine 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: MQSERIES Digest - 4 Dec 2002 to 5 Dec 2002 (#2002-342)
Anyone experience problems allocating multi volume page datasets? I have my LIST on digest… if you do respond could you respond to my email? Thanks!
Re: Weblogic/MQJMS
Have you tried command line commands (amqsput) to put the remote queue? If the environment works at that level and your message shows up on the other end, your JNDI implementation should work. I'd eliminate this layer and start moving up to higher levels (context, syntax, etc.). Are you throwing a javax.naming.NamingException? -Original Message-From: Jay Jayatissa [mailto:[EMAIL PROTECTED]]Sent: Wednesday, December 04, 2002 4:55 AMTo: [EMAIL PROTECTED]Subject: Weblogic/MQJMSHi, does anyone know when using JMS to create JNDI objects, if it is possible to have a JNDI object as a remote queue? Iam having difficulty binding to a remote queue on MQSeries from Weblogic. many thanks, Jay
MQSeries in HP Serviceguard clusters.
Hello everyone! I am about to cluster adapt an existing MQSeries installation on one node in a two-node cluster, where both nodes will eventually run MQSeries. I have the installation guide from IBM, but alas am a bit worried. The cluster is a production cluster and one of the more critical ones for the customer. Test environment is probably not an option, I am afraid. Have anyone done this before and have any tips, tricks, "do not!!", gotchas etc. Is the "MQSeries for HP-UX - Implementing with Multi-Computer/ServiceGuard" as good for this as it sounds. Its still version 1.0 after more than a year. ".0" make me nervous. ;-) Thanks in advance TJo -- - SchlumbergerSema AB Ebbe Lieberaths gatan 10-12 412 97 GÖTEBORG Mobil +46-708-51 44 59 Tel +46-31-751 44 59 (Q 46 00) Fax +46-31-751 47 74 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
Workflow & Clustering
Hi, Our organization is looking into using MQ Workflow. At this moment, we're not using any clustering in our environment. However, the MQ Workflow product seems to require clustering to operate correctly. What I understand of MQ Workflow, using just a single Enactment server, it must be possible to avoid using clustering, but this means we would have to manually edit the confuguration scripts that are generated when installing the workflow product. Personally, I have more confidence in the manual adjustment of the MQ configuration than in using clustering in a production environment, especially when only 1 workflow server is used. Does anyone have any experiences to share? The responsible projectmanager is afraid that IBM will not provide support when we change the configuration, so that no clustering is used. Any comments? Regards, Ard van der Leeuw Belastingdienst/Centrum voor ICT Servicebeheerder Gedistribueerde Services Continuiteit Generieke Infrastructuren Netwerken, Telematica en Gedistribueerde Services Tel: +31 55 528 3011 Mob: + 31 6 28846008 -- De Belastingdienst gebruikt e-mail niet voor officiele mededelingen. == 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
file systems
One of the system administrators at my client has insisted that there is not a requirement for separate file systems for MQ and MQ Integrator. We are now suffering performance problems. I have been unable to find any documentation that specifies that the performance problems may be caused by using one shared filesystem on a Solaris server. Also, as this is a development machine, there is only one physical disk. Can anybody point me to any evidence that using multiple filesystems will improve performance? Thanks, Tim Crossland http://www.solent-consultancy.com _ 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
