Re: How to trigger amqsput into the background
Peter, you certainly can't put the '&' directly into your script, it will be considered as a parameter by the trigger monitor. You can however, create another script that is triggered, but that script call your current script with a '&'. cheers, Benjamin F. Zhou Technical Specialist Messaging&Integration Supp. Mercedes-Benz USA x.2474 "Potkay, Peter M (ISD, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RTFORD.COM> Subject: How to trigger amqsput into the background Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 07/22/2004 04:08 PM Please respond to MQSeries List Solaris 2.8 MQ 5.3 CSD4 I have runmqtrm running in the foreground. I have the following in my ApplID field of the process definition: /var/mqm/peterscript.sh I have the following in /var/mqm/peterscript.sh: /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE SOLARIS1 This works great, as I see the following in the Trigger Monitor Window: __ Waiting for a trigger message /var/mqm/peterscript.sh 'TMC2PETER Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE my test message to be put Sample AMQSPUT0 end End of application trigger. __ Waiting for a trigger message So now I want the trigger monitor to kick off amqsput in the background. I don't care that I won't be able to put to it, I will use ps -ef|grep amqsput to verify it is up, and then kill -9 it. I tried putting this inside the script: /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE SOLARIS1 & and got this in the trigger monitor window: __ /var/mqm/peterscript.sh 'TMC2PETER Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE Sample AMQSPUT0 end End of application trigger. __ Waiting for a trigger message It just ends amqsput right away. It is not running in the background. And notice the Waiting for Trigger message line does not come up either. But if I then try retriggering it in the foreground again, I get this: /var/mqm/peterscript.sh 'TMC2PETER Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE Sample AMQSPUT0 end End of application trigger. __ Waiting for a trigger message I didn't get the chance to add my message; amqsput ends right away again, but now the Waiting for Trigger Message comes up, and now I can retrigger correctly in the foreground as I did in the beginning. I also tried putting the & in the Environment Data of the Process Def, I got this: __ Waiting for a trigger message Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE Sample AMQSPUT0 end again no Waiting for Trigger message error. Altering the Process def to remove the & and trying to trigger again gave me this: /var/mqm/peterscript.sh 'TMC2PETER Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE test message to put Sample AMQSPUT0 end End of application trigger. __ Waiting for a trigger message This time it didn't need that double triggering to get amqsput to show up properly. Any ideas of how to get it to start up in the background properly? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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
only getting junk from enque5
I'm not getting any msg from the list beside tons of junk from enque5. Anyone is getting the same? thanks, 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 Basic VMS questions
It's been years since my last touch on MQ for VMS VAX. On VAX, you can't just type the name of an executable to run it. you must really "run" it. To run amqsput or what'ever, you must create a file that contain the command string and then "run" it. Say you command is "amqsput YourQ YourQm < yourFile", put it in a file yourEx, set fileflag to execuitable, then from command line, type "run yourEx". This is what remains in my mind. No guarantee however. cheers, and... enjoy VMS - the most reliable OS ever existed ... Benjamin F. Zhou Technical Specialist Messaging&Integration Supp. Mercedes-Benz USA x.2474 Ruzi R <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .COM>cc: Sent by: Subject: Very Basic VMS questions MQSeries List <[EMAIL PROTECTED] en.AC.AT> 07/19/2004 03:17 PM Please respond to MQSeries List Hi All, I am very new to VMS ( VAX) (actually I just signed, as USER1, on to our VMS box for the first time). Queue manager is QM1 (and it is running, which I verified in MQExplorer). 1- How can I view the AMQERR01.LOG file? I entered the following command and got the error indicated below: PRESS::USER1 $ DSPMQFLS MQS_ROOT:[MQM.QMGRS.QM1.ERRORS]AMQERR01.LOG MQSeries Display MQ Files The queue manager is not available for use. 2- Why the sample amqs* programs are not working for me? This is what I entered on the command line and got an error shown below: PRESS::USER1 $ amqsbcg TEST.Q QM1 %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \AMQSBCG\ 3- How can I find the version of MQSeries (not WMQ)? Looks like I am not in the correct directory for the first 2 commands? Using my knowledge on other platforms, I played around with the MQS_ROOT:[MQM]... MQS_EXAMPLES[BIN]... etc to no avail. Can someone help, please? Many thanks in advance, 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
Re: amqcrsta processes
You have certainly reached the default maxchannels of 200, at which your application starts starving from connection. I suppose you're using clients access MQ. That's the same as I experienced before. Remove amqcrst from your /etc/inetd.conf and the corresponding entry in /etc/services, and add runmqlsr in your mq startup script. runmqlsr is superior insofar that it doesn't exhaust maxuproc limit, which default to 50 , I think. Certainly you need to increase your maxchannels quato to 1000 from the default 200. add it in qm.ini as described in the admin manual. enjoy the many channels, cheers, Benjamin F. Zhou Mercedes-Benz USA x.2474 W Samuel <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .CO.UK> cc: Sent by: Subject: amqcrsta processes MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/16/2004 06:13 AM Please respond to MQSeries List Hi everyone, On our Unix system, we have 5 active queue managers We've reached a state where none of these queue are responding anymore I've noticed that there are around 200 amqcrsta processes. I know that amqcrsta is related to channels but cant understand why so many processes are running Any idea how come so many amqcrsta processes are running and how can this be controlled/tuned ? Thanks, WS ___ALL-NEW Yahoo! Messenger - so many all-new ways to express yourself http://uk.messenger.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
trigger monitor as Windows service not working.
I experienced the same problem two years back with version 5.1. Eventually, I resort to using runmqtrm at comnand line to trigger applications. But now, with 5.3 CSD07, it is still not working. I defined queue, setup trigger, defined process, and specified initq. It works fine with runmqtrm at command line, but with trigger monitor service, nothing happens when a msg arrives at the queue. Would anyone mind sharing some insight? thanks, Benjamin F. Zhou Mercedes-Benz USA x.2474 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: runmqlsr - 5 instances running ?
Please ignore last posting, It seems to be specific to this platform( Linux/zOS). On AIX, it shows only one. "Benjamin F. Zhou"To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: BUSA.COM>Subject: runmqlsr - 5 instances running ? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/22/2004 07:48 AM Please respond to MQSeries List Hi, I'm replacing amqcrsta with runmqlsr. According to the insight I got from the Vegas conference, and a FAQ from IBM: "..., a SINGLE listener can now handle an unbounded number of connections..." However, whenever I start runmqlsr, a "ps -aef | grep runmqlsr" shows five instances of it running. Is this the default behavior? Can anyone explain why? thanks, Benjamin F. Zhou Technical Specialist Messaging&Integration Supp. Mercedes-Benz USA x.2474 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
runmqlsr - 5 instances running ?
Hi, I'm replacing amqcrsta with runmqlsr. According to the insight I got from the Vegas conference, and a FAQ from IBM: "..., a SINGLE listener can now handle an unbounded number of connections..." However, whenever I start runmqlsr, a "ps -aef | grep runmqlsr" shows five instances of it running. Is this the default behavior? Can anyone explain why? thanks, Benjamin F. Zhou Technical Specialist Messaging&Integration Supp. Mercedes-Benz USA x.2474 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: share MQ WindowsClient installation - Solution found.
Hi All, Just to report back my solution. an inspirating discussion with an IBM support staff led me to the most elegant solution I can think of: 1. I just install only the MQWindows client to a shared network drive, and copy the whole directory as a backup. 2. Export the MQSeries entry in my windows registry to a file MQSeries.reg 3. Uninstalled the MQwindows client from local PC. 4. rename the backup directory back to mqseries on the shared drive. 5. import the exported MQSeries.reg back in to windows registry. 6. set the MQSERVER environment variable the usual way. 7. run the MQclient program successfully. cheers, Benjamin F. Zhou Technical Specialist Messaging&Integration Supp. Mercedes-Benz USA x.2474 "Blondiaux Denis (DBB)" To: [EMAIL PROTECTED] Subject: Re: share MQ WindowsClient binary and library possible? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/11/2004 02:49 AM Please respond to MQSeries List Hi, I try to do the same thing but it's really not possible to run mqclient without adding minimal registry keys. You will find these three keys after my signature. A few month ago, I've open a change request to IBM to answer allowing client installation files on a LAN, without registry changes. The answer from IBM is in a few word : "it's a valid request since the licence for client is free. But it will not be treated with an absolute priority. so, MAY BE in another version." I think that if a lot of customer ask this request, they can choose to implement it in a CSD. Best Regards, Denis ps. Here is the three key that my tests show as required. [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion] "FilePath"="J:\\MQM\\TOOLS\\MQCLIENT" "WorkPath"="J:\\MQM\\TOOLS\\MQCLIENT" [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\AllQueueManagers] "DefaultPrefix"="J:\\MQM\\TOOLS\\MQCLIENT" -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Marty Fraiser Sent: jeudi 10 juin 2004 18:33 To: [EMAIL PROTECTED] Subject: Re: share MQ WindowsClient binary and library possible? I've seen that done successfully. It's been years since helping a customer set it up and don't remember the details but it worked for hundreds of clients pointing to a shared server drive. We may have added registry entries on each client to make it appear the client was installed but I don't remember, You should be able to figure out why you're getting a 2195 by tracing the client connect attempt. Maybe you don't have write access to the share or something along those lines; or maybe it's missing expected registry entries? You might try replicating the MQ registry entries from the server with client installed, with appropriate substitutions, to one of the client wannabes. HTH, Marty Benjamin F. Zhou wrote: >Hi, > >since quite many developers need to access MQ via WindowsClient. I tried >to install the client software once on a shared network drive, then just >add that location, say L:\ibm\mqseries\bin, to system path, and define >the MQSERVER environment variable. > >But this doesn't seem to work. and I got reason code 2195 - unexpected >error. I also checked the registry, don't really see any entry of >significance related to this problem. > >Has anyone tried this before with success? > >thanks a lot. > >Benjamin F. Zhou >Mercedes-Benz USA >x.2474 > >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 -- Dexia Bank disclaimer : http://www.dexia.be/maildisclaimer.htm -- 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: share MQ WindowsClient binary and library possible?
Hi Denis, many thanks for your insight. After adding the entries in the registry, I got a single, much more reasonable error MQRC2012 - ENVIRONMENT_ERROR. Not sure what that mean. I do have MQSERVER defined correctly pointing to the working svrconn and port. any idea? I'll do more research, when I come through with this, I'll report my result back. Bill, what's the SupportPac "Q" you mentioned? Nice to know someone did it successfully before. thanks a lot. Ben "Blondiaux Denis (DBB)" To: [EMAIL PROTECTED] Subject: Re: share MQ WindowsClient binary and library possible? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/11/2004 02:49 AM Please respond to MQSeries List Hi, I try to do the same thing but it's really not possible to run mqclient without adding minimal registry keys. You will find these three keys after my signature. A few month ago, I've open a change request to IBM to answer allowing client installation files on a LAN, without registry changes. The answer from IBM is in a few word : "it's a valid request since the licence for client is free. But it will not be treated with an absolute priority. so, MAY BE in another version." I think that if a lot of customer ask this request, they can choose to implement it in a CSD. Best Regards, Denis ps. Here is the three key that my tests show as required. [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion] "FilePath"="J:\\MQM\\TOOLS\\MQCLIENT" "WorkPath"="J:\\MQM\\TOOLS\\MQCLIENT" [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\AllQueueManagers] "DefaultPrefix"="J:\\MQM\\TOOLS\\MQCLIENT" -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Marty Fraiser Sent: jeudi 10 juin 2004 18:33 To: [EMAIL PROTECTED] Subject: Re: share MQ WindowsClient binary and library possible? I've seen that done successfully. It's been years since helping a customer set it up and don't remember the details but it worked for hundreds of clients pointing to a shared server drive. We may have added registry entries on each client to make it appear the client was installed but I don't remember, You should be able to figure out why you're getting a 2195 by tracing the client connect attempt. Maybe you don't have write access to the share or something along those lines; or maybe it's missing expected registry entries? You might try replicating the MQ registry entries from the server with client installed, with appropriate substitutions, to one of the client wannabes. HTH, Marty Benjamin F. Zhou wrote: >Hi, > >since quite many developers need to access MQ via WindowsClient. I tried >to install the client software once on a shared network drive, then just >add that location, say L:\ibm\mqseries\bin, to system path, and define >the MQSERVER environment variable. > >But this doesn't seem to work. and I got reason code 2195 - unexpected >error. I also checked the registry, don't really see any entry of >significance related to this problem. > >Has anyone tried this before with success? > >thanks a lot. > >Benjamin F. Zhou >Mercedes-Benz USA >x.2474 > >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 -- Dexia Bank disclaimer : http://www.dexia.be/maildisclaimer.htm -- 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
share MQ WindowsClient binary and library possible?
Hi, since quite many developers need to access MQ via WindowsClient. I tried to install the client software once on a shared network drive, then just add that location, say L:\ibm\mqseries\bin, to system path, and define the MQSERVER environment variable. But this doesn't seem to work. and I got reason code 2195 - unexpected error. I also checked the registry, don't really see any entry of significance related to this problem. Has anyone tried this before with success? thanks a lot. Benjamin F. Zhou Mercedes-Benz USA x.2474 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: many svrconn instances, as many amqcrsta running
Hi Pavel, Rob and Peter, thanks for the insight. I did insisted it must be some code not closing connection under certain circumstances, and ran a trace and sent to IBM for analysis. But were told all connections were closed properly, which virtually nullified my insertion to the developers. I'll following your advice to do more research. There seem to be no tcp_keepcnt on AIX, a command "no -otcp_keepcnt" returned my the following "0821-057 no: The ioctl SIOCGNETOPT system call failed.". again, many thanks. Maybe see you in Las Vegas? Ben Pavel Tolkachev cc: Sent by: Subject: Re: many svrconn instances, as many amqcrsta running MQSeries List <[EMAIL PROTECTED] en.AC.AT> 06/08/2004 12:51 PM Please respond to MQSeries List Hello Benjamin, T.Rob is right in principle, of course. But I guess, the connections had to go down, anyway, with these tcp settings. Just in case, what was your tcp_keepcnt? And, did you check your new tcp parameters took effect immediately? Also, I am not sure if the change takes effect for the existing connections (never checked that..). What else may have happened is that the applications were actually alive, although idle, in which case you do not have much control.. that's why DoS attacks are so nasty when done by the legitimate apps :-) Pavel "Wyatt, T. Rob" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: many svrconn instances, as many amqcrsta running List <[EMAIL PROTECTED] C.AT> 06/08/2004 11:05 AM Please respond to MQSeries List Benjamin, Using QMgr tuning to bring these channels down addresses only the symptom. Unless you correct the problem at it's root, nothing you do will scale well. The application MUST properly close it's resources and disconnect from the QMgr. If you successfully tune the channels, you will probably get through development and testing but you might not see the real impact until the application is in Production. On the other hand, if you leave your channels as they are now, you will have a convenient way to measure the success of the developers in fixing their code. -- T.Rob -Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Tuesday, June 08, 2004 10:52 AM To: [EMAIL PROTECTED] Subject: many svrconn instances, as many amqcrsta running Hi, AIX, 5.1, MQ5.3, csd06: we have JMS clients connecting to MQ via client mode. Initially, the maxchannels got reached quickly, and application failed at pretty low stress level. After I raised both MaxChannels and MaxActiveChannels to 400, the test went through pretty well. However, after each test, I see large number of the svrconn channel and the same number of amqcrsta running against the same qmgr. There's no sign they will ever come down, although I set keepAlive=yes and tcp_keepintvl and tcp_keepidle to 10 seconds. What else can be done to bring down these orphaned processes? I saw many postings concerning this or similar problem at mqseries.net , just none has found a solution. Anyone has more idea on this? best regards, Benjamin Zhou Mercedes-Benz USA. x2474 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 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 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
many svrconn instances, as many amqcrsta running
Hi, AIX, 5.1, MQ5.3, csd06: we have JMS clients connecting to MQ via client mode. Initially, the maxchannels got reached quickly, and application failed at pretty low stress level. After I raised both MaxChannels and MaxActiveChannels to 400, the test went through pretty well. However, after each test, I see large number of the svrconn channel and the same number of amqcrsta running against the same qmgr. There's no sign they will ever come down, although I set keepAlive=yes and tcp_keepintvl and tcp_keepidle to 10 seconds. What else can be done to bring down these orphaned processes? I saw many postings concerning this or similar problem at mqseries.net , just none has found a solution. Anyone has more idea on this? best regards, Benjamin Zhou Mercedes-Benz USA. x2474 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: Message Tracking
Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist Messaging&Integration Supp. Mercedes-Benz USA x.2474 Roger Lacroix <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ> cc: Sent by: MQSeriesSubject: Message Tracking List <[EMAIL PROTECTED] C.AT> 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID >From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID & GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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: Need help with BlokIP exit
Hi Ruzi,
did you figure out how to set it? I don't seem to be able to make the
BlockIP2.dll get loaded. specifically, I put all the files into
d:\utils\exit, and configured my SYSTEM.ADMIN.SVRCONN with
scyexit('d:\utils\exit\BlockIP2(BlockExit)'), and
scydata('d:\utils\exit\blck.cfg; -d')
But it doesn't seem to produce any log file, so I anticipate it didn't
load.
Would you mind shed some light on this setting? BTW, that does this
"(BlockExit)" mean? as parameter?
Benjamin F. Zhou
Messaging & Integration Supp.
Mercedes-Benz USA
(201) 573-2474
Ruzi R
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: Subject: Re: Need help with BlokIP exit
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
02/24/2004 05:45
PM
Please respond
to MQSeries List
Where is this c:\exit.log file defined?
Ruzi
--- Roger Lacroix <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> What errors are you getting - what is in the
> c:\exit.log file ??
>
> The one thing that I have learned about playing with
> Security Exits is that the
> OS and/or the MCA can be a REAL pain. Once a DLL or
> shared-object is loaded,
> it can stay loaded.
>
> Therefore, here is what I do whenever I rebuild an
> exit OR change the SYCDATA
> attribute of the channel.
>
> (1) Stop the channel with mode(force) until there
> are no more connections.
> (2) Copy DLL or shared-object to exit directory
> (3) Make any SYCDATA changes
> (4) Start the channel
> (5) Run program to make a connection.
>
> This may sound tedious but I have banged my head
> many times because a DLL or
> shared-object was previously loaded and I didn't
> realize it.
>
> P.S. I tried your example and it worked.
> i.e.
> SCYDATA(FN=c:\temp\Blockspec.txt;)
>
>
> Hope that helps.
>
> Regards,
> Roger Lacroix
> Capitalware Inc.
> http://www.capitalware.biz
>
>
> Quoting Ruzi R <[EMAIL PROTECTED]>:
>
> > Roger,
> >
> > Thanks. I just downloaded the BlockIP2 and tried
> again
> > and it works with SCYDATA having more than one IP.
> > However I still could not get the file working.
> > Display of the SCYDATA is:
> FN=c:\temp\Blockspec.txt;
> >
> > And Blockspec.txt has the following entries:
> > Patterns=125.25.2.23,125.25.3.44;
> > Userids=userid1,userid2;
> > BlockMqmUsers=Y;
> >
> > Any ideas what I am missing? Anyone?
> >
> > Thanks.
> >
> > Ruzi
> >
> >
> > --- Roger Lacroix <[EMAIL PROTECTED]>
> > wrote:
> > > Hi,
> > >
> > > You MUST put an ending semi-colon ";".
> > > i.e.
> > > SCYDATA(125.25.2.23;125.25.3.44;)
> > >
> > > Hope that helps. Also, you should use BlockIP2
> > > (more features!!)
> > >
> > > Regards,
> > > Roger Lacroix
> > > Capitalware Inc.
> > > http://www.capitalware.biz
> > >
> > >
> > > Quoting Ruzi R <[EMAIL PROTECTED]>:
> > >
> > > > MQ 5.3 CSD06 on Windows2000. I am trying to
> test
> > > > different configurations using BlockIP
> security
> > > exit.
> > > > It works when I use only one IP (full or
> partial
> > > with
> > > > an *) in SCYDATA.
> > > >
> > > > However, I could not get it to work when I
> specify
> > > > SCYDATA with more than one IP address like the
> > > > following:
> > > >
> > > > 1- SCYDATA(125.25.2.23;125.25.3.44) or
> > > > SCYDATA(125.25.2.*;125.25.3.*). Actually,
> because
> > > of
> > > > the requirements, I don t want to use a
> pattern
> > > but
> > > > specify the full IP addresses.
> > > >
> > > > 2- So that I can specify more IPs, I tried
> using
> > > FN
> > > > as follows without success:
> > > > SCYDATA('FN=c:\path..\Blockspec.txt;'). My
> > > > Blockspec.txt is defined like this (minding my
> > > commas
> > > > and semicolons):
> > > >
> > > > Patterns=125.25.2.23,125.25.3.44;
> > > > Userids=userid1,userid2;
> > > > BlockMqmUsers=Y;
> > > >
> > > > Has anyone gotten it working using the 1st ot
> 2nd
> > > > method mentioned above
Re: Puzzled - remote MQSC commands land in DeadQ
Hi Ian, your explanation makes sense. It looks like the only way to get around this would be to write a security exit and explicitly override the userid field with a local user id based on a proper security policy. I'll keep you posted on my solution. many thanks. Ben x.2474 "Chan, Ian M" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: Sent by: Subject: Re: Puzzled - remote MQSC commands land in DeadQ MQSeries List <[EMAIL PROTECTED] en.AC.AT> 04/04/2004 09:02 PM Please respond to MQSeries List Hi Ben, I think the commands were processed using the context in the user id field of MQMD and thus caused the security error. I remember (not sure though) escape PCF uses UserIdentifier field for authority checking and your id is not in the remote system. To answer your first question, the reply should go to the xmit queue directly at the remote qmgr and landed at the SYSTEM.MQSC.REPLY.QUEUE in the local qmgr. Cheers, Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Saturday, 3 April 2004 2:26 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled - remote MQSC commands land in DeadQ Hi Ian, many thanks for the insight. I tested by disabling GET on SYSTEM.ADMIN.COMMAND.QUEUE, then the command msg stays on this queue, which confirmed the receiving MCA does successfully put the request into the command queue. As soon as I enable the GET on this queue, the same number of msg appear on the deadQ. However, they are all of msg type "request" , not reply, as they should be. But why should the command server not populate the userid field with its own id when putting a reply? A few related questions: * where does the command server put the reply msg to? (SYSTEM.MQSC.REPLY.QUEUE? ) * Why are commands sent to command server from MQExplorer on NT got processed and replied correctly? * Where do these command reply msg go to before being picked up my the remote MQExplorer? Rao, I do use DEF on the channel's PUTAUT field. I must admit I'm more confused now. Any more idea? thanks, Ben "Chan, Ian M" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: Sent by: Subject: Re: Puzzled - remote MQSC commands land in DeadQ MQSeries List <[EMAIL PROTECTED] en.AC.AT> 04/01/2004 08:38 PM Please respond to MQSeries List Ben, I set this remote MQSC 2 years ago and I remembered I had the same problem. If I remembered correctly, it was caused by the reply message using the ID in the MQMD, which is your XP logon id. If that's not defined to AIX, you get the NOT_AUTHORIZED error. The MCAUSER specified in your RCVR only affects the authority for MQ to put to the request command queue. I ended up by setting a single id across the platforms and grant appropriate rights to achieve this. I am not good in the context security and may be someone have a better idea. Cheers, Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Friday, 2 April 2004 5:37 AM To: [EMAIL PROTECTED] Subject: Puzzled - remote MQSC commands land in DeadQ Hi, I setup a qmgr NTQM on XP serving as remote admin server, another qmgr AIXQM on AIX to which I submit MQSC commands. Both MQ5.3, CSD04. All the channels are defined, and specifically, I set the receving MCAUSER field on AIX qmgr to 'mqm', which is the same as I did with SYSTEM.ADMIN.SVRCONN channel on AIX for me to access the qmgr objects from MQExplorer on NT, which is working fine. But the mqsc commands I sent to AIXQM all end up in the SYSTEM.DEAD.LETTER.QUEUE in AIXQM, with reason code NOT_AUTHORIZED. What puzzles me most is that under context, the userid is still the NT machines' userid. I tried the same in MO71, the userid in context became musr_mqadmin, command msg land in DeadQ as well. I don't see any reason the receiving channel should fail in replacing the userid field in the msg header with 'mqm'. Has anyone experienced this? What could I be missing. thanks, Ben 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://
Re: Question On MQMD
Gaurav Suppose your applications use the information locally, like for a triggered application, then you can consider putting a file name and path in this field and let the triggered application access that file to get the data you want to pass to it. You can certainly have many such files, each contains specific data as you need. Just an idea. cheers, Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RTFORD.COM> Subject: Re: Question On MQMD Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 04/02/2004 02:28 PM Please respond to MQSeries List Sounds like you have some application data to pass around. Application data belongs in the message buffer. There is no other field in the MQMD for this, other than the 32 bytes in the ApplicationIDData field (which by the way can't bet set by JMS apps). -Original Message- From: Mittal, Gaurav [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 2:18 PM To: [EMAIL PROTECTED] Subject: Question On MQMD According to MQ documents, 'Application Identity Data' field can be used by apps to set information, if required. By default this field allows only 32 characters, is there a way to increase the size of this field?? Or is there any other header property which can be used to set information upto 100 characters? We are using 5.3csd5 queue manager version and our apps are using mqi api's for java. Any help is appreciated. Thanks Gaurav Mittal ___ EAI Consultant Wipro Technologies (612)-291-4551 (W) Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This 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
Re: Puzzled - remote MQSC commands land in DeadQ
Hi Ian, many thanks for the insight. I tested by disabling GET on SYSTEM.ADMIN.COMMAND.QUEUE, then the command msg stays on this queue, which confirmed the receiving MCA does successfully put the request into the command queue. As soon as I enable the GET on this queue, the same number of msg appear on the deadQ. However, they are all of msg type "request" , not reply, as they should be. But why should the command server not populate the userid field with its own id when putting a reply? A few related questions: * where does the command server put the reply msg to? (SYSTEM.MQSC.REPLY.QUEUE? ) * Why are commands sent to command server from MQExplorer on NT got processed and replied correctly? * Where do these command reply msg go to before being picked up my the remote MQExplorer? Rao, I do use DEF on the channel's PUTAUT field. I must admit I'm more confused now. Any more idea? thanks, Ben "Chan, Ian M" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: Sent by: Subject: Re: Puzzled - remote MQSC commands land in DeadQ MQSeries List <[EMAIL PROTECTED] en.AC.AT> 04/01/2004 08:38 PM Please respond to MQSeries List Ben, I set this remote MQSC 2 years ago and I remembered I had the same problem. If I remembered correctly, it was caused by the reply message using the ID in the MQMD, which is your XP logon id. If that's not defined to AIX, you get the NOT_AUTHORIZED error. The MCAUSER specified in your RCVR only affects the authority for MQ to put to the request command queue. I ended up by setting a single id across the platforms and grant appropriate rights to achieve this. I am not good in the context security and may be someone have a better idea. Cheers, Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Friday, 2 April 2004 5:37 AM To: [EMAIL PROTECTED] Subject: Puzzled - remote MQSC commands land in DeadQ Hi, I setup a qmgr NTQM on XP serving as remote admin server, another qmgr AIXQM on AIX to which I submit MQSC commands. Both MQ5.3, CSD04. All the channels are defined, and specifically, I set the receving MCAUSER field on AIX qmgr to 'mqm', which is the same as I did with SYSTEM.ADMIN.SVRCONN channel on AIX for me to access the qmgr objects from MQExplorer on NT, which is working fine. But the mqsc commands I sent to AIXQM all end up in the SYSTEM.DEAD.LETTER.QUEUE in AIXQM, with reason code NOT_AUTHORIZED. What puzzles me most is that under context, the userid is still the NT machines' userid. I tried the same in MO71, the userid in context became musr_mqadmin, command msg land in DeadQ as well. I don't see any reason the receiving channel should fail in replacing the userid field in the msg header with 'mqm'. Has anyone experienced this? What could I be missing. thanks, Ben 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: News: IBM buys Candle
..., I think the next good candidate should be MQSoftware. Benjamin F. Zhou Mercedes-Benz USA x.2474 Michael Dag <[EMAIL PROTECTED] To: [EMAIL PROTECTED] NET.NL> cc: Sent by: Subject: Re: News: IBM buys Candle MQSeries List <[EMAIL PROTECTED] en.AC.AT> 04/01/2004 02:19 PM Please respond to Michael.Dag I hope you meant: hate Omegamon... anyway my guess is your wish (if hate is what you meant...) will be granted... either Omegamon will be renamed to Tivoli MQ Adapter or is likely to get lost in the IBM cloud forever... Candle development staff will be scattered over IBM's labs Candle services staff will be scattered over IBM global services Candles product line will be ripped apart and absorbed by IBM product lines. I am not sure but thought the MQ related part of Candle was just a tip of the swallowed chunk of ice. just my 2 cents... Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] LEONARDO VALENTINO CRUZ Verzonden: donderdag 1 april 2004 18:37 Aan: [EMAIL PROTECTED] Onderwerp: News: IBM buys Candle --- Recebido de POINFOR.UX90825 351.21.3117492 01-04-04 --- -> MQSERIES(a)AKH-Wien.AC.AT -> roger.lacroix(a)CAPITALWARE.BIZ It's true and i heat OMEGAMON Leonardo Cruz Sistemas CICS/MQSeries [EMAIL PROTECTED] 351 213117492 BBVA Portugal * From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Thu, 1 Apr 2004 11:27:22 -0500 Subject: News: IBM buys Candle All, Now here's an interesting news item this morning: http://www.candle.com/www1/cnd/portal/views/pages/CNDportal_Press_Release_Ma ster/0,2279,2683_2949_3888424,00.html It is also listed in Yahoo's biz section. I wonder if it is really true or an April Fool's joke? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz 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 DISCLAIMER This message is intended exclusively for the named person. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of 'BBVA'. Please note that internet e-mail neither guarantees the confidentiality nor the proper receipt of the message sent. If the addressee of this message does not consent to the use of internet e-mail, please communicate it to us immediately. 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
Puzzled - remote MQSC commands land in DeadQ
Hi, I setup a qmgr NTQM on XP serving as remote admin server, another qmgr AIXQM on AIX to which I submit MQSC commands. Both MQ5.3, CSD04. All the channels are defined, and specifically, I set the receving MCAUSER field on AIX qmgr to 'mqm', which is the same as I did with SYSTEM.ADMIN.SVRCONN channel on AIX for me to access the qmgr objects from MQExplorer on NT, which is working fine. But the mqsc commands I sent to AIXQM all end up in the SYSTEM.DEAD.LETTER.QUEUE in AIXQM, with reason code NOT_AUTHORIZED. What puzzles me most is that under context, the userid is still the NT machines' userid. I tried the same in MO71, the userid in context became musr_mqadmin, command msg land in DeadQ as well. I don't see any reason the receiving channel should fail in replacing the userid field in the msg header with 'mqm'. Has anyone experienced this? What could I be missing. thanks, Ben 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
WBI Message Broker pricing ?
Hi MQSI-ers, anyone know the current pricing for the renamed / repackaged MQSI, which is not called WBI-Msg Broker? it was about $20K per CPU 6 months ago. I need the current pricing. I coudn't find it at IBM's site. thanks, Ben 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: MO71 question - viaQM-monitored QM stays green very short
Hi Paul, I figured out what I was missing. I was pointing the remote MQMON queue to the MQMON on the viaQM. it should be pointing to the command reply queue instead. The icon is now green all the time, even for my mainframe QM without CAF installed. many thanks for your help. Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question - viaQM-monitored QM stays green very short MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/22/2004 04:57 AM Please respond to MQSeries List Ben, It's difficult to guess what you're problem is from here. I suggest you follow the message. When you send a monitor message where does it go and how far does it get ? You can easily see whether it makes the round trip by looking at your channel sequence number. If you still can't see anything then feel free to send me you MQMON.CFG file and DIS Q(*) ALL output from both queue managers. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+----> | | "Benjamin F. | | | Zhou"| | | <[EMAIL PROTECTED]| | | USA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 19/03/2004 19:16 | | | Please respond to| | | MQSeries List| |-+> >-| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question - viaQM-monitored QM stays green very short | | | | | >-| Hi Paul, thanks for pointing that out. I set the two qmgrs as illustrated in the diagram. Although the queue MQMON in TEST is used for monitoring both qmgrs, those routed back from QMX are not being picked up. I tried both normal and loopback monitoring, with the same result. The only thing I didn't specify is the server queue field. What else could I be missing? many thanks for your help, Ben (Embedded image moved to file: pic08902.jpg) (See attached file: mqmon_infra.vsd) Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question - viaQM-monitored QM stays green very short MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/19/2004 05:10 AM Please respond to MQSeries List Ben, It is not true to say that "if you get commands to work, then monitoring will also work". You do have to configure your monitor queue correctly as well. Please read the section in the manual about monitoring. You can click on the location monitor button and see where the monitor messages go. If you still have problems perhaps you'd better contact me offline. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+> | | "Benjamin F. | | | Zhou"| | | <[EMAIL PROTECTED]| | | USA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 18/03/2004 16:02 | | | Please respond to| | | MQSeries List| |-+> >-| | | | To:
Re: MO71
Mike, it doesn't make a difference what name you give your NT userid, it will always be sent out in the format NTDOMAIN/userid. What you need is set the MCAUSER field on your SYSTEM.ADMIN.SVRCONN on the UNIX box to "mqm", or an id with the appropriate right. Apparently you're not worrying about security at this point. cheers, "Ward, Mike S" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] >cc: Sent by: Subject: Re: MO71 MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/19/2004 05:20 PM Please respond to MQSeries List Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+> | | "Ward, Mike S" | | | <[EMAIL PROTECTED]>| | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+> >--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | >--- | Hi, is a client required at both ends in order for the monitoring to work? 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: Multiple Brokers sharing the same Database?
Greg, it's not about table names. They are all the same no matter how many brokers you create. Only the entries in the tables are related to individual brokers. You certainly don't want to put your database as "remote" as Alaska if your brokers are in Orlando. I hope it make sense. Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 "Mabrito, Greg" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] AA.COM> cc: Sent by: Subject: Re: Multiple Brokers sharing the same Database? MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/18/2004 01:24 PM Please respond to MQSeries List I am curious about this also. We have moved our broker databases to be remote databases on a dedicated database server. I did not however use the same broker database for both brokers (different servers). When I looked at the tables that were created from the mqsicreatebroker command the tables names were the same so I was hesitant of mixing the two broker databases since the brokers contain the same flow names. I am not sure what the rules are here. If anyone has an explanation of how this works or knows a good reference for this I would greatly appreciate it. Is anyone else using remote broker database? Has anyone seen issues in regards to this? Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Kumar, Sudheer Sent: Thursday, March 18, 2004 10:34 AM To: [EMAIL PROTECTED] Subject: Re: Multiple Brokers sharing the same Database? We share a single database between two brokers. We have not seen any problems with this. Sudheer -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kulbir S. Thind Sent: Thursday, March 18, 2004 10:37 AM To: [EMAIL PROTECTED] Subject: Multiple Brokers sharing the same Database? Hi, If I intend on having multiple WBIMB (MQSI) brokers, can I use a single database as the Broker database and have the brokers share the database or do I need to have a separate broker database for each broker? If I can share the database across brokers is there any impact on performance? Is anyone sharing a database across multiple brokers? Thanks in advance. Kulbir 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: Multiple Brokers sharing the same Database?
Kulbir, unless your broker domain streches across geographical scale, there isn't much point not to let the brokers share the same broker database; although it doesn't make much sense either to have multiple brokers in the first place if they are all located in the same data center. cheers, Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 "Kulbir S. Thind" To: [EMAIL PROTECTED] Subject: Multiple Brokers sharing the same Database? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/18/2004 10:37 AM Please respond to MQSeries List Hi, If I intend on having multiple WBIMB (MQSI) brokers, can I use a single database as the Broker database and have the brokers share the database or do I need to have a separate broker database for each broker? If I can share the database across brokers is there any impact on performance? Is anyone sharing a database across multiple brokers? Thanks in advance. Kulbir 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: MO71 question - viaQM-monitored QM stays green very short
Hi Paul, I'm pretty sure the viaQM-monitored QM already has all the right configuration needed for the monitor. Otherwise I won't get the correct result on the screen when I double click on that QM. My challenge now is how to set the definition to keep it green, not just for a few seconds. I actually set monitor interval to 3, 6 seconds. But it still stays red until I double-click it, when all the qmgr info is shown and the icon turns green, only for a few seconds. thanks, Ben Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/17/2004 11:15 AM Please respond to MQSeries List Ben, Monitoring a location that you are directly connected to (either locally or via a client) is simple since the application need only be able to issue an API call. When you're going to a remote Queue Manager *via* another then you actually need to send a message and have it returned. So, yes, going via another queue manager is more complicated. I've just tried it though and it still seems to work fine so I recommend you read the manual and use loopback monitoring. ie. define a remote queue on your remote QM that 'points' back to the QM your MO71 is actually connected to. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+--------> | | "Benjamin F. | | | Zhou"| | | <[EMAIL PROTECTED]| | | USA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 12/03/2004 16:15 | | | Please respond to| | | MQSeries List| |-+> >-| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question | | | | | >-| Hi Paul, I still try to use viaQM because it may take weeks before it can be installed on the MF. Just to compare, I added another location whose qmgr is on the same NT machine. I set it up to be viaQM-monitored. After I double-click the QM, all the query results are shown on the screen about this QM, its icon turns green, but just for a short two seconds, it will turn red with 'X' right away. What does this mean? Is there more to configure for viaQM monitored QM? thanks, Ben Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/11/2004 01:26 PM Please respond to MQSeries List Ben, If you have the CAF (Client Access Facility) then it begs the question as to why you're routing your requests to MVS via an AIX Queue manager. Wouldn't you be better off defining your MO71 MVS location as a client connection. If you did you would then be able to browse the messages on the dead letter queue using MO71. Of course, both solutions require that you either have your userid registered with your MVS userid or you change the userid of the messages flowing to MVS to something it will accept. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+> | | "Benjamin F. | | | Zhou"| | | <[EMAIL PROTECTED]| | | USA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 11/03/2004 13:55 | | | Please respond to| | | MQSeries List| |-+> >--
Odd today: Error connecting via client to 'QM1' RC(2035) Not authorized.
Hi all, we use MQExplorer and MO71 to monitor remote qmgrs, on AIX and NT. Today a strange thing happens. I first got email notificaiton from MO71 that one of our NT qmgrs is down, there I see the msg in the subject.. I then checked it in MQExplorer, got similar msg: "Access not authorized, You are not authorized to perform this operation. (AMQ4035)". I remote login to that machine, everything is running fine, no report of disturbance, it's a production machine. So I ignore it for the time being. Then five hours later, I encountered the same on another NT machine. Maybe I'll have to restart the qmgr tonight to see what it will become. Anyone experienced this before? Any idea what could be wrong? thanks, Ben 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: MO71 question
Hi Paul, I still try to use viaQM because it may take weeks before it can be installed on the MF. Just to compare, I added another location whose qmgr is on the same NT machine. I set it up to be viaQM-monitored. After I double-click the QM, all the query results are shown on the screen about this QM, its icon turns green, but just for a short two seconds, it will turn red with 'X' right away. What does this mean? Is there more to configure for viaQM monitored QM? thanks, Ben Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/11/2004 01:26 PM Please respond to MQSeries List Ben, If you have the CAF (Client Access Facility) then it begs the question as to why you're routing your requests to MVS via an AIX Queue manager. Wouldn't you be better off defining your MO71 MVS location as a client connection. If you did you would then be able to browse the messages on the dead letter queue using MO71. Of course, both solutions require that you either have your userid registered with your MVS userid or you change the userid of the messages flowing to MVS to something it will accept. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+----> | | "Benjamin F. | | | Zhou"| | | <[EMAIL PROTECTED]| | | USA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 11/03/2004 13:55 | | | Please respond to| | | MQSeries List| |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question | | | | | >--| Hi Paul, Many thanks for the hint. I could eventually locate the msg in the deadQ on mainframe. However, since I can't read msg there as I can on other platforms, I have to guess what's there. It seems I do have to have CAF to read the msg. (I'm no MF literate) I also tried to use Loop-back monitoring, where I make the command queue on the mainframe a remote queue pointing back to viaQM's reply Queue. Now I see both channels in running status. Just the MO71 location for the MF qmgr is still not active. I anticipate the viaQM simply took over the msg before the MF entry gets a chance to get it. Do you see it that way? best regards, Ben Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/10/2004 05:14 AM Please respond to MQSeries List Ben, Nick has described it perfectly. The whole point of the 'via' location is that messages are routed to/from your target Queue Manager *via* this other location. As far as where did your message go ? Well, check the normal places. If you're certain the message got to the mainframe then it should have been processed by the command server. The most likely thing is that the command server didn't like your userid (or something) and will have dumped the request to the dead letter queue. If all else fails then trace is always an option. With tracing switched on you should be able to follow the path of any message and see exactly where it goes. However normally this shouldn't be necessary. Check all your DLQs, command queues and transmission queues and you'll probably find your message. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Nick Dilauro <[EMAIL PROTECTED]To: [EMAIL PROTECTED] >cc: Sent by: MQSeriesSubject: Re: MO71 question List
Re: MO71 question
Hi Paul, Many thanks for the hint. I could eventually locate the msg in the deadQ on mainframe. However, since I can't read msg there as I can on other platforms, I have to guess what's there. It seems I do have to have CAF to read the msg. (I'm no MF literate) I also tried to use Loop-back monitoring, where I make the command queue on the mainframe a remote queue pointing back to viaQM's reply Queue. Now I see both channels in running status. Just the MO71 location for the MF qmgr is still not active. I anticipate the viaQM simply took over the msg before the MF entry gets a chance to get it. Do you see it that way? best regards, Ben Paul Clarke <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COM>cc: Sent by: Subject: Re: MO71 question MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/10/2004 05:14 AM Please respond to MQSeries List Ben, Nick has described it perfectly. The whole point of the 'via' location is that messages are routed to/from your target Queue Manager *via* this other location. As far as where did your message go ? Well, check the normal places. If you're certain the message got to the mainframe then it should have been processed by the command server. The most likely thing is that the command server didn't like your userid (or something) and will have dumped the request to the dead letter queue. If all else fails then trace is always an option. With tracing switched on you should be able to follow the path of any message and see exactly where it goes. However normally this shouldn't be necessary. Check all your DLQs, command queues and transmission queues and you'll probably find your message. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Nick Dilauro <[EMAIL PROTECTED]To: [EMAIL PROTECTED] >cc: Sent by: MQSeriesSubject: Re: MO71 question List <[EMAIL PROTECTED] N.AC.AT> 09/03/2004 21:46 Please respond to MQSeries List Ben, I'm pretty sure it means that you are using the reply to queue you specified when you set up the location for the "via QM". Since that qmgr has connections to the other qmgr the replies are routed back to the "via QM". Even though it doesn't say so, you don't need any of the client info for the other qmgr. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Tuesday, March 09, 2004 11:11 AM To: [EMAIL PROTECTED] Subject: MO71 question Hi MO71 veterans, 1. what does it mean that "replyQ is not needed when using via QM". Where does the reply go to? to SYSTEM.DEFAULT.MODEL.QUEUE? Specifically, I'm setting up MO71 to monitor a mainframe QM (without CAF, I'm now convinced it's not needed) , via a QM on AIX. After I defined qmgr-alias on the AIX box to point to the MF QM, I see the request got sent to the mainframe, but no reply ever gets back. Apparently the MF QM didn't even try to send a reply back since the XmitQ is empty and sender channel to AIX never starts. I also setup qmgr alias on MF pointing to QM on AIX. The field mvs has been checked. 2. Has anyone ever used the "Command OK" field to run a batch program or whatever, on a win2k or XP machine? Paul, maybe you can pin-point what I'm missing right away. thanks a lot. Ben 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
MO71 "Command Fail/OK" field not working --- SOLVED !
Hi Nobert, it turned out the problem was not the syntax, but the way "batch job" is defined. What I was trying was let that field call a notify.bat file, which didn't work. It start working when I copied the content of that notify.bat file into the "Command Fail" field directly. This prompt me to write a small C program that makes a system call to invoke the notify.bat . I then put this notify.exe into the "Command Fail" field, and tested, it works great now. Thank you so much, it is really your responses that inspired me to think and test more which eventually led me to the solution. Paul, maybe you want to add a paragraph about this behavior to your document ? best regards, Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 Pfister Norbert <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ELLIUM.COM> cc: Sent by: MQSeries Subject: AW: AW: MO71 "Command Fail/OK" field not working. List <[EMAIL PROTECTED] AC.AT> 03/10/2004 01:38 AM Please respond to MQSeries List Hi Benjamin, your command syntax is wrong: To activate a batch, you have to type "cmd.exe /c" In your case: "cmd.exe /cd:\utils\notify.bat QMName" or in MO71 even "cmd.exe /cd:\utils\notify.bat %m" according to Paul Clarke's mqmon.pdf chapter 8 - Queue Manager monitoring . Regards, Norbert Pfister IT DB/DC-Systemtechnik ITELLIUM Systems & Services GmbH N - Bau V, 1. Stock, Zi. 105 Fürther Strasse 205 D-90429 Nürnberg, Germany Tel.: (+49) 0911/14-26548 Fax: (+49) 0911/14-36548 Mobil: (+49) 0151/14265011 mailto:[EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 9. März 2004 14:49 An: [EMAIL PROTECTED] Betreff: Re: AW: MO71 "Command Fail/OK" field not working. Hi Nobert, thanks for taking the time to reply. What Windows version are you using? We use XP. Here is my command string in the Command OK field: "d:\utils\notify.bat QMName". I also tried your syntax by typing "cmd.exe /d:\utils\notify.bat QMName". With the same result. If I understand correctly, the string in this field is put into a system call system(). Could this be a XP specific bug? mit herzlichem Dank, Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 Pfister Norbert <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ELLIUM.COM> cc: Sent by: MQSeries Subject: AW: MO71 "Command Fail/OK" field not working. List <[EMAIL PROTECTED] AC.AT> 03/09/2004 01:21 AM Please respond to MQSeries List Hi Benjamin, we did successfully via VisualBasic script: cmd.exe /cmonitor.vbs ok n %m %l cmd.exe /cmonitor.vbs fail y %m %l where the parms are: ' 1 - what: "ok" or "fail" ' 2 - MsgBox: "y" for yes, otherwise only to logfile ' 3 - QMGR-Name ' 4-n Location / Title Of course I had to activate the Windows scripting host on my workstation. Regards, Norbert Pfister IT DB/DC-Systemtechnik ITELLIUM Systems & Services GmbH N - Bau V, 1. Stock, Zi. 105 Fürther Strasse 205 D-90429 Nürnberg, Germany Tel.: (+49) 0911/14-26548 Fax: (+49) 0911/14-36548 Mobil: (+49) 0151/14265011 mailto:[EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Gesendet: Montag, 8. März 2004 20:22 An: [EMAIL PROTECTED] Betreff: MO71 "Command Fail/OK" field not working. Hi All, Again many thanks to all those who helped me located the key in monitoring MQ on z/OS with MO71. Now I am testing using MO71 to monitor
MO71 question
Hi MO71 veterans, 1. what does it mean that "replyQ is not needed when using via QM". Where does the reply go to? to SYSTEM.DEFAULT.MODEL.QUEUE? Specifically, I'm setting up MO71 to monitor a mainframe QM (without CAF, I'm now convinced it's not needed) , via a QM on AIX. After I defined qmgr-alias on the AIX box to point to the MF QM, I see the request got sent to the mainframe, but no reply ever gets back. Apparently the MF QM didn't even try to send a reply back since the XmitQ is empty and sender channel to AIX never starts. I also setup qmgr alias on MF pointing to QM on AIX. The field mvs has been checked. 2. Has anyone ever used the "Command OK" field to run a batch program or whatever, on a win2k or XP machine? Paul, maybe you can pin-point what I'm missing right away. thanks a lot. Ben Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: AW: MO71 "Command Fail/OK" field not working.
Hi Nobert, thanks for taking the time to reply. What Windows version are you using? We use XP. Here is my command string in the Command OK field: "d:\utils\notify.bat QMName". I also tried your syntax by typing "cmd.exe /d:\utils\notify.bat QMName". With the same result. If I understand correctly, the string in this field is put into a system call system(). Could this be a XP specific bug? mit herzlichem Dank, Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 Pfister Norbert <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ELLIUM.COM> cc: Sent by: MQSeries Subject: AW: MO71 "Command Fail/OK" field not working. List <[EMAIL PROTECTED] AC.AT> 03/09/2004 01:21 AM Please respond to MQSeries List Hi Benjamin, we did successfully via VisualBasic script: cmd.exe /cmonitor.vbs ok n %m %l cmd.exe /cmonitor.vbs fail y %m %l where the parms are: ' 1 - what: "ok" or "fail" ' 2 - MsgBox: "y" for yes, otherwise only to logfile ' 3 - QMGR-Name ' 4-n Location / Title Of course I had to activate the Windows scripting host on my workstation. Regards, Norbert Pfister IT DB/DC-Systemtechnik ITELLIUM Systems & Services GmbH N - Bau V, 1. Stock, Zi. 105 Fürther Strasse 205 D-90429 Nürnberg, Germany Tel.: (+49) 0911/14-26548 Fax: (+49) 0911/14-36548 Mobil: (+49) 0151/14265011 mailto:[EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Gesendet: Montag, 8. März 2004 20:22 An: [EMAIL PROTECTED] Betreff: MO71 "Command Fail/OK" field not working. Hi All, Again many thanks to all those who helped me located the key in monitoring MQ on z/OS with MO71. Now I am testing using MO71 to monitor our MQ network employe the "command Fail" field to run a batch job which sends out emails. But this seems not working. I also tried the command "amqsput TESTQ TESTQM < mail.txt", with the same result, got the msg "command submitted", but nothing is done. Has anyone successfully used this field to execute a command? I wonder what I could be doing wrong. thanks for your help. Benjamin Zhou 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: how to receive own posting to the list.
ww, thanks a lot for the rain ! cheers, Ben "Beinert, William" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: COM> Subject: Re: how to receive own posting to the list. Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/08/2004 03:03 PM Please respond to MQSeries List send the command SET MQSERIES REPRO to the listserver (not to the list) Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Monday, March 08, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: how to receive own posting to the list. anyone know how to receive one's own posting to the list? thanks, Ben 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
how to receive own posting to the list.
anyone know how to receive one's own posting to the list? thanks, Ben 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
MO71 "Command Fail/OK" field not working.
Hi All, Again many thanks to all those who helped me located the key in monitoring MQ on z/OS with MO71. Now I am testing using MO71 to monitor our MQ network employe the "command Fail" field to run a batch job which sends out emails. But this seems not working. I also tried the command "amqsput TESTQ TESTQM < mail.txt", with the same result, got the msg "command submitted", but nothing is done. Has anyone successfully used this field to execute a command? I wonder what I could be doing wrong. thanks for your help. Benjamin Zhou 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: SAVEQMGR PCF ERROR
Rao, Now that Peter has pointed out the newly introduced attribute NPMCLASS, you can modify the source code to get an upgraded saveqmgr yourself. It's not difficult. if you a somehow familiar with C. cheers, Benjamin F. Zhou Technical Specialist Enterprise Application Integration Mercedes-Benz USA x.2474 "Adiraju, Rao" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] Z.CO.NZ> cc: Sent by: Subject: Re: SAVEQMGR PCF ERROR MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/25/2004 09:53 PM Please respond to MQSeries List What does it mean - the Saveqmgr won't work with MQ V5.3 - CSD06, if so what are the alterantives. We are planning to upgrade to CSD06 within couple of weeks and we use Saveqmgr quite heavily. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 -Original Message- From: Peter Uranyi [mailto:[EMAIL PROTECTED] Sent: 26 February 2004 3:43 PM To: [EMAIL PROTECTED] Subject: Re: SAVEQMGR PCF ERROR Brent, A new queue attribute was introduced in CSD06, called NPMCLASS. It is documented in the readme file. Peter --- Brent Ireland <[EMAIL PROTECTED]> wrote: > Hi, > > I ran the saveqmgr and got about 30 "Unknown PCF Integer Parameter: 78" > messages. > > Does anyone why i am getting error 78? What does 78 refer to? > > I am running WebSphere MQ v5.3 on Win2K with CSD06. > > Thank you in advance. > > Brent Ireland > CAE Inc. > Global Information Technology (Dept J8) Supply Chain Programmers Group > Tel : (514) 341-6780 Ext. 2745 Fax / Tilicopieur : (514) 734-5605 > Email / Courriel : [EMAIL PROTECTED] > > Instructions for managing your mailing list subscription are provided > in the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: monitor MQ z/OS with MO71 ?
thanks Kerry for the good point. I'm not sure if we have MQc.lient on os/390 either. will check with our mainframe team on that. Kerry Swemmer <[EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA> cc: Sent by: MQSeriesSubject: Re: monitor MQ z/OS with MO71 ? List <[EMAIL PROTECTED] C.AT> 02/18/2004 03:40 AM Please respond to MQSeries List Howzit bfz, We don't have the client on OS/390 so we configure the monitoring via a Windows qmgr? RU using the client or not? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 17 February 2004 21:27 To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, 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 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: monitor MQ z/OS with MO71 ?
Philip, Yes, they are correct with SYSTEM.COMMAND.INPUT and SYSTEM.DEFAULT.MODEL.QUEUE for input and reply respectively. I created the channel SYSTEM.ADMIN.SVRCONN manually and put it in the client config. with ip address/port correctly specified. Other channels using the same port is working fine. Just not this one. thanka, Ben x.2474 [EMAIL PROTECTED] PMCHASE.COMTo: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: monitor MQ z/OS with MO71 ? <[EMAIL PROTECTED] .AC.AT> 02/17/2004 03:26 PM Please respond to MQSeries List Ben, Yes, I've gotten it to work. In fact, it's worked since 1996. What kind of problem are you having ? do you check off the MVS box ? The queue is "SYSTEM.COMMAND.INPUT" (normally), not "SYSTEM.ADMIN.COMMAND". This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71
Kerry,
Yes. I'm asking our mainframe person to check if we have the client
component installed at all. I got "Error connecting via client to 'MQSZ'
RC(2059) QMgr not available." at the bottom of the monitor screen.
thanks,
Ben
Kerry Swemmer
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
TEMS.CO.ZA> cc:
Sent by: MQSeriesSubject: Re: How to check if
MQClient is installed on os/390 ? - origiina
List l: monitor MQ z/OS with MO71
<[EMAIL PROTECTED]
C.AT>
02/19/2004 03:03 AM
Please respond to
MQSeries List
Howzit Ben,
Is the original monitoring issue still outstanding?
Cheers,
> Kerry Swemmer
> T-Systems South Africa (Pty) Ltd
> Database Administrator
> Computing and Desktop Services
> Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa
> Postal Address: PO Box 671, East London, 5200
> Phone: +27 (43) 706 2549
> Fax:+27 (43) 706 2085
> Mobile: +27 (83) 657 4151
> E-mail: [EMAIL PROTECTED]
> Internet: www.t-systems.co.za
-Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
Benjamin F. Zhou
Sent: 18 February 2004 18:46
To: [EMAIL PROTECTED]
Subject: Re: How to check if MQClient is installed on os/390 ? -
origiina l: monitor MQ z/OS with MO71
Hi Frank,
thanks a lot for sharing this with me.
Ben
x.2474
"Bright, Frank"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
HEALTH.COM> cc:
Sent by: MQSeries Subject: Re: How to check
if MQClient is installed on os/390 ? - origiina
Listl: monitor MQ z/OS with
MO71
<[EMAIL PROTECTED]
AC.AT>
02/18/2004 11:03 AM
Please respond to
MQSeries List
Extract from an old post from Roger Lacroix
Sent: Tuesday, March 11, 2003 6:50 PM
To: [EMAIL PROTECTED]
Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4
How to know if "Client Attachment Feature" (CAF) is installed on z/OS? It
is separate product from WMQ.
To find out if you have CAF installed on z/OS, look at CHIN
started-task
(on z/OS under SDSF, Display Active) for the following:
+CSQX099I CSQXGIP Client attachment feature available
where is the z/OS queue manager name.
Thanks
Frank
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
F. Zhou
Sent: Wednesday, February 18, 2004 10:33 AM
To: [EMAIL PROTECTED]
Subject: How to check if MQClient is installed on os/390 ? - origiinal:
monitor MQ z/OS with MO71
... but how can I check if MQClient component has been installed on an
os/390 platform? I'm not a mvs person.
thanks,
bfz
Kerry Swemmer
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
TEMS.CO.ZA> cc:
Sent by: MQSeriesSubject: Re: monitor MQ
z/OS with MO71 ?
List
<[EMAIL PROTECTED]
C.AT>
02/18/2004 03:40 AM
Please respond to
MQSeries List
Howzit bfz,
We don't have the client on OS/390 so we configure the monitoring via a
Windows qmgr? RU using the client or not?
Cheers,
Kerry Swemmer
T-Systems South Africa (Pty) Ltd
Database Administrator
Computing and Desktop Services
Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal
Address: PO Box 671, East London, 5200
Phone: +27 (43) 706 2549
Fax:+27 (43) 706 2085
Mobile: +27 (83) 657 4151
E-mail: [EMAIL PROTECTED]
Internet: www.t-systems.co.za
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin
F.
Zhou
Sent: 17 February 2004 21:27
To: [EMAIL PROTECTED]
Subject: monitor MQ z/OS with MO71 ?
has anyone successfully configured MO71 to monitor QM on z/OS ?
I think MO71 should be capable of that, but I couldn't make it connect.
any idea?
thanks,
bfz
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
Any views expressed in this message are those of the individual sender, and
T-Systems South Africa (Pty) Ltd accepts no liability therefore, except
where the sender specifically states them to be those of T-Systems South
Africa (Pty) Ltd. Although this message has been scanned for the possib
Re: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71
Hi Frank, thanks a lot for sharing this with me. Ben x.2474 "Bright, Frank" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] HEALTH.COM> cc: Sent by: MQSeries Subject: Re: How to check if MQClient is installed on os/390 ? - origiina Listl: monitor MQ z/OS with MO71 <[EMAIL PROTECTED] AC.AT> 02/18/2004 11:03 AM Please respond to MQSeries List Extract from an old post from Roger Lacroix Sent: Tuesday, March 11, 2003 6:50 PM To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 How to know if "Client Attachment Feature" (CAF) is installed on z/OS? It is separate product from WMQ. To find out if you have CAF installed on z/OS, look at CHIN started-task (on z/OS under SDSF, Display Active) for the following: +CSQX099I CSQXGIP Client attachment feature available where is the z/OS queue manager name. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Wednesday, February 18, 2004 10:33 AM To: [EMAIL PROTECTED] Subject: How to check if MQClient is installed on os/390 ? - origiinal: monitor MQ z/OS with MO71 ... but how can I check if MQClient component has been installed on an os/390 platform? I'm not a mvs person. thanks, bfz Kerry Swemmer <[EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA> cc: Sent by: MQSeriesSubject: Re: monitor MQ z/OS with MO71 ? List <[EMAIL PROTECTED] C.AT> 02/18/2004 03:40 AM Please respond to MQSeries List Howzit bfz, We don't have the client on OS/390 so we configure the monitoring via a Windows qmgr? RU using the client or not? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 17 February 2004 21:27 To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, 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 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 message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. 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
How to check if MQClient is installed on os/390 ? - origiinal: monitor MQ z/OS with MO71
... but how can I check if MQClient component has been installed on an os/390 platform? I'm not a mvs person. thanks, bfz Kerry Swemmer <[EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA> cc: Sent by: MQSeriesSubject: Re: monitor MQ z/OS with MO71 ? List <[EMAIL PROTECTED] C.AT> 02/18/2004 03:40 AM Please respond to MQSeries List Howzit bfz, We don't have the client on OS/390 so we configure the monitoring via a Windows qmgr? RU using the client or not? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 17 February 2004 21:27 To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, 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 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: monitor MQ z/OS with MO71 ?
Hi Arlen, I checked the MVS as well as client setting, with SYSTEM.ADMIN.SVRCONN specified and created. What I got was "Error connecting via client to 'QMGR' RC(2059) QMgr not available." the reply queue is SYSTEM.DEFAULT.MODEL.QUEUE, which exists. But I wonder why it uses a model queue as default. thanks, Ben "Williams, Arlen" To: [EMAIL PROTECTED] Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/17/2004 04:33 PM Please respond to MQSeries List Did you check the MVS selection so the correct command queue name will be used? Does the reply queue and monitor queue exist? Does the svrconn channel come up on the mainframe? What is the error you are getting? -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 3:05 PM To: [EMAIL PROTECTED] Subject: Re: monitor MQ z/OS with MO71 ? Hi Arlen, thanks for the response. I set the MCA user field on mainframe to the id I used to access the qmgr. but it doesn't work. Is there anything else I need to set? I remember the command server is always started upon qmgr startup. So that isn't an issue. thanks, bfz "Williams, Arlen" To: [EMAIL PROTECTED] Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/17/2004 03:14 PM Please respond to MQSeries List We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 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: monitor MQ z/OS with MO71 ?
Hi Arlen, thanks for the response. I set the MCA user field on mainframe to the id I used to access the qmgr. but it doesn't work. Is there anything else I need to set? I remember the command server is always started upon qmgr startup. So that isn't an issue. thanks, bfz "Williams, Arlen" To: [EMAIL PROTECTED] Subject: Re: monitor MQ z/OS with MO71 ? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/17/2004 03:14 PM Please respond to MQSeries List We have it working here. Make sure the account you are running on has the needed authorization on z/OS. -Original Message----- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 1:27 PM To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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
monitor MQ z/OS with MO71 ?
has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
how to make receiver channel 'inactive' on z/OS ?
Hi, is there a way to force a hanging receiver channel on z/OS into inactive status so it becomes available for a healthy restart? On Aix one can so a stop with status(inactive). Is this possible on mainframe? thanks for any hint. Benjamin F. Zhou Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
how to make receiver channel 'inactive' on z/OS -- please ignore last posting.
sorry for the hasty posting. I should have seen it on the subscreen. there's force and inactive option right there. regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 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: Puzzled: MQJE001, MQRC 2102 for non-mqm users
/ brokage-house, it is a fire-able offense to access PROD data if you have not been approved. Hence, generally speaking, people do not risk it. Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > Rob, > > thanks for the insight. > However, a JMS application accesses a qmgr via a connection factory object > defined in the JNDI namespace, NOT through a svrconn channel on the server, > i,e. it's actually not using the MQI channel. It can be seen from the > following entry in my definition script, that it actually creates a direct > socket connection to the host and port: > > def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) > port(1415) > > So such a definition makes it even more dangerous since there is no more MQ > level security can be activated. > > While writing this, it became clear to me that the above is provided as an > alternative to using MQI channel to access a remote qmgr in order to avoid > having to define a client channel on the client side. Certainly, the above > definition can be altered to use MQI channel instead of the host propery: > > def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) > > However, the first is a dangerous alternative. Any comment? > > regards, > Ben > > > > > > > > > > "Wyatt, T. Rob" > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > MERICA.COM> cc: > Sent by: MQSeriesSubject: Re: Puzzled: > MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/05/2004 10:50 AM > Please respond to > MQSeries List > > > > > > > Benjamin, > > That is because the channel used by the client is using the authority of > the > QMgr. Unless you put an MCAUSER or a security exit that substitutes a > different UserID on the channel, you will get administrative rights. This > is true of all client-connections and, yes, it is dangerous. > > -- T.Rob > > -Original Message- > From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] > Sent: Monday, January 05, 2004 9:55 AM > To: [EMAIL PROTECTED] > Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > > Bob, that's a good point. I've opened a ticket with IBM on this misleading > reason code. > > However, if I use client mode, the jms application needs neither +inq nor > +connect to the qmgr, to put a message to a queue. It dosn't even need a > +put/+get/+brose. It seems to me that in the case of MQClient, it is the > local qmgr that actually does the puts/gets. So no authorization is needed > at all. But this sounds too dangerous, doesn't it? > > regards, > > Benjamin F. Zhou > Mercedes-Benz USA > x.2474 > > > > > > Robert Broderick > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > OTMAIL.COM>cc: > Sent by: MQSeries Subject: Re: Puzzled: > MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > .AC.AT> > > > 01/02/2004 03:39 > PM > Please respond to > MQSeries List > > > > > > > Stillthe unanswered question > > Why the 2102 Is something looping. I cannot see why insufficient access > authority would generate this type of error. It seems there is an > unresolved > bug. > > About 2 months ago there was a discussin on the +inq for the JMS stuff and > if I remember correctly the person at that time was not getting a 2102. > > > bobbee > > > >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > >Date: Fri, 2 Jan 2004 13:40:13 -0600 > > > >When this happened to us, my developers were not printing the linked JMS > >exception so I did not have a reason code to look at. If I had been given > >a > >2102, it sure would have thrown me off! I like to keep the events turned > >on > >so when I was presented with the problem I very quickly found an event > >message showing the UserID, the QMgr INQ call and a 2035.
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben "Wyatt, T. Rob" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] C.AT> 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM>cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked JMS >exception so I did not have a reason code to look at. If I had been given >a >2102, it sure would have thrown me off! I like to keep the events turned >on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening inside the >Java >classes and not in his code. We have since learned that Java will inquire >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it >has to back out a GET. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 2:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi Rob, > >Great ! Your tip on adding inq right to non-mqm users did the trick. Here >is the setmqaut command: > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > >But how did you know that a JMS appl needs inq right to the qmgr to >establish connection? I didn't find such information on the JMS manual. > >thanks a lot for t
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM>cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked JMS >exception so I did not have a reason code to look at. If I had been given >a >2102, it sure would have thrown me off! I like to keep the events turned >on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening inside the >Java >classes and not in his code. We have since learned that Java will inquire >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it >has to back out a GET. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 2:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi Rob, > >Great ! Your tip on adding inq right to non-mqm users did the trick. Here >is the setmqaut command: > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > >But how did you know that a JMS appl needs inq right to the qmgr to >establish connection? I didn't find such information on the JMS manual. > >thanks a lot for the insight ! > >Ben > > > > > > > > "Wyatt, T. Rob" > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > MERICA.COM> cc: > Sent by: MQSeriesSubject: Re: Puzzled: >MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/02/2004 12:44 PM > Please respond to > MQSeries List > > > > > > >Benjamin, > >Are the classpaths the same between the two UserIDs? If you are on Unix, >try > >echo $CLASSPATH | tr ":" "\n" > >...from each user's command line and compare. There are generally two >types >of problems that manifest themselves differently under different users - >security, which you covered, and environment. > >Incidentally, you did not mention whether you gave the user Inquire on the >QMgr and queues. JMS will inquire the QMgr right after connecting. This >usually generates 2035's though. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 11:48 AM >To: [EMAIL PROTECTED] >Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi, > >first, happy new year to everyone. > >while trouble-shooting a WAS application's MQRC2102 problem, I wrote a >simple jms program to put msg to a queue. > >The program runs without problem if I start it as "mqm", but if I logon as >a different user than mqm, got the same MQJE001, MQRC 2102 exception. >I explicitely allowed that user the right to connect to the same qmgr and >put/get to the queues, and run the sample executible amqsput, amqsget >without any problem. > >
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Rob, Great ! Your tip on adding inq right to non-mqm users did the trick. Here is the setmqaut command: setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq But how did you know that a JMS appl needs inq right to the qmgr to establish connection? I didn't find such information on the JMS manual. thanks a lot for the insight ! Ben "Wyatt, T. Rob" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] C.AT> 01/02/2004 12:44 PM Please respond to MQSeries List Benjamin, Are the classpaths the same between the two UserIDs? If you are on Unix, try echo $CLASSPATH | tr ":" "\n" ...from each user's command line and compare. There are generally two types of problems that manifest themselves differently under different users - security, which you covered, and environment. Incidentally, you did not mention whether you gave the user Inquire on the QMgr and queues. JMS will inquire the QMgr right after connecting. This usually generates 2035's though. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:48 AM To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 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
Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 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: ms03 on MQ5.3 on Win2k problem
Hi all, thank everyone for the insight ! it showed again that one tends to see things more complicated than they really are, esp when he has dived into them. I was actually looking into the source code for clues. It turned out to be a single SYSTEM.DEAD.LETTER.QUEUE was damaged in one of our production boxes. cheers, Ben "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RTFORD.COM> Subject: Re: ms03 on MQ5.3 on Win2k problem Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 12/04/2003 11:18 AM Please respond to MQSeries List Look at all the queues in MQExplorer. The damaged one will have a funky little icon next to it. (At least it did the last couple of times I had the problem here.) -Original Message----- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 9:56 AM To: [EMAIL PROTECTED] Subject: ms03 on MQ5.3 on Win2k problem Hi, when we run saveqmgr compiled for v5.3 on one of our Win2K boxes with MQ5.3, we got the following message: . Queue definitions written to qmgr.mqs Skipping dynamic queue QMGR.REPLY.3FAC799201780120 Skipping dynamic queue SAVEQMGR.3FAC799201790120 Got bad PCF response message Type = 2 StrucLength = 36 Version = 1 Command = 13 MsgSeqNumber = 24 Control = 0 CompCode = 2 Reason = 2101 ParameterCount = 1 The RC 2101 means OBJECT_DAMAGED. But I can't figure out which one. Has anyone experienced this before? Is there a way to check each individual objects within a queue manager for damage? thanks for any idea. Benjamin F. Zhou Messaging & Integration Mercedes-Benz USA x.2474 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
Re: ms03 on MQ5.3 on Win2k problem
Just find out, we were using an older version which didn't identify damaged objects. I will rebuild it with the newer source code and see what happen. thanks, (Embedded image moved to file: pic26452.pcx) Benjamin Zhou To: MQSeries List <[EMAIL PROTECTED]> 12/04/2003 09:55 cc: AM Subject: ms03 on MQ5.3 on Win2k problem(Document link: Benjamin Zhou) Hi, when we run saveqmgr compiled for v5.3 on one of our Win2K boxes with MQ5.3, we got the following message: . Queue definitions written to qmgr.mqs Skipping dynamic queue QMGR.REPLY.3FAC799201780120 Skipping dynamic queue SAVEQMGR.3FAC799201790120 Got bad PCF response message Type = 2 StrucLength = 36 Version = 1 Command = 13 MsgSeqNumber = 24 Control = 0 CompCode = 2 Reason = 2101 ParameterCount = 1 The RC 2101 means OBJECT_DAMAGED. But I can't figure out which one. Has anyone experienced this before? Is there a way to check each individual objects within a queue manager for damage? thanks for any idea. Benjamin F. Zhou Messaging & Integration Mercedes-Benz USA x.2474 pic26452.pcx Description: Binary data
ms03 on MQ5.3 on Win2k problem
Hi, when we run saveqmgr compiled for v5.3 on one of our Win2K boxes with MQ5.3, we got the following message: . Queue definitions written to qmgr.mqs Skipping dynamic queue QMGR.REPLY.3FAC799201780120 Skipping dynamic queue SAVEQMGR.3FAC799201790120 Got bad PCF response message Type = 2 StrucLength = 36 Version = 1 Command = 13 MsgSeqNumber = 24 Control = 0 CompCode = 2 Reason = 2101 ParameterCount = 1 The RC 2101 means OBJECT_DAMAGED. But I can't figure out which one. Has anyone experienced this before? Is there a way to check each individual objects within a queue manager for damage? thanks for any idea. Benjamin F. Zhou Messaging & Integration Mercedes-Benz USA x.2474 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: Scheduling Message Flows-WMQI2.1
Great idea! But wouldn't it be better to let the script to start the msgflow instead? otherwise, an inhabited queue will cause your running msgflow to write large number of errors to the system log for unable to open the queue. Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 "RodrÃguez Alvarez-Querol, To: [EMAIL PROTECTED] Manuel Carlos" cc: <[EMAIL PROTECTED] Subject: Re: Scheduling Message Flows-WMQI2.1 RE.COM> Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 11/19/2003 05:20 AM Please respond to MQSeries List Suppose: Flow A is reading from Q.A. Your application puts messages in queue B. When a message is received in queue B the flow A will start processing messages. A possible solution: Inhibit get in Q.A Trigger queue B to start a script. This script should allow the get in Q.A > -Mensaje original- > De: Juni Per [SMTP:[EMAIL PROTECTED] > Enviado el: Wednesday, 19 November, 2003 10:32 > Para: [EMAIL PROTECTED] > Asunto: Scheduling Message Flows-WMQI2.1 > > Hi , > > Is there some way I can schedule message flows ?The input node is always > constantly looking for messages in a queue and grabs it . > But if I want have a message flow 'A' , to start only after I receive a > message from a certain application in another queue , what do I do?? > > _ > > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > <http://antispam.yahoo.com/whatsnewfree> 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: Invalid CCSID from WIN 2000 client to Z/OS
I dimmly remember MQ on z/os doesn't support "receiver gets it right", I could be wrong. But, if that's the case, you'll need to set your NT sending MCA definition to convert=yes. cheers, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Nushi Mehr <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .COM>cc: Sent by: Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 11/18/2003 12:49 PM Please respond to MQSeries List Thanks for your reply. I am not using ACTIVE X i AM USING Power Builder compiling C code. Iam thinking may be is the MQ library that I am using. I use MQIC32.LIB and maybe I should use MQM.LIB. How ever when we use MQM.LIB we get connection problem with MQCONN. Neil Casey <[EMAIL PROTECTED]> wrote: I don't know why your message is not getting converted. CP437 is US ASCII, which would be the code page of your PC. Are you certain that you are attempting to convert the incoming message. It may be that you should create the original message in CodePage 500 (International EBCDIC). The MQ Automation Classes for ActiveX provide methods for performing this conversion on message data as it is created or retrieved. The correct settings for the MQMD.Format and MQCIH.Format depends upon whether you are trying to drive the 3270 bridge or the DPL bridge. Possible values for the MQCIH.Format would be CSQCBDCI to drive conversion of 3270 map data, or MQSTR for character only DPL data. I haven't tried any of the conversion options with the CICS bridge. Regards, Neil Casey |-+> | | Nushi Mehr | | | | | COM> | | | Sent by: MQSeries| | | List | | | | | n.AC.AT> | | | | | | | | | 18/11/2003 09:27 | | | Please respond to| | | MQSeries List | | | | |-+> > --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS | > --| Thank you so much for your reply, I do exactly what you are saying regarding the mqmd, mqcih format. But it is not converting. I am not sure I might have to apply the PTF UQ76248, UQ76249. Any ideas ? Neil Casey wrote: Hello, MQSeries does not in general support conversion of CICS bridge datastreams, although conversion is possible in some specific instances. Look at the WebSphere MQ Application Programming Guide, Chapter 17, Under heading Programming for the Distributed Environment. It basically says that you need to ensure that your message is already in the correct CCSID for CICS (which in your case seems to be CCSID 500). If your message data is pure text, then you can achieve conversion by specifying a MQCIH.Format of MQString. Otherwise, you need to build the data stream in EBCDIC and/or mainframe binary data formats, and correctly set the Format and CCSID fields in the headers. The actual text from the manual is: Programming for th e distributed environment CICS DPL programs and transactions can be driven through the CICS bridge when the client application resides on a workstation. The main consideration when programming for the distributed environment is data conversion between the different encoding schemes and CCSID values of the workstation and z/OS. Conversion is carried out by two different routines, one for the MQCIH structure and another for the vector. You can ensure that conversion of the MQCIH is achieved by specifying MQFMT_CICS in the MQMD.Format field. Vector conversion, however, requires a little more consideration. CICS transactions in the distributed environment Conversion is only supported by the CICS bridge for the outbound SEND MAP and RECEIVE MAP request vectors, and for the inbound RECEIVE MAP vector. To achieve conversion of the SEND MAP and RECEIVE MAP vectors, do this: Make sure that you ass emble your maps specifying DSECT=ADSDL in your DFHMSD macro. Your map must be assembled under CICS Transaction Server for OS/390 Version 1.2 or greater for the ADSD or ADSDL to be made available. If you do not have the original mapset definition, recreate the map using the CICS DFHBMSUP utility. Specify a value of MQCADSD_SEND+MQCADSD_MSGFORMAT in field MQCIH.ADSDescriptor. If you are usin
Re: MQ Channel KeepAlive not working on os/390
Hi Morag, thanks for the clarification. Too bad that the manuals on this subject is not very clear. I'll check that setting with our mainframe programmer. best regards, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Morag Hughson <[EMAIL PROTECTED] To: [EMAIL PROTECTED] COM> cc: Sent by: Subject: MQ Channel KeepAlive not working on os/390 MQSeries List <[EMAIL PROTECTED] en.AC.AT> 11/12/2003 03:47 PM Please respond to MQSeries List I agree with you that the Intercomms guide and MQSC book could both do with an addition something along the lines of that which is in the System Setup Guide, thus:- TCPKEEP Specifies whether the TCP KEEPALIVE facility, as specified by the KEEPALIVEOPTIONS statement in the TCP profile configuration data set, is to be used. If it is used, the interval is specified by the channel attribute KeepAliveInterval (KAINT). TCPIP Keepalive is a TCPIP feature and requires the overall TCPIP keepalive to be switched on. What it does not require you to do is change the overall system timeout value. That can be left at 2 hours, or whatever it is on your system. It must be switched on though. I will look into getting the other books updated with this information Cheers Morag Morag Hughson (Miss) WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] -- HI, as Morag suggested below and in his article. I set the KEEPALIVE to YES in the CSQ6CHIP macro for the queue manager, set KEEP ALIVE INTERVAL to 120 seconds, HBINT to 300 seconds so it doesn't interfere with the test. I did the same on the sending side of the channel on AIX, and set DISCINT to 6000 seconds; I started the channel by sending a message to a remote queue, saw the channel running, then pulled the network cable from the AIX box. However, after over 60 minutes, the rcvr channel on os/390 is still in RUN status. Apparently, not even the heartbeat interval is functioning as described in Horag's document page 19-20. It was my understanding before that with network interrupted, HBINT and DISCINT won't work. But Horag's article suggested otherwise, and said heartbeat interval is used to detect network failure, which is more plausible than my initial understanding. The manual also implies that on os/390 (z/os), TCPIP KeepAlive KAINT is mqseries specific so there is no need to reconfigure KeepAlive for the system's overall TCPIP settting. Am I wrong on this? Has anyone tested this attribute on os/390? best regards, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Morag Hughson <[EMAIL PROTECTED] To: [EMAIL PROTECTED] COM> cc: Sent by: Subject: Re: MQ Channel KeepAlive not working on MVS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/30/2003 06:06 AM Please respond to MQSeries List Ensure that you have TCPKEEP=YES set in your channel initiator parameters (CSQXPARM built from CSQ6CHIP Macro) and also ensure that KeepAlive is set on in your TCP/IP settings. Quick plug for new SupportPac MA0C http://www-3.ibm.com/software/integration/support/supportpacs/individual/md0c.html See page 25-26 for keepalive details. Also see the Intercommunication guide, Chapter 6. Channel Attributes Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] -- Hi, on MVS, Keep Alive Interval is a channel attribute. To test its effectiveness, I set it to 30 seconds on a receiving MCA on mainframe, start the channel, then unplug the network cable from the sending side (AIX box), hoping the status of the receiving MCA on mainframe will become inactive in about 30 seconds. But it didn't. I keep the cable off for 5 minutes, the receiving MCA is still in running status. (Note, to remove the influence of HBINT and discint in the test, I set them both to very large values) However, after I plug the cable back, the sending channel goes into healthy running state right away. I tested the same on NT machines. there, after 30 seconds, the receiving side becomes inactive and ready to be restarted. This is what I had expected based on my knowledge on TCP/
Re: MQ Channel KeepAlive not working on os/390
Hi Peter, Yes, not only that, we restarted the queue manager. best regards,, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RTFORD.COM> Subject: Re: MQ Channel KeepAlive not working on os/390 Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 11/12/2003 03:28 PM Please respond to MQSeries List Did you stop and restart the channel after changing that attribute? -Original Message----- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 3:05 PM To: [EMAIL PROTECTED] Subject: MQ Channel KeepAlive not working on os/390 HI, as Morag suggested below and in his article. I set the KEEPALIVE to YES in the CSQ6CHIP macro for the queue manager, set KEEP ALIVE INTERVAL to 120 seconds, HBINT to 300 seconds so it doesn't interfere with the test. I did the same on the sending side of the channel on AIX, and set DISCINT to 6000 seconds; I started the channel by sending a message to a remote queue, saw the channel running, then pulled the network cable from the AIX box. However, after over 60 minutes, the rcvr channel on os/390 is still in RUN status. Apparently, not even the heartbeat interval is functioning as described in Horag's document page 19-20. It was my understanding before that with network interrupted, HBINT and DISCINT won't work. But Horag's article suggested otherwise, and said heartbeat interval is used to detect network failure, which is more plausible than my initial understanding. The manual also implies that on os/390 (z/os), TCPIP KeepAlive KAINT is mqseries specific so there is no need to reconfigure KeepAlive for the system's overall TCPIP settting. Am I wrong on this? Has anyone tested this attribute on os/390? best regards, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Morag Hughson <[EMAIL PROTECTED] To: [EMAIL PROTECTED] COM> cc: Sent by: Subject: Re: MQ Channel KeepAlive not working on MVS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/30/2003 06:06 AM Please respond to MQSeries List Ensure that you have TCPKEEP=YES set in your channel initiator parameters (CSQXPARM built from CSQ6CHIP Macro) and also ensure that KeepAlive is set on in your TCP/IP settings. Quick plug for new SupportPac MA0C http://www-3.ibm.com/software/integration/support/supportpacs/individual/md0 c.html See page 25-26 for keepalive details. Also see the Intercommunication guide, Chapter 6. Channel Attributes Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] -- Hi, on MVS, Keep Alive Interval is a channel attribute. To test its effectiveness, I set it to 30 seconds on a receiving MCA on mainframe, start the channel, then unplug the network cable from the sending side (AIX box), hoping the status of the receiving MCA on mainframe will become inactive in about 30 seconds. But it didn't. I keep the cable off for 5 minutes, the receiving MCA is still in running status. (Note, to remove the influence of HBINT and discint in the test, I set them both to very large values) However, after I plug the cable back, the sending channel goes into healthy running state right away. I tested the same on NT machines. there, after 30 seconds, the receiving side becomes inactive and ready to be restarted. This is what I had expected based on my knowledge on TCP/IP KeepAlive. But why is it different on MVS? Is anyone working on mainframe aware of this? Can you offer some explanation? thanks, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 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
MQ Channel KeepAlive not working on os/390
HI, as Morag suggested below and in his article. I set the KEEPALIVE to YES in the CSQ6CHIP macro for the queue manager, set KEEP ALIVE INTERVAL to 120 seconds, HBINT to 300 seconds so it doesn't interfere with the test. I did the same on the sending side of the channel on AIX, and set DISCINT to 6000 seconds; I started the channel by sending a message to a remote queue, saw the channel running, then pulled the network cable from the AIX box. However, after over 60 minutes, the rcvr channel on os/390 is still in RUN status. Apparently, not even the heartbeat interval is functioning as described in Horag's document page 19-20. It was my understanding before that with network interrupted, HBINT and DISCINT won't work. But Horag's article suggested otherwise, and said heartbeat interval is used to detect network failure, which is more plausible than my initial understanding. The manual also implies that on os/390 (z/os), TCPIP KeepAlive KAINT is mqseries specific so there is no need to reconfigure KeepAlive for the system's overall TCPIP settting. Am I wrong on this? Has anyone tested this attribute on os/390? best regards, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Morag Hughson <[EMAIL PROTECTED] To: [EMAIL PROTECTED] COM> cc: Sent by: Subject: Re: MQ Channel KeepAlive not working on MVS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/30/2003 06:06 AM Please respond to MQSeries List Ensure that you have TCPKEEP=YES set in your channel initiator parameters (CSQXPARM built from CSQ6CHIP Macro) and also ensure that KeepAlive is set on in your TCP/IP settings. Quick plug for new SupportPac MA0C http://www-3.ibm.com/software/integration/support/supportpacs/individual/md0c.html See page 25-26 for keepalive details. Also see the Intercommunication guide, Chapter 6. Channel Attributes Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] -- Hi, on MVS, Keep Alive Interval is a channel attribute. To test its effectiveness, I set it to 30 seconds on a receiving MCA on mainframe, start the channel, then unplug the network cable from the sending side (AIX box), hoping the status of the receiving MCA on mainframe will become inactive in about 30 seconds. But it didn't. I keep the cable off for 5 minutes, the receiving MCA is still in running status. (Note, to remove the influence of HBINT and discint in the test, I set them both to very large values) However, after I plug the cable back, the sending channel goes into healthy running state right away. I tested the same on NT machines. there, after 30 seconds, the receiving side becomes inactive and ready to be restarted. This is what I had expected based on my knowledge on TCP/IP KeepAlive. But why is it different on MVS? Is anyone working on mainframe aware of this? Can you offer some explanation? thanks, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 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: MQ Channel KeepAlive not working on MVS
Hi Morag, great document ! both comprehensive and enlightened. Best regards, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Morag Hughson <[EMAIL PROTECTED] To: [EMAIL PROTECTED] COM> cc: Sent by: Subject: Re: MQ Channel KeepAlive not working on MVS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 10/30/2003 06:06 AM Please respond to MQSeries List Ensure that you have TCPKEEP=YES set in your channel initiator parameters (CSQXPARM built from CSQ6CHIP Macro) and also ensure that KeepAlive is set on in your TCP/IP settings. Quick plug for new SupportPac MA0C http://www-3.ibm.com/software/integration/support/supportpacs/individual/md0c.html See page 25-26 for keepalive details. Also see the Intercommunication guide, Chapter 6. Channel Attributes Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] -- Hi, on MVS, Keep Alive Interval is a channel attribute. To test its effectiveness, I set it to 30 seconds on a receiving MCA on mainframe, start the channel, then unplug the network cable from the sending side (AIX box), hoping the status of the receiving MCA on mainframe will become inactive in about 30 seconds. But it didn't. I keep the cable off for 5 minutes, the receiving MCA is still in running status. (Note, to remove the influence of HBINT and discint in the test, I set them both to very large values) However, after I plug the cable back, the sending channel goes into healthy running state right away. I tested the same on NT machines. there, after 30 seconds, the receiving side becomes inactive and ready to be restarted. This is what I had expected based on my knowledge on TCP/IP KeepAlive. But why is it different on MVS? Is anyone working on mainframe aware of this? Can you offer some explanation? thanks, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 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
MQ Channel KeepAlive not working on MVS
Hi, on MVS, Keep Alive Interval is a channel attribute. To test its effectiveness, I set it to 30 seconds on a receiving MCA on mainframe, start the channel, then unplug the network cable from the sending side (AIX box), hoping the status of the receiving MCA on mainframe will become inactive in about 30 seconds. But it didn't. I keep the cable off for 5 minutes, the receiving MCA is still in running status. (Note, to remove the influence of HBINT and discint in the test, I set them both to very large values) However, after I plug the cable back, the sending channel goes into healthy running state right away. I tested the same on NT machines. there, after 30 seconds, the receiving side becomes inactive and ready to be restarted. This is what I had expected based on my knowledge on TCP/IP KeepAlive. But why is it different on MVS? Is anyone working on mainframe aware of this? Can you offer some explanation? thanks, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 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
