Re: Xa Resource manager not available
If maxcur is not specified, what is the default? The manual is not very explicit. -Original Message- From: Jim Nuckolls [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 06:04 To: [EMAIL PROTECTED] Subject: Re: Xa Resource manager not available Hm, that's not according to design as far as I remember. It was 2 years ago (Oracle 8 and MQ 5.2) when I was dealing with that particular configuration. Neither side is supposed to depend on the other partner(s) being available 100%. Sounds like time for a PMR. I would turn on the trace facility for the XA flows in the XA string in qm.ini as part of my data gathering prior to opening the incident. Here is the string in the qm.ini file I used to collect as much detail as possible. The DbgFl=0x15 is the setting that says to collect as much data as possible. xaoopen: xa_info=Oracle_XA+Acc=P/app_prod01/longliveoracle+SesTm=0+DB=PRCSMDB1+LogDir =/tmp+MaxCur=100+SQLNet=PRCSMDB1+DbgFl=0x15,rmid=1,flags=0x0 Hopefully this will get you a little further into the problem determination process. Cheers... Jim Nuckolls [EMAIL PROTECTED] Kearns, Emile E wrote: > Hi all, > > Is there another to start the XA connect between the Queue Manager and an > Oracle Database other than to restart the Queue Manager. > > Often the DBA's stops and starts a database without the MQ admin staff > knowing, this then breaks the XA connection. > After the database has been restarted, the XA connection is not there. > How can this be started with restarting the QMGR? > > > For information about he Standard Bank group visit our web site > www.standardbank.co.za > > Disclaimer and confidentiality note > > Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. > It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are > those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please > notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. > Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. > I > > 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 For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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: Microsoft Java Runtime vs Sun Java Runtime Environment (JRE) 1 .4.1
Thanks for your help! Bob Kasischke <[EMAIL PROTECTED]> wrote: I must be missing something because I sure don't see anywhere on this web page where they talk about a _Microsoft_ SDK for Java I think there are IBM Java SDKs and Sun Java SDKs. To answer the original question: I don't think MQ V5.2 will work (very well) with the _Microsoft_ Java Runtime. The version of this Java was only 1.1.4 or so. As noted on the web page IBM is looking for version 1.3 or later. Also note that the JRE is bundled as part of the SDK so you can install either Robert S. Kasischke 415-243-6975 -Original Message-From: O'Keeffe, Michael [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 18, 2003 3:32 PMTo: [EMAIL PROTECTED]Subject: Re: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1 .4.1 Check this link out. The IBM (of course) 1.3.0 SDK is the supported platform for NT, but it seems you're able to run with the Microsoft SDK http://www-3.ibm.com/software/integration/support/supportpacs/individual/ma88.html - Original Message - From: Cherie Tan To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:03 AM Subject: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1.4.1 Hi All, I had one question. I am currently running Microsoft Java Runtime on my Win NT4.0 server. I had MQSeries Client v5.2 installed in that server. Is there any implications if i were to replace MS Java Runtime with JRE? I had tried to look thru the documentation provided by the IBM but was not able to find anything on this. Any help or comment is greatly appreciated! Many thanks in advance. Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month! Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Re: RFHUTIL(IH03)
The client version works. I was just interested to see if the server version can be configured to connect remotely. -Original Message- From: Christopher Frank [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 02:27 To: [EMAIL PROTECTED] Subject: Re: RFHUTIL(IH03) Emile, >>>Is it possible to set RFHUTIL, running on NT, up to look at >>>remote QMGR on Solaris , If so how? There is a client version called rfhutilc. Both are included in the SupportPac. 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 For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel Retry Counts/Intervals
Don't forget about Heartbeats. If a RCVR does not get a HB back from the other side in the required time, it assumes an outage and goes into Inactive. When the network comes back up, the SNDR finally gets a successful retry, and finds the RCVR inactive, ready to do business. If the SNDR successfully retries a connection after an outage but before the heartbeat, then the RCVR is still running, and then AdoptMCA steps up to the plate to save the day like Steve explained below. Properly set up, it is very rare that you have to manually interfere to get channels running again after an outage. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:08 PM To: [EMAIL PROTECTED] Subject: Re: Channel Retry Counts/Intervals Beware this is a long response but it is technical in nature, which is a welcome relief for those of you who got tired of the "Spiraling downhill" thread. When I referred to the fact that your sender channel LONGRETRY and LONGTMR attributes can be set to ZERO, this would only make sense if your DISCINT interval expires BEFORE your SHORTRTY * SHORTMR interval. Well this ONLY works if there are no messages left on your XMITQ. DUH! In short this was an IDIOTIC statement to make, let alone broadcast to all of you. I thank you all for allowing me to say this versus one of our more assertive personalities on the Listserver. Do I hear chuckles in the background? From this point forward, I will proof read my statements BEFORE hitting the SEND key. To save what dignity I have left, what I was ATTEMPTING to do is explain how channels can be made more reliable by using the DISCINT, ADOPTNEWMCA, and ADOPTNEWMCATIMEOUT attributes in combination with the SHORT* and LONG* attribute values. Allow me to re-explain. The DISCINT interval only works for SENDER type channels. Let's assume this attribute is set to 10 minutes. If no messages go to the XMIT queue for that channel within that time period, the SENDER channel will quiesce, as will the RECEIVER channel (assuming there is connectivity between the two). If the connectivity is broken, then the ADOPNEWMCA and ADOPTNEWMCATIMEOUT attributes take over, since they work on RECEIVER-type channels. With that said... When a network outage occurs, there is no guarantee that both ends of the channel will detect the failure at the same time. Often the sending channel detects the failure first since it is trying to send the message. If the sending channel goes into an inactive state during a network outage (disconnect interval expired), when new messages arrive and the network is back online, the sender channel will try to reconnect to the target queue manager but since the previous receiver channel is still running with the same name, the new inbound connection request is rejected because the receiver is still stuck waiting on the previous socket signature (did not receive the disconnect request from the sender channel due to the network outage). Remember, a sender channel will only connect if it finds the receiver in an INACTIVE state. The ADOPTNEWMCA attribute allows you to control the shutdown of a receiver channel and the startup of a new one. By configuring ADOPTNEWMCA, if a new inbound connection request arrives and there is already a channel with that name running from the same network address and from the same queue manager, then the new channel tries to stop the previous one by requesting it to end. If the previous channel does not respond to this request by the time the ADOPTNEWMCATIMEOUT interval expires (lets assume it is set to 20 seconds), a second attempt is made. If the receiver channel has not ended after the ADOPTNEWMCATIMEOUT wait interval expired for a second time, I believe MQSeries ends the channel with a CHANNEL IN USE error. With all this said, I find this a cleaner, more robust solution to handle system or network interruptions, though maybe some of the issues we have, are cleaned up in V5.3 (we are at an earlier release of V5.2 - cost reasons). This configuration was principally done to resolve issues with remote connections found throughout the United States. Without using the ADOPTNEWMCA* attributes, if the sender channels time-out while there was a network outage or a system crashed, the receiver channels would stay up. Once the incident was resolved (network or system outage), we had to bounce numerous receiver channels to get them to reconnect. Using the ADOPTNEWMCA parameters in conjunction with the DISCINT attribute, channels reconnect on their own free will - no matter what the previous outage was or its time duration. Oh, and DON'T set the LONG* channel attributes to ZERO. Keep the LONGRETRY attribute at its default value (999,999,999) and change the LONGTMR attribute to fit whatever timeout values fits your situation. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Glen Larson Sent: Tuesday, June 17, 2003 9:15 AM To: [EMA
Re: Default port 1414 changed.
I believe Shelden is right EXCEPT one step was missed. In order for the
inetd daemon to recognize a change in its configuration file, you either
need to BOUNCE (stop/start) inetd or issue the refresh command (in AIX it is
'refresh -s inetd', not sure under HP-UX) to reread the /etc/inetd.conf
file.
Steve
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Brian T.
Shelden
Sent: Wednesday, June 18, 2003 4:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Default port 1414 changed.
Hi Sasha,
> I wonder if someone seen this and if it is bug or "feature" .
> Any fixes available.
>
> We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2
> queue managers on it, A and B. A were listeneing (inetd) on
> 1414 and B on 1415. Then we changed ports so A listening on
> 1415 and B on 1414. After the change is done, all SENDER
> channels on qmgr A that have no port specified, trying to
> access remote qmgrs on port 1415. I fthe specify explicitly
> port 1414 in connection for sender channel it works.
>
> Does the default port for SENDER channels meant to be the same
> as port on which QMGR listening ???
I've seen that. I think "feature," but I understand why
you find it confusing.
I think your subject line is very telling. I bet you have a
service called MQSeries in /etc/services, and you just moved
its port to 1415, right?
Here's what I think is going on under the covers. Like a good
TCP/IP app, MQ is doing getservbyname("MQSeries"). If there
is no service called MQSeries, either in NIS nor files (or
whatever), it defaults to the hard-coded default of 1414.
Butyou do indeed have a service called MQSeries. But
you've moved it to 1415. So the default is now 1415.
Change your service names to MQSeriesA for queue manager A
and MQSeriesB for queue manager B in both /etc/inetd.conf and
/etc/services, and you'll get the behaviour you expect.
--Brian T. Shelden [EMAIL PROTECTED]
Shelden & Associates, Inc. New York, NY 10280
Certified MQSeries Specialists (212) 786-0175
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 was content-scanned by GatewayDefender
6/18/2003 - 5:28:28 PM - BA03ec1e7c.0001.mml
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel Retry Counts/Intervals
Beware this is a long response but it is technical in nature, which is a welcome relief for those of you who got tired of the "Spiraling downhill" thread. When I referred to the fact that your sender channel LONGRETRY and LONGTMR attributes can be set to ZERO, this would only make sense if your DISCINT interval expires BEFORE your SHORTRTY * SHORTMR interval. Well this ONLY works if there are no messages left on your XMITQ. DUH! In short this was an IDIOTIC statement to make, let alone broadcast to all of you. I thank you all for allowing me to say this versus one of our more assertive personalities on the Listserver. Do I hear chuckles in the background? From this point forward, I will proof read my statements BEFORE hitting the SEND key. To save what dignity I have left, what I was ATTEMPTING to do is explain how channels can be made more reliable by using the DISCINT, ADOPTNEWMCA, and ADOPTNEWMCATIMEOUT attributes in combination with the SHORT* and LONG* attribute values. Allow me to re-explain. The DISCINT interval only works for SENDER type channels. Let's assume this attribute is set to 10 minutes. If no messages go to the XMIT queue for that channel within that time period, the SENDER channel will quiesce, as will the RECEIVER channel (assuming there is connectivity between the two). If the connectivity is broken, then the ADOPNEWMCA and ADOPTNEWMCATIMEOUT attributes take over, since they work on RECEIVER-type channels. With that said... When a network outage occurs, there is no guarantee that both ends of the channel will detect the failure at the same time. Often the sending channel detects the failure first since it is trying to send the message. If the sending channel goes into an inactive state during a network outage (disconnect interval expired), when new messages arrive and the network is back online, the sender channel will try to reconnect to the target queue manager but since the previous receiver channel is still running with the same name, the new inbound connection request is rejected because the receiver is still stuck waiting on the previous socket signature (did not receive the disconnect request from the sender channel due to the network outage). Remember, a sender channel will only connect if it finds the receiver in an INACTIVE state. The ADOPTNEWMCA attribute allows you to control the shutdown of a receiver channel and the startup of a new one. By configuring ADOPTNEWMCA, if a new inbound connection request arrives and there is already a channel with that name running from the same network address and from the same queue manager, then the new channel tries to stop the previous one by requesting it to end. If the previous channel does not respond to this request by the time the ADOPTNEWMCATIMEOUT interval expires (lets assume it is set to 20 seconds), a second attempt is made. If the receiver channel has not ended after the ADOPTNEWMCATIMEOUT wait interval expired for a second time, I believe MQSeries ends the channel with a CHANNEL IN USE error. With all this said, I find this a cleaner, more robust solution to handle system or network interruptions, though maybe some of the issues we have, are cleaned up in V5.3 (we are at an earlier release of V5.2 - cost reasons). This configuration was principally done to resolve issues with remote connections found throughout the United States. Without using the ADOPTNEWMCA* attributes, if the sender channels time-out while there was a network outage or a system crashed, the receiver channels would stay up. Once the incident was resolved (network or system outage), we had to bounce numerous receiver channels to get them to reconnect. Using the ADOPTNEWMCA parameters in conjunction with the DISCINT attribute, channels reconnect on their own free will - no matter what the previous outage was or its time duration. Oh, and DON'T set the LONG* channel attributes to ZERO. Keep the LONGRETRY attribute at its default value (999,999,999) and change the LONGTMR attribute to fit whatever timeout values fits your situation. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Glen Larson Sent: Tuesday, June 17, 2003 9:15 AM To: [EMAIL PROTECTED] Subject: Re: Channel Retry Counts/Intervals Stephan, when the problem is network related yes, but what about the inevitable outages for hardware/software/power/cooling upgrades that may take 4-12 hours on a weekend. Now some but not all of the servers may be down at this time, either because the are not on the same platform, or maybe not even in the same datacenter. In that case is it not better to let MQ reconnect on its own, rather require an admin to fix something that really isn't a problem? Glen Larson Zurich North America "Stephan C. Moen" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 06/16/2003 11:25:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTE
Re: Very many MQClient queues...
Do the users signon with a unique id that is available to the application. If so use it or a portion of it when you generate your perm-dynamic or temp-dynamic reply to queues. Regards Tim A Ruzi R <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: Very many MQClient queues... List <[EMAIL PROTECTED] N.AC.AT> 17/06/2003 03:40 Please respond to MQSeries List That is not an option for us due to volume. As I said, ASSUME the worst case scenario where you have as many client queues as the number of clients. One reply queue for all is not an option due to the volume. However we could cut down on the num of queues, by say, using 1 queue per 20 clients. However, I really don't want to spend to much time on discussion on the number of queues as it is not an issue for me. As I said, let's assume we'll have 1000 local reply queues (one per client). Again the question I am asking is: Not the number of Reply queues or how we can cut down on that number, but RATHER "Where should we store the reply queue info?" In the "ini" file on each client machine? In LDAP? In DB? Or what? Is anyone using a huge number of client reply queues? If so, where do you store the reply q info? Thanks Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > Or just have one reply queue and get the reply > messages by CorrelID. > > -Original Message- > From: Rick Tsujimoto > [mailto:[EMAIL PROTECTED] > Sent: Monday, June 16, 2003 10:59 AM > To: [EMAIL PROTECTED] > Subject: Re: Very many MQClient queues... > > > You could change the apps to create dynamic > temporary queues and use them > as the reply queues. No LDAP or DB2 required. > > > > > Ruzi R > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > OM> cc: > Sent by: > Subject: Very many MQClient > queues... > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 06/16/2003 08:32 > AM > Please respond > to MQSeries List > > > > > > We ll have around Java apps running on about 1000 > MQClient (5.3 CSD03) on W2K connecting to MQ 5.3 > CSD03 > server on W2K. Request queue will be one but the > reply > queue will be as many as the number of clients or > fewer (it has not been decided yet). I know how to > determine the number of reply queues needed > (frequency, depending on message volume etc.); so > this > is not an issue. Let's take the worst case scenario > and just assume that there will be 1000 reply queues > (one for each client). > > The development people do not want to use use an > INI > file on each machine to get their client-queue > names, > claiming that there would be just too many INI files > around. I am thinking of using LDAP or DB2 for this > purpose. I would like to know how other people are > handling a similar situation. > > Any comments/suggestions would be appreciated. > > Thanks, > > Ruzi > > 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 > > > This communication, including attachments, is for > the exclusive use of > addressee and may contain proprietary, confidential > or privileged > information. If you are not the intended recipient, > any use, copying, > disclosure, dissemination or distribution is > strictly prohibited. If > you are not the intended recipient, please notify > the sender > immediately by return email and delete this > communication and destroy all copies. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Very many MQClient queues...
What is the expected volume? Regards Tim A Ruzi R <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: Very many MQClient queues... List <[EMAIL PROTECTED] N.AC.AT> 18/06/2003 03:55 Please respond to MQSeries List Hi Glen, Thanks for the response... I have suggested using one reply queue but because of the volume they don't want to go for it. I still think they could use one reply queue for all and each one get its reply based on correlid , but they are not willing to do so... Ruzi --- Glen Larson <[EMAIL PROTECTED]> wrote: > Ruzi, > > I seems to me the simplist solution is the best. > One reply queue, using > Correlid/msgid to identify the messages. > > The only reason that this would not work well is if > messages are queued up > for a along period of time, and so maintained a > large queue depth.If > this is a requirement, I would question the > application, on why they cannot > get the messages sooner, and thereby keeping the > queue close to empty. > > This keeps admin costs down, and you may find you > burn as many cycles > getting the init info as you do doing a qualified > get. > > Glen Larson > Zurich North America > > > Ruzi R <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on > 06/16/2003 01:02:27 PM > > Please respond to MQSeries List > <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > > Subject:Re: Very many MQClient queues... > > > Frederico, > > Thanks for the idea. Actually, we could load this > config queue with each clients config info. Each > client can then can MQGET its config info based on a > correlid (which is that uniqueu id you have > mentioned_, which would have to be stored somewhere > outside the app. This would require many (I can > determine the number later) unique ids to be stored > somewhere. Where would you suggest??? As I said, > development team does not want to use the ini file > currently, unless I can convince them to do so. > > Thanks for any suggestions... > > Ruzi > > > --- Federico Demi <[EMAIL PROTECTED]> wrote: > > ...or, if you really want to make things nicely > > complicated, you could have > > a well know queue on the server MYCFG.QUEUE where > > you store (in the form of > > persistent msgs) the correspondence between a > client > > (clients must have a > > unique id) and the reply queue it should use. > > > > The approach is not cheap because you then need an > > admin tool to maintain > > the entries in the cfg queue, but it may be ok if > > you use it to store also > > other client related cfg items... > > > > Ciao, > > F. > > > > __ > > Federico Demi > > Primeur > > Via Malagoli, 12 -- 56124 Pisa, Italy > > Phone: +39 050 31331 > > Fax: +39 050 3133232 > > Mobile: +39 348 8960 563 > > http://www.primeur.com > > mailto:[EMAIL PROTECTED] > > > > > > > > - Original Message - > > From: "Potkay, Peter M (PLC, IT)" > > <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, June 16, 2003 6:16 PM > > Subject: Re: Very many MQClient queues... > > > > > > > Or just have one reply queue and get the reply > > messages by CorrelID. > > > > > > -Original Message- > > > From: Rick Tsujimoto > > [mailto:[EMAIL PROTECTED] > > > Sent: Monday, June 16, 2003 10:59 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Very many MQClient queues... > > > > > > > > > You could change the apps to create dynamic > > temporary queues and use them > > > as the reply queues. No LDAP or DB2 required. > > > > > > > > > > > > > > > Ruzi R > > > <[EMAIL PROTECTED] > To: > > > [EMAIL PROTECTED] > > > OM> > cc: > > > Sent by: > > Subject: Very many MQClient > > > queues... > > > MQSeries List > > > <[EMAIL PROTECTED] > > > en.AC.AT> > > > > > > > > > 06/16/2003 08:32 > > > AM > > > Please respond > > > to MQSeries List > > > > > > > > > > > > > > > > > > We ll have around Java apps running on about > 1000 > > > MQClient (5.3 CSD03) on W2K connecting to MQ 5.3 > > CSD03 > > > server on W2K. Request queue will be one but the > > reply > > > queue will be as many as the number of clients > or > > > fewer (it has not been decided yet). I know how > to > > > determine the number of reply queues needed > > > (frequency, depending on message volume etc.); > so > > this > > > is not an issue. Let's take the worst case > > scenario > > > and just assume that there will be 1000 reply > > queues > > > (one for each client). > > > > > > The deve
Re: Stopping NT Local/System account access for the client
If the clients are connecting remotely and remotely only, in order to secure queue manager you need to use both SSL to establish identity and MCAUSER as a handle to configure access control. Here is an example. Say you have 2 channels. SYSTEM.ADMIN.SVRCONN PAYROLL.SVRCONN All of those channels are a vulnerable including whatever other svrconns you might have. Step 1. Enable SSL authentication on all channels, meaning only entities who have matching DN string or have crtificates that were signed by the CA that the queue manager trusts, etc. or both. Step 2. - Practicing defense in depth :) Hardcode appropriate MCA user id for each channel with the user id that you will use in setmqaut commands to grant necessary access control. So for SYSTEM.ADMIN.SVRCONN you could actually put in mqm for MCAUSER in case you need to manage the queue manager from somewhere where you are not mqm. Its ok since you are the only who would have the certificate that would be necessary to make the connection. PAYROLL.SVRCONN Create a certificate with dn=,ou=payroll and make sure that your queue manager only accepts the certficates by the ca that it trusts or the ones queue manager signed itself or with certificates that are simply in the keystore. Now, no one but your payroll will be able to connect to that and no other channel. This is called establishing authenticity of the client. From here on, you do not want payrol to have full access to all the objects so you hardcode mcauser with user id payrol and using setmqaut commands configure access to only payrol queues and that's it. This is called access control. Repeat this all "incoming channels" since this could be easily applied to recevier channels as well. If someone thinks this is will not work, let me know. mikhail. - Original Message - From: "Crowder, Randall" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 18, 2003 4:37 PM Subject: Re: Stopping NT Local/System account access for the client Thanks Wyatt, This is great info... I don't think the MCAUSER parm is really what I need. It appears that it just gives the connecting client the rights of the user specified in MCAUSER (as checked by OAM)... What keeps an ill intentioned person from connecting to another server conn channel? Sounds like the exit that restricts by incoming IP is more like what I need... I don't really want to use SSL because of the overhead. Thanks again... Randy -Original Message- From: Wyatt, T. Rob To: [EMAIL PROTECTED] Sent: 6/18/03 3:02 PM Subject: Re: Stopping NT Local/System account access for the client Randy, Client connections are very unsecure by default but you can tighten them up quite a bit. Whatever ID runs the listener is potentially used by the OAM to check authorities. If you use a channel exit or specify an MCAUSER, you can force the ID to be a low-privileged user - but only for that specific channel. Remember, just because you protect SOME.APP.SVRCONN with an exit or MCAUSER, doesn't mean an intruder won't try to come in through SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN channels, they can easily put up a SDR to connect to one of your RCVR/RQSTR channels. It's kind of a pain to manipulate the listener process ID and use MCAUSERs because you need some kind of administrative access to the box so the usual solution is to use an exit of some sort. This is true across all the distributed platforms, BTW, not just Wintel. Jørgen Pederson wrote a small exit program that filters connection requests by IP. I think he's trying to get it released as a Support Pac but in the meantime he's made it available at: http://home19.inet.tele.dk/m-invent/ Click on "Tips And Tricks" then look for the link to "BlockIP Security Exit". He provides source as well as Windows DLL. It's very effective as is or you can use it as an starting point and add your own features in. -- T.Rob -Original Message- From: Crowder, Randall [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: Stopping NT Local/System account access for the client All, Probably not news to anyone else, but I have discovered what I believe is a major security hole with the Client... For NT/2000 it appears that as long as a service is running under the local/system account, if it can client connect to an NT/2000 queue manager with full rights. I have a test "service" that I install and run under my local system account. It uses the client to connect to a queue manager and then puts a test message on the SYSTEM.DEFAULT.LOCAL.QUEUE. Regardless of how a queue manager is secured with setmqaut, as long as the service runs under local/system, it can connect to the queue manager and put messages. Beyond using SSL, is there any way around this behavior? Thanks, Randy Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration Instructions for managing your mailing list
Re: Stopping NT Local/System account access for the client
If the application will be connecting in server/bind mode therefore
bypassing server connection channels the only way to secure the queue
manager is to forbid applications from running under system but rather
have it run under a specific UID for which the proper access control can
be established.
- Original Message -
From: "Pavel Tolkachev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 18, 2003 5:13 PM
Subject: Re: Stopping NT Local/System account access for the client
Hello Randy,
If you leave MCAUSER blank (' '), the channel agent will actually run on
behalf of the user as reported by the client. The details of user names
used are in the book (mostly "Clients" and "Intercommunication" as far
as I can remember) but they depend on both client platform and server
platform. For NT to NT, I beleive, the "strongest" security check is
performed which involves domain controller and similar stuff (like user
provides its SID or something similar -- but do not hold me to it
please)).
Yes, it is mostly "authentification by assertion" especially if you
beleive the attacker can forge the MQ protocol completely. But still
slightly better than nothing.
SSL looks the way to go. I got it working, with streaming type of
ciphers like RC4 x 128 x SHA it must be reasonably fast and reliable.
3DES would slow down things, but even using it I do not beleive SSL
would become a bottleneck, especially considering MQ performance. Much
faster MOMs like those from Tibco or Vitria are using SSL and that makes
me think the slowdown will be relatively insignificant with MQ. What
will suffer is an initial connection time because the keystore
decryption algorithms are traditionally made slow -- and for good
reasons. It takes especially a while to complete any single operation
with .kdb database with IBM's gsk; JDK's keytool is much faster working
with .jks databases but still takes time. (your SSL participants may
need to use both: queue manager will use kdb and client can use .kdb (C
clients, not tried) or .jks (Java clients, tried)).
Hope this will help,
Pavel
"Crowder, Randall"
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
ALCITY.COM>cc:
Sent by: MQSeries List Subject: Re:
Stopping NT Local/System account access for the client
<[EMAIL PROTECTED]
T>
06/18/2003 04:37 PM
Please respond to
MQSeries List
Thanks Wyatt,
This is great info... I don't think the MCAUSER parm is really what I
need.
It appears that it just gives the connecting client the rights of the
user
specified in MCAUSER (as checked by OAM)... What keeps an ill
intentioned
person from connecting to another server conn channel?
Sounds like the exit that restricts by incoming IP is more like what I
need... I don't really want to use SSL because of the overhead.
Thanks again...
Randy
-Original Message-
From: Wyatt, T. Rob
To: [EMAIL PROTECTED]
Sent: 6/18/03 3:02 PM
Subject: Re: Stopping NT Local/System account access for the client
Randy,
Client connections are very unsecure by default but you can tighten them
up
quite a bit. Whatever ID runs the listener is potentially used by the
OAM
to check authorities. If you use a channel exit or specify an MCAUSER,
you
can force the ID to be a low-privileged user - but only for that
specific
channel. Remember, just because you protect SOME.APP.SVRCONN with an
exit
or MCAUSER, doesn't mean an intruder won't try to come in through
SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN
channels,
they can easily put up a SDR to connect to one of your RCVR/RQSTR
channels.
It's kind of a pain to manipulate the listener process ID and use
MCAUSERs
because you need some kind of administrative access to the box so the
usual
solution is to use an exit of some sort. This is true across all the
distributed platforms, BTW, not just Wintel.
Jørgen Pederson wrote a small exit program that filters connection
requests
by IP. I think he's trying to get it released as a Support Pac but in
the
meantime he's made it available at:
http://home19.inet.tele.dk/m-invent/ Click on "Tips And Tricks" then
look
for the link to "BlockIP Security Exit". He provides source as well as
Windows DLL. It's very effective as is or you can use it as an starting
point and add your own features in.
-- T.Rob
-Original Message-
From: Crowder, Randall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 10:00 AM
To: [EMAIL PROTECTED]
Subject: Stopping NT Local/System account access for the client
All,
Probably not news to anyone else, but I have discovered what I believe
is a
major security hole with the Client... For NT/2000 it appears that as
long
as a service is running under the local/system account, if it can client
connect to an NT/2000 queue manager wi
Re: Microsoft Java Runtime vs Sun Java Runtime Environment (JRE) 1 .4.1
I must be missing something because I sure don't see anywhere on this web page where they talk about a _Microsoft_ SDK for Java I think there are IBM Java SDKs and Sun Java SDKs. To answer the original question: I don't think MQ V5.2 will work (very well) with the _Microsoft_ Java Runtime. The version of this Java was only 1.1.4 or so. As noted on the web page IBM is looking for version 1.3 or later. Also note that the JRE is bundled as part of the SDK so you can install either Robert S. Kasischke 415-243-6975 -Original Message-From: O'Keeffe, Michael [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 18, 2003 3:32 PMTo: [EMAIL PROTECTED]Subject: Re: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1 .4.1 Check this link out. The IBM (of course) 1.3.0 SDK is the supported platform for NT, but it seems you're able to run with the Microsoft SDK http://www-3.ibm.com/software/integration/support/supportpacs/individual/ma88.html - Original Message - From: Cherie Tan To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:03 AM Subject: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1.4.1 Hi All, I had one question. I am currently running Microsoft Java Runtime on my Win NT4.0 server. I had MQSeries Client v5.2 installed in that server. Is there any implications if i were to replace MS Java Runtime with JRE? I had tried to look thru the documentation provided by the IBM but was not able to find anything on this. Any help or comment is greatly appreciated! Many thanks in advance. Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month!
Re: Stopping NT Local/System account access for the client
Pavel,
Just to clarify, it is not necessary to forge the MQ protocol to assert a
user ID in a client. In fact, it is a trivial task to set this field using
a Java client. If the ID is suppressed, the connection will acquire
whatever ID the listener runs as.
-- T.Rob
-Original Message-
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 5:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Stopping NT Local/System account access for the client
Hello Randy,
If you leave MCAUSER blank (' '), the channel agent will actually run on
behalf of the user as reported by the client. The details of user names used
are in the book (mostly "Clients" and "Intercommunication" as far as I can
remember) but they depend on both client platform and server platform. For
NT to NT, I beleive, the "strongest" security check is performed which
involves domain controller and similar stuff (like user provides its SID or
something similar -- but do not hold me to it please)).
Yes, it is mostly "authentification by assertion" especially if you beleive
the attacker can forge the MQ protocol completely. But still slightly better
than nothing.
SSL looks the way to go. I got it working, with streaming type of ciphers
like RC4 x 128 x SHA it must be reasonably fast and reliable. 3DES would
slow down things, but even using it I do not beleive SSL would become a
bottleneck, especially considering MQ performance. Much faster MOMs like
those from Tibco or Vitria are using SSL and that makes me think the
slowdown will be relatively insignificant with MQ. What will suffer is an
initial connection time because the keystore decryption algorithms are
traditionally made slow -- and for good reasons. It takes especially a while
to complete any single operation with .kdb database with IBM's gsk; JDK's
keytool is much faster working with .jks databases but still takes time.
(your SSL participants may need to use both: queue manager will use kdb and
client can use .kdb (C clients, not tried) or .jks (Java clients, tried)).
Hope this will help,
Pavel
"Crowder, Randall"
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
ALCITY.COM>cc:
Sent by: MQSeries List Subject: Re: Stopping
NT Local/System account access for the client
<[EMAIL PROTECTED]
T>
06/18/2003 04:37 PM
Please respond to
MQSeries List
Thanks Wyatt,
This is great info... I don't think the MCAUSER parm is really what I need.
It appears that it just gives the connecting client the rights of the user
specified in MCAUSER (as checked by OAM)... What keeps an ill intentioned
person from connecting to another server conn channel?
Sounds like the exit that restricts by incoming IP is more like what I
need... I don't really want to use SSL because of the overhead.
Thanks again...
Randy
-Original Message-
From: Wyatt, T. Rob
To: [EMAIL PROTECTED]
Sent: 6/18/03 3:02 PM
Subject: Re: Stopping NT Local/System account access for the client
Randy,
Client connections are very unsecure by default but you can tighten them
up
quite a bit. Whatever ID runs the listener is potentially used by the
OAM
to check authorities. If you use a channel exit or specify an MCAUSER,
you
can force the ID to be a low-privileged user - but only for that
specific
channel. Remember, just because you protect SOME.APP.SVRCONN with an
exit
or MCAUSER, doesn't mean an intruder won't try to come in through
SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN
channels,
they can easily put up a SDR to connect to one of your RCVR/RQSTR
channels.
It's kind of a pain to manipulate the listener process ID and use
MCAUSERs
because you need some kind of administrative access to the box so the
usual
solution is to use an exit of some sort. This is true across all the
distributed platforms, BTW, not just Wintel.
Jørgen Pederson wrote a small exit program that filters connection
requests
by IP. I think he's trying to get it released as a Support Pac but in
the
meantime he's made it available at:
http://home19.inet.tele.dk/m-invent/ Click on "Tips And Tricks" then
look
for the link to "BlockIP Security Exit". He provides source as well as
Windows DLL. It's very effective as is or you can use it as an starting
point and add your own features in.
-- T.Rob
-Original Message-
From: Crowder, Randall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 10:00 AM
To: [EMAIL PROTECTED]
Subject: Stopping NT Local/System account access for the client
All,
Probably not news to anyone else, but I have discovered what I believe
is a
major security hole with the Client... For NT/2000 it appears that as
long
as a service is running under the local/system account, if it can client
connect to an NT/2000 queu
Re: Service provider in Java
thanks Brian I do not want to define any remote queues in the MQ manager (for the service provider) MQ itself will resolve the situation and place the message on the transmission queue. Then I can easily attach new front end applications and only bother about channel and Xmit queue on the MQ manager for the service provider. When we execute the Java application without any Remote queue definitions, we end up in in the error situatiuon 'queue missed' ! We have seen this before when using MQ adapters, (JMS based) from external vendors, towards standard ERP systems... Please provide me with the URL:s and I will update myself on alternatives to the trigger monitor! denis From: "McCarty, Brian" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Service provider in Java Date: Wed, 18 Jun 2003 11:04:59 -0500 I may not understand all your requirements, but there shouldn't be anything stopping you from coding the reply-to-q in the message just because you're using a java app. Maybe you could describe what you're seeing the problem to be some more. Also, if you have the capacity to run this as a JMS app, you could use the MessageListener or a Message Driven Bean to "listen" to the queue rather than doing triggering or a get with wait type app. Basically with a MDB, the container manages connections to the queue and then when a message arrives, it hands it off to a real worker instance. It's very nice because connection pooling and threading problems are virtually eliminated. The drawback is that with a MDB you will need a J2EE application server that supports the EJB 2.0 specification (MQ 5.3 won't have a problem supporting it.), I'm plugging WAS 5.0 here. However, you can still use a MessageListener without using an MDB, you just have to do the connection pooling, etc. stuff yourself. If you think this is something you want to do I can point you to all of the URL's you would need to get started. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: mq wiberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:52 AM To: [EMAIL PROTECTED] Subject: Service provider in Java We are running a B2B application (for 3 years) where the portal is in common for all Europe. We are integrating with different SOP-systems on different platforms. All these 'service providers' in the SOP-systems have been set up without any remote queue definitions for the reply back. The service has been easy to use by other 'front-ends' relying on the reply-to-queue/mgr information in the message itelf. For the first time the service provider is written in Java and executed on w2000. The intention was to have the very same setup as before. but 1. We can't execute without a remote queue definition! Does Java demand for a remote queue? or are we just bad in using the Java Classes. 2. Are there any trigger monitor, dedicated for Java, that do not start the JVM every time the trigger is turned on? TIA Denis Wiberg _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 _ 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: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1 .4.1
Check this link out. The IBM (of course) 1.3.0 SDK is the supported platform for NT, but it seems you're able to run with the Microsoft SDK http://www-3.ibm.com/software/integration/support/supportpacs/individual/ma88.html - Original Message - From: Cherie Tan To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:03 AM Subject: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1.4.1 Hi All, I had one question. I am currently running Microsoft Java Runtime on my Win NT4.0 server. I had MQSeries Client v5.2 installed in that server. Is there any implications if i were to replace MS Java Runtime with JRE? I had tried to look thru the documentation provided by the IBM but was not able to find anything on this. Any help or comment is greatly appreciated! Many thanks in advance. Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month!
Re: Performance monitoring/matricies
yes there is Bobbee, and please forgive my shameless plug -- it's called QN-StatWatch -- check out http://www.reconda.com , or contact me directly... hopefully before you run out and get that tin cup... Robert Broderick wrote: We have a large system wich spans WIN200K, Solaris, Tandem, OS390 (MVS & TPF), MQ & MQSI using both Client and server connections at different points. We are in the middle of stress testing and are experiencing delays. Much to our complaints, there are no MQ tools in the Shop. The shop is enterprise sized, so is the application. Is there a product that will do performance monitoring of messaging going through the system. I know of some administration tools that lend themselves to this BUT...is there a product that can be configured to wathc points of entry and exit and corellate the data based on MSGID and CORELID and report back performance. bobbee _ The new MSN 8: advanced junk mail 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: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1.4.1
Which versions? - Original Message - From: Cherie Tan To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:03 AM Subject: Microsoft Java Runtime vs Sun Java Runtim Environment (JRE) 1.4.1 Hi All, I had one question. I am currently running Microsoft Java Runtime on my Win NT4.0 server. I had MQSeries Client v5.2 installed in that server. Is there any implications if i were to replace MS Java Runtime with JRE? I had tried to look thru the documentation provided by the IBM but was not able to find anything on this. Any help or comment is greatly appreciated! Many thanks in advance. Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month!
Re: MQSICREATEBROKER - SEGMENTATION FAULT
I don't know if your still having trouble with this one, but the trace I was talking about earlier is to set an environment variable: MQSI_UTILTIY_TRACE=debug and the MQSI_UTILITY_TRACESIZE=10 or some number significantly big. Then run mqsicreatebroker. http://publibfp.boulder.ibm.com/epubs/pdf/bipyaq00.pdf Try Marty's suggestion first and if that doesn't work, try the trace to see where it dumps. It's probably because of the Merant driver issue or char con problem. Let us know how it works out. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Marty G. Trice [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:00 PM To: [EMAIL PROTECTED] Subject: Re: MQSICREATEBROKER - SEGMENTATION FAULT Give this a try my friend 1. Shut down all database instances as the instance owner ID: db2stop force. 2. Shut down the administration server instance as the admin instance ID: db2admin stop force. 3. Back up the original db2.o under /usr/lpp/db2__/lib 4. Issue "slibclean" as root. 5. Copy db2_36.0 to db2.o, ensuring that ownership and permissions are consistent: cp db2_36.o db2.o -r--r--r-- bin:bin for db2.o To switch back to the original object, simply follow the same procedure using the backed up db2.o file. Marty G. Trice WebSphere MQ/MQI Administrator Sara Lee Business Services - EAI Group [EMAIL PROTECTED] 336.519.2939 "McCarty, Brian" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] AA.COM> cc: Sent by: MQSeriesSubject: Re: MQSICREATEBROKER - SEGMENTATION FAULT List <[EMAIL PROTECTED] n.AC.AT> 06/18/2003 12:23 PM Please respond to MQSeries List Look for a core file or look in WMQI admin doc for how to set an early trace for commands (not the broker user trace stuff). That trace should tell you the last thing that happened before the dump. Usually it's a database access problem. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 10:07 AM To: [EMAIL PROTECTED] Subject: MQSICREATEBROKER - SEGMENTATION FAULT Dear all, Has anyone encountered a segmentation fault error while creating the broker? What causes this? Here is my error: mqsicreatebroker DGBCGB01 -i mquid -a mquid01 -q DGBCGB01 -n WMQIBRDB -u mquid -p mquid01 AMQ8110: WebSphere MQ queue manager already exists. WebSphere MQ queue manager running. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. Segmentation fault my platform - AIX 5L MQ 53 CSD 04 MQSI v21 CSD 03 DB2 8.1 Do reply please !! Regards 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: Default port 1414 changed.
Hi Sasha,
I wonder if someone seen this and if it is bug or "feature" .
Any fixes available.
We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2
queue managers on it, A and B. A were listeneing (inetd) on
1414 and B on 1415. Then we changed ports so A listening on
1415 and B on 1414. After the change is done, all SENDER
channels on qmgr A that have no port specified, trying to
access remote qmgrs on port 1415. I fthe specify explicitly
port 1414 in connection for sender channel it works.
Does the default port for SENDER channels meant to be the same
as port on which QMGR listening ???
I've seen that. I think "feature," but I understand why
you find it confusing.
I think your subject line is very telling. I bet you have a
service called MQSeries in /etc/services, and you just moved
its port to 1415, right?
Here's what I think is going on under the covers. Like a good
TCP/IP app, MQ is doing getservbyname("MQSeries"). If there
is no service called MQSeries, either in NIS nor files (or
whatever), it defaults to the hard-coded default of 1414.
Butyou do indeed have a service called MQSeries. But
you've moved it to 1415. So the default is now 1415.
Change your service names to MQSeriesA for queue manager A
and MQSeriesB for queue manager B in both /etc/inetd.conf and
/etc/services, and you'll get the behaviour you expect.
--Brian T. Shelden [EMAIL PROTECTED]
Shelden & Associates, Inc. New York, NY 10280
Certified MQSeries Specialists (212) 786-0175
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: Stopping NT Local/System account access for the client
Hello Randy,
If you leave MCAUSER blank (' '), the channel agent will actually run on behalf of the
user as reported by the client. The details of user names used are in the book (mostly
"Clients" and "Intercommunication" as far as I can remember) but they depend on both
client platform and server platform. For NT to NT, I beleive, the "strongest" security
check is performed which involves domain controller and similar stuff (like user
provides its SID or something similar -- but do not hold me to it please)).
Yes, it is mostly "authentification by assertion" especially if you beleive the
attacker can forge the MQ protocol completely. But still slightly better than nothing.
SSL looks the way to go. I got it working, with streaming type of ciphers like RC4 x
128 x SHA it must be reasonably fast and reliable. 3DES would slow down things, but
even using it I do not beleive SSL would become a bottleneck, especially considering
MQ performance. Much faster MOMs like those from Tibco or Vitria are using SSL and
that makes me think the slowdown will be relatively insignificant with MQ. What will
suffer is an initial connection time because the keystore decryption algorithms are
traditionally made slow -- and for good reasons. It takes especially a while to
complete any single operation with .kdb database with IBM's gsk; JDK's keytool is much
faster working with .jks databases but still takes time. (your SSL participants may
need to use both: queue manager will use kdb and client can use .kdb (C clients, not
tried) or .jks (Java clients, tried)).
Hope this will help,
Pavel
"Crowder, Randall"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
ALCITY.COM>cc:
Sent by: MQSeries List Subject: Re: Stopping NT
Local/System account access for the client
<[EMAIL PROTECTED]
T>
06/18/2003 04:37 PM
Please respond to
MQSeries List
Thanks Wyatt,
This is great info... I don't think the MCAUSER parm is really what I need.
It appears that it just gives the connecting client the rights of the user
specified in MCAUSER (as checked by OAM)... What keeps an ill intentioned
person from connecting to another server conn channel?
Sounds like the exit that restricts by incoming IP is more like what I
need... I don't really want to use SSL because of the overhead.
Thanks again...
Randy
-Original Message-
From: Wyatt, T. Rob
To: [EMAIL PROTECTED]
Sent: 6/18/03 3:02 PM
Subject: Re: Stopping NT Local/System account access for the client
Randy,
Client connections are very unsecure by default but you can tighten them
up
quite a bit. Whatever ID runs the listener is potentially used by the
OAM
to check authorities. If you use a channel exit or specify an MCAUSER,
you
can force the ID to be a low-privileged user - but only for that
specific
channel. Remember, just because you protect SOME.APP.SVRCONN with an
exit
or MCAUSER, doesn't mean an intruder won't try to come in through
SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN
channels,
they can easily put up a SDR to connect to one of your RCVR/RQSTR
channels.
It's kind of a pain to manipulate the listener process ID and use
MCAUSERs
because you need some kind of administrative access to the box so the
usual
solution is to use an ex
Vladimir Veytsel is out of the Office.
I will be out of the office from 06/18/2003 until 06/19/2003. I will respond to your message when I return. My emergency out-of-office contacts: Phone: 201-251-3892 Pager: 917-218-8938 Regards, Vlad. 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: Unsubscribe
signoff Richard Santilli Randy J Clark <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .HONDA.COM> cc: Sent by: Subject: Re: Unsubscribe MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/18/2003 02:51 PM Please respond to MQSeries 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 Richard Santilli <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ESSIVE.COM>cc: Sent by: MQSeries List Subject: Unsubscribe <[EMAIL PROTECTED] T> 06/18/2003 11:03 AM Please respond to MQSeries List Richard Santilli === This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please contact the sender by email/fax and destroy all paper and electronic copies of the original message. 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
DB2 Timed Trigger
Have a database with state data coming out of the Broker. Want to clean up the database every 15 Min. Otherwise because of the vol. we will start getting performance degrations. This is OS390 Is there a way of kicking off a stored procedure (with a trigger) every 15 min. I have seen there are triggers for the DB operations (events) but none for time. TRICK I could use CA7 but don't want to schedule jobs if I don't have to. bobbee _ The new MSN 8: advanced junk mail 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
CHADEXIT on mainframe queue managers
I've got a CHADEXIT on the mainframe which inserts a MSGEXIT on my cluster-sender channels when they start up. With the move to MQ 5.3.1 on the mainframe, the exit has to change to use the MsgExitPtr field instead of the MsgExit field. Has anyone done this already and could give me some pointers (no pun intended) I'd like to avoid allocating new storage to hold the name of my exit if I can. I am trying to point the MsgExitPtr at the original MsgExit field in the MQCD, but the exit (although it complies cleanly) causes an error whenever a channel tries to start. Is there a way to get this to work or do I have to bite the bullet and allocate storage in my exit to store the 8 byte exit name? If anyone has a sample CHAD exit which sets these values using the pointers and could share it, I'd appreciate it. Thanks, John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 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: Stopping NT Local/System account access for the client
Thanks Wyatt, This is great info... I don't think the MCAUSER parm is really what I need. It appears that it just gives the connecting client the rights of the user specified in MCAUSER (as checked by OAM)... What keeps an ill intentioned person from connecting to another server conn channel? Sounds like the exit that restricts by incoming IP is more like what I need... I don't really want to use SSL because of the overhead. Thanks again... Randy -Original Message- From: Wyatt, T. Rob To: [EMAIL PROTECTED] Sent: 6/18/03 3:02 PM Subject: Re: Stopping NT Local/System account access for the client Randy, Client connections are very unsecure by default but you can tighten them up quite a bit. Whatever ID runs the listener is potentially used by the OAM to check authorities. If you use a channel exit or specify an MCAUSER, you can force the ID to be a low-privileged user - but only for that specific channel. Remember, just because you protect SOME.APP.SVRCONN with an exit or MCAUSER, doesn't mean an intruder won't try to come in through SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN channels, they can easily put up a SDR to connect to one of your RCVR/RQSTR channels. It's kind of a pain to manipulate the listener process ID and use MCAUSERs because you need some kind of administrative access to the box so the usual solution is to use an exit of some sort. This is true across all the distributed platforms, BTW, not just Wintel. Jørgen Pederson wrote a small exit program that filters connection requests by IP. I think he's trying to get it released as a Support Pac but in the meantime he's made it available at: http://home19.inet.tele.dk/m-invent/ Click on "Tips And Tricks" then look for the link to "BlockIP Security Exit". He provides source as well as Windows DLL. It's very effective as is or you can use it as an starting point and add your own features in. -- T.Rob -Original Message- From: Crowder, Randall [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: Stopping NT Local/System account access for the client All, Probably not news to anyone else, but I have discovered what I believe is a major security hole with the Client... For NT/2000 it appears that as long as a service is running under the local/system account, if it can client connect to an NT/2000 queue manager with full rights. I have a test "service" that I install and run under my local system account. It uses the client to connect to a queue manager and then puts a test message on the SYSTEM.DEFAULT.LOCAL.QUEUE. Regardless of how a queue manager is secured with setmqaut, as long as the service runs under local/system, it can connect to the queue manager and put messages. Beyond using SSL, is there any way around this behavior? Thanks, Randy Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration 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: MQSeries and .Net
Title: MQSeries and .Net Randy, Thanks for the help. I'll give this a try. Andrew -Original Message-From: Crowder, Randall [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 18, 2003 12:19 PMTo: [EMAIL PROTECTED]Subject: Re: MQSeries and .Net Andrew, Use MQGMO_SYNCPOINT for the get and MQPMO_SYNCPOINT for the put. Then do a commit. They will both be included in the same unit of work. Thanks, Randy "The man who has nothing for which he is willing to fight and nothing he cares about more than his personal safety is a miserable creature who has no chance of being free unless made and kept so by the exertions of better men than himself" - John S. Mill Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration Phone: 216.257.5306 Cell: 216.287.5386 -Original Message-From: Andrew Don [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 18, 2003 10:59 AMTo: [EMAIL PROTECTED]Subject: MQSeries and .Net Hello, I was wondering if anyone has had any experience making MQ queues transactional using .Net and MQSeries. I have MQSeries Version 5.2 (Server edition) running on a Windows 2000 server, while using the MQAX200 ActiveX. We're trying to access another MQ server to retrieve and put messages. I have an application written in C# that can successfully get and put messages to the MQ server, but I'm not sure how to make the process of getting/putting a MQ message transactional. I am new to the MQ world and I'm having trouble finding any good examples. If anyone can point me to some sample code or provide any tips, it would be greatly appreciated. Thanks. Andrew 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: Performance monitoring/matricies
Thak you Peter for taking the time on this. I have forwarded this to the person trying to make a decision. I was wondering how you found out about the buffer sizs. Thought you were buying drinks for the Hursley guys or rumaging through their garbage bins in the back of their office complex. tnx, bobbee From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies Date: Wed, 18 Jun 2003 14:28:53 -0400 That one sentence applies to a specific feature of TV that I found most useful. (TV does do other things) It allows you see every single option on every single MQ call. You know when a MQCONN call took place for instance, to the microsecond if on MF or Solaris, millisecond otherwise. You know that it took an MQOPEN call .247 seconds to complete. You know what the application specified for every field in the MQMD going into the PUT or GET, and you see every field in the MQMD returned by the QM. You know all the GMO and PMO options set by the application. And you can browse every message after the fact. Based on what you chose to collect, you can run queries that are very informative, like: Show me all the MQCONN calls for the last week Show me all the MQ calls for Application XYZ for Tuesday between 3 and 6. Show me any messages that went thru the system that had ABC in bytes 783,784 and 785 of the message buffer. Or show me any messages that had "bobbee" anywhere in the buffer. Show me any MQSET calls. Show me any calls that ended with a RC of 2033, or any other RC. When the results come up, you get tons of other info on each call. Who made it, what TCODE was it running under, was it succesful, etc. Since MQSI and MCAs are apps, this allowed me to learn all sorts of neat stuff about these apps and what they do under the covers. Fiddle with your channel settings or MQInput Node and watch how the MQ calls change. TV is how we learned that MQSI is changing the buffer size on its MQGET calls, which sometimes causes it to do a double get to take care of the truncated error. (I just ran a query where the app was MQSI, where the call was MQGET and where the RC was 2080). Most importantly, I don't have to rely on the app area to tell me what they think they are doing with MQ. I know for a fact. They call me and tell me MQ is losing messages. I tell them to try coding something other than 0 for Expiry!!! (This actually happened once. Try solving that problem when they insist "nothing has changed" in the app) -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:09 PM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies Peter, You use the words 'Application" and "Monitoring" in the same sentence. What does this imply. Can you give an example(s) of some of the features. "Readers Digest" version. bobbee Basically we have multi platform Messaging hops with an additional stop in a broker (OS390). It is not coming up to the TPS requirements desired by the client. There is nothing here in the way of a global MQ monitoring / administration / management tool(S). They are doing performance testing and have a microscope view of all the pieces. They need help!! I am trying to suggest a best fit solution. But they need it up fast and quick. >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies >Date: Wed, 18 Jun 2003 09:40:33 -0400 > >Yes, Transaction Vision (TV) is not cheap, but the amount of info it gives >you about your MQ applications is awesome. > >I use QPASA every day. There is only a slight overlap with what it does and >TV does. They are 2 different and complimentary products. > >Reconda StatWatch is closer in function to TV than QPASA. > >-Original Message- >From: Scott Gray [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 7:09 PM >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies > > >We looked at it last year and it was a solid product, but imho unbelievably >expensive. MQSoftware now offers a business dashboard capability in their >QPasa V3 product that has similar capabilites...We own QPasa now and it's >been a struggle since day one, but YMMV. >Scott > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of >McCarty, Brian >Sent: Tuesday, June 17, 2003 10:06 AM >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies > > >Yes, Bristol's transaction vision looks like a real good tool for >end-to-end >message/transaction monitoring: > >http://www.bristol.com/transactionvision/index.html > >but this does require that a binary intercept the MQ calls made by the >application before hitting the queue manager. They say that it is >lightweight, but you probably want to do your own performance/release >te
Re: Spiraling downhill - helpful tools and tips
(Please note: I don't work for TechRepublic, so I removed the actual URLs this time. Personally, I found a few useful tips, other I found humorous and somewhat appropriate to the thread. You decide. -EARmerc) NO-CHARGE TECHREPUBLIC DOWNLOADS--YOUR KEY TO CAREER SUCCESS! TechRepublic's Downloads area is THE place to find the tools, tips, and tricks you need to do your job better, no matter your IT role. And, the best thing is...they're ALL FREE! It's a great benefit of your TechRepublic membership. Check out these downloads below, and enjoy...courtesy of TechRepublic! USE THIS CHECKLIST WHEN PLANNING AN OFFICE RELOCATION PROJECT (e.g. to Calcutta) (URL furnished on request) >From lost cables to poor space planning, office moves are about as complicated an IT project as a consultant can take on. Learn from the TechRepublic members who've gone before you by downloading a member-inspired checklist to ensure smooth relocations. EMPLOYEE EQUIPMENT CHANGE REQUEST FORM (to add the Asian Support Hotline) (URL furnished on request) Get ahead of the game when handling employee equipment changes by implementing a process that facilitates early notification. The first step of notification is downloading our equipment change request form. EMPLOYEE TERMINATION CHECKLIST (for outsourced employees) (URL furnished on request) When terminating an employee, make sure you've properly handled all technology items, such as network access. Download this termination checklist template to ensure that the appropriate manager has dealt with all necessary general and IT issues. 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: Stopping NT Local/System account access for the client
Hello Randall, First of all, check that MCAUSER field is set to ' ' (space), not mqm in SVRCONN channel definition. After that, if both server and client are running on nt platform, there must be a way to make queue manager to authenticate using [EMAIL PROTECTED] credentials (if MQ does not do it by default which I think it does) which is not very easy to forge without hacking the client code (theoretically MQ could also do some nt trickery to check the user is actually logged in on the domain at source ip address). Still, it is a pretty weak authentication, so SSL is probably the way to go. Just a 2 c Pavel "Crowder, Randall" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ALCITY.COM>cc: Sent by: MQSeries List Subject: Re: Stopping NT Local/System account access for the client <[EMAIL PROTECTED] T> 06/18/2003 02:44 PM Please respond to MQSeries List Anyone have any ideas on this one... Thanks in advance for your help. rjc "The man who has nothing for which he is willing to fight and nothing he cares about more than his personal safety is a miserable creature who has no chance of being free unless made and kept so by the exertions of better men than himself" - John S. Mill Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration -Original Message- From: Crowder, Randall Sent: Tuesday, June 17, 2003 10:00 AM To: 'MQSeries List' Subject: Stopping NT Local/System account access for the client All, Probably not news to anyone else, but I have discovered what I believe is a major security hole with the Client... For NT/2000 it appears that as long as a service is running under the local/system account, if it can client connect to an NT/2000 queue manager with full rights. I have a test "service" that I install and run under my local system account. It uses the client to connect to a queue manager and then puts a test message on the SYSTEM.DEFAULT.LOCAL.QUEUE. Regardless of how a queue manager is secured with setmqaut, as long as the service runs under local/system, it can connect to the queue manager and put messages. Beyond using SSL, is there any way around this behavior? Thanks, Randy Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Stopping NT Local/System account access for the client
Randy, Client connections are very unsecure by default but you can tighten them up quite a bit. Whatever ID runs the listener is potentially used by the OAM to check authorities. If you use a channel exit or specify an MCAUSER, you can force the ID to be a low-privileged user - but only for that specific channel. Remember, just because you protect SOME.APP.SVRCONN with an exit or MCAUSER, doesn't mean an intruder won't try to come in through SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN channels, they can easily put up a SDR to connect to one of your RCVR/RQSTR channels. It's kind of a pain to manipulate the listener process ID and use MCAUSERs because you need some kind of administrative access to the box so the usual solution is to use an exit of some sort. This is true across all the distributed platforms, BTW, not just Wintel. Jørgen Pederson wrote a small exit program that filters connection requests by IP. I think he's trying to get it released as a Support Pac but in the meantime he's made it available at: http://home19.inet.tele.dk/m-invent/ Click on "Tips And Tricks" then look for the link to "BlockIP Security Exit". He provides source as well as Windows DLL. It's very effective as is or you can use it as an starting point and add your own features in. -- T.Rob -Original Message- From: Crowder, Randall [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: Stopping NT Local/System account access for the client All, Probably not news to anyone else, but I have discovered what I believe is a major security hole with the Client... For NT/2000 it appears that as long as a service is running under the local/system account, if it can client connect to an NT/2000 queue manager with full rights. I have a test "service" that I install and run under my local system account. It uses the client to connect to a queue manager and then puts a test message on the SYSTEM.DEFAULT.LOCAL.QUEUE. Regardless of how a queue manager is secured with setmqaut, as long as the service runs under local/system, it can connect to the queue manager and put messages. Beyond using SSL, is there any way around this behavior? Thanks, Randy Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration 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: Spiraling downhill - delete key is 2 the right of the \ key
If none of us work in MQ because it pays squat for reasons discussed here, then there will be no more listserve, or only one where everyone is asking everyone questions, including "Where did the guys who knew all the answers go?", instead of answers to MQ questions. The biggest problem I have with all this is what one person brought up before, which I assume/fear is accurate. And that is there are no taxes collected for salaries sent overseas (Could that be true?!?!?). And no goods are purchased in US stores if the salaries are sent overseas. -Original Message- From: Fryett.Chris [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 2:23 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling (even further) downhill If you don't like hit the "Delete" key, otherwise take a back seat as Bobbee has suggested. If you have a question, issue, or problem you are free to send an email to the list server. If you would like to respond to an email on the list server go ahead, otherwise skip the messages that pertain to this subject. Thank you. -Original Message- From: Richard Santilli [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:40 AM To: [EMAIL PROTECTED] Subject: Re: Spiraling (even further) downhill I noticed that most or all of these emails do not pertain to MQ or MQSI. Can we please use this forum for work related issues pertaining to MQ and MQSI. Thank You. "Stephan C. Moen"To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: Re: Spiraling (even further) downhill Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/18/2003 09:04 AM Please respond to MQSeries List There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, "is the cup half-full or half-empty"? Your answer will most likely reflect the job status you currently find yourself in. We can COMPLAIN and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best "Find a niche in the market and plug it with your skills so you can earn the money you choose to make." That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broder
Re: Default port 1414 changed.
Aha! I bet it fell back to item #3 because Sasha mentioned inetd.conf. Probably he actually did not change inetd.conf (where you usually use the symbolic name of the service, like MQSeries), but instead changed the number in /etc/services? Great excerpt, Justin! I believe I saw the procedure before but never realized all the consequences. Pavel Justin Fries <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeriesSubject: Re: Default port 1414 changed. List <[EMAIL PROTECTED] n.AC.AT> 06/18/2003 12:23 PM Please respond to MQSeries List Hi, When choosing a port, MQ uses the following sequence: 1. Any port explicitly named: 127.0.0.1(1421) 2. The default port in the qm.ini file: TCP: Port=1416 3. The port associated with the 'MQSeries' service in the /etc/services file: MQSeriestcp/1419### Default MQ port 4. Port 1414. If 1414 isn't being picked up, odds are that another port number has been found at step 2 or step 3. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Default port 1414 changed. 06/18/2003 09:58 AM Please respond to MQSeries List I have seen this and was mystified by this too. I didn't track this down or verify it's existence (other things got in the way) BUT I thought somewhere this is a configurable parameter (default port) I was going to look in one of the two ini files to see if it was there (QM QMS). Not sure if this was even near the solution to the problem BUT I vaguely remember something on this subject. bobbee >From: Sasha Gerasimenko <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Default port 1414 changed. >Date: Wed, 18 Jun 2003 10:59:42 +0100 > >Hi there. > >I wonder if someone seen this and if it is bug or "feature" . Any fixes >available. > >We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers >on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. >Then we changed ports so A listening on 1415 and B on 1414. After the >change is done, all SENDER channels on qmgr A that have no port specified, >trying to access remote qmgrs on port 1415. I fthe specify explicitly port >1414 in connection for sender channel it works. > >Does the default port for SENDER channels meant to be the same as port on >which QMGR listening ??? > >Thanks. > > > Alexander Gerasimenko > (a.k.a. Sasha) > Information Services >International, (part of Mars Inc.) > Global AMI Team, ISW , *120, >x.6629 >
Re: Unsubscribe
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 Richard Santilli <[EMAIL PROTECTED]To: [EMAIL PROTECTED] ESSIVE.COM>cc: Sent by: MQSeries List Subject: Unsubscribe <[EMAIL PROTECTED] T> 06/18/2003 11:03 AM Please respond to MQSeries List Richard Santilli === This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please contact the sender by email/fax and destroy all paper and electronic copies of the original message. 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: Stopping NT Local/System account access for the client
Anyone have any ideas on this one... Thanks in advance for your help. rjc "The man who has nothing for which he is willing to fight and nothing he cares about more than his personal safety is a miserable creature who has no chance of being free unless made and kept so by the exertions of better men than himself" - John S. Mill Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration -Original Message- From: Crowder, Randall Sent: Tuesday, June 17, 2003 10:00 AM To: 'MQSeries List' Subject: Stopping NT Local/System account access for the client All, Probably not news to anyone else, but I have discovered what I believe is a major security hole with the Client... For NT/2000 it appears that as long as a service is running under the local/system account, if it can client connect to an NT/2000 queue manager with full rights. I have a test "service" that I install and run under my local system account. It uses the client to connect to a queue manager and then puts a test message on the SYSTEM.DEFAULT.LOCAL.QUEUE. Regardless of how a queue manager is secured with setmqaut, as long as the service runs under local/system, it can connect to the queue manager and put messages. Beyond using SSL, is there any way around this behavior? Thanks, Randy Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration 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
Richard Santilli === This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please contact the sender by email/fax and destroy all paper and electronic copies of the original message. 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: Performance monitoring/matricies
That one sentence applies to a specific feature of TV that I found most useful. (TV does do other things) It allows you see every single option on every single MQ call. You know when a MQCONN call took place for instance, to the microsecond if on MF or Solaris, millisecond otherwise. You know that it took an MQOPEN call .247 seconds to complete. You know what the application specified for every field in the MQMD going into the PUT or GET, and you see every field in the MQMD returned by the QM. You know all the GMO and PMO options set by the application. And you can browse every message after the fact. Based on what you chose to collect, you can run queries that are very informative, like: Show me all the MQCONN calls for the last week Show me all the MQ calls for Application XYZ for Tuesday between 3 and 6. Show me any messages that went thru the system that had ABC in bytes 783,784 and 785 of the message buffer. Or show me any messages that had "bobbee" anywhere in the buffer. Show me any MQSET calls. Show me any calls that ended with a RC of 2033, or any other RC. When the results come up, you get tons of other info on each call. Who made it, what TCODE was it running under, was it succesful, etc. Since MQSI and MCAs are apps, this allowed me to learn all sorts of neat stuff about these apps and what they do under the covers. Fiddle with your channel settings or MQInput Node and watch how the MQ calls change. TV is how we learned that MQSI is changing the buffer size on its MQGET calls, which sometimes causes it to do a double get to take care of the truncated error. (I just ran a query where the app was MQSI, where the call was MQGET and where the RC was 2080). Most importantly, I don't have to rely on the app area to tell me what they think they are doing with MQ. I know for a fact. They call me and tell me MQ is losing messages. I tell them to try coding something other than 0 for Expiry!!! (This actually happened once. Try solving that problem when they insist "nothing has changed" in the app) -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 1:09 PM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies Peter, You use the words 'Application" and "Monitoring" in the same sentence. What does this imply. Can you give an example(s) of some of the features. "Readers Digest" version. bobbee Basically we have multi platform Messaging hops with an additional stop in a broker (OS390). It is not coming up to the TPS requirements desired by the client. There is nothing here in the way of a global MQ monitoring / administration / management tool(S). They are doing performance testing and have a microscope view of all the pieces. They need help!! I am trying to suggest a best fit solution. But they need it up fast and quick. >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies >Date: Wed, 18 Jun 2003 09:40:33 -0400 > >Yes, Transaction Vision (TV) is not cheap, but the amount of info it gives >you about your MQ applications is awesome. > >I use QPASA every day. There is only a slight overlap with what it does and >TV does. They are 2 different and complimentary products. > >Reconda StatWatch is closer in function to TV than QPASA. > >-Original Message- >From: Scott Gray [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 7:09 PM >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies > > >We looked at it last year and it was a solid product, but imho unbelievably >expensive. MQSoftware now offers a business dashboard capability in their >QPasa V3 product that has similar capabilites...We own QPasa now and it's >been a struggle since day one, but YMMV. >Scott > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of >McCarty, Brian >Sent: Tuesday, June 17, 2003 10:06 AM >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies > > >Yes, Bristol's transaction vision looks like a real good tool for >end-to-end >message/transaction monitoring: > >http://www.bristol.com/transactionvision/index.html > >but this does require that a binary intercept the MQ calls made by the >application before hitting the queue manager. They say that it is >lightweight, but you probably want to do your own performance/release >testing also. > >Brian M. McCarty >USAA, Senior Systems Programmer >210.913.1678 >MQ/WMQI Specialist/Solutions Expert >e-business Solution Advisor/Designer/Technologist > > -Original Message- >From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 7:53 AM >To: [EMAIL PROTECTED] >Subject: Re: Performance monitoring/matricies > >TransactionVision or Reconda > > > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 8:16 AM >To: [EMAI
Re: Spiraling (even further) downhill
If you don't like hit the "Delete" key, otherwise take a back seat as Bobbee has suggested. If you have a question, issue, or problem you are free to send an email to the list server. If you would like to respond to an email on the list server go ahead, otherwise skip the messages that pertain to this subject. Thank you. -Original Message- From: Richard Santilli [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:40 AM To: [EMAIL PROTECTED] Subject: Re: Spiraling (even further) downhill I noticed that most or all of these emails do not pertain to MQ or MQSI. Can we please use this forum for work related issues pertaining to MQ and MQSI. Thank You. "Stephan C. Moen"To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: Re: Spiraling (even further) downhill Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/18/2003 09:04 AM Please respond to MQSeries List There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, "is the cup half-full or half-empty"? Your answer will most likely reflect the job status you currently find yourself in. We can COMPLAIN and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best "Find a niche in the market and plug it with your skills so you can earn the money you choose to make." That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee
Re: MQSICREATEBROKER - SEGMENTATION FAULT
Give this a try my friend 1. Shut down all database instances as the instance owner ID: db2stop force. 2. Shut down the administration server instance as the admin instance ID: db2admin stop force. 3. Back up the original db2.o under /usr/lpp/db2__/lib 4. Issue "slibclean" as root. 5. Copy db2_36.0 to db2.o, ensuring that ownership and permissions are consistent: cp db2_36.o db2.o -r--r--r-- bin:bin for db2.o To switch back to the original object, simply follow the same procedure using the backed up db2.o file. Marty G. Trice WebSphere MQ/MQI Administrator Sara Lee Business Services - EAI Group [EMAIL PROTECTED] 336.519.2939 "McCarty, Brian" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] AA.COM> cc: Sent by: MQSeriesSubject: Re: MQSICREATEBROKER - SEGMENTATION FAULT List <[EMAIL PROTECTED] n.AC.AT> 06/18/2003 12:23 PM Please respond to MQSeries List Look for a core file or look in WMQI admin doc for how to set an early trace for commands (not the broker user trace stuff). That trace should tell you the last thing that happened before the dump. Usually it's a database access problem. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 10:07 AM To: [EMAIL PROTECTED] Subject: MQSICREATEBROKER - SEGMENTATION FAULT Dear all, Has anyone encountered a segmentation fault error while creating the broker? What causes this? Here is my error: mqsicreatebroker DGBCGB01 -i mquid -a mquid01 -q DGBCGB01 -n WMQIBRDB -u mquid -p mquid01 AMQ8110: WebSphere MQ queue manager already exists. WebSphere MQ queue manager running. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. Segmentation fault my platform - AIX 5L MQ 53 CSD 04 MQSI v21 CSD 03 DB2 8.1 Do reply please !! Regards 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
unsubscribe
unsubscribe RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. 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 and .Net
Title: MQSeries and .Net Andrew, Use MQGMO_SYNCPOINT for the get and MQPMO_SYNCPOINT for the put. Then do a commit. They will both be included in the same unit of work. Thanks, Randy "The man who has nothing for which he is willing to fight and nothing he cares about more than his personal safety is a miserable creature who has no chance of being free unless made and kept so by the exertions of better men than himself" - John S. Mill Randy Crowder National City Corp Strategic Technology Services - Infrastructure Integration Phone: 216.257.5306 Cell: 216.287.5386 -Original Message-From: Andrew Don [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 18, 2003 10:59 AMTo: [EMAIL PROTECTED]Subject: MQSeries and .Net Hello, I was wondering if anyone has had any experience making MQ queues transactional using .Net and MQSeries. I have MQSeries Version 5.2 (Server edition) running on a Windows 2000 server, while using the MQAX200 ActiveX. We're trying to access another MQ server to retrieve and put messages. I have an application written in C# that can successfully get and put messages to the MQ server, but I'm not sure how to make the process of getting/putting a MQ message transactional. I am new to the MQ world and I'm having trouble finding any good examples. If anyone can point me to some sample code or provide any tips, it would be greatly appreciated. Thanks. Andrew 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: Performance monitoring/matricies
Peter, You use the words 'Application" and "Monitoring" in the same sentence. What does this imply. Can you give an example(s) of some of the features. "Readers Digest" version. bobbee Basically we have multi platform Messaging hops with an additional stop in a broker (OS390). It is not coming up to the TPS requirements desired by the client. There is nothing here in the way of a global MQ monitoring / administration / management tool(S). They are doing performance testing and have a microscope view of all the pieces. They need help!! I am trying to suggest a best fit solution. But they need it up fast and quick. From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies Date: Wed, 18 Jun 2003 09:40:33 -0400 Yes, Transaction Vision (TV) is not cheap, but the amount of info it gives you about your MQ applications is awesome. I use QPASA every day. There is only a slight overlap with what it does and TV does. They are 2 different and complimentary products. Reconda StatWatch is closer in function to TV than QPASA. -Original Message- From: Scott Gray [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 7:09 PM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies We looked at it last year and it was a solid product, but imho unbelievably expensive. MQSoftware now offers a business dashboard capability in their QPasa V3 product that has similar capabilites...We own QPasa now and it's been a struggle since day one, but YMMV. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of McCarty, Brian Sent: Tuesday, June 17, 2003 10:06 AM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies Yes, Bristol's transaction vision looks like a real good tool for end-to-end message/transaction monitoring: http://www.bristol.com/transactionvision/index.html but this does require that a binary intercept the MQ calls made by the application before hitting the queue manager. They say that it is lightweight, but you probably want to do your own performance/release testing also. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 7:53 AM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies TransactionVision or Reconda -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 8:16 AM To: [EMAIL PROTECTED] Subject: Performance monitoring/matricies We have a large system wich spans WIN200K, Solaris, Tandem, OS390 (MVS & TPF), MQ & MQSI using both Client and server connections at different points. We are in the middle of stress testing and are experiencing delays. Much to our complaints, there are no MQ tools in the Shop. The shop is enterprise sized, so is the application. Is there a product that will do performance monitoring of messaging going through the system. I know of some administration tools that lend themselves to this BUT...is there a product that can be configured to wathc points of entry and exit and corellate the data based on MSGID and CORELID and report back performance. bobbee _ The new MSN 8: advanced junk mail 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Spiraling (even further) downhill
I noticed that most or all of these emails do not pertain to MQ or MQSI. Can we please use this forum for work related issues pertaining to MQ and MQSI. Thank You. "Stephan C. Moen"To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: Re: Spiraling (even further) downhill Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/18/2003 09:04 AM Please respond to MQSeries List There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, "is the cup half-full or half-empty"? Your answer will most likely reflect the job status you currently find yourself in. We can COMPLAIN and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best "Find a niche in the market and plug it with your skills so you can earn the money you choose to make." That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid
Re: Default port 1414 changed.
The parameter is configurable on OS/390: " START LISTENER TRPTYPE( TCP ) PORT( 1414 ) " is specified in MQSAINPX input member for the CHANNEL INITIATOR address space. We also have our TCT/IP config designating that port for our MQSA queue manager. I suspect that an analogue exists for each platform. 1414 is the default specified port from the install. It should be matched in the TCP/IP profile specifications. That port number is not a requirement, so you can pick your own. I use 1414 and 1415 for two queue managers. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Three Mercedes Drive Montvale, NJ 07345 201-573-2619 201-573-4383 fax 866-308-3782 pager - Forwarded by Ernest Roberts/171/DCAG/DCX on 06/18/2003 12:19 PM - Robert Broderick <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 06/18/2003 09:58 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Default port 1414 changed. I have seen this and was mystified by this too. I didn't track this down or verify it's existence (other things got in the way) BUT I thought somewhere this is a configurable parameter (default port) I was going to look in one of the two ini files to see if it was there (QM QMS). Not sure if this was even near the solution to the problem BUT I vaguely remember something on this subject. bobbee >From: Sasha Gerasimenko <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Default port 1414 changed. >Date: Wed, 18 Jun 2003 10:59:42 +0100 > >Hi there. > >I wonder if someone seen this and if it is bug or "feature" . Any fixes >available. > >We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers >on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. >Then we changed ports so A listening on 1415 and B on 1414. After the >change is done, all SENDER channels on qmgr A that have no port specified, >trying to access remote qmgrs on port 1415. I fthe specify explicitly port >1414 in connection for sender channel it works. > >Does the default port for SENDER channels meant to be the same as port on >which QMGR listening ??? > >Thanks. > > > Alexander Gerasimenko > (a.k.a. Sasha) > Information Services >International, (part of Mars Inc.) > Global AMI Team, ISW , *120, >x.6629 > DDI: +44 (0) 118 9446629 > mobile: +44 (0) 7760201663 > mailto: >[EMAIL PROTECTED] > web: www.mars.com > > > _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Default port 1414 changed.
Hi, When choosing a port, MQ uses the following sequence: 1. Any port explicitly named: 127.0.0.1(1421) 2. The default port in the qm.ini file: TCP: Port=1416 3. The port associated with the 'MQSeries' service in the /etc/services file: MQSeries tcp/1419 ### Default MQ port 4. Port 1414. If 1414 isn't being picked up, odds are that another port number has been found at step 2 or step 3. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 06/18/2003 09:58 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Default port 1414 changed. I have seen this and was mystified by this too. I didn't track this down or verify it's existence (other things got in the way) BUT I thought somewhere this is a configurable parameter (default port) I was going to look in one of the two ini files to see if it was there (QM QMS). Not sure if this was even near the solution to the problem BUT I vaguely remember something on this subject. bobbee >From: Sasha Gerasimenko <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Default port 1414 changed. >Date: Wed, 18 Jun 2003 10:59:42 +0100 > >Hi there. > >I wonder if someone seen this and if it is bug or "feature" . Any fixes >available. > >We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers >on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. >Then we changed ports so A listening on 1415 and B on 1414. After the >change is done, all SENDER channels on qmgr A that have no port specified, >trying to access remote qmgrs on port 1415. I fthe specify explicitly port >1414 in connection for sender channel it works. > >Does the default port for SENDER channels meant to be the same as port on >which QMGR listening ??? > >Thanks. > > > Alexander Gerasimenko > (a.k.a. Sasha) > Information Services >International, (part of Mars Inc.) > Global AMI Team, ISW , *120, >x.6629 > DDI: +44 (0) 118 9446629 > mobile: +44 (0) 7760201663 > mailto: >[EMAIL PROTECTED] > web: www.mars.com > > > _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSICREATEBROKER - SEGMENTATION FAULT
Look for a core file or look in WMQI admin doc for how to set an early trace for commands (not the broker user trace stuff). That trace should tell you the last thing that happened before the dump. Usually it's a database access problem. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 10:07 AM To: [EMAIL PROTECTED] Subject: MQSICREATEBROKER - SEGMENTATION FAULT Dear all, Has anyone encountered a segmentation fault error while creating the broker? What causes this? Here is my error: mqsicreatebroker DGBCGB01 -i mquid -a mquid01 -q DGBCGB01 -n WMQIBRDB -u mquid -p mquid01 AMQ8110: WebSphere MQ queue manager already exists. WebSphere MQ queue manager running. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. Segmentation fault my platform - AIX 5L MQ 53 CSD 04 MQSI v21 CSD 03 DB2 8.1 Do reply please !! Regards 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: Service provider in Java
I may not understand all your requirements, but there shouldn't be anything stopping you from coding the reply-to-q in the message just because you're using a java app. Maybe you could describe what you're seeing the problem to be some more. Also, if you have the capacity to run this as a JMS app, you could use the MessageListener or a Message Driven Bean to "listen" to the queue rather than doing triggering or a get with wait type app. Basically with a MDB, the container manages connections to the queue and then when a message arrives, it hands it off to a real worker instance. It's very nice because connection pooling and threading problems are virtually eliminated. The drawback is that with a MDB you will need a J2EE application server that supports the EJB 2.0 specification (MQ 5.3 won't have a problem supporting it.), I'm plugging WAS 5.0 here. However, you can still use a MessageListener without using an MDB, you just have to do the connection pooling, etc. stuff yourself. If you think this is something you want to do I can point you to all of the URL's you would need to get started. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: mq wiberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:52 AM To: [EMAIL PROTECTED] Subject: Service provider in Java We are running a B2B application (for 3 years) where the portal is in common for all Europe. We are integrating with different SOP-systems on different platforms. All these 'service providers' in the SOP-systems have been set up without any remote queue definitions for the reply back. The service has been easy to use by other 'front-ends' relying on the reply-to-queue/mgr information in the message itelf. For the first time the service provider is written in Java and executed on w2000. The intention was to have the very same setup as before. but 1. We can't execute without a remote queue definition! Does Java demand for a remote queue? or are we just bad in using the Java Classes. 2. Are there any trigger monitor, dedicated for Java, that do not start the JVM every time the trigger is turned on? TIA Denis Wiberg _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Xa Resource manager not available
Hm, that's not according to design as far as I remember. It was 2 years ago (Oracle 8 and MQ 5.2) when I was dealing with that particular configuration. Neither side is supposed to depend on the other partner(s) being available 100%. Sounds like time for a PMR. I would turn on the trace facility for the XA flows in the XA string in qm.ini as part of my data gathering prior to opening the incident. Here is the string in the qm.ini file I used to collect as much detail as possible. The DbgFl=0x15 is the setting that says to collect as much data as possible. xaoopen: xa_info=Oracle_XA+Acc=P/app_prod01/longliveoracle+SesTm=0+DB=PRCSMDB1+LogDir=/tmp+MaxCur=100+SQLNet=PRCSMDB1+DbgFl=0x15,rmid=1,flags=0x0 Hopefully this will get you a little further into the problem determination process. Cheers... Jim Nuckolls [EMAIL PROTECTED] Kearns, Emile E wrote: Hi all, Is there another to start the XA connect between the Queue Manager and an Oracle Database other than to restart the Queue Manager. Often the DBA's stops and starts a database without the MQ admin staff knowing, this then breaks the XA connection. After the database has been restarted, the XA connection is not there. How can this be started with restarting the QMGR? For information about he Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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: Spiraling downhill
Besides, unions do not have the power they once did. Just look at a news broadcast and see how many TV cameras are unmanned. 20 years ago the unions would not have allowed that. "Robert Broderick" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: "MQSeriesSubject: Re: Spiraling downhill List" <[EMAIL PROTECTED] .AC.AT> 06/17/2003 03:30 PM Please respond to "MQSeries List" What you must realize is that most unions represent the Blue Collar workers of the US. Not your average VP or AVP with an educational and professional background. BUT if something isn't done both by the workers and the administration about this I'm afraid all our technical knowledge and IT resources will be come non-existent and we will be giving t much power to non-American interests. >From: Pavel Tolkachev <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill >Date: Tue, 17 Jun 2003 14:53:50 -0400 > >Hello Bobbee, > >Sorry for continuing on the off-topic.. > >There is something common and unfortunate in all unions I heard about from >my buddies and relatives who happened to join them: after a little while a >union is going to take advantage of its hard working members much more >efficiently than the employer. > >So, unless you are going to leave the technical side and join the dark one >(meaning -- union administration), a union may not be a beneficial idea for >you. For some intermediate form, though, take a look at >http://www.freelancersunion.org/. I am not saying they are not like all >others unions (and I am not a member myself, I am permanent as of now), but >at least they do not have (and supposedly won't have any soon) an exlusive >with any employer/trade of type "union job". > >Pavel > > > > > Robert Broderick > <[EMAIL PROTECTED]To: >[EMAIL PROTECTED] > OTMAIL.COM> cc: > Sent by: MQSeries Subject: Re: Spiraling >downhill > List > <[EMAIL PROTECTED] > .AC.AT> > > > 06/17/2003 11:26 > AM > Please respond to > MQSeries List > > > > > > >Yes I agree, > >And sure, There are alot of corners on Wall St. > > bee-oh-dubble-bee-dubble-egh > > > >From: "Fryett.Chris" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Spiraling downhill > >Date: Tue, 17 Jun 2003 09:18:08 -0400 > > > >Here! Here! > > > >It is more common today that contracting agencies are taking advantage of > >the large surplus of unemployed by paying really bad, but charging the > >clients a lot. I suspect that this contract agency if it is one is > >charging the client 50-75 percent over this amount. > > > >Let me know when you get that tin can and I'll join you ;-) > > > >Chris > > > > > >-Original Message- > >From: Robert Broderick [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, June 17, 2003 7:59 AM > >To: [EMAIL PROTECTED] > >Subject: Spiraling downhill > > > > > >This is not a technical issue so take a back seat if you want to complain > > > >WOW. Look at this. Notice the rate > > > >SKILLS REQUIRED: MQ Series, Unix, mainframe > >LOCATION: Hicksville, NY > >RATE: $25-30/hr > >AREA: 516 > >LENGTH: 12 months > >TERM: CON_IND CON_CORP > >SUMMARY: X Xx has an immediate opening for a Software Support > >Specialist. Candidate should be able work as a MQ Series administrator >and > >support various MQ series messaging infrastructure related projects. > >Candidate must be familiar with MQSeries V5.2 and... > > > >You know there is a vagrant who hangs out in fromnt of Grand Central > >Station. They did and article on him a few years back in the NY Times. He > >supposedly make about 100+ K a year pan handeling. I think after my >current > >contract ends I'm going to the hardware store to get a tin cup and >increase > >my revenue why decreasing my exposure to STRESS!! We need to start a > >UNION!!! > > > > > >bee-oh-dubble-bee-dubble-egh > > > >_ > >The new MSN 8: advanced junk mail 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 > > > > > >* > >The info
Re: Default port 1414 changed.
I had a similar problem while setting up queue managers on a Solaris box. I had setup listners on a particular port using inetd and then I had to change it. The reason was that some of the MQ IPC objects were hanging around and I had to clean them up. Stop your queue manager, clean all mq related shared memory and semaphores and then restart the queue managers again. Thanks Kamal >From: Sasha Gerasimenko <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Default port 1414 changed. >Date: Wed, 18 Jun 2003 10:59:42 +0100 > >Hi there. > >I wonder if someone seen this and if it is bug or "feature" . Any fixes >available. > >We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers >on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. >Then we changed ports so A listening on 1415 and B on 1414. After the >change is done, all SENDER channels on qmgr A that have no port specified, >trying to access remote qmgrs on port 1415. I fthe specify explicitly port >1414 in connection for sender channel it works. > >Does the default port for SENDER channels meant to be the same as port on >which QMGR listening ??? > >Thanks. > > > Alexander Gerasimenko > (a.k.a. Sasha) > Information Services >International, (part of Mars Inc.) > Global AMI Team, ISW , *120, >x.6629 > DDI: +44 (0) 118 9446629 > mobile: +44 (0) 7760201663 > mailto: >[EMAIL PROTECTED] > web: www.mars.com > > > _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Default port 1414 changed.
Are you using clustering? Are the sender channels in question by chance the static cluster sender or the dynamic cluster senders? I think we have fixed this before but let me know about your clustering usage so I can help more. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:59 AM To: [EMAIL PROTECTED] Subject: Re: Default port 1414 changed. I have seen this and was mystified by this too. I didn't track this down or verify it's existence (other things got in the way) BUT I thought somewhere this is a configurable parameter (default port) I was going to look in one of the two ini files to see if it was there (QM QMS). Not sure if this was even near the solution to the problem BUT I vaguely remember something on this subject. bobbee >From: Sasha Gerasimenko <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Default port 1414 changed. >Date: Wed, 18 Jun 2003 10:59:42 +0100 > >Hi there. > >I wonder if someone seen this and if it is bug or "feature" . Any fixes >available. > >We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers >on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. >Then we changed ports so A listening on 1415 and B on 1414. After the >change is done, all SENDER channels on qmgr A that have no port specified, >trying to access remote qmgrs on port 1415. I fthe specify explicitly port >1414 in connection for sender channel it works. > >Does the default port for SENDER channels meant to be the same as port on >which QMGR listening ??? > >Thanks. > > > Alexander Gerasimenko > (a.k.a. Sasha) > Information Services >International, (part of Mars Inc.) > Global AMI Team, ISW , *120, >x.6629 > DDI: +44 (0) 118 9446629 > mobile: +44 (0) 7760201663 > mailto: >[EMAIL PROTECTED] > web: www.mars.com > > > _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Default port 1414 changed.
DO NOT set the Port setting for the TCP parameters. If you do, any channels that you create will append whatever value you have set in the Port setting to the end of the channel. I bet your Port setting for TCP parameters on QMA is set to 1415. Any channel you create on QMA that does not have a specific port specified in the properties of that channel will use 1415. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 9:59 AM To: [EMAIL PROTECTED] Subject: Re: Default port 1414 changed. I have seen this and was mystified by this too. I didn't track this down or verify it's existence (other things got in the way) BUT I thought somewhere this is a configurable parameter (default port) I was going to look in one of the two ini files to see if it was there (QM QMS). Not sure if this was even near the solution to the problem BUT I vaguely remember something on this subject. bobbee >From: Sasha Gerasimenko <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Default port 1414 changed. >Date: Wed, 18 Jun 2003 10:59:42 +0100 > >Hi there. > >I wonder if someone seen this and if it is bug or "feature" . Any fixes >available. > >We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers >on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. >Then we changed ports so A listening on 1415 and B on 1414. After the >change is done, all SENDER channels on qmgr A that have no port specified, >trying to access remote qmgrs on port 1415. I fthe specify explicitly port >1414 in connection for sender channel it works. > >Does the default port for SENDER channels meant to be the same as port on >which QMGR listening ??? > >Thanks. > > > Alexander Gerasimenko > (a.k.a. Sasha) > Information Services >International, (part of Mars Inc.) > Global AMI Team, ISW , *120, >x.6629 > DDI: +44 (0) 118 9446629 > mobile: +44 (0) 7760201663 > mailto: >[EMAIL PROTECTED] > web: www.mars.com > > > _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Spiraling downhill
Fwd: TechRepublic Downloads--Help You Need to Succeed. TechRepublic http://www.techrepublic.com NO-CHARGE TECHREPUBLIC DOWNLOADS--YOUR KEY TO CAREER SUCCESS! TechRepublic's Downloads area is THE place to find the tools, tips, and tricks you need to do your job better, no matter your IT role. And, the best thing is...they're ALL FREE! It's a great benefit of your TechRepublic membership. Check out these downloads below, and enjoy...courtesy of TechRepublic! USE THIS CHECKLIST WHEN PLANNING AN OFFICE RELOCATION PROJECT http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BPiv0AM >From lost cables to poor space planning, office moves are about as complicated an IT project as a consultant can take on. Learn from the TechRepublic members who've gone before you by downloading a member-inspired checklist to ensure smooth relocations. A FIREWALL CHECKLIST http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BPiw0AN Use this checklist to make sure that firewall needs and security policy requirements cover all the vital aspects of a multilayer security approach. EMPLOYEE EQUIPMENT CHANGE REQUEST FORM http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BPix0AO Get ahead of the game when handling employee equipment changes by implementing a process that facilitates early notification. The first step of notification is downloading our equipment change request form. VISIO STENCIL FOR DIAGRAMMING NETWORK DEVICES http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BPiy0AP Although Microsoft Visio provides a lot of sample objects for network diagramming, it doesn't include many objects for rack-based equipment. Our download offers a bunch of additional rack-based server and device objects. CALL LEVEL CHART http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BPiz0AQ Both large and small IT shops can benefit from using a call level plan to improve staff productivity and user satisfaction. To help you create such a plan, we've developed a sample call level chart that you can download and customize. EMPLOYEE TERMINATION CHECKLIST http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BPi10AD When terminating an employee, make sure you've properly handled all technology items, such as network access. Download this termination checklist template to ensure that the appropriate manager has dealt with all necessary general and IT issues. Copyright (C) 2003 CNET Networks, Inc. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc. TechRepublic Logo is a trademark of CNET Networks, Inc. ** You expressed interest in receiving periodic updates and information from TechRepublic when you became a TechRepublic member. If you wish to be removed from this list, please click below: http://members.techrepublic.com/cgi-bin9/DM/y/eMWC0Escuo0HBB0BMqK0Ai&name=ezyern [EMAIL PROTECTED] You are currently on our mailing list as [EMAIL PROTECTED] ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Performance monitoring/matricies
> I use QPASA every day. There is only a slight overlap with > what it does and > TV does. They are 2 different and complimentary products. > Sorry for interrupting your conversation with vendor information, but I'm an architect for MQSoftware. We have announced a new product called Q Nami! which is our business transaction monitoring product. You can get some details from our web site, or feel free to contact me off the list. Cheers, Craig -- Craig L. Ching Chief Product Architect IBM Certified Specialist, MQSeries IBM Certified Developer, MQSeries MQSoftware, Inc. (952) 345-8720 www.mqsoftware.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Spiraling downhill (OT)
25-30/hr for an MQ administrator (and w/o benefits) does not appear top of the chain, esp when he is expected to be an expert on multiple platforms. I'm wondering how many companies are looking ( or willing to settle ) for 'Jacks of all trades but master of none' vs platform specialists "Paul Meekin" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] CO.UK> cc: Sent by: Subject: Re: Spiraling downhill (OT) "MQSeries List" <[EMAIL PROTECTED] n.AC.AT> 06/18/2003 07:47 AM Please respond to "MQSeries List" (Sorry - can't resist...) Many of these anti-offshore posts seem to be suggesting that the Laissez-faire free-market economy that the US (amongst others) wants to see installed throughout the rest of the world also incorporates some sort of social responsibility. It's all very well nurturing free markets in China etc because you expect to be able to sell your goods there but when they turn around and, in the best tradition of the free market, undercut you with an equally good quality product at a lower price it's a bit hypocritical to start complaining. But another point I'm curious about which is implied by some of these posts is the longer term future of the MQ jobs market. Take Java - in the early days people with Java skills weere at a premium. Now every high school graduate comes out equipped with 3 years Java 'experience' and the market bacame saturated. A similar thing seems to be happening with Oracle DBAs. But I haven't noticed this happening with MQ. MQ has never really hit the mainstream, thus preserving the premium value of those of us with the skills and experience. Once the market picks up again and demand massively outstrips supply I think we'll be back where we were near the top of the chain. Is this a common view? Cheers, Paul This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy or forward all or any of it in any form. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. 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: Spiraling (even further) downhill
unsubscribe -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Williams, Dave (Systems Management) Sent: 18 June 2003 12:05 To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid a bowl of rice a day. >Today Japanese labor is as expensive as US labor > >Things will even out as the rest of the world becomes more prosperous, and >the free flow of goods and services will only speed the process. > >Bill > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 2:36 PM >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill > > >AMEN! Start a union, or maybe get our legislature to wake up and smell the >coffee... > >The good old USA lost 2 million jobs last year. Offshore jobs reduce our >wages and also pay zero income taxes. Do you hear that that sucking sound >its these jobs on our economy. These offshore income earners at Americans >expense spend zero, none, nada, zip, zilch, money in America resulting in >zero sales taxes being paid as well. This great offshore push only lines >the pockets of the CEO's and the like. They are nothing but a drain on >our economy. It may not be your job today but it could be tomorrow. I >wonder how long we will go and how bad it will get before we get serious >about a union or employing a powerful lobbyist. > > > > >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 _ The new MSN 8: advanced junk mail 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 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: Spiraling (even further) downhill
Whatever you are saying must be interesting
-Original Message-
From: MQSeries List on behalf of Robert Broderick
Sent: Wed 6/18/2003 9:09 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: Spiraling (even further) downhill
REMOVED_BY_THE_EXCHANGE_CONTENT_SCANNING_SERVICE_5CAE6CF4_4D03_48A0
The original message content contained a virus or was blocked due to blocking
rules and has been removed.
Ëk¹Ëb¢{ ¢¹¨" ¨º¹X§X¬¶˛±Êâ¦بªަº/ם{ax¸¬¶ǫ¼g§z¶¥Rǫ°k¢uæ¯j)ZnW¶m§ÿðÃ
l¡û\¢`+r¯zm§ÿ!Â'§iƭüÄz¸±ª܆+Þ
MQSeries and .Net
Title: MQSeries and .Net Hello, I was wondering if anyone has had any experience making MQ queues transactional using .Net and MQSeries. I have MQSeries Version 5.2 (Server edition) running on a Windows 2000 server, while using the MQAX200 ActiveX. We're trying to access another MQ server to retrieve and put messages. I have an application written in C# that can successfully get and put messages to the MQ server, but I'm not sure how to make the process of getting/putting a MQ message transactional. I am new to the MQ world and I'm having trouble finding any good examples. If anyone can point me to some sample code or provide any tips, it would be greatly appreciated. Thanks. Andrew 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
MQSICREATEBROKER - SEGMENTATION FAULT
Dear all, Has anyone encountered a segmentation fault error while creating the broker? What causes this? Here is my error: mqsicreatebroker DGBCGB01 -i mquid -a mquid01 -q DGBCGB01 -n WMQIBRDB -u mquid -p mquid01 AMQ8110: WebSphere MQ queue manager already exists. WebSphere MQ queue manager running. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. The setmqaut command completed successfully. Segmentation fault my platform - AIX 5L MQ 53 CSD 04 MQSI v21 CSD 03 DB2 8.1 Do reply please !! Regards 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
Generate XML output Message Problem
Hi, I have a XML input like following. valuevalue valuevalue valuevalue I want to generate the XML output like following valueabc xyzAABBCC xxyyzztest In my code, I have following lines but does not work well. DECLARE myref REFERENCE TO InputRoot.XML.Data.part[];WHILE LASTMOVE(myref) = TRUE DO IF UPPER(myref.(XML.attr)id) = 'PART_1' THEN SET OutputRoot.XML.New.Data.part.(XML.attr)id = 'Part_1'; SET OutputRoot.XML.New.Data.part.part_1_item = myref.part_1_item; ELSE IF UPPER(myref.(XML.attr)id) = 'PART_2' THEN SET OutputRoot.XML.New.Data.part.(XML.attr)id = 'Part_2'; SET OutputRoot.XML.New.Data.part.item = 'abc'; SET OutputRoot.XML.New.Data.part.item = 'xyz'; ELSE IF UPPER(partyref.(XML.attr)ID) = 'PARTY_3' THEN SET OutputRoot.XML.New.Data.part.(XML.attr)id = 'Part_3'; SET OutputRoot.XML.New.Data.part.item_3 = 'test'; END IF; END IF; END IF; MOVE myref NEXTSIBLING;END WHILE; However, I only got following result. value Could anybody tell me what's wrong here? Thanks. Mike Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo.
Re: Spiraling downhill (OT)
Yes, it was about at that time Congress was convinced to change the emigration laws, by creating the H-1B and L1 visas. These permits firms to "temporarily bring" foreign born professionals into the US to handle this extra work. Now, however, the H-1B and L1 "temps" are still in the US. At what point do these temporary visa expire ? |-+-> | | Robert Broderick | | | <[EMAIL PROTECTED]| | | OTMAIL.COM> | | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | .AC.AT> | | | | | | | | | 06/17/2003 03:34 | | | PM| | | Please respond to | | | MQSeries List | | | | |-+-> >-| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Spiraling downhill (OT) | >-| What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid a bowl of rice a day. >Today Japanese labor is as expensive as US labor > >Things will even out as the rest of the world becomes more prosperous, and >the free flow of goods and services will only speed the process. > >Bill > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 2:36 PM >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill > > >AMEN! Start a union, or maybe get our legislature to wake up and smell the >coffee... > >The good old USA lost 2 million jobs last year. Offshore jobs reduce our >wages and also pay zero income taxes. Do you hear that that sucking sound >its these jobs on our economy. These offshore income earners at Americans >expense spend zero, none, nada, zip, zilch, money in America resulting in >zero sales taxes being paid as well. This great offshore push only lines >the pockets of the CEO's and the like. They are nothing but a drain on >our economy. It may not be your job today but it could be tomorrow. I >wonder how long we will go and how bad it will get before we get serious >about a union or employing a powerful lobbyist. > > > > >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 _ The new MSN 8: advanced junk mail 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statem
Re: Spiraling downhill (OT)
Someone in this thread needs to remember his Economics 101 and the classic supply-demand curves. At the same time we expect decent wages we also expect lower prices for "the things that we buy". The manufacturers of "the things that we buy" constantly look for ways to lower the cost of manufacturing, sales and distribution so that their products are most attractively priced so that we tend to buy theirs. Lowering costs is why companies turn to other sources for their IT requirements.because we, IT workers, are also consumers. We have again met the enemy and it is us. Start buying products without regard to price and things may change. Otherwise everyone on this thread needs to read the ancient, but still applicable, "An Inquiry into the Nature and Causes of the Wealth of Nations" by Adam Smith in which he describes the famous 'invisible hand' which describes our economic behaviors. An excerpt (quote): Every individual necessarily labors to render the annual revenue of the society as great as he can. He generally neither intends to promote the public interest, nor knows how much he is promoting it...He intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention. Nor is it always the worse for society that it was no part of his intention. By pursuing his own interest he frequently promotes that of the society more effectually than when he really intends to promote it. I have never known much good done by those who affected to trade for the public good. Is anyone on this thread immune to what is stated there? >>> [EMAIL PROTECTED] 06/18/03 08:42AM >>> HUMMM. Sounds like the start of the Great Depression. Too many goods and no one to buy them. Which leads to corporate cut backs which leads to more no one to buy products which.. I feel the teeth sinking into my American butt as we speak!! We have finally caught our perverbal tail and are eating ourselves! Too smart for our own good!! bobbee >From: "Fryett.Chris" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 20:25:27 -0400 > >The problem honestly is not that American cars were bad back then, it was >the fact we wanted to support our local salvage yard where cousin bud >worked. > >Truly what I have found over the years is US workers have become to >comfortable in their jobs, and that created laziness among a number of >them. Then the DOT.COM's crashed occurred and many investors, >corporations, and VC's discovered they bought into vaporware. So, when >corporations realized they over extended themselves they decided the best >way to resolve the issue was to outsource certain parts of the companies >projects overseas and fire/layoff the US workers. Heck, if you had to pay >someone $0.10 - $0.30 to the $1.00 and it was your money wouldn't you? So, >how do you compete with it? You can't unless you are willing to work for >less and that is exactly what is happening. The butt heads of the past >screwed it up for us today. Also the problem is the cost-of-living isn't >going down to compensate for this reduction so now you'll have to work two >or three jobs to equal what you make now. Say good-bye to your kids and >spouse because you will not see them for a long time. Also, get your grave >arranged, because the stress alone will kill you quicker than smoking. > >It may be time to go back to school and become a psychologist where you can >sleep through your counseling sessions, and on occasion say "That sounds >interesting have you tried another way to handle that". Sorry, regressing >;^) > >Chris > > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 6:01 PM >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) > > >First off I am not a Honda employee... > >I agree things will turn around as the rest of the world prospers but it >will be a long time coming and painful along the way... > >When did the American cars become competitive the 90's well that was a >painful 20-30 years in the US auto industry so I guess the bulk of the next >20-30 years are going to be painful for US IT workers. I agree with that >assessment then. > >Are you instructing college age children to go into the IT field or steer >clear... > >The US Auto industry was once number one in the world and what is it now? >Sure still a case can be made that it is number one but only by the har on >its chinny chin chin and I would bet hardly any on this board drive and >American car. > >If we stay with the auto industry example the US IT industry dominance is >also gone never to return!! > >CONED has no unions huh? I would assume by your comments you are 5 years >or less from retirement - and thus have no worries... I pity the current >crop of CS college graduates - what they saw when they
Re: RFHUTIL(IH03)
It's rfhutilc you need (client version) create a .bat file with the following in the direcory where rfhutilc is installed @echo off SET MQSERVER=SYSTEM.ADMIN.SVRCONN/TCP/hostname(port_of_QM) start rfhutilc this works for me regards, Dec - Original Message - From: "McCarty, Brian" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 18, 2003 1:43 PM Subject: Re: RFHUTIL(IH03) Look again at all the files that come in the package. There should be a .pdf file (doc) and an rfutilc.exe. That is the client version. I have never actually used it, but from what the doc says it's for making connections from machines with only the MQ client installed (you will have to install it yourself). Give that a shot, maybe configure the MQSERVER variable before firing up rfutilc.exe? Let us know how it goes. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Kearns, Emile E [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 6:43 AM To: [EMAIL PROTECTED] Subject: RFHUTIL(IH03) Importance: High Is it possible to set RFHUTIL, running on NT, up to look at remote QMGR on Solaris , If so how? For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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
Service provider in Java
We are running a B2B application (for 3 years) where the portal is in common for all Europe. We are integrating with different SOP-systems on different platforms. All these 'service providers' in the SOP-systems have been set up without any remote queue definitions for the reply back. The service has been easy to use by other 'front-ends' relying on the reply-to-queue/mgr information in the message itelf. For the first time the service provider is written in Java and executed on w2000. The intention was to have the very same setup as before. but 1. We can't execute without a remote queue definition! Does Java demand for a remote queue? or are we just bad in using the Java Classes. 2. Are there any trigger monitor, dedicated for Java, that do not start the JVM every time the trigger is turned on? TIA Denis Wiberg _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Default port 1414 changed.
I have seen this and was mystified by this too. I didn't track this down or verify it's existence (other things got in the way) BUT I thought somewhere this is a configurable parameter (default port) I was going to look in one of the two ini files to see if it was there (QM QMS). Not sure if this was even near the solution to the problem BUT I vaguely remember something on this subject. bobbee From: Sasha Gerasimenko <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Default port 1414 changed. Date: Wed, 18 Jun 2003 10:59:42 +0100 Hi there. I wonder if someone seen this and if it is bug or "feature" . Any fixes available. We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. Then we changed ports so A listening on 1415 and B on 1414. After the change is done, all SENDER channels on qmgr A that have no port specified, trying to access remote qmgrs on port 1415. I fthe specify explicitly port 1414 in connection for sender channel it works. Does the default port for SENDER channels meant to be the same as port on which QMGR listening ??? Thanks. Alexander Gerasimenko (a.k.a. Sasha) Information Services International, (part of Mars Inc.) Global AMI Team, ISW , *120, x.6629 DDI: +44 (0) 118 9446629 mobile: +44 (0) 7760201663 mailto: [EMAIL PROTECTED] web: www.mars.com _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Performance monitoring/matricies
Yes, Transaction Vision (TV) is not cheap, but the amount of info it gives you about your MQ applications is awesome. I use QPASA every day. There is only a slight overlap with what it does and TV does. They are 2 different and complimentary products. Reconda StatWatch is closer in function to TV than QPASA. -Original Message- From: Scott Gray [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 7:09 PM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies We looked at it last year and it was a solid product, but imho unbelievably expensive. MQSoftware now offers a business dashboard capability in their QPasa V3 product that has similar capabilites...We own QPasa now and it's been a struggle since day one, but YMMV. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of McCarty, Brian Sent: Tuesday, June 17, 2003 10:06 AM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies Yes, Bristol's transaction vision looks like a real good tool for end-to-end message/transaction monitoring: http://www.bristol.com/transactionvision/index.html but this does require that a binary intercept the MQ calls made by the application before hitting the queue manager. They say that it is lightweight, but you probably want to do your own performance/release testing also. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 7:53 AM To: [EMAIL PROTECTED] Subject: Re: Performance monitoring/matricies TransactionVision or Reconda -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 8:16 AM To: [EMAIL PROTECTED] Subject: Performance monitoring/matricies We have a large system wich spans WIN200K, Solaris, Tandem, OS390 (MVS & TPF), MQ & MQSI using both Client and server connections at different points. We are in the middle of stress testing and are experiencing delays. Much to our complaints, there are no MQ tools in the Shop. The shop is enterprise sized, so is the application. Is there a product that will do performance monitoring of messaging going through the system. I know of some administration tools that lend themselves to this BUT...is there a product that can be configured to wathc points of entry and exit and corellate the data based on MSGID and CORELID and report back performance. bobbee _ The new MSN 8: advanced junk mail 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Spiraling (even further) downhill
Here Here, Very good closing remarks to an interesting thread! I am sorry my origional remark started such a long thread but that paints a clear picture this is a concern to all of us. Thanks for all your comments bobbee From: "Stephan C. Moen" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Spiraling (even further) downhill Date: Wed, 18 Jun 2003 07:21:17 -0500 There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, "is the cup half-full or half-empty"? Your answer will most likely reflect the job status you currently find yourself in. We can bitch and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best "Find a niche in the market and plug it with your skills so you can earn the money you choose to make." That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid a bowl of rice a day. >Today Japanese labor is as expensive as US labor > >Things will even out as the rest of the world becomes more prosperous, and >the free flow of goods and services will only speed the process. > >Bill > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTEC
Re: Spiraling (even further) downhill
There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, "is the cup half-full or half-empty"? Your answer will most likely reflect the job status you currently find yourself in. We can COMPLAIN and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best "Find a niche in the market and plug it with your skills so you can earn the money you choose to make." That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid a bowl of rice a day. >Today Japanese labor is as expensive as US labor > >Things will even out as the rest of the world becomes more prosperous, and >the free flow of goods and services will only speed the process. > >Bill > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 2:36 PM >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill > > >AMEN! Start a union, or maybe get our legislature to wake up and smell the >coffee... > >The good old USA lost 2 million jobs last year. Offshore jobs reduce our >wages and also pay zero income taxes. Do you hear that that sucking sound >its these jobs on our economy. These offshore income earners at
Re: Spiraling downhill (OT)
HUMMM. Sounds like the start of the Great Depression. Too many goods and no one to buy them. Which leads to corporate cut backs which leads to more no one to buy products which.. I feel the teeth sinking into my American butt as we speak!! We have finally caught our perverbal tail and are eating ourselves! Too smart for our own good!! bobbee From: "Fryett.Chris" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) Date: Tue, 17 Jun 2003 20:25:27 -0400 The problem honestly is not that American cars were bad back then, it was the fact we wanted to support our local salvage yard where cousin bud worked. Truly what I have found over the years is US workers have become to comfortable in their jobs, and that created laziness among a number of them. Then the DOT.COM's crashed occurred and many investors, corporations, and VC's discovered they bought into vaporware. So, when corporations realized they over extended themselves they decided the best way to resolve the issue was to outsource certain parts of the companies projects overseas and fire/layoff the US workers. Heck, if you had to pay someone $0.10 - $0.30 to the $1.00 and it was your money wouldn't you? So, how do you compete with it? You can't unless you are willing to work for less and that is exactly what is happening. The butt heads of the past screwed it up for us today. Also the problem is the cost-of-living isn't going down to compensate for this reduction so now you'll have to work two or three jobs to equal what you make now. Say good-bye to your kids and spouse because you will not see them for a long time. Also, get your grave arranged, because the stress alone will kill you quicker than smoking. It may be time to go back to school and become a psychologist where you can sleep through your counseling sessions, and on occasion say "That sounds interesting have you tried another way to handle that". Sorry, regressing ;^) Chris -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 6:01 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) First off I am not a Honda employee... I agree things will turn around as the rest of the world prospers but it will be a long time coming and painful along the way... When did the American cars become competitive the 90's well that was a painful 20-30 years in the US auto industry so I guess the bulk of the next 20-30 years are going to be painful for US IT workers. I agree with that assessment then. Are you instructing college age children to go into the IT field or steer clear... The US Auto industry was once number one in the world and what is it now? Sure still a case can be made that it is number one but only by the har on its chinny chin chin and I would bet hardly any on this board drive and American car. If we stay with the auto industry example the US IT industry dominance is also gone never to return!! CONED has no unions huh? I would assume by your comments you are 5 years or less from retirement - and thus have no worries... I pity the current crop of CS college graduates - what they saw when they entered college and what they are getting 4-5 years later is sure two different pictures. BTW I have contracted at only Japanese companies for 20 years! :) Honda worldwide sells and builds more cars in the US than in any other market - we build and export 1000's of cars from the US each and every week. "Beinert, William" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: OM> Subject: Re: Spiraling downhill (OT) Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 06/17/2003 12:12 PM Please respond to MQSeries List LMAO at this rant from a Honda employee... He may have quoted this word for word from the auto workers unnions in the 60s when US cars were garbage because they didn't have any competition from manufacturers who did care about quality. I remember being told Japanese cars were cheap becuase the workers only were paid a bowl of rice a day. Today Japanese labor is as expensive as US labor Things will even out as the rest of the world becomes more prosperous, and the free flow of goods and services will only speed the process. Bill -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 2:36 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill AMEN! Start a union, or maybe get our legislature to wake up and smell the coffee... The good old USA lost 2 million jobs last year. Offshore jobs reduce our wages and also pay zero income taxes. Do you hear that that sucking sound its
Re: RFHUTIL(IH03)
Look again at all the files that come in the package. There should be a .pdf file (doc) and an rfutilc.exe. That is the client version. I have never actually used it, but from what the doc says it's for making connections from machines with only the MQ client installed (you will have to install it yourself). Give that a shot, maybe configure the MQSERVER variable before firing up rfutilc.exe? Let us know how it goes. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -Original Message- From: Kearns, Emile E [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 6:43 AM To: [EMAIL PROTECTED] Subject: RFHUTIL(IH03) Importance: High Is it possible to set RFHUTIL, running on NT, up to look at remote QMGR on Solaris , If so how? For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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: RFHUTIL(IH03)
Emile, >>>Is it possible to set RFHUTIL, running on NT, up to look at >>>remote QMGR on Solaris , If so how? There is a client version called rfhutilc. Both are included in the SupportPac. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ & MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Spiraling (even further) downhill
There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, "is the cup half-full or half-empty"? Your answer will most likely reflect the job status you currently find yourself in. We can bitch and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best "Find a niche in the market and plug it with your skills so you can earn the money you choose to make." That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid a bowl of rice a day. >Today Japanese labor is as expensive as US labor > >Things will even out as the rest of the world becomes more prosperous, and >the free flow of goods and services will only speed the process. > >Bill > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 2:36 PM >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill > > >AMEN! Start a union, or maybe get our legislature to wake up and smell the >coffee... > >The good old USA lost 2 million jobs last year. Offshore jobs reduce our >wages and also pay zero income taxes. Do you hear that that sucking sound >its these jobs on our economy. These offshore income earners at
Re: Spiraling downhill (OT)
(Sorry - can't resist...) Many of these anti-offshore posts seem to be suggesting that the Laissez-faire free-market economy that the US (amongst others) wants to see installed throughout the rest of the world also incorporates some sort of social responsibility. It's all very well nurturing free markets in China etc because you expect to be able to sell your goods there but when they turn around and, in the best tradition of the free market, undercut you with an equally good quality product at a lower price it's a bit hypocritical to start complaining. But another point I'm curious about which is implied by some of these posts is the longer term future of the MQ jobs market. Take Java - in the early days people with Java skills weere at a premium. Now every high school graduate comes out equipped with 3 years Java 'experience' and the market bacame saturated. A similar thing seems to be happening with Oracle DBAs. But I haven't noticed this happening with MQ. MQ has never really hit the mainstream, thus preserving the premium value of those of us with the skills and experience. Once the market picks up again and demand massively outstrips supply I think we'll be back where we were near the top of the chain. Is this a common view? Cheers, Paul This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy or forward all or any of it in any form. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
RFHUTIL(IH03)
Is it possible to set RFHUTIL, running on NT, up to look at remote QMGR on Solaris , If so how? For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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
Spiraling (even further) downhill
This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee >From: "Beinert, William" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill (OT) >Date: Tue, 17 Jun 2003 15:12:25 -0400 > >LMAO at this rant from a Honda employee... >He may have quoted this word for word from the auto workers unnions in the >60s when US cars were garbage because they didn't have any competition from >manufacturers who did care about quality. >I remember being told Japanese cars were cheap becuase the workers only >were paid a bowl of rice a day. >Today Japanese labor is as expensive as US labor > >Things will even out as the rest of the world becomes more prosperous, and >the free flow of goods and services will only speed the process. > >Bill > >-Original Message- >From: Randy J Clark [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 2003 2:36 PM >To: [EMAIL PROTECTED] >Subject: Re: Spiraling downhill > > >AMEN! Start a union, or maybe get our legislature to wake up and smell the >coffee... > >The good old USA lost 2 million jobs last year. Offshore jobs reduce our >wages and also pay zero income taxes. Do you hear that that sucking sound >its these jobs on our economy. These offshore income earners at Americans >expense spend zero, none, nada, zip, zilch, money in America resulting in >zero sales taxes being paid as well. This great offshore push only lines >the pockets of the CEO's and the like. They are nothing but a drain on >our economy. It may not be your job today but it could be tomorrow. I >wonder how long we will go and how bad it will get before we get serious >about a union or employing a powerful lobbyist. > > > > >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 _ The new MSN 8: advanced junk mail 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
Default port 1414 changed.
Hi there. I wonder if someone seen this and if it is bug or "feature" . Any fixes available. We have HPUX box with HP ServiceGuard with MQ 5.2 and run 2 queue managers on it, A and B. A were listeneing (inetd) on 1414 and B on 1415. Then we changed ports so A listening on 1415 and B on 1414. After the change is done, all SENDER channels on qmgr A that have no port specified, trying to access remote qmgrs on port 1415. I fthe specify explicitly port 1414 in connection for sender channel it works. Does the default port for SENDER channels meant to be the same as port on which QMGR listening ??? Thanks. Alexander Gerasimenko (a.k.a. Sasha) Information Services International, (part of Mars Inc.) Global AMI Team, ISW , *120, x.6629 DDI: +44 (0) 118 9446629 mobile: +44 (0) 7760201663 mailto: [EMAIL PROTECTED] web: www.mars.com
Re: Spiraling downhill
OK Lets see.Everyone who is participating on this thread, everyone who has something to add to this thread and anyone who is interested in this thread and anyone who would remotely want to add anything to this thread send me you home / office/ girlfriend / boyfriend / bars address and I will go around and rip all your cables out of your computers so the people who feel comfortable in their jobs and who would also like to control what goes in and out of this LISTSERV can have their little heart satisfied. Because somewhere, somehow they think I and they have the power to control what people are typing. So as I am the group appointed execution man. Everybody bow their heads to the malcontents and get ready for the swiish of my blade. OneTwoThree...bang!!! All your cables have been cut and they will be reconnected as soon as the FEW give us a list of what they would like to to talk about. bobbee PS The point here is we all have an exposure to downsizing and off shore practices. If you aren't aware of what is going on in the market you stand to risk yourself, career and family because of lack of financial input. EVERYBODY is at risk As for the malcontents, like I said "take a back seat". Bye everyone, it has been fun again. The guy a couple of EMAILs back who gave the political review. That was interesting. From: "Fryett.Chris" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill Date: Tue, 17 Jun 2003 20:39:12 -0400 I think Bobbee need to close this thread since he *&$($% started it, and he knows that a number of us are in a crappy situation with the job market. Plus, if you haven't had to deal with being unemployed from a permanent or contract position it is difficult to understand. So, I second closing this thread -Original Message- From: Warren Betty [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 7:44 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill As for everything, the rate/price is determined by the market. It will fluctuate depending on the supply and demand. It the current market rate is $ 25-30, so be it. I think it is time to close this topic. Warren "Brian S. Crabtree"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: K.NET> Subject: Re: Spiraling downhill Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 06/17/03 01:00 PM Please respond to MQSeries List Philip $25-30 is reasonable for an MQ Admin Current market rates are $30 MQ Admin $35 MQ Developer $40 WMQI/MQWF $45-50 MQ and WMQI and MQWF and WAS Project Leader/Architect There are companies that will pay more but if a contract gets out to the agencies then the rates drop especially when you are not dealing with the prime agent Brian S. Crabtree EAI Consultant - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 17, 2003 3:14 PM Subject: Re: Spiraling downhill > I believe we're missing the point here. This issues isn't $25-35 offered > rate, but if any MQer would work for that rate. The advertisement could > simply be a trial balloon. > > > > > > "Potkay, Peter M > (PLC, IT)" To: [EMAIL PROTECTED] > <[EMAIL PROTECTED]cc: > RTFORD.COM>Subject: Re: Spiraling downhill > Sent by: MQSeries > List > <[EMAIL PROTECTED] > AC.AT> > > > 06/17/2003 09:35 AM > Please respond to > MQSeries List > > > > > > > Hicksville??? > > maybe a hick MQ specialist is only worth 25-30 per hr... > > > -Original Message- > From: Williams, Dave (Systems Management) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 8:42 AM > To: [EMAIL PROTECTED] > Subject: Re: Spiraling downhill > > > Wow this isn't good. > > -Original Message- > From: Robert Broderick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 7:59 AM > To: [EMAIL PROTECTED] > Subject: Spiraling downhill > > This is not a technical issue so take a back seat if you want to > complain > > WOW. Look at this. Notice the rate > > SKILLS REQUIRED: MQ Series, Unix, mainframe > LOCATION: Hicksville, NY > RATE: $25-30/hr > AREA: 516 > LENGTH: 12 months > TERM: CON_IND CON_CORP > SUMMARY: X Xx has an immediate opening for a Software > Support > Specialist. Candidate should be able work as a MQ Series administrator > and > support various MQ series messaging infrastructure related projects. > Candidate must be familiar with MQSer
Re: Very many MQClient queues...THANKS
Ruzi Temporary dynamic queues are tailor made for your situation... It does not make sense to have 1000's of permanent queues set up for several reasons: a) Initial set up/config/running costs - cost of setting up MQ / LDAP or a DB and configuring them etc b) Maintenance costs you are going to have to maintain all of this externalized data and your application is vulnerable if you cannot access it ( server failures etc ) ... you will need to make that server highly available to avoid a single-point-of-failure arising. c) Flexibility - dynamic queues can come and go as required ... for request/reply type transactions there is rarely a need for persistent messages ... so if the queue disappears ... whats the problem? d) Scalability - you only need the reply-to-queues for the duration of active clients. e.g. If only 200 clients are active only 200 queues will be chewing up MQSeries resources as more clients connect .. more queues will be created ... so that the resources match the load. e) Authentication at the LDAP is not a reason to have these extra queues authentication is a completely separate issue. I have seen many LDAP based MQSeries systems fail because they did not consider the "SPOF" in their design. If you must externalise the queue names and make them permanent on your queue manager... make sure you have a replication LDAP server somewhere else. otherwise. :-(. It sounds like your developmemt team are potentially creating a rod for their own backs? Cheers Kevin
Xa Resource manager not available
Hi all, Is there another to start the XA connect between the Queue Manager and an Oracle Database other than to restart the Queue Manager. Often the DBA's stops and starts a database without the MQ admin staff knowing, this then breaks the XA connection. After the database has been restarted, the XA connection is not there. How can this be started with restarting the QMGR? For information about he Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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: OS/400 and RPG
I don't disagree with anything you say (except perhaps what the question is). However, all I am suggesting is a route to discard invalid messages if the size != known value makes it invalid. Rather than working out the size then getting and discarding the message, fix the buffer at the known value, accept a truncation and discard the message. Obviously this has pretty specific scenarios and is *not* a default mechanism. Regards John. -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: 17 June 2003 13:28 To: [EMAIL PROTECTED] Subject: Re: OS/400 and RPG The question is, is it a problem message, or just a message that is large? If the queue max message length is not sized properly, do you really want to throw away a message? If the poster is trying to find a way to self manage his buffers regardless of the message size, then you could take the approach of reallocating a larger one (not just one that meets the exact size of the incoming message), and redo the MQGET. Storage is cheap. Discarded messages could cost you your job. John Scott <[EMAIL PROTECTED] To: [EMAIL PROTECTED] S.CO.UK> cc: Sent by: Subject: Re: OS/400 and RPG MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/16/2003 01:59 PM Please respond to MQSeries List This is what I would do but that's not what I understood from the original question: "In the end I want to have the application check to see if a message is above a certain size, if it is, then I want it to branch into a get with a 0 sized message buffer, thus removing the problem message." >From this I took that he wanted to throw away the problem message, by trying to work out it's size to remove it. You could remove it by accepting a truncated message. The RC indicates it was truncated, so you know to throw it away. If the application required very high performance and used non-persistent messages, accepting a truncated message to discard it may be the right option. Catching truncated msg failures and regetting with a larger buffer may cause unacceptable delays. Regards John. -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: 16 June 2003 13:43 To: [EMAIL PROTECTED] Subject: Re: OS/400 and RPG John, Wouldn't it be better to not set MQGMO_ACCEPT_TRUNCATED_MSG and test if a truncation error occurred, get the message length, obtain a larger buffer and redo the MQGET? John Scott <[EMAIL PROTECTED] To: [EMAIL PROTECTED] S.CO.UK> cc: Sent by: Subject: Re: OS/400 and RPG MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/16/2003 06:05 AM Please respond to MQSeries List Why not use MQGMO_ACCEPT_TRUNCATED_MSG on the get options. You'll get a message and received a warning for a message that's too large. You can then discard it if it was truncated. Regards John. -Original Message- From: Saar, Andrew [mailto:[EMAIL PROTECTED] Sent: 13 June 2003 19:52 To: [EMAIL PROTECTED] Subject: OS/400 and RPG On OS/400 utilizing RPG and MQ 5.1, can someone help me understand how you would query a message for it's size to determine if it's going to be too large before you get it? I can do this in the C++ and Java environments, but I unfortunately and very ignorant when it comes to RPG and I'm of little help right now to the group who is inquiring. In the end I want to have the application check to see if a message is above a certain size, if it is, then I want it to branch into a get with a 0 sized message buffer, thus removing the problem message. Thank you very much for your help, Andrew 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
