Re: MVS msg exit (MQPUT) processing causes increase in MSTR regio n size.
Stefan, I live in Charlotte, North Carolina where every night the news has a story about West Nile virus and encephalitis so the phrase kind of gave me a jolt. I don't claim to speak for the rest of the list, the Star Wars reference was just the first thing that came to mind. I'm all recovered now. :-) Still, one more thing to add to the list of stuff that doesn't translate well. Stories abound about marketing campaigns that failed because of bad translations, like when Chevy discovered that the literal translation of their "Nova" car model in Spanish was "won't go". I worked for NationsBank before the merger with Bank Of America. The story there was that they had to choose between the two names and in some languages "NationsBank" translated roughly into "Bank Owned By The State". Well, back to work. Sorry for the digression off topic. I'm turning on my "Universal Translator" now... -- T.Rob -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:31 PM To: [EMAIL PROTECTED] Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR regio n size. Ooops... Looks like the literal translation of a quite common phrase in my native language had an unexpected effect... Maybe I should stick with 'just a thought' next time. Apologies to anybody who was impacted by the 'visual', it wasn't my intention to be the nauseous kind! Stefan >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR regio > n size. >Date: Wed, 3 Sep 2003 14:55:18 -0500 > >Master, I feel there has been a great disturbance in The List. It is as if >1,600 people collectively went "eeewww, thanks for the visual - NOT!". > >-- T.Rob (who is leaving his desk to go wash up...) > >-Original Message- >From: Stefan Sievert [mailto:[EMAIL PROTECTED] >Sent: Wednesday, September 03, 2003 3:05 PM >To: [EMAIL PROTECTED] >Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR >region size. > > >Dax, >is the memory increase ongoing, ie. does it increase with every test run, >or >only once? >If only once, have you tried to configure the exit, but bypass your >processing within the exit and just return? I am just guessing, but maybe >the memory increase you see is caused by the pure loading of the exit? How >big is the exit load module? >Just some brain pus... >Stefan > >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 _ Get MSN 8 and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental 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: HPUX install: "./lap/jre/bin/java: not found"
I haven't done it on HPUX but I think it's caused by the umask setting. Cheers, Ian -Original Message- From: Yuval Ofer [mailto:[EMAIL PROTECTED] Sent: Wednesday, 3 September 2003 9:19 PM To: [EMAIL PROTECTED] Subject: HPUX install: "./lap/jre/bin/java: not found" I'm tring to install MQ on HPUX11i. I got the following error: # cd /local/MQ # . ./mqlicense.sh -accept ksh: ./lap/jre/bin/java: not found ERROR: Installation will not succeed unless the license agreement can be accepted.> Any Ideas? 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: MVS msg exit (MQPUT) processing causes increase in MSTR regio n size.
Ooops... Looks like the literal translation of a quite common phrase in my native language had an unexpected effect... Maybe I should stick with 'just a thought' next time. Apologies to anybody who was impacted by the 'visual', it wasn't my intention to be the nauseous kind! Stefan From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR regio n size. Date: Wed, 3 Sep 2003 14:55:18 -0500 Master, I feel there has been a great disturbance in The List. It is as if 1,600 people collectively went "eeewww, thanks for the visual - NOT!". -- T.Rob (who is leaving his desk to go wash up...) -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 3:05 PM To: [EMAIL PROTECTED] Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size. Dax, is the memory increase ongoing, ie. does it increase with every test run, or only once? If only once, have you tried to configure the exit, but bypass your processing within the exit and just return? I am just guessing, but maybe the memory increase you see is caused by the pure loading of the exit? How big is the exit load module? Just some brain pus... Stefan 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 _ Get MSN 8 and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental 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: MVS msg exit (MQPUT) processing causes increase in MSTR regio n size.
Master, I feel there has been a great disturbance in The List. It is as if 1,600 people collectively went "eeewww, thanks for the visual - NOT!". -- T.Rob (who is leaving his desk to go wash up...) -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 3:05 PM To: [EMAIL PROTECTED] Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size. Dax, is the memory increase ongoing, ie. does it increase with every test run, or only once? If only once, have you tried to configure the exit, but bypass your processing within the exit and just return? I am just guessing, but maybe the memory increase you see is caused by the pure loading of the exit? How big is the exit load module? Just some brain pus... Stefan 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
6125 error in .Net app....
Hi all I am flying in an area that I am not familiar with trying to help out a developer but here goes anyway:) I have a 2 .Net apps that are connecting to a Solaris box via an MQ client. The Client and server MQ version is 5.2, csd 5 for the server. One app is sending a request that is going off to a version 5.2 OS390 qmanager for some backend processing. As the request comes back, the second app processes it and returns to the queue to wait for other responses. The second app is in an unlimited wait. The problem that we are encountering is an occasional 6125 error which basically stops processing for the receiving app and requires us to have to recycle it to get it processing again. The text associated with the 6125 error suggests that the queue has not been opened but I know that it has because some messages do process before this is received, so what I am assuming is happening is that somehow the connection is being "lost", or the reference to it and then the recycle establishes a new one. I want to say this is a network connectivity issue but am really guessing here. Anyone seen this kind of occurrence?!? Thanks in advance! Dan 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: Accounting
Dave START TRACE(ACCTG) CLASS(03) The SMF records give input and output byte counts by local queue name. Richard Jackson SIAC - CICS/MQ Systems 212-383-9043 "Williams, Dave (Systems To: [EMAIL PROTECTED] Management)" cc: (bcc: Richard Jackson/SIAC) <[EMAIL PROTECTED]Subject: Accounting OM> Sent by: MQSeries List <[EMAIL PROTECTED] n.ac.at> 09/03/2003 01:04 PM Please respond to MQSeries List I want to capture queue-level SMF records (subtype2) and from what I gather to this point I have to specify class 3 when while doing a start on the accounting trace (using the START TRACE command), but I can't put my finger on the doc. Does anyone know where it's located or has anyone done this? Also is anyone familiar w/Point-to-point JMS? TIA, Dave W. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer. 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: MVS msg exit (MQPUT) processing causes increase in MSTR region size.
Dax, is the memory increase ongoing, ie. does it increase with every test run, or only once? If only once, have you tried to configure the exit, but bypass your processing within the exit and just return? I am just guessing, but maybe the memory increase you see is caused by the pure loading of the exit? How big is the exit load module? Just some brain pus... Stefan From: d a <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: MVS msg exit (MQPUT) processing causes increase in MSTR region size. Date: Wed, 3 Sep 2003 18:08:23 + Thanks very much to all who have responded thus far (Ruzi, Richard and Neil), A few other things to add for anyone who is following this - I had done as Neil suggested, and run things without the exit, and in this case the size of the MSTR does NOT grow. So I know for sure it s caused by the exit .specifically the MQPUT or MQPUT1. - I also have tried to just let things be after processing is complete and the MSTR storage increases .just to see if after x period the storage is released by the MSTR .but it does not .well not in 12+ hours. - After pushing the messages (1000 in each direction) through the SDR and the RCVR, I then go and clear all the messages of the queues. Just wanted to see if this had any bearing, and once again nothing, the MSTR sits with that storage. - Also tried to manually stop / restart the channels, this also had no bearing on things. - The default persistence of the queue s is N . - You guys (Ruzi and Neil) are both correct, but in different cases, about the commit processing. In my case, I cannot use MQCMIT. This is an exert from the Intercommunication Guide : " All MQI calls except MQCMIT/CSQBCMT and MQBACK/CSQBBAK are allowed. They must be contained after MQCONN (with a blank queue manager name). If these calls are used, the exit must be link-edited with the stub CSQXSTUB. The exception to this rule is that security channel exits may issue commit and backout MQI calls. To do this, code the verbs CSQXCMT and CSQXBAK in place of MQCMIT/CSQBCMT and MQBACK/CSQBBAK." Thanks very much .Dax. _ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar 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 _ Help protect your PC: Get a free online virus scan at McAfee.com. 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: Accounting
You can enter the following command to turn it on: START TRACE(ACCTG) CLASS(3) It's documented in the System Setup Guide and the MQSC Command Reference. What was a little confusing is that you can't turn it on via the SMFACCT parameter. You have to turn in on using the command although you can add this command to your CSQINP2 input dataset. - Bruce Giordano "Williams, Dave (Systems Management)" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Sent by: MQSeries List Subject: Accounting <[EMAIL PROTECTED]> Wednesday September 3, 2003 01:04 PM Please respond to MQSeries List I want to capture queue-level SMF records (subtype2) and from what I gather to this point I have to specify class 3 when while doing a start on the accounting trace (using the START TRACE command), but I can't put my finger on the doc. Does anyone know where it's located or has anyone done this? Also is anyone familiar w/Point-to-point JMS? TIA, Dave W. 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: MVS msg exit (MQPUT) processing causes increase in MSTR region size.
Are you taking into account the size of the Msg Exit code itself when it is loaded into memory and remains resident? Just a thought. Cheers... Jim Nuckolls d a wrote: Thanks very much to all who have responded thus far (Ruzi, Richard and Neil), A few other things to add for anyone who is following this - I had done as Neil suggested, and run things without the exit, and in this case the size of the MSTR does NOT grow. So I know for sure it s caused by the exit .specifically the MQPUT or MQPUT1. - I also have tried to just let things be after processing is complete and the MSTR storage increases .just to see if after x period the storage is released by the MSTR .but it does not .well not in 12+ hours. - After pushing the messages (1000 in each direction) through the SDR and the RCVR, I then go and clear all the messages of the queues. Just wanted to see if this had any bearing, and once again nothing, the MSTR sits with that storage. - Also tried to manually stop / restart the channels, this also had no bearing on things. - The default persistence of the queue s is N . - You guys (Ruzi and Neil) are both correct, but in different cases, about the commit processing. In my case, I cannot use MQCMIT. This is an exert from the Intercommunication Guide : " All MQI calls except MQCMIT/CSQBCMT and MQBACK/CSQBBAK are allowed. They must be contained after MQCONN (with a blank queue manager name). If these calls are used, the exit must be link-edited with the stub CSQXSTUB. The exception to this rule is that security channel exits may issue commit and backout MQI calls. To do this, code the verbs CSQXCMT and CSQXBAK in place of MQCMIT/CSQBCMT and MQBACK/CSQBBAK." Thanks very much .Dax. _ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar 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
Consultant
Just a funny story -- sending it just in hope enough people on the list will find it amusing. I apologize for the off-topic and also in case it is an old joke. Pavel A shepherd was herding his flock in a remote pasture when suddenly a brand-new BMW advanced out of a dust cloud towards him. The driver, young man in a Broni suit, Gucci shoes, Ray Ban sunglasses and YSL tie, leans out the window and asks the shepherd, "If I tell you exactly how many sheep you have in your flock, will you give me one?" The shepherd looks at the man, obviously a yuppie, then looks at his peacefully grazing flock and calmly answers, "Sure. Why not?" The yuppie parks his car, whips out his Dell notebook computer, connects it to his cell phone, surfs to a NASA page on the internet, where he calls up a GPS satellite navigation system to get an exact fix on his location which he then feeds to another NASA satellite that scans the area in an ultra-high-resolution photo. They young man then opens the digital photo in Adobe Photoshop and exports it to an image processing facility in Hamburg, Germany. Within seconds, he receives an email on his Palm Pilot that the image has been processed and the data stored. He then accesses a MS-SQL database through an ODBC connected Excel spreadsheet with hundreds of complex formulas. He uploads all of this data via an email on his Blackberry and, after a few minutes, receives a response. Finally, he prints out a full-colour, 150-page report on his hi-tech, miniaturized HP LaserJet printer and finally turns to the shepherd and says, "You have exactly 1586 sheep." "That's right. Well, I guess you can take one of my sheep." says the shepherd. He watches the young man select one of the animals and looks on amused as the young man stuffs it into the boot of his car. Then the shepherd says to the young man, "Hey, if I can tell you exactly what your business is, will you give me back my sheep?" The young man thinks about it for a second and then says, "Okay, why not?" "You're a consultant." says the shepherd. "Wow! That's correct," says the yuppie, "but how did you guess that?" "No guessing required." answered the shepherd. "You showed up here even though nobody called you; you want to get paid for an answer I already knew; to a question I never asked; and you don't know crap about my business... and Now give me back my dog." -- 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
MA0I - Oracle PL/SQL language support
Does anyone have this running on Oracle 9? The last weekend my development database was upgraded from 8.1.7 to 9.2.0 (on Solaris) and it has not run since. It is never getting to MQ so that is not an issue, It seems to be a problem with the listener configuration based on the error messages, but other listeners are working fine. I have not even recompiled the shared objects at this point, because I did not think it would matter. Anyone have any experience with it? __ r dirk tolson Systems EngineerSavannah River Site dirk.tolson at srs.gov Aiken, SC 29808 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
MVS msg exit (MQPUT) processing causes increase in MSTR region size.
Thanks very much to all who have responded thus far (Ruzi, Richard and Neil), A few other things to add for anyone who is following this - I had done as Neil suggested, and run things without the exit, and in this case the size of the MSTR does NOT grow. So I know for sure it s caused by the exit .specifically the MQPUT or MQPUT1. - I also have tried to just let things be after processing is complete and the MSTR storage increases .just to see if after x period the storage is released by the MSTR .but it does not .well not in 12+ hours. - After pushing the messages (1000 in each direction) through the SDR and the RCVR, I then go and clear all the messages of the queues. Just wanted to see if this had any bearing, and once again nothing, the MSTR sits with that storage. - Also tried to manually stop / restart the channels, this also had no bearing on things. - The default persistence of the queue s is N . - You guys (Ruzi and Neil) are both correct, but in different cases, about the commit processing. In my case, I cannot use MQCMIT. This is an exert from the Intercommunication Guide : " All MQI calls except MQCMIT/CSQBCMT and MQBACK/CSQBBAK are allowed. They must be contained after MQCONN (with a blank queue manager name). If these calls are used, the exit must be link-edited with the stub CSQXSTUB. The exception to this rule is that security channel exits may issue commit and backout MQI calls. To do this, code the verbs CSQXCMT and CSQXBAK in place of MQCMIT/CSQBCMT and MQBACK/CSQBBAK." Thanks very much .Dax. _ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar 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: Outsourcing - my observations after my trip to India
If you are reducing costs and increasing your profits by reducing costs/wages are you developing markets, creating consumers, and increasing the size of the total economic pie? Or are you cannibalizing for the sake of profits and actually shrinking the size of the total economic pie. Absolutely your company may temporarily become more profitable. One thing that is certain while profits may be up overall pricing power will decrease. All Companies ultimately need disposable income in the hands of consumers. If a company is to grow and have pricing power these consumers need money. Cost reduction is the easy way out. In fact cost reduction is the lowest of the low hanging fruit used to return a company to profitability. The bottom line is LONG TERM growth is only sustainable by developing new markets. It used to be that economic downturns were used to reduce the froth created during the overheated periods of economic expansion. A company would reduce costs - the largest of these savings where always through layoffs, subsequently profits would improve and a company would start to spend these profits on capital improvements and the hiring of new employees. Now what happens if these profits are spent on foreign products and foreign workers. We have the jobless recovery that so many are claiming we are having now. Globalization will over time develop new markets - how much time - is anyones guess. One thing is for sure the effects of the new global economy will be painful to some (the current haves) and enjoyable for others(for the current have nots) . Will globalizing the economy expand the size of the pie or merely reallocate it? How many Mercedes or for that matter Nike cross trainers are those coders in Bangladesh or those assembling the Nike cross trainers buying. This is a highly complex issue. What drives profits. I would say demand I do not subscribe to some of our political leaders supply-side economics BS. I personally believe over time Globalization will be a good thing. However during this time of transition and uncertainty we should all admit no one really knows definitively what the long term effects will be on the US economy. The government while maybe not inacting protectionist legislation should at least monitor the situation and not act as if nothing is going on here. This loss of jobs hits the government doubly hard... all the while the government is spending money on unemployment and at the same time collecting ZERO payroll taxes and ZERO income taxes from the jobs lost. I believe a slow steady as she goes approach maybe the best approach. This would give all those involved time to adjust. Just as any of you that as a youngster grew too rapidly you probably experienced growing pains. The economy may infact if not artificially regulated experience devastating structural affects. We all have seen the madness business's and businessmen are willing to subject themselves, their companies, and their employees lives to - just look back to the craziness of the internet bubble. Capitalism can go a stray directed by greed. So in the mean time government regulation or intervention might just buy enough time for the effects of these uncertain times to become more thoroughly understood - which would not be a bad thein in my opinion. For years through immigration quotas we have regulated the people entering the US job market now through our technology we have open a new can of worms that allows jobs to be lost without physical immigration to just open this door completely has never been what the US has done. Darren Douch <[EMAIL PROTECTED]To: [EMAIL PROTECTED] om> cc: Sent by: MQSeriesSubject: Re: Outsourcing - my observations after my trip to List India <[EMAIL PROTECTED] N.AC.AT> 09/02/2003 02:18 PM Please respond to MQSeries List I'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that
Accounting
I want to capture queue-level SMF records (subtype2) and from what I gather to this point I have to specify class 3 when while doing a start on the accounting trace (using the START TRACE command), but I can't put my finger on the doc. Does anyone know where it's located or has anyone done this? Also is anyone familiar w/Point-to-point JMS? TIA, Dave W. 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: Outsourcing - my observations after my trip to India <-- Attachment History Removed
For years through immigration quotas we have regulated the people entering the US job market. Now through our technology we have opened a new can of worms. This can of worms allows US jobs to be lost without physical immigration. To just open this door completely has never been what the US has done. So I believe to ignore this is truth is not considering the entire truth. We have always had a certain amount of protectionist regulation through immigration quotas. Navin Vali <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IRWAYS.COM> cc: Sent by: MQSeries Subject: Re: Re: Outsourcing - my observations after my trip List to India <-- Attachment History Removed <[EMAIL PROTECTED] C.AT> 09/03/2003 12:44 AM Please respond to MQSeries List Hi Darren, I can't agree more with you You cant eat the Cake and Keep it too some real intelligent observations.. Regards Navin PS: But still " I " think we should stick to technical stuff on this list. Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: MQSERIES cc: bcc: Subject: Re: Outsourcing - my observations after my trip to India MessageI'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that lose their jobs, but I thought the US was a lover of free trade and the global economy. Actuall y that's a lie, I didn't think the US was a lover of free trade - they just like it when it suits them. Capitilism is about profits, one half of the profit equation is reducing costs - if companies can get the same goods / labour more cheaply somewhere else then they will. Some will send too many jobs, or the wrong jobs, abroad, will struggle then bring them back, or will fold. Others will get it right and their shareholders will cheer them on. Of course in some respects creating jobs in '3rd world' countries is good - their standard of living increases and makes them better potential markets for western goods and services. Do you want a global economy or not? The answer is 'yes', 'no', or 'just when it suits me'. Obviously, these opinions are just my own... Darren. - Original Message - From: Christopher D. Fryett To: [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 6:38 PM Subject: Outsourcing - my observations after my trip to India -Original Message- From: Christopher D. Fryett Sent: Sunday, August 31, 2003 12:30 PM To: Subject: RE: Outsourcing - my observations after my trip to India Zafar: Thank you for the detailed report you acquired from India. Although I don't completely agree that the outsourcing is 1% of the GDP based on the Indian colleagues I am currently working with right now who say the continued trend will help the 4 primary states of India which a
Re: Outsourcing - my observations after my trip to India
"Well said" indeed. It's always easy to jump up and down and scream too bad when you are on the receiving side. But let us see how long the flow of jobs and money keep moving in that direction. Lets remember, that while the people in this country do have a say in the way things run, the government is the one in charge of making sure our best interest are kept in mind. With the loss of jobs and the mis-accounting of non-taxed funds going out the door it is only too soon before my Uncle, remember him, realizes that his wallet is shrinking while the number of people he supports grows more in need of that which he is loosing. Our uncle is usually slow, but when he starts moving he is usually quick to implement a solution. Nothing motavates him more than money. BEING A CAPITALITISTIC STATE and all. The kaos is already being felt around here. NJ has already implemented laws against outsourcing. Other states are discussing this. It may not be too long before the companies in the origional EMAIL start laying off their 6 month wonders. So when the time comes, and trust me, as a living breathing, home grown ugly american, we will protect our own. And at that time I will Clap, Clap and Clap. And here ends my contribution to this thread. ON TO THE MQ STUFF! bee-oh-dubble-bee-dubble-egh PS. I have had discussions concerning corporate billing going out the door to outsourcing companies. If I was one of those 6 month wonders I would question WHY the company I worked for was taking SO much off the top and delivering so little to it's workers. Must be nice!! From: "Williams, Dave (Systems Management)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Outsourcing - my observations after my trip to India Date: Wed, 3 Sep 2003 09:06:50 -0400 I disagree with "well said". It's more like "tough darts". -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 8:29 AM To: [EMAIL PROTECTED] Subject: Re: Outsourcing - my observations after my trip to India Well said indeed. -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 5:18 PM To: [EMAIL PROTECTED] Subject: Re: Outsourcing - my observations after my trip to India I'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that lose their jobs, but I thought the US was a lover of free trade and the global economy. Actually that's a lie, I didn't think the US was a lover of free trade - they just like it when it suits them. _ Get MSN 8 and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental 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: Outsourcing - my observations after my trip to India
Darren: Yep, technical the stuff being talked about is technical since it is technically our jobs throughout the world. I do apologize if it seems that India is getting picked on and clearly that is not my intention. Some of my best friends and colleagues are from India and I have great respect for them. It just happens that India has become a significant issue not only in the U.S. but other aspects of the world. They are gaining ground, and that I applaud them. I don't applaud the fact that corporations sacrificing our jobs to make an easy buck which could continue to destabilize our economy and infrastructure. Yes, this is another aspect of globalization, but when it affects you directly in the pocket book and family it is serious and taken seriously. Thank you. Chris *** This is the opinion of the author and only the author and does not represent the organizations the author works or has worked for now or in the past. *** - Forwarded by Chris Fryett/MutualOMA on 09/03/2003 09:41 AM - |-+---> | | "Navin Vali"| | | <[EMAIL PROTECTED]| | | IRWAYS.COM> | | | Sent by: "MQSeries | | | List" | | | <[EMAIL PROTECTED]| | | C.AT> | | | | | | | | | 09/03/2003 02:44 AM | | | Please respond to | | | "MQSeries List" | | | | |-+---> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Outsourcing - my observations after my trip to India | | | >--| Hi Darren, I can't agree more with you You cant eat the Cake and Keep it too some real intelligent observations.. Regards Navin PS: But still " I " think we should stick to technical stuff on this list. 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: MVS msg exit (MQPUT) processing causes increase in MSTR region size.
Definitely. I must have misunderstood the issue (as I did not read the whole thing carefully). Thanks for correcting, David... Ruzi --- "David C. Partridge" <[EMAIL PROTECTED]> wrote: > I beg to differ! > > A commit takes place under the scope of a connection > handle. When a channel > exit connects to the queue manager, it will get back > an HCONN, but the > reason code will be MQRC_ALREADY_CONNECTED and the > HCONN it gets is the same > one the MCA is using, so any commits issues by the > exit *will* interfere > with the commits issued by the MCA. > > David > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Ruzi R > Sent: 03 September 2003 12:15 > To: [EMAIL PROTECTED] > Subject: Re: MVS msg exit (MQPUT) processing causes > increase in MSTR > region size. > > > > be careful with the suggestion from Ruzi. > > > > The message exit runs inside the unit of work for > > the MCA. If you commit, > > then you are committing the channel's work as > well. > > Not true. The application's commit is separate from > Channel's commit. Channel's commit depends on > BATCHSZ/BATCHINT attributes. > > Ruzi > > --- Neil Casey <[EMAIL PROTECTED]> wrote: > > Hi Dax (are you a DS9 fan?) > > > > be careful with the suggestion from Ruzi. > > > > The message exit runs inside the unit of work for > > the MCA. If you commit, > > then you are committing the channel's work as > well. > > > > You shouldn't have to worry about not committing > in > > your exit as the MCA > > will issue a commit for every batch. > > > > I have no idea why your real storage usage is > rising > > only when your exit is > > run, but to test it out, try running your programs > > without any exits, and > > at the same time run a local program which inserts > > the same message load as > > the exit would do. Look at the memory usage after > > this test and compare > > with running your exit to determine if your exit > is > > behaving badly. I would > > also suggest checking the virtual usage as well as > > real. If the virtual > > usage is unchanged, then what you are seeing is > not > > a leek, but a change in > > the working set in an unconstrained system. This > > would represent normal > > behaviour. Your system is clearly unconstrained > > because your paging rate is > > 0. > > > > Regards, > > > > Neil Casey. > > > > > > |-+> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | n.AC.AT> | > > | || > > | || > > | | 03/09/2003 02:29 | > > | | Please respond to| > > | | MQSeries List| > > | || > > |-+> > > > > > >--- > ---| > > | > > > >| > > | To: [EMAIL PROTECTED] > > > >| > > | cc: > > > >| > > | Subject: Re: MVS msg exit (MQPUT) > > processing causes increase in MSTR > > region | > > |size. > > > >| > > > > > >--- > ---| > > > > > > > > > > The first thing that came to my mind (without > > reading > > all the deatils carefully-- not that I could > > understand the code all that much) is that, it > might > > be caused by a delayed "commit"??? From your code, > I > > think you are using the default MQPMO. On the > > mainframe the Syncpoint is the default ( > > Syncpoint=yes). Looks like you are not commiting > > each > > message after each PUT (or after so many > messages). > > When you diconnect without the explicit commit, an > > implicit commit occurs committing all the 1000 > > messages. In the meantime, the 1000 messages > > (depending on on their size probably) may be > causing > > the space to expand. Since you are experimenting, > I > > suggest you try using a commit after every (or say > > 10 > > messages) and see whether you get the some > problem. > > > > I don"t know if the above is causing your problem, > > but > > I thought I would share my opinion with you > anyway. > > > > Best regards, > > > > Ruzi > > > > --- d a <[EMAIL PROTECTED]> wrote: > > > To the MVS people on the list > > > > > > I have been playing around with the following > > > message exit code it all > > > works fine BUT, I have just noticed that the > MSTR > > > address spaces for the 2 > > > queue mgrs I am testing on expands considerably > > not > > > a good thing > > > > > > Here is the setup, I have 2 queue mgrs QMG1 and > > > QMG2, and a set of
Re: Outsourcing - my observations after my trip to India
Title: Message I disagree with “well said”. It’s more like ”tough darts”. -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 8:29 AM To: [EMAIL PROTECTED] Subject: Re: Outsourcing - my observations after my trip to India Well said indeed. -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 5:18 PM To: [EMAIL PROTECTED] Subject: Re: Outsourcing - my observations after my trip to India I'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that lose their jobs, but I thought the US was a lover of free trade and the global economy. Actually that's a lie, I didn't think the US was a lover of free trade - they just like it when it suits them.
[no subject]
unsubscribe * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Riyad Bank. Finally, the recipient should check this email and any attachments for the presence of any viruses. Riyad Bank accepts no liability for any damage caused by any virus / error transmitted by this email. *
Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size.
You are both right, since you are talking about different things. Ruzi is correct to say that the application's commit is separate from Channel's commit. Neil is correct to say that a commit within a message exit would commit the MCA's UoW, and therefore this should not be done. However, it was not clear to me from the original problem, whether the MQPUT that Dax commented out, was in an application or in a message exit. Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] Ruzi R <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR List region size. <[EMAIL PROTECTED] N.AC.AT> 03/09/2003 12:14 Please respond to MQSeries List > be careful with the suggestion from Ruzi. > > The message exit runs inside the unit of work for > the MCA. If you commit, > then you are committing the channel's work as well. Not true. The application's commit is separate from Channel's commit. Channel's commit depends on BATCHSZ/BATCHINT attributes. Ruzi --- Neil Casey <[EMAIL PROTECTED]> wrote: > Hi Dax (are you a DS9 fan?) > > be careful with the suggestion from Ruzi. > > The message exit runs inside the unit of work for > the MCA. If you commit, > then you are committing the channel's work as well. > > You shouldn't have to worry about not committing in > your exit as the MCA > will issue a commit for every batch. > > I have no idea why your real storage usage is rising > only when your exit is > run, but to test it out, try running your programs > without any exits, and > at the same time run a local program which inserts > the same message load as > the exit would do. Look at the memory usage after > this test and compare > with running your exit to determine if your exit is > behaving badly. I would > also suggest checking the virtual usage as well as > real. If the virtual > usage is unchanged, then what you are seeing is not > a leek, but a change in > the working set in an unconstrained system. This > would represent normal > behaviour. Your system is clearly unconstrained > because your paging rate is > 0. > > Regards, > > Neil Casey. > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | n.AC.AT> | > | || > | || > | | 03/09/2003 02:29 | > | | Please respond to| > | | MQSeries List| > | || > |-+> > > > --| > | > >| > | To: [EMAIL PROTECTED] > >| > | cc: > >| > | Subject: Re: MVS msg exit (MQPUT) > processing causes increase in MSTR > region | > |size. > >| > > > --| > > > > > The first thing that came to my mind (without > reading > all the deatils carefully-- not that I could > understand the code all that much) is that, it might > be caused by a delayed "commit"??? From your code, I > think you are using the default MQPMO. On the > mainframe the Syncpoint is the default ( > Syncpoint=yes). Looks like you are not commiting > each > message after each PUT (or after so many messages). > When you diconnect without the explicit commit, an > implicit commit occurs committing all the 1000 > messages. In the meantime, the 1000 messages > (depending on on their size probably) may be causing > the space to expand. Since you are experimenting, I > suggest you try using a commit after every (or say > 10 > messages) and see whether you get the some problem. > > I don"t know if the above is causing your problem, > but > I thought I would share my opinion with you anyway. > > Best regards, > > Ruzi > > --- d a <[EMAIL PROTECTED]> wrote: > > To the MVS people on the list > > > > I have been playing around with the following > > message exit code it all > > works fine BUT, I have just noticed that the MSTR > > address spaces for the 2 > > queue mgrs I am testing on expands considerably > not > > a good thing > > > > Here is the setup, I have 2 queue mgrs QMG1 and > > QMG2, and a set of SD
Re: MQSeries on iSeries
Hi Marcin,
Here are the cold-start procedures (a.k.a. the 12 step process) I received
from IBM about two years ago. I've used them several times.
Lynn
~~`
Document ID: 20915351
What are some reasons to perform a cold start of MQ/400 :
Journal receivers(ie AMQA*) are missing causing the STRMQM to fails
If executing the a modified procedure fails (reference bottom of note)
NOTE: This problem can occur at any release.
NOTE: . WARNING
..
Please warn the customer that deleting his AMQAJRN MAY
discard some message data.
This will depend on how MQSeries was shut-down. If RCDMQMIMG
was executed before
ENDMQM, then this should minimize the number of journal
receivers required for STRMQM.
. WARNING
..
Please try the following:
1) DLTJRN JRN(Qmgrlib/AMQAJRN)
2) DLTJRNRCV JRNRCV(Qmgrlib/AMQA*) DLTOPT(*IGNINQMSG)
3) RMVLNK OBJLNK('/QIBM/USERDATA/MQM/QMGRS/QmgrName/QMQMCHKPT')
4) CRTJRNRCV JRNRCV(Qmgrlib/AMQA00) THRESHOLD(81920)
5) CHGOBJOWN OBJ(Qmgrlib/AMQA00) OBJTYPE(*JRNRCV) NEWOWN(QMQM)
6) CHGOBJPGP OBJ(Qmgrlib/AMQA00) OBJTYPE(*JRNRCV) NEWPGP(QMQMADM)
7) CRTJRN JRN(Qmgrlib/AMQAJRN) JRNRCV(Qmgrlib/AMQA00)
MSGQ(Qmgrlib/AMQAJRNMSG) MNGRCV(*SYSTEM)
8) CHGOBJOWN OBJ(Qmgrlib/AMQAJRN) OBJTYPE(*JRN) NEWOWN(QMQM)
9) CHGOBJPGP OBJ(Qmgrlib/AMQAJRN) OBJTYPE(*JRN) NEWPGP(QMQMADM)
10) WRKJRN Qmgrlib/AMQAJRN option 9
(associate the local journal receivers with the AMQAJRN, if
upgrading or restoring the journal receivers)
11) STRMQM
12) RCDMQMIMG OBJ(*ALL) OBJTYPE(*ALL) MQMNAME(QmgrName)
NOTE: Qmgrlib will be the name of library created when the queue manager was
created. To
see a list of possible queue manager libraries execute the
following command
WRKLIB LIB(QM*).
QmgrName will be the name of your queue manager.
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Marcin
Wilk
Sent: Wednesday, September 03, 2003 4:42 AM
To: [EMAIL PROTECTED]
Subject: MQSeries on iSeries
Hello everybody!
I am looking for description of cold restart procedure of MQSeries on
iSeries. I have searched many pages of ibm documentation. Now I know
how to start and stop it on iSeries, but I still don't really know
what "cold restart" really mean in this particular case. If you have
any suggestions or experience in using MQSeries on iSeries please
help. If you colud point me to interesting resources I would be very
gratefull.
Thank you in advance.
Best Regards,
Marcin Wilk
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: MQSeries on iSeries
A cold restart usually means rebuilding your queue manager. I don't if the iSeries coldstart is special to that platform or not, but I doubt it. Marcin Wilk <[EMAIL PROTECTED] To: [EMAIL PROTECTED] L> cc: Sent by: Subject: MQSeries on iSeries MQSeries List <[EMAIL PROTECTED] en.AC.AT> 09/03/2003 04:42 AM Please respond to MQSeries List Hello everybody! I am looking for description of cold restart procedure of MQSeries on iSeries. I have searched many pages of ibm documentation. Now I know how to start and stop it on iSeries, but I still don't really know what "cold restart" really mean in this particular case. If you have any suggestions or experience in using MQSeries on iSeries please help. If you colud point me to interesting resources I would be very gratefull. Thank you in advance. Best Regards, Marcin Wilk 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: MVS msg exit (MQPUT) processing causes increase in MSTR region size.
I beg to differ! A commit takes place under the scope of a connection handle. When a channel exit connects to the queue manager, it will get back an HCONN, but the reason code will be MQRC_ALREADY_CONNECTED and the HCONN it gets is the same one the MCA is using, so any commits issues by the exit *will* interfere with the commits issued by the MCA. David -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Ruzi R Sent: 03 September 2003 12:15 To: [EMAIL PROTECTED] Subject: Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size. > be careful with the suggestion from Ruzi. > > The message exit runs inside the unit of work for > the MCA. If you commit, > then you are committing the channel's work as well. Not true. The application's commit is separate from Channel's commit. Channel's commit depends on BATCHSZ/BATCHINT attributes. Ruzi --- Neil Casey <[EMAIL PROTECTED]> wrote: > Hi Dax (are you a DS9 fan?) > > be careful with the suggestion from Ruzi. > > The message exit runs inside the unit of work for > the MCA. If you commit, > then you are committing the channel's work as well. > > You shouldn't have to worry about not committing in > your exit as the MCA > will issue a commit for every batch. > > I have no idea why your real storage usage is rising > only when your exit is > run, but to test it out, try running your programs > without any exits, and > at the same time run a local program which inserts > the same message load as > the exit would do. Look at the memory usage after > this test and compare > with running your exit to determine if your exit is > behaving badly. I would > also suggest checking the virtual usage as well as > real. If the virtual > usage is unchanged, then what you are seeing is not > a leek, but a change in > the working set in an unconstrained system. This > would represent normal > behaviour. Your system is clearly unconstrained > because your paging rate is > 0. > > Regards, > > Neil Casey. > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | n.AC.AT> | > | || > | || > | | 03/09/2003 02:29 | > | | Please respond to| > | | MQSeries List| > | || > |-+> > > >--- ---| > | > >| > | To: [EMAIL PROTECTED] > >| > | cc: > >| > | Subject: Re: MVS msg exit (MQPUT) > processing causes increase in MSTR > region | > |size. > >| > > >--- ---| > > > > > The first thing that came to my mind (without > reading > all the deatils carefully-- not that I could > understand the code all that much) is that, it might > be caused by a delayed "commit"??? From your code, I > think you are using the default MQPMO. On the > mainframe the Syncpoint is the default ( > Syncpoint=yes). Looks like you are not commiting > each > message after each PUT (or after so many messages). > When you diconnect without the explicit commit, an > implicit commit occurs committing all the 1000 > messages. In the meantime, the 1000 messages > (depending on on their size probably) may be causing > the space to expand. Since you are experimenting, I > suggest you try using a commit after every (or say > 10 > messages) and see whether you get the some problem. > > I don"t know if the above is causing your problem, > but > I thought I would share my opinion with you anyway. > > Best regards, > > Ruzi > > --- d a <[EMAIL PROTECTED]> wrote: > > To the MVS people on the list > > > > I have been playing around with the following > > message exit code it all > > works fine BUT, I have just noticed that the MSTR > > address spaces for the 2 > > queue mgrs I am testing on expands considerably > not > > a good thing > > > > Here is the setup, I have 2 queue mgrs QMG1 and > > QMG2, and a set of SDR/RCVR > > channels between them, all with the exit defined > as > > a message exit on them. > > I then send through 1000 messages in both > directions > > to drive the exit > > defined on the RCVR and SDR channels. > > > > The result Note the Real storage frames: > > > > Before processing: > > - > > JOBNAME ,StepName,ProcStep,JobID ,Owner > > ,C,Pos,DP,Real,Paging, SIO > > QMG1MSTR QMG1MSTR PROCSTEP STC05201 QMG1MSTR NS > > FE 8084 0.00 0.00 > > QMG1CHIN QMG1CHIN PROCSTEP STC05203
Re: MQIPT through a firewall - part II
Hi Phil, Thanks for the reply. I suspected as much but I have to say I'm surprised there hasn't been more interest in this feature. Oh well... While you're here ;-) I've found that the second part of the chain isn't working either. I've set up the Apache Rewrite as specified in the manual and I believe this is working but I'm getting 2059 when I try to connect my MQ client. The remote MQIPT trace shows that I'm getting through Apache and the HTTP header looks ok but shortly after this I get a Java exception in the remote MQIPT: Time: 12:23:43.231 2003.09.03 Class: com.ibm.mq.ipt.ConnectionThread Method: callerToResponder Thread ID: ConnThd for Route 61414-0 Logger: TraceLogger 61414 Waiting for next message from caller... Time: 12:23:43.581 2003.09.03 Class: com.ibm.mq.ipt.ConnectionThread Method: run Thread ID: ConnThd for Route 61414-0 Logger: TraceLogger 61414 IOException in run() : , p1=java.io.EOFException --> com.ibm.mq.ipt.ConnectionThread.closeAllConnections (ConnThd for Route 61414-0) 12:23:43.581 I've got trace=5 so I don't know how to get any more details about this. Any help would be appreciated. Cheers, Paul -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Phil Blake Sent: 02 September 2003 20:52 To: [EMAIL PROTECTED] Subject: MQIPT through a firewall Hi Paul, Sorry, MQIPT doesn't support proxy authentication. I think you're only the second person to ask for this feature. All I can say is that it's on the requirements list for the next release of MQIPT if and when there is one. Sorry I can't be more exact. Phil Blake - Message from Paul Meekin <[EMAIL PROTECTED]> on Tue, 2 Sep 2003 10:01:42 +0100 - Subject: MQIPT through a firewall I'm trying to get an MQ connection going through a firewall in pretty much the same configuration as the "Apache Rewrite" scenario as detalied in the MQIPT manual. As you've probably already guessed - it's not working. My HTTP proxy requires basic authentication. Here is the result from the trace: Time: 09:49:48.711 2003.09.02 Class: com.ibm.mq.ipt.ConnectionThread Method: getHTTPHeader Thread ID: ConnThd for Route 62000-0 Logger: TraceLogger 62000 HTTP/1.1 407 Proxy authentication required Proxy-Authenticate: NTLM Proxy-Authenticate: Basic realm="172.30.60.2" Content-Length: 503 Content-Type: text/html Time: 09:49:48.711 2003.09.02 Class: com.ibm.mq.ipt.ConnectionThread Method: createHTTPConnection Thread ID: ConnThd for Route 62000-0 Logger: TraceLogger 62000 MQCPE058 CONNECT request to myhost.mydomain.com(80) through ewprxy2(8080) failed Anyone know if it is possible to pass a userid/password to the HTTP proxy? By the way, the actual setup is: MQ Client -> Local MQIPT -> HTTP Proxy -> (firewall) -> Apache HTTP Server -> MQIPT -> Target QMgr Cheers, Paul Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive * This e-mail 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: Outsourcing - my observations after my trip to India
Title: Message Well said indeed. -Original Message-From: Darren Douch [mailto:[EMAIL PROTECTED]Sent: Tuesday, September 02, 2003 5:18 PMTo: [EMAIL PROTECTED]Subject: Re: Outsourcing - my observations after my trip to India I'm not a historian but this has been happening since the industrial revolution and probably throughout all human history - industries decline and (hopefully) other things arise to replace them. Britain's textile industry declined as cheap labour in the far east took over, our coal industry declined because it was cheaper to mine it elsewhere, our manufacturing base has been in decline for 20 years, etc, etc. Maybe IT will be the next industry to decline in the West in the face of cheap labour in the East, maybe it wont. That depends upon how much protectionism the West puts in place and whether or not we are satisified with the quality of the work the East does - we're happy with the quality of the Nike trainers they make in Malaysia, so why not the quality of the code they write in Bangdledesh? Yes it's tough on those that lose their jobs, but I thought the US was a lover of free trade and the global economy. Actually that's a lie, I didn't think the US was a lover of free trade - they just like it when it suits them.
HPUX install: "./lap/jre/bin/java: not found"
I'm tring to install MQ on HPUX11i. I got the following error: # cd /local/MQ # . ./mqlicense.sh -accept ksh: ./lap/jre/bin/java: not found ERROR: Installation will not succeed unless the license agreement can be accepted.> Any Ideas? 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
unsubscribe
unsubscribe * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Riyad Bank. Finally, the recipient should check this email and any attachments for the presence of any viruses. Riyad Bank accepts no liability for any damage caused by any virus / error transmitted by this email. *
Re: MVS msg exit (MQPUT) processing causes increase in MSTR region size.
> be careful with the suggestion from Ruzi. > > The message exit runs inside the unit of work for > the MCA. If you commit, > then you are committing the channel's work as well. Not true. The application's commit is separate from Channel's commit. Channel's commit depends on BATCHSZ/BATCHINT attributes. Ruzi --- Neil Casey <[EMAIL PROTECTED]> wrote: > Hi Dax (are you a DS9 fan?) > > be careful with the suggestion from Ruzi. > > The message exit runs inside the unit of work for > the MCA. If you commit, > then you are committing the channel's work as well. > > You shouldn't have to worry about not committing in > your exit as the MCA > will issue a commit for every batch. > > I have no idea why your real storage usage is rising > only when your exit is > run, but to test it out, try running your programs > without any exits, and > at the same time run a local program which inserts > the same message load as > the exit would do. Look at the memory usage after > this test and compare > with running your exit to determine if your exit is > behaving badly. I would > also suggest checking the virtual usage as well as > real. If the virtual > usage is unchanged, then what you are seeing is not > a leek, but a change in > the working set in an unconstrained system. This > would represent normal > behaviour. Your system is clearly unconstrained > because your paging rate is > 0. > > Regards, > > Neil Casey. > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | n.AC.AT> | > | || > | || > | | 03/09/2003 02:29 | > | | Please respond to| > | | MQSeries List| > | || > |-+> > > >--| > | > >| > | To: [EMAIL PROTECTED] > >| > | cc: > >| > | Subject: Re: MVS msg exit (MQPUT) > processing causes increase in MSTR > region | > |size. > >| > > >--| > > > > > The first thing that came to my mind (without > reading > all the deatils carefully-- not that I could > understand the code all that much) is that, it might > be caused by a delayed "commit"??? From your code, I > think you are using the default MQPMO. On the > mainframe the Syncpoint is the default ( > Syncpoint=yes). Looks like you are not commiting > each > message after each PUT (or after so many messages). > When you diconnect without the explicit commit, an > implicit commit occurs committing all the 1000 > messages. In the meantime, the 1000 messages > (depending on on their size probably) may be causing > the space to expand. Since you are experimenting, I > suggest you try using a commit after every (or say > 10 > messages) and see whether you get the some problem. > > I don"t know if the above is causing your problem, > but > I thought I would share my opinion with you anyway. > > Best regards, > > Ruzi > > --- d a <[EMAIL PROTECTED]> wrote: > > To the MVS people on the list > > > > I have been playing around with the following > > message exit code it all > > works fine BUT, I have just noticed that the MSTR > > address spaces for the 2 > > queue mgrs I am testing on expands considerably > not > > a good thing > > > > Here is the setup, I have 2 queue mgrs QMG1 and > > QMG2, and a set of SDR/RCVR > > channels between them, all with the exit defined > as > > a message exit on them. > > I then send through 1000 messages in both > directions > > to drive the exit > > defined on the RCVR and SDR channels. > > > > The result Note the Real storage frames: > > > > Before processing: > > - > > JOBNAME ,StepName,ProcStep,JobID ,Owner > > ,C,Pos,DP,Real,Paging, SIO > > QMG1MSTR QMG1MSTR PROCSTEP STC05201 QMG1MSTR NS > > FE 8084 0.00 0.00 > > QMG1CHIN QMG1CHIN PROCSTEP STC05203 QMG1CHIN IN > > FB 2897 0.00 0.00 > > > > JOBNAME ,StepName,ProcStep,JobID ,Owner > > ,C,Pos,DP,Real,Paging, SIO > > QMG2MSTR QMG2MSTR PROCSTEP STC05202 QMG2MSTR NS > > FE 8056 0.00 0.00 > > QMG2CHIN QMG2CHIN PROCSTEP STC05204 QMG2CHIN IN > > FB 2970 0.00 0.00 > > > > > > After processing: > > - > > JOBNAME ,StepName,ProcStep,JobID ,Owner > > ,C,Pos,DP,Real,Paging, SIO > > QMG1MSTR QMG1MSTR PROCSTEP STC05201 QMG1MSTR NS > > FE 10T 0.00 0.00 > > QMG1CHIN QMG1CHIN PROCSTEP STC05203 QMG1CHIN IN > > FB 3307 0.00 0.00 > > > > JOBNA
MQSeries on iSeries
Hello everybody! I am looking for description of cold restart procedure of MQSeries on iSeries. I have searched many pages of ibm documentation. Now I know how to start and stop it on iSeries, but I still don't really know what "cold restart" really mean in this particular case. If you have any suggestions or experience in using MQSeries on iSeries please help. If you colud point me to interesting resources I would be very gratefull. Thank you in advance. Best Regards, Marcin Wilk 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: Configuring Multiple Channel Exits
Actually that memory could be freed by the CHAD exit, but only on MQ 5.2
and above!
When the channel shuts down, the CHAD is driven with reason MQXR_TERM (on
MQ 5.2 and above), so you could store this stuff in gotten storage hung of
(e.g.) MQCXP.ExitUserData (allocated at MQXR_INIT time).
However on MQ 5.1 and below the CHAD is driven with neither MQXR_INIT nor
with MQXR_TERM, so if you are running on 5.1 or below, you need come up
with some sort of scheme which either avoids using gotten storage, or only
allocates it once and thus avoid a continual memory leak ("core
cancer").
Dave
-Original Message-From: MQSeries List
[mailto:[EMAIL PROTECTED]On Behalf Of shailesh
kumarSent: 03 September 2003 08:45To:
[EMAIL PROTECTED]Subject: Re: Configuring Multiple Channel
Exits
Thanks David.
That was a very useful piece of
information.
Another question at this point.
If I need to set 2 MsgExits on my Auto-Defined
CLUSSDR channel, then I should set this in MsgExitPtr and set the
MsgExitsDefined to 2. If, on the CLUSRCVR channel no MsgExits were set, then the
MsgExitPtr will initially point to NULL.
Does this mean that my Auto-Definition Exit
should allocate the required memory to hold the Exit List ( from your previous
information this will be "2*ExitNameLength"
bytes. This memory cannot be freed by my exit. Who will
free it then?
Also, if the CLURCVR has 1 MsgExit configured, then
when I override this with my 2 MsgExits, again I have to allocate memory to hold
my 2 exit names and point MsgExitPtr to this allocted memory.
Is my above understanding of the problem correct on
the first hand? Is the approach of allocating the memory in my exit and pointing
the ExitPtr to this memory the correct way of solving this?
Thanks in advance.
Shailesh Kumar
- Original Message -
From:
David C. Partridge
To: [EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 2:08
PM
Subject: Re: Configuring Multiple Channel
Exits
1) Each field is the length of ExitNameLength, which isn't necessarily
the same as MQ_EXIT_NAME_LENGTH. The total length (pointed to e.g.
by MsgExitPtr) will be ExitNameLength times
ExitNameLength.
2) IIRC, If the QM supports chained exits, then it will always use
MsgExitsDefined, and MsgExitPtr rather than MsgExit.
Be warned, on 390, the MQCD version may be incorrectly set in a
clustered environment (too high a level) and so an 0C4 may not be far away if
you totally trust it. There was an APAR raised for this in MQ 2.1
(can't remember if it was PQ39541, or PQ41371), and it may have also applied
to 5.2.
Dave
Re: Message Backup / Export
The supportpac is MA01. Try at http://www-3.ibm.com/software/integration/support/supportpacs/product.html for the list and http://www-3.ibm.com/software/integration/support/supportpacs/individual/ma0 1.html for the actual MA01 supportpac. Regards John Scott. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 02 September 2003 17:03 To: [EMAIL PROTECTED] Subject: Re: Message Backup / Export Hi Michael, I quite often use the free "q program" (I don"t remember the supportpac number) for copying a queue to a file. Ruzi --- Business Integration <[EMAIL PROTECTED] > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Michael > Sent: 29 August 2003 15:18 > To: [EMAIL PROTECTED] > Subject: Message Backup / Export > > > I have a lot of messages sitting on a queue and > before I process them my > boss wants me to take a sample of them and back them > up. There are about > 50,000 messages and he is looking for a sample of > about 100-200 or so. Is > there an app out there that will allow me to do this > easily? > > Thank you. > > Michael > > 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 ** 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: Configuring Multiple Channel Exits
Thanks David. That was a very useful piece of information. Another question at this point. If I need to set 2 MsgExits on my Auto-Defined CLUSSDR channel, then I should set this in MsgExitPtr and set the MsgExitsDefined to 2. If, on the CLUSRCVR channel no MsgExits were set, then the MsgExitPtr will initially point to NULL. Does this mean that my Auto-Definition Exit should allocate the required memory to hold the Exit List ( from your previous information this will be "2*ExitNameLength" bytes. This memory cannot be freed by my exit. Who will free it then? Also, if the CLURCVR has 1 MsgExit configured, then when I override this with my 2 MsgExits, again I have to allocate memory to hold my 2 exit names and point MsgExitPtr to this allocted memory. Is my above understanding of the problem correct on the first hand? Is the approach of allocating the memory in my exit and pointing the ExitPtr to this memory the correct way of solving this? Thanks in advance. Shailesh Kumar - Original Message - From: David C. Partridge To: [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 2:08 PM Subject: Re: Configuring Multiple Channel Exits 1) Each field is the length of ExitNameLength, which isn't necessarily the same as MQ_EXIT_NAME_LENGTH. The total length (pointed to e.g. by MsgExitPtr) will be ExitNameLength times ExitNameLength. 2) IIRC, If the QM supports chained exits, then it will always use MsgExitsDefined, and MsgExitPtr rather than MsgExit. Be warned, on 390, the MQCD version may be incorrectly set in a clustered environment (too high a level) and so an 0C4 may not be far away if you totally trust it. There was an APAR raised for this in MQ 2.1 (can't remember if it was PQ39541, or PQ41371), and it may have also applied to 5.2. Dave
